On Fri, 30 Jan 2026 at 15:55, Al Viro <[email protected]> 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
