Messages in this thread | | | Date | Wed, 26 Jan 2022 18:22:45 +0800 | Subject | Re: [PATCH -next] xhci: fix two places when dealing with return value of function xhci_check_args | From | 谢泓宇 <> |
| |
1."What problem? r8152_submit_rx needs to detach netdev if -ENODEV happened, but -ENODEV will never happen because xhci_urb_enqueue only returns -EINVAL if the return value of xhci_check_args <= 0. So r8152_submit_rx will will call napi_schedule to re-submit that urb, and this will cause infinite urb submission. The whole point is, if xhci_check_args returns value A, xhci_urb_enqueque shouldn't return any other value, because that will change some driver's behavior(like r8152.c).
2."So if 0 is returned, you will now return that here, is that ok? That is a change in functionality. But this can only ever be the case for a root hub, is that ok?"
It's the same logic, but now xhci_urb_enqueue can return -ENODEV if xHC is halted. If it happens on a root hub, xhci_urb_enqueue won't be called.
3."Again, this means all is good? Why is this being called for a root hub?"
It is the same logic with the old one, but now xhci_check_streams_endpoint can return -ENODEV if xHC is halted.
thanks
Hongyu Xie
On Tue, 25 Jan 2022 at 22:02, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Wed, Jan 26, 2022 at 05:41:26PM +0800, Hongyu Xie wrote: >> From: Hongyu Xie <xiehongyu1@kylinos.cn> >> >> xhci_check_args returns 4 types of value, -ENODEV, -EINVAL, 1 and 0. >> xhci_urb_enqueue and xhci_check_streams_endpoint return -EINVAL if >> the return value of xhci_check_args <= 0. >> This will cause a problem. > What problem? > >> For example, r8152_submit_rx calling usb_submit_urb in >> drivers/net/usb/r8152.c. >> r8152_submit_rx will never get -ENODEV after submiting an urb >> when xHC is halted, >> because xhci_urb_enqueue returns -EINVAL in the very beginning. >> >> Fixes: 203a86613fb3 ("xhci: Avoid NULL pointer deref when host dies.") >> Cc: stable@vger.kernel.org >> Signed-off-by: Hongyu Xie <xiehongyu1@kylinos.cn> >> --- >> drivers/usb/host/xhci.c | 9 ++++++--- >> 1 file changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index dc357cabb265..a7a55dd206fe 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -1604,9 +1604,12 @@ static int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flag >> struct urb_priv *urb_priv; >> int num_tds; >> >> - if (!urb || xhci_check_args(hcd, urb->dev, urb->ep, >> - true, true, __func__) <= 0) >> + if (!urb) >> return -EINVAL; >> + ret = xhci_check_args(hcd, urb->dev, urb->ep, >> + true, true, __func__); >> + if (ret <= 0) >> + return ret; > So if 0 is returned, you will now return that here, is that ok? > That is a change in functionality. > > But this can only ever be the case for a root hub, is that ok? > >> >> slot_id = urb->dev->slot_id; >> ep_index = xhci_get_endpoint_index(&urb->ep->desc); >> @@ -3323,7 +3326,7 @@ static int xhci_check_streams_endpoint(struct xhci_hcd *xhci, >> return -EINVAL; >> ret = xhci_check_args(xhci_to_hcd(xhci), udev, ep, 1, true, __func__); >> if (ret <= 0) >> - return -EINVAL; >> + return ret; > Again, this means all is good? Why is this being called for a root hub? > > thanks, > > greg k-h
| |