Re: [PATCH 1/2] fs: add support for LOOKUP_NONBLOCK

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Dec 11, 2020 at 11:50:12AM -0700, Jens Axboe wrote:

> I could filter on O_TRUNC (and O_CREAT) in the caller from the io_uring
> side, and in fact we may want to do that in general for RESOLVE_LOOKUP
> as well.

You do realize that it covers O_RDWR as well, right?  If the object is on
a frozen filesystem, mnt_want_write() will block until the thing gets thawed.

> > AFAICS, without that part it is pretty much worthless.  And details
> > of what you are going to do in the missing bits *do* matter - unlike the
> > pathwalk side (which is trivial) it has potential for being very
> > messy.  I want to see _that_ before we commit to going there, and
> > a user-visible flag to openat2() makes a very strong commitment.
> 
> Fair enough. In terms of patch flow, do you want that as an addon before
> we do RESOLVE_NONBLOCK, or do you want it as part of the core
> LOOKUP_NONBLOCK patch?

I want to understand how it will be done.

> Agree, if we're going bool, we should make it the more usually followed
> success-on-false instead. And I'm happy to see you drop those
> likely/unlikely as well, not a huge fan. I'll fold this into what I had
> for that and include your naming change.

BTW, I wonder if the compiler is able to figure out that

bool f(void)
{
	if (unlikely(foo))
		return false;
	if (unlikely(bar))
		return false;
	return true;
}

is unlikely to return false.  We can force that, obviously (provide an inlined
wrapper and slap likely() there), but...