On Thu, Jan 29, 2026 at 2:52 PM Al Viro <[email protected]> wrote:
> > 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.
> > 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.
> 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
