From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (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 6068A271467 for ; Wed, 19 Nov 2025 14:18:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763561914; cv=none; b=mpjOqCzQneKYRvkKqcVLvgd/TIsjuKtJXqK6rFOVNNACzDunqsPFPEnqD8K7a+RFuA2y/xDfi4REe8jzJs7y0VpGlUDnDLLNDFzO2PirdCvuARqvtdzzgO89U8ZxdMdt/pnEbqv9fO+TOOtsrgJYezUC7+K4H0ppglZbjMWoMd4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763561914; c=relaxed/simple; bh=Q5EOxCTQdn1ySEXR7SVKzd/64b+mxnMmmV2Z+3mpiSM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ICQ5fNsAuKNKJxbDPM+7D/9VPOB+jw2tOxIqEvr7l3Iw/SaF7KqkRln3ulHWFAUtTMbTPEJe2YxoIwZB67B5rgXw99Es3k4Rt2kgTpqH8zFOuAiqaPdsDI7wlN6Iuczsb3iXXNe8t5YzLcULb7ni36x5ffxEekNlArUN0osAQRE= 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=K8vl3B5x; arc=none smtp.client-ip=209.85.222.170 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="K8vl3B5x" Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-8b1e54aefc5so561025285a.1 for ; Wed, 19 Nov 2025 06:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763561911; x=1764166711; 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=+90yb+fqxTrYXVbMXgZSbTTIEwgP0Ry7UtEBvEYn0Ak=; b=K8vl3B5xx2O3DZ0kP2Vc5VkvOp94HEdUDT++ASuQz5yuOHZ085bOBgJI8OsQVGyRdV waVd4eCvOmEhbTJirysQzM4YzPqnyB8UspK7zawdO6TXnEJFsYZA/ubiQ0CWQCzMdBiH 9mBz1UFwQNnr2dREiL/IHrlQ18EgxzspI+nEIJQOjX+kPJ4pYCm6EesAcBqluYi2L+fD EFQf7QSi+YUqCqQSE7vX4xmnOACbOr77uv/Enc0cFirD6DFedSyAzR6N9XDDIiIUE1D0 H4XWRUf8GtlWQsZdri5RxBAiaUMBUBcnKkafouQcPEXTzbK2lsEIXuVeW8q1EbmLWsZO 1U2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763561911; x=1764166711; 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=+90yb+fqxTrYXVbMXgZSbTTIEwgP0Ry7UtEBvEYn0Ak=; b=JDPu90SYaP+X6H6qpOtkhtBLAo4EGoBgt/lgn05rXuiOlygLSp7LD+kYwKgr+E20Z0 UTRYdjLU23MBdbkc6qtv2LpGPqWceTsrw2idAgXnsNuDRUSvwKk2J9XnT4V0y4bWTRyG nC2NCTqihiWKOrjcL878NBTOFsNHucSENJVqM10G7uz7F/MPG/X4hBWOmNwWylq4CExv DfKwQg1jiz62mLgrZ6NwnvH4YCy0iLtB0L0kBQ2U0SBeX8dJ1fq7hYGoHRcV2ieXR94p Qt3gsX+WtKVq42uSmn3KgDsapxVulxPajt7TnAy5kaIyvWtX01SpETbvR6Km+lIdujbU QIiQ== X-Forwarded-Encrypted: i=1; AJvYcCVxcVwyH25RQUGuE/AX9IlBSAshE5S7fYINYJxTmcGIAAvbF7iVhFTUV6qEPLw9g1nrLe7wmCqyzorTYFA=@vger.kernel.org X-Gm-Message-State: AOJu0Yy888Q6C3iy7tByc29KeQ/IFgAoGrfipAshkT7osMwlpSj1Kc1o kTygc5IAiKKsmcR/QcZD3/HfLPjx7GR+vg4oUT2rWlf6cNlwlAtFy10N X-Gm-Gg: ASbGnct3NtQBhzbPqHQyKKs4DXV3pR7vpyuP4aBO+h1jKZ3p91Ju9jDGhtTTmWEIcgR 8ytb6uYRsueV99hAWneEEr10KBz5RhMMOBu+1lsLb+x/j9DCez95foMbs1YAgMJSfnB0v90tGQE T6DpxiEPI0XTe39G4MSuJ2Fq2LXs4UN3KBw2xQq8dvvuPLRm2g+XZ8suVjwHgx74F9kgFYQiOY1 QGuSkoAFFEHpQcgy/NIzRlmLc/+9giv83asFyyblj7C9vXB++4l53CWUq4z4I76XVJkI/oSL8Ul JAG+v/42zGUzl4PEjam6UWZzg5AVQij9ROQvKO/ybybmvihKGYkXcbXVpnRntfyyZKrjCrH5aWz zloI9oD3MsLuHN286NtnZJBt8Q5NGtNnv3q+gQabonQWmyeJqY4lSU7d/xm7Sae8Kv/MpYSQHD7 pdJAMcjebNEE79bJ2nE418brCo X-Google-Smtp-Source: AGHT+IG/wzISuTDTwU38rnHlKFVsjZYQ1LAPqI+YUX2j1eJ0psrgSKOCOoYPLV+mt1/9ePq3equZlQ== X-Received: by 2002:a05:620a:7103:b0:8b2:e704:5626 with SMTP id af79cd13be357-8b31701c1c9mr416720285a.38.1763561911106; Wed, 19 Nov 2025 06:18:31 -0800 (PST) Received: from arborvitaetree.localnet ([2600:4041:3a6:c00::15]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b2af041e55sm1434580485a.42.2025.11.19.06.18.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Nov 2025 06:18:30 -0800 (PST) From: Stephanie Gawroriski To: Heikki Krogerus Cc: Linus Torvalds , Linux Kernel Mailing List , Greg Kroah-Hartman Subject: Re: Linux 6.18-rc6 Date: Wed, 19 Nov 2025 09:18:30 -0500 Message-ID: <6115647.MhkbZ0Pkbq@arborvitaetree> In-Reply-To: References: <7886111.EvYhyI6sBW@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" 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.