On 06/14/2017 08:26 PM, David Sterba wrote:
On Wed, Jun 14, 2017 at 06:02:38PM +0800, Anand Jain wrote:
write_dev_flush() checks if the device is flush capable, however as
the device mode can change any time, this check should be after the
wait part of the code.
This would apply to code before "btrfs: wait part of the
write_dev_flush() can be separated out", right?
Yes.
The problematic case is when a flush bio is sent, queue status changes
and waiting is skipped. A bio would leak. Next time the flushing is
enabled, write_dev_flush allocaes a new bio and either it would leak or
waiting will happen as expected.
The bio would leak only if the barriers are switched between write and
wait. Not impossible, but I still think a race hard to win. The
consequences are not absolutely fatal.
Yeah more of a theoretical problem and hard to reproduce unless there
is a deliberate attempt.
Also, the cleanups in write_dev_flush fix the bug in another way, so we
don't need this separate patch as a potential stable backport. The patch
mentioned above can be considered a fix but would need some manual
adaptations to apply. Therefore I don't think we need the $subj patch.
Agreed. Kindly ignore this and the V2.2 of
[PATCH 3/3 v2.2] btrfs: wait part of the write_dev_flush()...
patch as well.
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
