On Fri, Jan 30, 2026 at 04:14:48PM -0800, Linus Torvalds wrote: > 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.
I'd rather go for a spinlock there, protecting these FFS_DEACTIVATED transitions; let me try and put together something along those lines. Matter of fact, I would drop the atomics for ->opened completely and do all changes under the same spinlock - it's really just ->open() and ->release(). Simpler that way... The shitty part is that ->set_alt() thing and its callers seems to be written in assumption that it can come from an interrupt, so we'd need spin_lock_irq() in open/release and spin_lock_irqsave() in set_alt/disable... Another fun part is that we need a barrier on transition from FFS_CLOSING in ffs_data_reset() - right now it's not even the last assignment in there. Same spinlock would solve that - screw explicit barriers, it's _not_ a hot path and the locking is convoluted enough as it is.
