linux-kernel - Re: [RFC] vfs: avoid sb->s_umount lock while changing bind-mount flags

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] [day] [month] [year] [list]

Message-ID: <CAGr1F2HF0sXD5Ejq3HN9YAtpeLqYJkZc=79+B=2XErj_Z_kufA@mail.gmail.com>
Date:	Mon, 30 Sep 2013 14:44:33 -0700
From:	Aditya Kali <adityakali@...gle.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Anatol Pomazau <anatol@...gle.com>,
	"Theodore Ts'o" <tytso@....edu>, tj@...nel.org, axboe@...nel.dk
Subject: Re: [RFC] vfs: avoid sb->s_umount lock while changing bind-mount flags

On Mon, Sep 30, 2013 at 1:03 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Mon, Sep 30, 2013 at 11:13:23AM -0700, Aditya Kali wrote:
>> +Ted Ts'o, Tejun Heo, Jens Axboe
>>
>>
>> On 09/30/2013 10:54 AM, Aditya Kali wrote:
>> >Hi Al and other fs-developers,
>> >
>> >Please let me know what you think about this patch.
>
> Don't top-post, please...  What prevents a race between MS_BIND remounts
> and plain ones?  Used to be serialized on ->s_umount, but...

The rational here is that MS_BIND remounts need to act on the bind
mount-point only (struct vfsmount *) and not on the underlying
superblock (struct super_block *). So, intuitively, it should not be
necessary to take a superblock level lock for the MS_BIND case. As for
the modification of mnt_flags on vfsmount, there is already
vfsmount_lock taken in both MS_BIND and non-MS_BIND case to prevent
the race.

Following is the example that demonstrates the problem that I am
trying to address with this patch:

(1) /dev/sda is mounted at /mnt/sda
(2) /mnt/sda/users/user1 is bind mounted at /home/user1/ ;
/mnt/sda/users/user2 is bind mounted at /home/user2/
(3) user1 is doing buffered writes in /home/user1/logs/
(4) admin tries to make /home/user2/bin/ read-only using a bind-mounts:
    $ mount --bind /home/user2/bin/ /home/user2/bin/    # this is fast
    $ mount --bind -o remount,ro /home/user2/bin/    # this blocks
behind any writeback happening on sda (because of sb->s_umount write
lock)

Please advise.

Thanks,
-- 
Aditya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/