[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fbf87ddf-6d8e-43b7-b9f5-65025395b170@rowland.harvard.edu>
Date: Sat, 31 Aug 2024 00:29:02 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Selvarasu Ganesan <selvarasu.g@...sung.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, royluo@...gle.com,
paul@...pouillou.net, elder@...nel.org, yuanlinyu@...onor.com,
quic_kriskura@...cinc.com, crwulff@...il.com,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
jh0801.jung@...sung.com, dh10.jung@...sung.com, naushad@...sung.com,
akash.m5@...sung.com, rc93.raju@...sung.com,
taehyun.cho@...sung.com, hongpooh.kim@...sung.com,
eomji.oh@...sung.com, shijie.cai@...sung.com,
stable <stable@...nel.org>
Subject: Re: [PATCH] usb: gadget: udc: Add null pointer check for udc in
gadget_match_driver
On Fri, Aug 30, 2024 at 06:16:12PM +0530, Selvarasu Ganesan wrote:
> Hi Alan,
>
> Thanks for your comments. I understand your suggestions. We already have
> a similar reference check with the udc name before calling
> usb_gadget_register_driver.
> In the drivers/usb/gadget/configfs.c file, I am wondering if there might
> be an issue with the check of udc_name before
> usb_gadget_register_driver. This is the only way to allow
> gadget_register to be called before releasing or unregistering an
> existing udc. Do you think we need to add an additional check here,
> referencing the UDC, to prevent gadget_register from being called before
> the existing UDC is released?
I don't understand what you're saying. There is no routine named
"gadget_register". (And there is no variable named "udc_name" in the
code below, although there is gi->composite.gadget_driver.udc_name --
but that's not a variable, it is a field in a structure.)
> drivers/usb/gadget/configfs.c : gadget_dev_desc_UDC_store()
> ===========================================================
> if (gi->composite.gadget_driver.udc_name) {
> ret = -EBUSY;
> goto err;
> }
> gi->composite.gadget_driver.udc_name = name;
Are you talking about this check and assignment? Why do you think there
might be a problem here?
Are you worried that some UDC might be released while this code is
running? If that happens, why would it be a problem?
> ret = usb_gadget_register_driver(&gi->composite.gadget_driver);
Alan Stern
Powered by blists - more mailing lists