From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F5A42D5A16 for ; Tue, 18 Nov 2025 20:18:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763497106; cv=none; b=bqQ0xPmYW7zxjLrm908ncif/+ac6tc56LSKzdUCULANUyoZHwIEirsV3iU8A9GkV6iW2tBUzP3Px6dsXX2tgy0ALOXO1UENRE+B32tL3atE7IIwKHWODCtOiv1qGhK/aPx4B+YTm0J+CADSHUnOS7v9w6QCoxRNzx3kiGQSdqz8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763497106; c=relaxed/simple; bh=XTs4rHYxBFNn9mf7p4vwYBgBMoLM6WeP1xrX1n7jvQg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OlyifbngAkNQHNIvBBehs7LI0uWTEDq/id+ExkEgP9G/krWnaUzHcIbHd5eyY3kmLIwP96RrCCAEM5vGOH9pmgYAwnYNwXYgfpVXKSVWKGVzFGUV2lM5cM1AVgIDfBJoi1vpHfoEOG5/SfPDKIxbl4NNSbuc9DJGfAw5GAcCQLg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TrJJ0P/i; arc=none smtp.client-ip=209.85.222.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TrJJ0P/i" Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-8b2ec756de0so240934085a.3 for ; Tue, 18 Nov 2025 12:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763497104; x=1764101904; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=k1ByfRjIG+ZebykRagCCUc1LVvF7qCA9aIPO3rA0CiI=; b=TrJJ0P/i55ehU1DzM+iMI+/L2SC+dj976dAenSGM5UPaRyIHkHamCkgwumNHc6AdGP YqoqY9+Jm7qnCC12avrCuCnj9vGoCpQ5Qt0oxw6JY0NAy/O89S4y2epmQlDgkczgDUdf l5rdX5olKSBMdLfHNq8Va40fq+q+NrrDLh8gXnf/Tm81JFdme5zfxR7jpn5oVdqClSLg bt2vMeTn03Fm/PdGHDdE7DLjaSu0J91BlMSz4yD+cADl8D47RFvUZUAIMF+muPZWT0BG Re1OXWoDom7FK1cGATwqD5n7TYKFxeUnk9m1SKWqZ9sz+gNNQEWCQNv1Y8ywW/r4ltyx dE4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763497104; x=1764101904; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=k1ByfRjIG+ZebykRagCCUc1LVvF7qCA9aIPO3rA0CiI=; b=FQULoSp5HBGNUzOB4Rc5W7Rbu0vkRWGMJyByh+/+Qlf8nB3UdnlnhFBVLMWDUzN2UH n5u0msQjgx7QoSDzeQS9AU++nceSmQGyakRLX+7L245IpZSx++M2vnI8i9HJywbisEFL YadPfopVIbfF9cJvZMzh/sDITdZTdT66HgnekBlG8vf8+y/CF8B1XbVllXfJADT5ijuj rK34i93x1sT2EJ2qF6lt7U86x7P7xBcKrnMFuxdV/GA+s5XFwBex0KakFn33DLCzWUC4 9BotIEzsIxIH0+zme0u2TaOjAtetgzyzN+oSuZEIWabAEvp9bCQ8vSm2jUDRWQC1VDA4 nPgg== X-Gm-Message-State: AOJu0YzI176qgjcmym1ARjTZ6QIF+Aq4bncFiIjTllW1CihWYI3XmA8y HuU+g79RyXaFzna+ZRDVO2CC4HcfMzz/pe7seSBK19778gZtkoSdbwoG X-Gm-Gg: ASbGncuGP31ypQbr3t1MxEQNPXuVjqSuN+Oe3lEL7bnHFZAMvvYeWbhTSeVtxoodK6h 5knR6mOOIzRXLEgXlpomVbg9+IIt4E2RQe4cskYaXm9aB+M9tFdqD88tAcARv35eQ+Loj8KfkGr eb8zozMMGbJ/rAFz6bm/Kntj0DpMkq28ym4J4PlnRwp7mcp+24rlIqGCPb2V74FDi1F289GriPG zK1yQy6jP269xHxwL9qpvvaiaRXx11fLR07G29xTyQwOe7G447yHf1Hm6oTojLUF8IbIEpIPV3j 1h1LBwG8LjSBrLOfMoJ37pMa6l5pC33Tc35Ijmo0V0kVzAT6rjmUxNWe0PxQi506rF8JfK2vtUh MlhMZ7AH+KdMq+hHV+gsN93dsKRQWXceEcsioFxY86q6X6RF14UeM9as22tF0957xxL+h122FKe vhMIGtA8v5W2LreQ== X-Google-Smtp-Source: AGHT+IEVF8zZR8QTWmHsEGneDQZ5MHcxuAYGIxnT2e3hyvFCAQQTdUx3xtWoBowLd2q6ANrNs244Tg== X-Received: by 2002:a05:620a:5bec:b0:8b2:d56a:f2f3 with SMTP id af79cd13be357-8b2d56b123fmr1272287785a.87.1763497104044; Tue, 18 Nov 2025 12:18:24 -0800 (PST) Received: from arborvitaetree.localnet ([2600:4041:3a6:c00::15]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b2aef2f9bbsm1273183985a.31.2025.11.18.12.18.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Nov 2025 12:18:23 -0800 (PST) From: Stephanie Gawroriski To: Linus Torvalds Cc: Linux Kernel Mailing List , Greg Kroah-Hartman , Heikki Krogerus Subject: Re: Linux 6.18-rc6 Date: Tue, 18 Nov 2025 15:18:23 -0500 Message-ID: <7886111.EvYhyI6sBW@arborvitaetree> In-Reply-To: References: <2203148.PYKUYFuaPT@arborvitaetree> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Hi! On Tuesday, 18 November 2025 13:01:54 EST Linus Torvalds wrote: > On Tue, 18 Nov 2025 at 09:23, Stephanie Gawroriski > > 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.