| Message ID | 20210121202855.17400-1-tiwai@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: pwc: Fix the URB buffer allocation | expand |
Thanks for the patch, it all looks good to me. Feel free to add my r-b: Reviewed-by: Robert Foss <robert.foss@linaro.org> On Thu, 21 Jan 2021 at 21:34, Takashi Iwai <tiwai@suse.de> wrote: > > The URB buffer allocation of pwc driver involves with the > dma_map_single(), and it needs to pass the right device. Currently it > passes usb_device.dev, but it's no real device that manages the DMA. > Since the passed device has no DMA mask set up, now the pwc driver > hits the WARN_ON_ONCE() check in dma_map_page_attrs() (that was > introduced in 5.10), resulting in an error at URB allocations. > Eventually this ended up with the black output. > > This patch fixes the bug by passing the proper device, the bus > controller, to make the URB allocation and map working again. > > BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1181133 > Cc: <stable@vger.kernel.org> > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > drivers/media/usb/pwc/pwc-if.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c > index 61869636ec61..d771160bb168 100644 > --- a/drivers/media/usb/pwc/pwc-if.c > +++ b/drivers/media/usb/pwc/pwc-if.c > @@ -461,7 +461,7 @@ static int pwc_isoc_init(struct pwc_device *pdev) > urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint); > urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP; > urb->transfer_buffer_length = ISO_BUFFER_SIZE; > - urb->transfer_buffer = pwc_alloc_urb_buffer(&udev->dev, > + urb->transfer_buffer = pwc_alloc_urb_buffer(udev->bus->controller, > urb->transfer_buffer_length, > &urb->transfer_dma); > if (urb->transfer_buffer == NULL) { > @@ -524,7 +524,7 @@ static void pwc_iso_free(struct pwc_device *pdev) > if (urb) { > PWC_DEBUG_MEMORY("Freeing URB\n"); > if (urb->transfer_buffer) > - pwc_free_urb_buffer(&urb->dev->dev, > + pwc_free_urb_buffer(urb->dev->bus->controller, > urb->transfer_buffer_length, > urb->transfer_buffer, > urb->transfer_dma); > -- > 2.26.2 >
Hi Takashi, Thank you for this patch, but it clashes with another patch trying to do the same thing that has already been merged in our tree: https://patchwork.linuxtv.org/project/linux-media/patch/20210104170007.20625-1-matwey@sai.msu.ru/ I do prefer your patch over the one already merged since it is a bit simpler, but shouldn't the calls to dma_sync_single_for_cpu() and dma_sync_single_for_device() in pwc-if.c also use urb->dev->bus->controller? Also, Matwey's patch uses urb->dev->bus->sysdev instead of urb->dev->bus->controller. How does 'sysdev' relate to 'controller'? I think 'controller' is the right device to use, but either seems to work when I test it with my pwc webcam. Andrew, your patch: https://patchwork.linuxtv.org/project/linux-media/patch/20210204232851.1020416-1-andrew@lunn.ch/ is effectively identical to Takashi's, so I'll mark your patch as Obsoleted. Just so you know :-) Regards, Hans On 21/01/2021 21:28, Takashi Iwai wrote: > The URB buffer allocation of pwc driver involves with the > dma_map_single(), and it needs to pass the right device. Currently it > passes usb_device.dev, but it's no real device that manages the DMA. > Since the passed device has no DMA mask set up, now the pwc driver > hits the WARN_ON_ONCE() check in dma_map_page_attrs() (that was > introduced in 5.10), resulting in an error at URB allocations. > Eventually this ended up with the black output. > > This patch fixes the bug by passing the proper device, the bus > controller, to make the URB allocation and map working again. > > BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1181133 > Cc: <stable@vger.kernel.org> > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > drivers/media/usb/pwc/pwc-if.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c > index 61869636ec61..d771160bb168 100644 > --- a/drivers/media/usb/pwc/pwc-if.c > +++ b/drivers/media/usb/pwc/pwc-if.c > @@ -461,7 +461,7 @@ static int pwc_isoc_init(struct pwc_device *pdev) > urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint); > urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP; > urb->transfer_buffer_length = ISO_BUFFER_SIZE; > - urb->transfer_buffer = pwc_alloc_urb_buffer(&udev->dev, > + urb->transfer_buffer = pwc_alloc_urb_buffer(udev->bus->controller, > urb->transfer_buffer_length, > &urb->transfer_dma); > if (urb->transfer_buffer == NULL) { > @@ -524,7 +524,7 @@ static void pwc_iso_free(struct pwc_device *pdev) > if (urb) { > PWC_DEBUG_MEMORY("Freeing URB\n"); > if (urb->transfer_buffer) > - pwc_free_urb_buffer(&urb->dev->dev, > + pwc_free_urb_buffer(urb->dev->bus->controller, > urb->transfer_buffer_length, > urb->transfer_buffer, > urb->transfer_dma); >
On Fri, Feb 05, 2021 at 01:36:43PM +0100, Hans Verkuil wrote: > Hi Takashi, > > Thank you for this patch, but it clashes with another patch trying to do the same thing > that has already been merged in our tree: > > https://patchwork.linuxtv.org/project/linux-media/patch/20210104170007.20625-1-matwey@sai.msu.ru/ > > I do prefer your patch over the one already merged since it is a bit simpler, but > shouldn't the calls to dma_sync_single_for_cpu() and dma_sync_single_for_device() > in pwc-if.c also use urb->dev->bus->controller? > > Also, Matwey's patch uses urb->dev->bus->sysdev instead of urb->dev->bus->controller. > How does 'sysdev' relate to 'controller'? I think 'controller' is the right device to > use, but either seems to work when I test it with my pwc webcam. Hi Hans A quick grep in driver/usb show that all but one dma mapping operation use sysdev. The one other case uses controller. So the numbers suggest controller is wrong, sysdev is correct. But maybe ask GregKH? Andrew
On Fri, 05 Feb 2021 13:53:21 +0100, Andrew Lunn wrote: > > On Fri, Feb 05, 2021 at 01:36:43PM +0100, Hans Verkuil wrote: > > Hi Takashi, > > > > Thank you for this patch, but it clashes with another patch trying to do the same thing > > that has already been merged in our tree: > > > > https://patchwork.linuxtv.org/project/linux-media/patch/20210104170007.20625-1-matwey@sai.msu.ru/ > > > > I do prefer your patch over the one already merged since it is a bit simpler, but > > shouldn't the calls to dma_sync_single_for_cpu() and dma_sync_single_for_device() > > in pwc-if.c also use urb->dev->bus->controller? > > > > Also, Matwey's patch uses urb->dev->bus->sysdev instead of urb->dev->bus->controller. > > How does 'sysdev' relate to 'controller'? I think 'controller' is the right device to > > use, but either seems to work when I test it with my pwc webcam. > > Hi Hans > > A quick grep in driver/usb show that all but one dma mapping operation > use sysdev. The one other case uses controller. So the numbers suggest > controller is wrong, sysdev is correct. Indeed, looks so. In most cases, this doesn't matter since both point to the same device object. In some cases like xhci-plat HCD, they differ. And sysdev might be a better choice from the consistency POV. But this brought an interesting question, too. eg. USB chipidea HCD uses platform devices for both controller and sysdev, and I couldn't find any DMA mask setup. So, no matter what to use, the uwc driver would be broken on this... Maybe it's just not covered. > But maybe ask GregKH? To be certain, better to involve with USB people, yeah. thanks, Takashi
Hi Takashi > Indeed, looks so. In most cases, this doesn't matter since both point > to the same device object. In some cases like xhci-plat HCD, they > differ. And sysdev might be a better choice from the consistency > POV. > > But this brought an interesting question, too. eg. USB chipidea > HCD uses platform devices for both controller and sysdev, and I > couldn't find any DMA mask setup. So, no matter what to use, the uwc > driver would be broken on this... Maybe it's just not covered. Did you do a git bisect to see what actually broke it? "1161db6776bd: media: usb: pwc: Don't use coherent DMA buffers for ISO transfer" introduced the code, not the regression. If we understand the regression, that might give us the answer about chipidea. Andrew
On Fri, 05 Feb 2021 14:13:02 +0100, Andrew Lunn wrote: > > Hi Takashi > > > Indeed, looks so. In most cases, this doesn't matter since both point > > to the same device object. In some cases like xhci-plat HCD, they > > differ. And sysdev might be a better choice from the consistency > > POV. > > > > But this brought an interesting question, too. eg. USB chipidea > > HCD uses platform devices for both controller and sysdev, and I > > couldn't find any DMA mask setup. So, no matter what to use, the uwc > > driver would be broken on this... Maybe it's just not covered. > > Did you do a git bisect to see what actually broke it? "1161db6776bd: > media: usb: pwc: Don't use coherent DMA buffers for ISO transfer" > introduced the code, not the regression. If we understand the > regression, that might give us the answer about chipidea. It's the recent DMA core change, the commit f959dcd6ddfd ("dma-direct: Fix potential NULL pointer dereference"). But basically it's a right fix, and the driver hitting this "regression" has been already broken but casually worked without setting a proper DMA mask. Takashi
On Fri, Feb 05, 2021 at 02:42:23PM +0100, Takashi Iwai wrote: > On Fri, 05 Feb 2021 14:13:02 +0100, > Andrew Lunn wrote: > > > > Hi Takashi > > > > > Indeed, looks so. In most cases, this doesn't matter since both point > > > to the same device object. In some cases like xhci-plat HCD, they > > > differ. And sysdev might be a better choice from the consistency > > > POV. > > > > > > But this brought an interesting question, too. eg. USB chipidea > > > HCD uses platform devices for both controller and sysdev, and I > > > couldn't find any DMA mask setup. So, no matter what to use, the uwc > > > driver would be broken on this... Maybe it's just not covered. > > > > Did you do a git bisect to see what actually broke it? "1161db6776bd: > > media: usb: pwc: Don't use coherent DMA buffers for ISO transfer" > > introduced the code, not the regression. If we understand the > > regression, that might give us the answer about chipidea. > > It's the recent DMA core change, the commit f959dcd6ddfd ("dma-direct: > Fix potential NULL pointer dereference"). But basically it's a right > fix, and the driver hitting this "regression" has been already broken > but casually worked without setting a proper DMA mask. So for the chipidea, it also just 'casually worked'. But now it probably does not. But that is a separate chipidea issue. None of my ARM systems use the chipidea IP core, so i cannot test anything. Andrew
On 05/02/2021 14:53, Andrew Lunn wrote: > On Fri, Feb 05, 2021 at 02:42:23PM +0100, Takashi Iwai wrote: >> On Fri, 05 Feb 2021 14:13:02 +0100, >> Andrew Lunn wrote: >>> >>> Hi Takashi >>> >>>> Indeed, looks so. In most cases, this doesn't matter since both point >>>> to the same device object. In some cases like xhci-plat HCD, they >>>> differ. And sysdev might be a better choice from the consistency >>>> POV. >>>> >>>> But this brought an interesting question, too. eg. USB chipidea >>>> HCD uses platform devices for both controller and sysdev, and I >>>> couldn't find any DMA mask setup. So, no matter what to use, the uwc >>>> driver would be broken on this... Maybe it's just not covered. >>> >>> Did you do a git bisect to see what actually broke it? "1161db6776bd: >>> media: usb: pwc: Don't use coherent DMA buffers for ISO transfer" >>> introduced the code, not the regression. If we understand the >>> regression, that might give us the answer about chipidea. >> >> It's the recent DMA core change, the commit f959dcd6ddfd ("dma-direct: >> Fix potential NULL pointer dereference"). But basically it's a right >> fix, and the driver hitting this "regression" has been already broken >> but casually worked without setting a proper DMA mask. > > So for the chipidea, it also just 'casually worked'. But now it > probably does not. But that is a separate chipidea issue. None of my > ARM systems use the chipidea IP core, so i cannot test anything. Since few people use the pwc driver anymore, and certainly not on non-intel devices, I am happy with Matwey's patch as is merged in our media tree for 5.12. I'll mark Takashi's patch as Obsolete in patchwork as well. I might have an SBC with a chipidea, if so, I'll give it a quick spin. Regards, Hans
On Fri, 05 Feb 2021 15:05:00 +0100, Hans Verkuil wrote: > > On 05/02/2021 14:53, Andrew Lunn wrote: > > On Fri, Feb 05, 2021 at 02:42:23PM +0100, Takashi Iwai wrote: > >> On Fri, 05 Feb 2021 14:13:02 +0100, > >> Andrew Lunn wrote: > >>> > >>> Hi Takashi > >>> > >>>> Indeed, looks so. In most cases, this doesn't matter since both point > >>>> to the same device object. In some cases like xhci-plat HCD, they > >>>> differ. And sysdev might be a better choice from the consistency > >>>> POV. > >>>> > >>>> But this brought an interesting question, too. eg. USB chipidea > >>>> HCD uses platform devices for both controller and sysdev, and I > >>>> couldn't find any DMA mask setup. So, no matter what to use, the uwc > >>>> driver would be broken on this... Maybe it's just not covered. > >>> > >>> Did you do a git bisect to see what actually broke it? "1161db6776bd: > >>> media: usb: pwc: Don't use coherent DMA buffers for ISO transfer" > >>> introduced the code, not the regression. If we understand the > >>> regression, that might give us the answer about chipidea. > >> > >> It's the recent DMA core change, the commit f959dcd6ddfd ("dma-direct: > >> Fix potential NULL pointer dereference"). But basically it's a right > >> fix, and the driver hitting this "regression" has been already broken > >> but casually worked without setting a proper DMA mask. > > > > So for the chipidea, it also just 'casually worked'. But now it > > probably does not. But that is a separate chipidea issue. None of my > > ARM systems use the chipidea IP core, so i cannot test anything. > > Since few people use the pwc driver anymore, and certainly not on non-intel > devices, I am happy with Matwey's patch as is merged in our media tree for > 5.12. > > I'll mark Takashi's patch as Obsolete in patchwork as well. > > I might have an SBC with a chipidea, if so, I'll give it a quick spin. Fair enough. Thanks! Takashi
diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c index 61869636ec61..d771160bb168 100644 --- a/drivers/media/usb/pwc/pwc-if.c +++ b/drivers/media/usb/pwc/pwc-if.c @@ -461,7 +461,7 @@ static int pwc_isoc_init(struct pwc_device *pdev) urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint); urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP; urb->transfer_buffer_length = ISO_BUFFER_SIZE; - urb->transfer_buffer = pwc_alloc_urb_buffer(&udev->dev, + urb->transfer_buffer = pwc_alloc_urb_buffer(udev->bus->controller, urb->transfer_buffer_length, &urb->transfer_dma); if (urb->transfer_buffer == NULL) { @@ -524,7 +524,7 @@ static void pwc_iso_free(struct pwc_device *pdev) if (urb) { PWC_DEBUG_MEMORY("Freeing URB\n"); if (urb->transfer_buffer) - pwc_free_urb_buffer(&urb->dev->dev, + pwc_free_urb_buffer(urb->dev->bus->controller, urb->transfer_buffer_length, urb->transfer_buffer, urb->transfer_dma);
The URB buffer allocation of pwc driver involves with the dma_map_single(), and it needs to pass the right device. Currently it passes usb_device.dev, but it's no real device that manages the DMA. Since the passed device has no DMA mask set up, now the pwc driver hits the WARN_ON_ONCE() check in dma_map_page_attrs() (that was introduced in 5.10), resulting in an error at URB allocations. Eventually this ended up with the black output. This patch fixes the bug by passing the proper device, the bus controller, to make the URB allocation and map working again. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1181133 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> --- drivers/media/usb/pwc/pwc-if.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)