[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YvWGOKqmuaGm8yCd@ZenIV>
Date: Thu, 11 Aug 2022 23:44:08 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jeff Layton <jlayton@...nel.org>,
Ilya Dryomov <idryomov@...il.com>, ceph-devel@...r.kernel.org,
linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>
Subject: Re: [GIT PULL] Ceph updates for 5.20-rc1
On Thu, Aug 11, 2022 at 03:22:38PM -0700, Linus Torvalds wrote:
> On Thu, Aug 11, 2022 at 3:04 PM Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > FWIW, I wonder if we should do
> > if (READ_ONCE(dentry->d_parent) != parent)
> > continue;
> > before grabbing ->d_lock (and repeat the check after grabbing it,
>
> It kind of makes sense. We already do that d_name.hash check outside
> of the lock, so we already have that "we might race with a rename"
> situation.
>
> That said, I do think __d_lookup_rcu() is the more important of the two.
>
> Here's a recreation of that patch I mentioned where the OP_COMPARE is
> moved out of the loop. Just for fun, look at how much better the code
> generation is for the common case when you don't have the call messing
> up the clobbered registers etc.
>
> Entirely untested, and I might have messed something up, but I suspect
> this is a much bigger deal than whether d_same_name() is inlined or
> not in the non-RCU path.
Looks sane at the first pass, but right now I'm really half-asleep - 5 hours
of sleep tonight, and about the same yesterday ;-/
I'll try to grab at least an hour or two and reread it once I'm more or less
awake...
Powered by blists - more mailing lists