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

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

On Thu, Jan 29, 2026 at 03:23:35AM +0000, Al Viro wrote:
> On Wed, Jan 28, 2026 at 04:58:57PM -0800, Samuel Wu wrote:
> > On Tue, Jan 27, 2026 at 8:58 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > 
> > > Very interesting...  Does 1544775687f0 (parent of e5bf5ee26663)
> > > demonstrate that behaviour?
> > 
> > Reverting only 1544775687f0 (functionfs: need to cancel ->reset_work
> > in ->kill_sb()) does not fix the issue. With 6.19-rc7 as baseline, the
> > simplest working recipe at the moment is with 6ca67378d0e7,
> > c7747fafaba0, and e5bf5ee26663 reverted.
> 
> Sorry, I hadn't been clear enough: if you do
> git switch --detach 1544775687f0 
> and build the resulting tree, does the breakage reproduce?  What I want
> to do is to split e5bf5ee26663 into smaller steps and see which one
> introduces the breakage, but the starting point would be verify that
> there's no breakage prior to that.
> 
> 
> PS: v6.19-rc7 contains fc45aee66223 ("get rid of kill_litter_super()"),
> and reverting 6ca67378d0e7 ("convert functionfs") would reintroduce
> the call of that function in ffs_fs_kill_sb(), so the resulting tree
> won't even build on any configs with functionfs enabledd; are you sure
> that you'd been testing v6.19-rc7 + reverts of just these 3 commits?

Could you try your reproducer on mainline with the following delta applied?

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 05c6750702b6..6c6d55ba0749 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -646,12 +646,11 @@ static int ffs_ep0_open(struct inode *inode, struct file *file)
 	if (ret < 0)
 		return ret;
 
-	ffs_data_opened(ffs);
 	if (ffs->state == FFS_CLOSING) {
-		ffs_data_closed(ffs);
 		mutex_unlock(&ffs->mutex);
 		return -EBUSY;
 	}
+	ffs_data_opened(ffs);
 	mutex_unlock(&ffs->mutex);
 	file->private_data = ffs;