Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp4612848rdb; Fri, 29 Dec 2023 07:32:41 -0800 (PST) X-Google-Smtp-Source: AGHT+IFi4tTvzgwHWSGv2njfE6r+pGLmRnizgvjd3P5c66bpqTD/yFF5x9irNL1fP0YucLZRGHl1 X-Received: by 2002:a17:902:d58b:b0:1d4:5939:523a with SMTP id k11-20020a170902d58b00b001d45939523amr11085279plh.33.1703863961069; Fri, 29 Dec 2023 07:32:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703863961; cv=none; d=google.com; s=arc-20160816; b=JeWU0BLvWHjvA79zw5G8X012kR5J+ZF4/91YIm9NqdXfuOFT4LIoQTsYIDSheNVP7/ MvwYxJyp2eWTakgN4wHpAqhVb0UhxwStyVj2iqtf/T2+AkNoZdOUTk6/y+9/fFXkKZDW Pzh3G8bd+VI2ByRAdoLSZp8i10glSR3TqA98FfA4N+YWQQuOUQ5tovGNoQithaE7yt8y 4v1oykPh70j/94pFAH/STHf5uQQtbz1i1wEZyDgmAnS++F0x3LlFSt6uy/5FAQWFsurz Qv13d9Aoh57ejlfJluPFe8udC6C1OqUYf6upHsT7+z3uMs1b54MZwxX6V0Q/9wfRwocV 6a6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=Fuwm5osfeBUHYeYPPSG6vtbTRogaCAUkvtsoWX0gyjs=; fh=CBI7dXwWBQnlfnXBr/atuGBlWaxVfVtiSZGjCWWjSVo=; b=BQOVdJgUHeEvEgEcijW59I7b9QfSPeN9r1BHuWZljMGDliOtgcsCQsCIRF5nMGPvKF 1iANkEiP2AHtn/XxOJ7DPaiUSp9mnNWIQNvh4IaZ2ddzt9mpugYmVWvuSrZhUixs0yjV tKnExSAduodrKNhwtjcso3TbL0M/cB0TmUV6Xim+8RFtZaotaVNCeQJL1GsiwGFPD8A3 PDTYcp0t19lHzGHVzxYNQrRyuR//NwWx5Wma/dF+FL0VQEAcGUnFRlpF65cYwo2SsCeU 9K7Av7MrAnd3Suz54VZzMRP2azJ2vUFbkEcvB+a1S+gpfB43KpjvXhRuXzEVU9CkR+7d rBQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-13141-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13141-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id y8-20020a17090322c800b001d439a425bcsi10641889plg.514.2023.12.29.07.32.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Dec 2023 07:32:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-13141-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-13141-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13141-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 1226FB224A8 for ; Fri, 29 Dec 2023 15:32:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A87E6125C1; Fri, 29 Dec 2023 15:32:22 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from cae.in-ulm.de (cae.in-ulm.de [217.10.14.231]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2CEA6125AB; Fri, 29 Dec 2023 15:32:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=c--e.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=c--e.de Received: by cae.in-ulm.de (Postfix, from userid 1000) id 671A71402F9; Fri, 29 Dec 2023 16:32:16 +0100 (CET) Date: Fri, 29 Dec 2023 16:32:16 +0100 From: "Christian A. Ehrhardt" To: RD Babiera Cc: heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, badhri@google.com, stable@vger.kernel.org, Chris Bainbridge Subject: Re: [PATCH v1] usb: typec: class: fix typec_altmode_put_partner to put plugs Message-ID: References: <20231121203954.173364-2-rdbabiera@google.com> 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: <20231121203954.173364-2-rdbabiera@google.com> Hi, I found this mail in the archives after looking at a bug report that was bisected to the change that resulted from the following analysis: https://lore.kernel.org/all/CAP-bSRb3SXpgo_BEdqZB-p1K5625fMegRZ17ZkPE1J8ZYgEHDg@mail.gmail.com/ AFAICS the analysis below is partially flawed On Tue, Nov 21, 2023 at 08:39:55PM +0000, RD Babiera wrote: > When releasing an Alt Mode, typec_altmode_release called by a plug device > will not release the plug Alt Mode, meaning that a port will hold a > reference to a plug Alt Mode even if the port partner is unregistered. > As a result, typec_altmode_get_plug() can return an old plug altmode. > > Currently, typec_altmode_put_partner does not raise issues > when unregistering a partner altmode. Looking at the current > implementation: > > > static void typec_altmode_put_partner(struct altmode *altmode) > > { > > struct altmode *partner = altmode->partner; > > When called by the partner Alt Mode, then partner evaluates to the port's > Alt Mode. When called by the plug Alt Mode, this also evaluates to the > port's Alt Mode. > > > struct typec_altmode *adev; > > > > if (!partner) > > return; > > > > adev = &partner->adev; > > This always evaluates to the port's typec_altmode > > > if (is_typec_plug(adev->dev.parent)) { > > struct typec_plug *plug = to_typec_plug(adev->dev.parent); > > > > partner->plug[plug->index] = NULL; > > If the routine is called to put the plug's Alt mode and altmode refers to > the plug, then adev referring to the port can never be a typec_plug. If > altmode refers to the port, adev will always refer to the port partner, > which runs the block below. > > > } else { > > partner->partner = NULL; > > } > > put_device(&adev->dev); > > } So far everything is fine. > When calling typec_altmode_set_partner, a registration always calls > get_device() on the port partner or the plug being registered, This is wrong. It is the altmode of the plug or partner that holds a reference to the altmode of the port not the other way around. The port's altmode has (back) pointers to the altmodes of its partner and the cable plugs but these are weak references that do not contribute to the refcount. > therefore > typec_altmode_put_partner should put_device() the same device. By changing Thus this conclusion is wrong. The put_device() used to be correct. > adev to altmode->adev, we make sure to put the correct device and properly > unregister plugs. The reason port partners are always properly > unregistered is because even when adev refers to the port, the port > partner gets nullified in the else block. The port device currently gets > put(). Please correct me if I missed something. regards Christian