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: <CAOssrKcq5MRmN1NnywOxCx6366PY4R9auEeFOjgD1YURXHK0fg@mail.gmail.com>
Date:   Thu, 11 May 2017 10:11:06 +0200
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     David Howells <dhowells@...hat.com>,
        Jeff Layton <jlayton@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-nfs@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 14/14] Add commands to create or update a superblock

On Thu, May 11, 2017 at 9:38 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Wed, May 10, 2017 at 05:20:31PM +0100, David Howells wrote:
>
>> @@ -64,8 +70,8 @@ struct sb_config_operations {
>>       int (*parse_option)(struct sb_config *sc, char *p);
>>       int (*monolithic_mount_data)(struct sb_config *sc, void *data);
>>       int (*validate)(struct sb_config *sc);
>> -     struct dentry *(*mount)(struct sb_config *sc);
>> -     int (*fill_super)(struct super_block *s, struct sb_config *sc);
>> +     int (*create_super)(struct sb_config *sc);
>
> Hell, NO.
>
> The primary effect of that thing is *NOT* to create a superblock.  It
> might be a side effect, and quite often it will happen, but the
> real goal here is a mountable tree.  Which might or might not reside
> on a new superblock.  And which might very well involve no object
> creation whatsoever.
>
> This name is actively misleading and the same goes for its relatives
> (vfs_create_super(), etc.).  It's "give me a tree to mount", not
> "create something or other".

Indeed, I haven't thought of that.  And there's a good hornet's nest
waiting to poke ones hand into: mounting the same blockdev with
different options will get you either

 - EBUSY if the MS_* flags mismatch
 - silently ignored options in any other case

which is far from being nice and consistent.

Thanks,
Miklos

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ