From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E79CC2FF669 for ; Wed, 19 Nov 2025 09:08:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763543325; cv=none; b=T2R/uceCFs7dfg8sUWup7y56VS743YeKf4ptyRDSWo0gHoy4maRZQhgB+mRcPb72YpvbfLAka7wrYSVoDb4v++hD8iXkVVjepACdCBCh+Q0+OMX08+1W8fDi2lhbWGPRiqz6AssMFjs58buR5on92oMMTTJ+XcXG6D6OAGI9I18= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763543325; c=relaxed/simple; bh=9SvwG4PGjK3D1xI7pu6JMYtYVH6Ju7R06hMCrYRqgsQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eKczzx+Rmcnap3LNXzHylczzOXPq6lo7bdT4xIKAdsr2CyOrBbflklLlQqEPciORqzfQF7D5otKuXbFWKuVgjwrioEyfwDE7X21aU0lXYq0GNDtVBHwqdxniYWGCwKqodw7UXquMuEcP4iwkGeTxYjYmcUdcBUkl3ZLlM31aFko= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=kG+c+nU8; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="kG+c+nU8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763543323; x=1795079323; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9SvwG4PGjK3D1xI7pu6JMYtYVH6Ju7R06hMCrYRqgsQ=; b=kG+c+nU8+SXncP33ZpmEKF1hNzibfwoM87l5mFcYRubqK4Dwdu9y6gwU oc2tdBDNXsNV/vfGd6sRmW6Ycy7b3IoM1RJTArc4rTzMb5jE+N3CC/bEA 36e+Cd6oAqgWJgxCaFnurtlveTMMQaFS9YxmkXyi8AmAc20azXescXTE9 cbR0Hf+8Mzz3JbJNE3pKscgrcxRBwHCxSfL6zx7/0F+TRMkDF5ZbHHY4d 8vQweGU3/Bp58aTxdTKlm/TOC+3i8zKL0gT4kvESiMAyKblxSZUWgHatf OiGYKEI9IvJPrmGwdQe9QMBjPbBfzzQWb4RbQKOUQPHXzYtFk0teP/f4X A==; X-CSE-ConnectionGUID: OBk2t0MDRvahwsMek2DCUg== X-CSE-MsgGUID: tYKp7xj5SAegntv5zVjjGQ== X-IronPort-AV: E=McAfee;i="6800,10657,11617"; a="75903994" X-IronPort-AV: E=Sophos;i="6.19,315,1754982000"; d="scan'208";a="75903994" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 01:08:42 -0800 X-CSE-ConnectionGUID: 2+91W8kXSTyzjH/sqE7eTg== X-CSE-MsgGUID: Vf7AyItrQTCi98P92FtHww== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,315,1754982000"; d="scan'208";a="195476785" Received: from aschofie-mobl2.amr.corp.intel.com (HELO kuha) ([10.124.221.82]) by orviesa004.jf.intel.com with SMTP; 19 Nov 2025 01:08:39 -0800 Received: by kuha (sSMTP sendmail emulation); Wed, 19 Nov 2025 11:08:35 +0200 Date: Wed, 19 Nov 2025 11:08:35 +0200 From: Heikki Krogerus To: Stephanie Gawroriski Cc: Linus Torvalds , Linux Kernel Mailing List , Greg Kroah-Hartman Subject: Re: Linux 6.18-rc6 Message-ID: References: <2203148.PYKUYFuaPT@arborvitaetree> <7886111.EvYhyI6sBW@arborvitaetree> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7886111.EvYhyI6sBW@arborvitaetree> 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); } /** -- heikki