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
| ||
|
Date: Sat, 21 Apr 2018 19:53:52 -0700 From: "Luis R. Rodriguez" <mcgrof@...nel.org> To: Jan Kara <jack@...e.cz> Cc: "Luis R. Rodriguez" <mcgrof@...nel.org>, viro@...iv.linux.org.uk, bart.vanassche@....com, ming.lei@...hat.com, tytso@....edu, darrick.wong@...cle.com, jikos@...nel.org, rjw@...ysocki.net, pavel@....cz, len.brown@...el.com, linux-fsdevel@...r.kernel.org, boris.ostrovsky@...cle.com, jgross@...e.com, todd.e.brandt@...ux.intel.com, nborisov@...e.com, martin.petersen@...cle.com, ONeukum@...e.com, oleksandr@...alenko.name, oleg.b.antonyan@...il.com, yu.chen.surf@...il.com, dan.j.williams@...el.com, linux-pm@...r.kernel.org, linux-block@...r.kernel.org, linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 03/11] fs: add frozen sb state helpers On Thu, Nov 30, 2017 at 06:13:10PM +0100, Jan Kara wrote: > On Wed 29-11-17 15:23:48, Luis R. Rodriguez wrote: > > The question of whether or not a superblock is frozen needs to be > > augmented in the future to account for differences between a user > > initiated freeze and a kernel initiated freeze done automatically > > on behalf of the kernel. > > > > Provide helpers so that these can be used instead so that we don't > > have to expand checks later in these same call sites as we expand > > the definition of a frozen superblock. > > > > Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org> > > So helpers are fine but... > > > +/** > > + * sb_is_frozen_by_user - is superblock frozen by a user call > > + * @sb: the super to check > > + * > > + * Returns true if the super freeze was initiated by userspace, for instance, > > + * an ioctl call. > > + */ > > +static inline bool sb_is_frozen_by_user(struct super_block *sb) > > +{ > > + return sb->s_writers.frozen == SB_FREEZE_COMPLETE; > > +} > > ... I dislike the _by_user() suffix as there may be different places that > call freeze_super() (e.g. device mapper does this during some operations). > Clearly we need to distinguish "by system suspend" and "the other" cases. > So please make this clear in the naming. > > In fact, what might be a cleaner solution is to introduce a 'freeze_count' > for superblock freezing (we already do have this for block devices). Then > you don't need to differentiate these two cases - but you'd still need to > properly handle cleanup if freezing of all superblocks fails in the middle. > So I'm not 100% this works out nicely in the end. But it's certainly worth > a consideration. Seems reasonable. Luis
Powered by blists - more mailing lists