linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC][PATCH] getname_maybe_null() - the third variant of pathname copy-in
Date: Fri, 18 Oct 2024 20:38:22 +0100	[thread overview]
Message-ID: <20241018193822.GB1172273@ZenIV> (raw)
In-Reply-To: <20241018165158.GA1172273@ZenIV>

On Fri, Oct 18, 2024 at 05:51:58PM +0100, Al Viro wrote:

> Extra cycles where?  If anything, I'd expect a too-small-to-measure
> speedup due to dereference shifted from path_init() to __set_nameidata().
> Below is literally all it takes to make filename_lookup() treat NULL
> as empty-string name.
> 
> NOTE: I'm not talking about forcing the pure by-descriptor case through
> the dfd+pathname codepath; not without serious profiling.  But treating
> AT_FDCWD + NULL by the delta below and passing NULL struct filename to
> filename_lookup()?  Where do you expect to have the lost cycles on that?

[snip]

BTW, could you give me a reference to the mail with those objections?
I don't see anything in my mailbox, but...

Or was that in one of those AT_EMPTY_PATH_NOCHECK (IIRC?) threads?

Anyway, what I'm suggesting is

1) teach filename_lookup() to handle NULL struct filename * argument, treating
it as "".  Trivial and does not impose any overhead on the normal cases.

2) have statx try to recognize AT_EMPTY_PATH, "" and AT_EMPTY_PATH, NULL.
If we have that and dfd is *NOT* AT_FDCWD, we have a nice descriptor-based
case and can deal with it.
If the name is not empty, we have to go for dfd+filename path.  Also obvious.
Where we get trouble is AT_FDCWD, NULL case.  But with (1) we can simply
route that to the same dfd+filename path, just passing it NULL for filename.

That handles the currently broken case, with very little disruption to
anything else.

What's more, the logics for "is it NULL or empty with AT_EMPTY_PATH" no
longer needs to care about dfd.  We can encapsulate it nicely into
a function that takes userland pointer + flags and does the following:

	if no AT_EMPTY_PATH in flags
		return getname(pointer)
	if pointer == NULL		     (same as vfs_empty_path())
		return NULL
	peek at the first byte, if it's '\0' (same as vfs_empty_path())
		return NULL
	name = getname_flags(pointer, LOOKUP_EMPTY)
	if IS_ERR(name)
		return name
	if unlikely(name is empty)
		putname(name)
		return NULL
	return name

Then statx() (or anyone who wants similar AT_EMPTY_PATH + NULL semantics)
can do this:
	name = getname_maybe_null(user_pointer, flags)
	if (!name && dfd >= 0) // or dfd != AT_FDCWD, perhaps
		do_something_by_fd(dfd, ...)
	else
		do_something_by_name(dfd, name, ...)
without the bitrot-prone boilerplate.

  reply	other threads:[~2024-10-18 19:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09  4:03 [RFC][PATCH] getname_maybe_null() - the third variant of pathname copy-in Al Viro
2024-10-15 14:05 ` Christian Brauner
2024-10-16  5:09   ` Al Viro
2024-10-16  8:32     ` Christian Brauner
2024-10-16 14:00       ` Al Viro
2024-10-16 14:49         ` Christian Brauner
2024-10-17 23:54           ` Al Viro
2024-10-18 11:06             ` Christian Brauner
2024-10-18 16:51               ` Al Viro
2024-10-18 19:38                 ` Al Viro [this message]
2024-10-19  5:03                   ` Al Viro
2024-10-19 16:15                     ` Linus Torvalds
2024-10-19 17:11                       ` Al Viro
2024-10-19 17:27                         ` Linus Torvalds
2024-10-21 12:38                         ` Christian Brauner
2024-10-21 12:39                     ` Christian Brauner
2024-10-21 17:09                       ` Al Viro
2024-10-21 22:43                         ` Al Viro
2024-10-22  8:49                           ` Christian Brauner
2024-10-30  6:37                             ` Al Viro
2024-10-21 12:47                   ` Christian Brauner
2024-10-21 17:05                     ` Al Viro
2024-10-21 12:36                 ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241018193822.GB1172273@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).