linux-kernel - Re: [PATCH 1/5] kernfs: implement i

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]

Date:   Wed, 24 May 2017 10:40:00 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Shaohua Li <shli@...com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        linux-kernel@...r.kernel.org, tj@...nel.org,
        gregkh@...uxfoundation.org, viro@...iv.linux.org.uk,
        Kernel-team@...com
Subject: Re: [PATCH 1/5] kernfs: implement i_generation

On Tue, May 23, 2017 at 08:09:48AM -0700, Shaohua Li wrote:
> > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
> > > index db5900aaa..09d093e 100644
> > > --- a/fs/kernfs/dir.c
> > > +++ b/fs/kernfs/dir.c
> > > @@ -634,6 +634,7 @@ static struct kernfs_node *__kernfs_new_node(struct kernfs_root *root,
> > >  	if (ret < 0)
> > >  		goto err_out2;
> > >  	kn->ino = ret;
> > > +	kn->generation = atomic_inc_return(&root->next_generation);
> > 
> > i_generation is only supposed to be valid on a per-inode basis, so this
> > global counter seems really odd.
> 
> What's the difference between per-inode or per-super? The i_generation doesn't
> need to be consecutive for an inode. I checked other fs, a lot of filesystems
> implement i_generation in this way, for example, f2fs, ext4.

of course per-sb is a valid implementation, but it seems like
introducing an easily avoidable bottleneck by serializing on a per-sb
cacheline for each file creation.  But then again it seems like kernfs
already has various other per-sb contention points, so maybe it's not
an issue in the end.