On Fri, Nov 20, 2015 at 12:06:33PM -0800, Liu Bo wrote: > On Fri, Nov 20, 2015 at 09:57:49AM -0800, Liu Bo wrote: > > On Fri, Nov 20, 2015 at 08:13:58AM -0500, Chris Mason wrote: > > > On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote: > > > > while xfstesting, this bug[1] is spotted by both btrfs/061 and btrfs/063, > > > > so those sub-stripe writes are gatherred into plug callback list and > > > > hopefully we can have a full stripe writes. > > > > > > > > However, while processing these plugged callbacks, it's within an atomic > > > > context which is provided by blk_sq_make_request() because of a get_cpu() > > > > in blk_mq_get_ctx(). > > > > > > > > This changes to always use btrfs_rmw_helper to complete the pending writes. > > > > > > > > > > Thanks Liu, but MD raid has the same troubles, we're not atomic in our unplugs. > > > > Yeah, MD also does, but I don't see a way to change mq code at this > > stage.. > > Correct it: MD raid5_unplug runs stripes inside a pair of spinlock (conf->device_lock) and moreover, those writes will be forwarded to raid5d to finish the job. > > So md raid can run fine within atomic context. Check MD raid10 -chris -- 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
