linux-kernel - Re: Linux 6.18-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7886111.EvYhyI6sBW@arborvitaetree>
Date: Tue, 18 Nov 2025 15:18:23 -0500
From: Stephanie Gawroriski <xerthesquirrel@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Subject: Re: Linux 6.18-rc6

Hi!

On Tuesday, 18 November 2025 13:01:54 EST Linus Torvalds wrote:
> On Tue, 18 Nov 2025 at 09:23, Stephanie Gawroriski
> 
> <xerthesquirrel@...il.com> wrote:
> > Since rc6 I am getting crashes in JetBrain's Rider backend for CLion,
> > which
> 
> > the backend is a C# application specifically, which gives in its logs:
> Yeah, that looks like the same bug that David Wang and some other
> people reported.
> 
> Can you check current top-of-tree, which includes that commit
> 5bebe8de1926 ("mm/huge_memory: Fix initialization of huge zero folio")
> which hopefully fixes this for you.

I have been running 5bebe8de1926 for a bit and so far no issues! Have tried a 
few suspends and re-runs to simulate my normal workflow, seems to be stable!

> > 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.