linux-kernel - Re: [PATCH] btrfs: resume qgroup rescan on rw remount

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170711170335.GV2866@twin.jikos.cz>
Date:   Tue, 11 Jul 2017 19:03:35 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Nikolay Borisov <nborisov@...e.com>
Cc:     Aleksa Sarai <asarai@...e.de>, Chris Mason <clm@...com>,
        Josef Bacik <jbacik@...com>, David Sterba <dsterba@...e.com>,
        linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Jeff Mahoney <jeffm@...e.com>
Subject: Re: [PATCH] btrfs: resume qgroup rescan on rw remount

On Mon, Jul 10, 2017 at 04:56:36PM +0300, Nikolay Borisov wrote:
> On 10.07.2017 16:12, Nikolay Borisov wrote:
> > On  4.07.2017 14:49, Aleksa Sarai wrote:
> >> Several distributions mount the "proper root" as ro during initrd and
> >> then remount it as rw before pivot_root(2). Thus, if a rescan had been
> >> aborted by a previous shutdown, the rescan would never be resumed.
> >>
> >> This issue would manifest itself as several btrfs ioctl(2)s causing the
> >> entire machine to hang when btrfs_qgroup_wait_for_completion was hit
> >> (due to the fs_info->qgroup_rescan_running flag being set but the rescan
> >> itself not being resumed). Notably, Docker's btrfs storage driver makes
> >> regular use of BTRFS_QUOTA_CTL_DISABLE and BTRFS_IOC_QUOTA_RESCAN_WAIT
> >> (causing this problem to be manifested on boot for some machines).
> >>
> >> Cc: <stable@...r.kernel.org> # v3.11+
> >> Cc: Jeff Mahoney <jeffm@...e.com>
> >> Fixes: b382a324b60f ("Btrfs: fix qgroup rescan resume on mount")
> >> Signed-off-by: Aleksa Sarai <asarai@...e.de>
> > 
> > Indeed, looking at the code it seems that b382a324b60f ("Btrfs: fix
> > qgroup rescan resume on mount") missed adding the qgroup_rescan_resume
> > in the remount path. One thing which I couldn't verify though is whether
> > reading fs_info->qgroup_flags without any locking is safe from remount
> > context.
> > 
> > During remount I don't see any locks taken that prevent operations which
> > can modify qgroup_flags.
> 
> Further inspection reveals that the access rules to qgroup_flags are
> somewhat broken so this patch doesn't really make things any worse than
> they are.

The usage follows a pattern for a bitfield, updated by set_bit/clear_bit
etc. The updates to the state or inconsistency is not safe, so some
updates could get lost under some circumstances.

Patch added to devel queue, possibly will be submitted to 4.13 so stable
can pick it.