[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <352f587fe4e24a8bea5f841b5f93df92164072d0.camel@themaw.net>
Date: Sun, 20 Dec 2020 09:37:42 +0800
From: Ian Kent <raven@...maw.net>
To: Tejun Heo <tj@...nel.org>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Fox Chen <foxhlchen@...il.com>, akpm@...ux-foundation.org,
dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, miklos@...redi.hu,
ricklind@...ux.vnet.ibm.com, sfr@...b.auug.org.au,
viro@...iv.linux.org.uk
Subject: Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency
improvement
On Sun, 2020-12-20 at 07:52 +0800, Ian Kent wrote:
> On Sat, 2020-12-19 at 11:23 -0500, Tejun Heo wrote:
> > Hello,
> >
> > On Sat, Dec 19, 2020 at 03:08:13PM +0800, Ian Kent wrote:
> > > And looking further I see there's a race that kernfs can't do
> > > anything
> > > about between kernfs_refresh_inode() and
> > > fs/inode.c:update_times().
> >
> > Do kernfs files end up calling into that path tho? Doesn't look
> > like
> > it to
> > me but if so yeah we'd need to override the update_time for kernfs.
You are correct, update_time() will only be called during symlink
following and only to update atime.
So this isn't sufficient to update the inode attributes to reflect
changes make by things like kernfs_setattr() or when the directory
link count changes ...
Sigh!
Powered by blists - more mailing lists