Re: [PATCH v4 00/54] tree-in-dcache stuff
From: Samuel Wu <hidden>
Date: 2026-01-30 01:16:33
Also in:
linux-efi, linux-fsdevel, linux-mm, linux-usb, linuxppc-dev, ocfs2-devel, selinux
On Thu, Jan 29, 2026 at 2:52 PM Al Viro [off-list ref] wrote:
quoted
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.
Ultimately, same conclusion as before: 6.18-rc5 with patches up to 1544775687f0 works, but adding e5bf5ee26663 breaks it.
quoted
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?
I also could have been more clear- I had to s/kill_anon_super/kill_litter_super/ as part of the revert of 6ca67378d0e7 to properly build. That felt like an appropriate change, but if not, adding patches on top of 6.18-rc5 is perfectly fine for testing this.
quoted hunk ↗ jump to hunk
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;
This didn't work on either build variant (6.18-rc5 and 6.19-rc7).
I'm exploring a few other paths, but not having USB access makes
traditional tools a bit difficult. One thing I'm rechecking and is
worth mentioning is the lockdep below: it's been present for quite
some time now, but I'm not sure if it would have some undesired
interaction with your patch.
[ BUG: Invalid wait context ]
6.18.0-rc5-mainline-maybe-dirty-4k
-----------------------------
irq/360-dwc3/352 is trying to lock:
ffffff800792deb8 (&psy->extensions_sem){.+.+}-{3:3}, at:
__power_supply_set_property+0x40/0x180
other info that might help us debug this:
context-{4:4}
1 lock held by irq/360-dwc3/352:
#0: ffffff8017bb98f0 (&gi->spinlock){....}-{2:2}, at:
configfs_composite_suspend+0x28/0x68
Call trace:
show_stack+0x18/0x28 (C)
__dump_stack+0x28/0x3c
dump_stack_lvl+0xac/0xf0
dump_stack+0x18/0x3c
__lock_acquire+0x794/0x2bec
lock_acquire+0x148/0x2cc
down_read+0x3c/0x194
__power_supply_set_property+0x40/0x180
power_supply_set_property+0x14/0x20
dwc3_gadget_vbus_draw+0x8c/0xcc
usb_gadget_vbus_draw+0x48/0x130
composite_suspend+0xcc/0xe4
configfs_composite_suspend+0x44/0x68
dwc3_thread_interrupt+0x8f8/0xc88
irq_thread_fn+0x48/0xa8
irq_thread+0x150/0x31c
kthread+0x150/0x280
ret_from_fork+0x10/0x20