Thread (81 messages) flat view 81 messages, 5 authors, 2026-02-01

Re: [PATCH v4 00/54] tree-in-dcache stuff

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2026-01-31 00:15:07
Also in: bpf, linux-efi, linux-fsdevel, linux-mm, linux-usb, ocfs2-devel, selinux

On Fri, 30 Jan 2026 at 15:55, Al Viro [off-list ref] wrote:
So we have something that does O_NDELAY opens of ep0 *and* does not retry on
EAGAIN?

How lovely...
Actually, I think that is pretty normal behavior.

Generally, O_NDELAY and friends should *NOT* turn locks into trylocks
- because user space has no sane way to deal with kernel lock issues,
and user space simply shouldn't care.

So O_NDELAY should be about avoiding IO, not about avoiding perfectly
normal locks.

Of course, that horrendous driver locking is broken, since it holds
the lock over IO, so that driver basically conflates IO and locking,
and that's arguably the fundamental problem here.

But I suspect that for this case, we should just pass in zero to
ffs_mutex_lock() on open, and say that the O_NONBLOCK flag is purely
about the subsequent IO, not about the open() itself.

That is, after all, how the driver used to work.

                Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help