On Fri, Jan 30, 2026 at 5:16 PM Al Viro <[email protected]> wrote: > > On Fri, Jan 30, 2026 at 05:05:34PM -0800, Samuel Wu wrote: > > > > How lovely... Could you slap > > > WARN_ON(ret == -EAGAIN); > > > right before that > > > if (ret < 0) > > > return ret; > > > > Surprisingly ret == 0 every time, so no difference in dmesg logs with > > this addition. > > What the hell? Other than that mutex_lock(), the only change in there > is the order of store to file->private_data and call of ffs_data_opened(); > that struct file pointer is not visible to anyone at that point...
Agree, 09e88dc22ea2 (serialize ffs_ep0_open() on ffs->mutex) in itself is quite straightforward. Not familiar with this code path so just speculating, but is there any interaction with previous patches (e.g. refcounting)? > Wait, it also brings ffs_data_reset() on that transition under ffs->mutex... > For a quick check: does > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git > for-wsamuel2 > git switch --detach FETCH_HEAD > demonstrate the same breakage? Had to adjust forward declaration of ffs_data_reset() to build, but unfortunately same breakage.
