Re: Linux 6.18-rc6

[Stephanie Gawroriski <xerthesquirrel@gmail.com>]

On Wednesday, 19 November 2025 04:08:35 EST Heikki Krogerus wrote:
> Hi
> 
> > > > Unrelated to this, after suspending and docking my laptop to my dock,
> > > > I
> > > > get
> > > > this now:
> > > > 
> > > > [50598.774359] ------------[ cut here ]------------
> > > > [50598.774371] kernfs: can not remove 'typec', no directory
> > > > [50598.774389] WARNING: CPU: 2 PID: 48932 at fs/kernfs/dir.c:1706
> > > > kernfs_remove_by_name_ns+0xcf/0xe0
> > > 
> > > Ok, that is indeed unrelated, and should be mostly harmless apart from
> > > the scary message. Do you see any other effects than the noise in the
> > > logs?
> > 
> > Not that I know of.
> > 
> > > Somebody is trying to remove a sysfs entry that has no parent,
> > > presumably because it was never registered in the first place.
> > > 
> > > At a guess, it's some error handling cleanup that is done
> > > unconditionally, unregistering an entry even when the original
> > > registration failed. Or unregistering twice.
> > > 
> > > Looks like ucsi / typec handling:
> > > > [50598.774763] Call Trace:
> > > > [50598.774775]  typec_unregister_partner+0x6c/0x110
> > > > [50598.774787]  ucsi_unregister_partner+0x103/0x140
> > > > [50598.774794]  ucsi_handle_connector_change+0x34d/0x3e0
> > > > [50598.774803]  process_one_work+0x18b/0x340
> > > > [50598.774811]  worker_thread+0x256/0x3a0
> > > > [50598.774824]  kthread+0xfc/0x240
> > > 
> > > but that said, I don't see why this would be new behavior. I don't see
> > > anything that has changed in this area lately in the typec class
> > > handling.
> > > 
> > > In fact, looking around, I see much older reports that look a bit like
> > > this, so I don't think it's new.
> > > 
> > > Adding Greg and Heikki who might know what is going on. See
> > > 
> > >    https://lore.kernel.org/all/2203148.PYKUYFuaPT@arborvitaetree/
> > > 
> > > for original report.
> > > 
> > >                 Linus
> > 
> > I really only noticed it when I was looking in dmesg very recently to see
> > if there were any application crashes due to huge_memory issue. I do look
> > in dmesg often enough, but mostly to see if devices are being recognized
> > properly or other events such as when the embedded JVM I am working on
> > split locks.
> Thanks for the report. It looks like the code does not increment the
> reference count of the USB device that is liked to the typec partner.
> 
> Is it possible for you to test this?
> 
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 9b2647cb199b..4ace92af9856 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -805,6 +805,8 @@ static void typec_partner_link_device(struct
> typec_partner *partner, struct devi return;
>         }
> 
> +       get_device(dev);
> +
>         if (partner->attach)
>                 partner->attach(partner, dev);
>  }
> @@ -816,6 +818,8 @@ static void typec_partner_unlink_device(struct
> typec_partner *partner, struct de
> 
>         if (partner->deattach)
>                 partner->deattach(partner, dev);
> +
> +       put_device(dev);
>  }
> 
>  /**

I can give it a try! I do notice the trace in dmesg, however it does not 
always appear when docking/undocking so I am not sure the conditions in which 
it occurs in.