On 5/2/18 9:15 AM, David Sterba wrote:
> On Wed, May 02, 2018 at 12:29:28PM +0200, David Sterba wrote:
>> On Thu, Apr 26, 2018 at 03:23:49PM -0400, je...@suse.com wrote:
>>> From: Jeff Mahoney <je...@suse.com>
>>> +static void queue_rescan_worker(struct btrfs_fs_info *fs_info)
>>> +{
>>> + mutex_lock(&fs_info->qgroup_rescan_lock);
>>> + if (btrfs_fs_closing(fs_info)) {
>>> + mutex_unlock(&fs_info->qgroup_rescan_lock);
>>> + return;
>>> + }
>>> + if (WARN_ON(fs_info->qgroup_rescan_running)) {
>>
>> The warning is quite noisy, I see it after tests btrfs/ 017, 022, 124,
>> 139, 153. Is it necessary for non-debugging builds?
>>
>> The tested branch was full for-next so it could be your patchset
>> interacting with other fixes, but the warning noise level question still
>> stands.
>
> So it must be something with the rest of misc-next or for-next patches,
> current for 4.17 queue does show the warning at all, and the patch is ok
> for merge.
>
You might have something that causes it to be more noisy but it looks
like it should be possible to hit on 4.16. The warning is supposed to
detect and complain about multiple rescan threads starting. What I
think it's doing here is (correctly) identifying a different race: at
the end of btrfs_qgroup_rescan_worker, we clear the rescan status flag,
drop the lock, commit the status item transaction, and then update
->qgroup_rescan_running. If a rescan is requested before the lock is
reacquired, we'll try to start it up and then hit that warning.
So, the warning is doing its job. Please hold off on merging this patch.
IMO the root cause is overloading fs_info->qgroup_flags to correspond to
the on-disk item and control runtime behavior. I've been meaning to fix
that for a while, so I'll do that now.
-Jeff
--
Jeff Mahoney
SUSE Labs
--
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
