On Fri, Apr 27, 2018 at 11:56 AM, David Sterba <dste...@suse.cz> wrote: > On Thu, Apr 26, 2018 at 03:23:49PM -0400, je...@suse.com wrote: >> From: Jeff Mahoney <je...@suse.com> >> >> Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization) >> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but >> ended up reintroducing the hang-on-unmount bug that the commit it >> intended to fix addressed. >> >> The race this time is between qgroup_rescan_init setting >> ->qgroup_rescan_running = true and the worker starting. There are >> many scenarios where we initialize the worker and never start it. The >> completion btrfs_ioctl_quota_rescan_wait waits for will never come. >> This can happen even without involving error handling, since mounting >> the file system read-only returns between initializing the worker and >> queueing it. >> >> The right place to do it is when we're queuing the worker. The flag >> really just means that btrfs_ioctl_quota_rescan_wait should wait for >> a completion. >> >> This patch introduces a new helper, queue_rescan_worker, that handles >> the ->qgroup_rescan_running flag, including any races with umount. >> >> While we're at it, ->qgroup_rescan_running is protected only by the >> ->qgroup_rescan_mutex. btrfs_ioctl_quota_rescan_wait doesn't need >> to take the spinlock too. >> >> Fixes: d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization) >> Signed-off-by: Jeff Mahoney <je...@suse.com> > > I've added this to misc-next as I'd like to push it to the next rc. The > Fixes is fixed. >
I don't see it pushed to misc-next yet, but based on f89fbcd776, could you update the reference in the first line of the commit to match the Fixes line? Thanks, Noah -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
