[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250207200105.GF1977892@ZenIV>
Date: Fri, 7 Feb 2025 20:01:05 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: NeilBrown <neilb@...e.de>
Cc: Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jeff Layton <jlayton@...nel.org>,
Dave Chinner <david@...morbit.com>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/19] VFS: use d_alloc_parallel() in
lookup_one_qstr_excl() and rename it.
On Thu, Feb 06, 2025 at 04:42:40PM +1100, NeilBrown wrote:
> - dentry = d_alloc(base, name);
> - if (unlikely(!dentry))
> + dentry = d_alloc_parallel(base, name);
> + if (unlikely(IS_ERR_OR_NULL(dentry)))
> return ERR_PTR(-ENOMEM);
Huh? When does d_alloc_parallel() return NULL and why do you
play with explicit ERR_PTR(-ENOMEM) here?
> + if ((flags & LOOKUP_INTENT_FLAGS) == 0)
Yecchh... Thank you (from all reviewers, I suspect) for the exciting
opportunity to verify what values are possible in lookup_flags in various
callers and which are guaranteed to intersect with your LOOKUP_INTENT_FLAGS
mask.
> +#define LOOKUP_INTENT_FLAGS (LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_EXCL | \
> + LOOKUP_RENAME_TARGET)
> +
... as well as figuring out WTF do LOOKUP_OPEN and LOOKUP_EXCL fit into
that.
Powered by blists - more mailing lists