All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Benson Leung <bleung@google.com>,
	Prashant Malani <pmalani@chromium.org>,
	Guenter Roeck <linux@roeck-us.net>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/6] usb: Iterator for ports
Date: Tue, 30 Mar 2021 11:49:21 -0400	[thread overview]
Message-ID: <20210330154921.GC980260@rowland.harvard.edu> (raw)
In-Reply-To: <YGLqV4nB/lPS1AOF@kuha.fi.intel.com>

On Tue, Mar 30, 2021 at 12:07:35PM +0300, Heikki Krogerus wrote:
> On Mon, Mar 29, 2021 at 02:49:46PM -0400, Alan Stern wrote:
> > On Mon, Mar 29, 2021 at 11:44:25AM +0300, Heikki Krogerus wrote:
> > > Introducing usb_for_each_port(). It works the same way as
> > > usb_for_each_dev(), but instead of going through every USB
> > > device in the system, it walks through the USB ports in the
> > > system.
> > > 
> > > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > > ---
> > >  drivers/usb/core/usb.c | 46 ++++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/usb.h    |  1 +
> > >  2 files changed, 47 insertions(+)
> > > 
> > > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> > > index 2ce3667ec6fae..62368c4ed37af 100644
> > > --- a/drivers/usb/core/usb.c
> > > +++ b/drivers/usb/core/usb.c
> > > @@ -398,6 +398,52 @@ int usb_for_each_dev(void *data, int (*fn)(struct usb_device *, void *))
> > >  }
> > >  EXPORT_SYMBOL_GPL(usb_for_each_dev);
> > >  
> > > +struct each_hub_arg {
> > > +	void *data;
> > > +	int (*fn)(struct device *, void *);
> > > +};
> > > +
> > > +static int __each_hub(struct usb_device *hdev, void *data)
> > > +{
> > > +	struct each_hub_arg *arg = (struct each_hub_arg *)data;
> > > +	struct usb_hub *hub;
> > > +	int ret = 0;
> > > +	int i;
> > > +
> > > +	hub = usb_hub_to_struct_hub(hdev);
> > > +	if (!hub)
> > > +		return 0;
> > 
> > What happens if the hub is removed exactly now?  Although hdev is 
> > reference-counted (and the loop iterator does take a reference to it), 
> > usb_hub_to_struct_hub doesn't take a reference to hub.  And hub->ports 
> > isn't refcounted at all.
> 
> If the hub is removed right now, and if hub_disconnect() also manages
> to remove the ports before we have time to take the lock below, then
> hdev->maxchild will be 0 by the time we can take the lock. In that
> case nothing happens here.

Okay, good.

> If on the other hand we manage to acquire the usb_port_peer_mutex
> before hub_disconnect(), then hub_disconnect() will simply have to
> wait until we are done, and only after that remove the ports.
> 
> > > +	mutex_lock(&usb_port_peer_mutex);
> > > +
> > > +	for (i = 0; i < hdev->maxchild; i++) {
> > > +		ret = arg->fn(&hub->ports[i]->dev, arg->data);
> > > +		if (ret)
> > > +			break;
> > > +	}
> > > +
> > > +	mutex_unlock(&usb_port_peer_mutex);
> > 
> > I have a feeling that it would be better to take and release this mutex 
> > in usb_for_each_port (or its caller), so that it is held over the whole 
> > loop.
> 
> I disagree. The lock is for the ports, not the hubs. We should take
> the lock when we are going through the ports of a hub, but release it
> between the hubs. Otherwise we will be only keeping things on hold for
> a long period of time for no good reason (I for example have to
> evaluate the _PLD of every single port which takes a lot of time). We
> don't need to prevent other things from happening to the hubs at the
> same time.

All right, you convinced me.

Acked-by: Alan Stern <stern@rowland.harvard.edu>

Alan Stern

  reply	other threads:[~2021-03-30 15:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29  8:44 [PATCH v2 0/6] usb: Linking ports to their Type-C connectors Heikki Krogerus
2021-03-29  8:44 ` [PATCH v2 1/6] usb: typec: Organize the private headers properly Heikki Krogerus
2021-03-29  8:44 ` [PATCH v2 2/6] usb: typec: Declare the typec_class static Heikki Krogerus
2021-03-29  8:44 ` [PATCH v2 3/6] usb: typec: Port mapping utility Heikki Krogerus
2021-03-29 15:15   ` kernel test robot
2021-03-29 15:15     ` kernel test robot
2021-03-29 16:06   ` kernel test robot
2021-03-29 16:06     ` kernel test robot
2021-03-29  8:44 ` [PATCH v2 4/6] usb: Link the ports to the connectors they are attached to Heikki Krogerus
2021-03-29  8:44 ` [PATCH v2 5/6] usb: Iterator for ports Heikki Krogerus
2021-03-29 18:49   ` Alan Stern
2021-03-30  9:07     ` Heikki Krogerus
2021-03-30 15:49       ` Alan Stern [this message]
2021-03-29  8:44 ` [PATCH v2 6/6] usb: typec: Link all ports during connector registration Heikki Krogerus
2021-03-29  8:48   ` Greg Kroah-Hartman
2021-03-29  9:17     ` Heikki Krogerus
2021-03-29  9:19       ` Heikki Krogerus
2021-03-29  9:21         ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210330154921.GC980260@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=bleung@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pmalani@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.