On 3.05.2018 00:11, jeffm@xxxxxxxx wrote: > From: Jeff Mahoney <jeffm@xxxxxxxx> > > Hi Dave - > > Here's the updated patchset for the rescan races. This fixes the issue > where we'd try to start multiple workers. It introduces a new "ready" > bool that we set during initialization and clear while queuing the worker. > The queuer is also now responsible for most of the initialization. > > I have a separate patch set start that gets rid of the racy mess surrounding > the rescan worker startup. We can handle it in btrfs_run_qgroups and > just set a flag to start it everywhere else. I'd be interested in seeing those patches. Some time ago I did send a patch which cleaned up the way qgroup rescan was initiated. It was done from "btrfs_run_qgroups" and I think this is messy. Whatever we do we ought to really have well-defined semantics when qgroups rescan are run, preferably we shouldn't be conflating rescan + run (unless there is _really_ good reason to do). In the past the rescan from scan was used only during qgroup enabling. > > -Jeff > > --- > > Jeff Mahoney (3): > btrfs: qgroups, fix rescan worker running races > btrfs: qgroups, remove unnecessary memset before btrfs_init_work > btrfs: qgroup, don't try to insert status item after ENOMEM in rescan > worker > > fs/btrfs/async-thread.c | 1 + > fs/btrfs/ctree.h | 2 + > fs/btrfs/qgroup.c | 100 +++++++++++++++++++++++++++--------------------- > 3 files changed, 60 insertions(+), 43 deletions(-) > -- 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
