linux-ext4 - Re: [PATCH 02/17] ext4: Add fs parameter description

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20191217121956.amsymslmuoy6kzu4@work>
Date:   Tue, 17 Dec 2019 13:19:56 +0100
From:   Lukas Czerner <lczerner@...hat.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     linux-ext4@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 02/17] ext4: Add fs parameter description

On Tue, Dec 17, 2019 at 12:44:19AM +0000, Al Viro wrote:
> On Wed, Nov 06, 2019 at 11:14:42AM +0100, Lukas Czerner wrote:
> > +	fsparam_string_empty
> > +			("usrjquota",		Opt_usrjquota),
> > +	fsparam_string_empty
> > +			("grpjquota",		Opt_grpjquota),
> 
> Umm...  That makes ...,usrjquota,... equivalent to ...,usrjquota=,...
> unless I'm misreading the series.  Different from mainline, right?

Unfortunatelly yes, I do not think this is a problem, but if you have a
solution within the new mount api framework I am happy to use it.

> 
> > +	fsparam_bool	("barrier",		Opt_barrier),
> > +	fsparam_flag	("nobarrier",		Opt_nobarrier),
> 
> That's even more interesting.  Current mainline:
> 		barrier		OK, sets EXT4_MOUNT_BARRIER
> 		barrier=0	OK, sets EXT4_MOUNT_BARRIER
> 		barrier=42	OK, sets EXT4_MOUNT_BARRIER
> 		barrier=yes	error
> 		barrier=no	error
> 		nobarrier	OK, clears EXT4_MOUNT_BARRIER
> Unless I'm misreading your series, you get
> 		barrier		error

Not really, this seems to be working as expected. Assuming that this
didn't change since 5.4.0-rc6. I does make sense to me that specifying
bool type parameter without any options would express "true".


> 		barrier=0	OK, sets EXT4_MOUNT_BARRIER


> 		barrier=42	error
> 		barrier=yes	OK, sets EXT4_MOUNT_BARRIER
> 		barrier=no	OK, sets EXT4_MOUNT_BARRIER

Those three are different, just because of how param_book() work. I do
not really see a problem with it, but if we want to keep it exactly the
same as current mainline it would be difficult with how the current api
works. Any suggestions ?

Thanks!
-Lukas

> 		nobarrier	OK, clears EXT4_MOUNT_BARRIER
> 
> Granted, mainline behaviour is... unintuitive, to put it mildly,
> but the replacement is just as strange _and_ incompatible with the
> existing one.
> 
> Am I missing something subtle there?
>