linux-kernel - Re: [PATCH v2] usb: dwc2: add missing SLAB_CACHE_DMA flag for desc_hsisoc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAP_JKPuve2pHzcMwzApmNHFXHsmKHB2PFKWqBLf0gg0j0KTtmw@mail.gmail.com>
Date: Tue, 13 Jan 2026 15:16:54 +0530
From: karthikeyan K S <karthiproffesional@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: hminas@...opsys.com, gregory.herrero@...el.com, linux-usb@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] usb: dwc2: add missing SLAB_CACHE_DMA flag for desc_hsisoc_cache

Hi Greg,

Thanks for the detailed review.

> Are you sure this is ok? You are now taking from a _very_ limited chunk
> of memory for this controller.

All current allocation sites already pass GFP_DMA, so DMA-zone memory
is already being consumed today. That said, I fully understand the
concern about further constraining allocations at the cache level.

> What platform is this that requires this, and what changed to suddenly
> need this to be this way?

No specific platform requires this, and nothing is broken. I noticed
this during code review, as desc_gen_cache uses SLAB_CACHE_DMA while
desc_hsisoc_cache does not, despite both being used for DMA descriptors.

> So I would like to find out why this is needed now, all these years
> later. What caused this to show up at this point in time?

There is no functional need. The current code works correctly because
GFP_DMA is always passed at allocation time. This was only a
consistency cleanup, and using a Fixes tag here was incorrect.

Given that this is long-working code with no real-world issue, I agree
this change is not justified and I will withdraw the patch and not
resend it.

> Also, should this go to stable kernels?

No, since no bug is being fixed.

Regards,
Karthikeyan

On Sun, Jan 11, 2026 at 6:36 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Sun, Jan 11, 2026 at 12:32:18PM +0000, Karthikeyan K S wrote:
> > The desc_hsisoc_cache kmem_cache is used to allocate DMA descriptors
> > for High-Speed isochronous transfers. These descriptors are passed to
> > the hardware via dma_map_single() in dwc2_desc_list_alloc().
> >
> > The desc_gen_cache, which serves the same purpose for other transfer
> > types, correctly specifies SLAB_CACHE_DMA. However, desc_hsisoc_cache
> > was created without this flag, despite both caches being used
> > identically for DMA descriptor allocation.
> >
> > Add the missing SLAB_CACHE_DMA flag to desc_hsisoc_cache for
> > consistency and correctness on platforms with DMA zone restrictions.
> > This also protects against future allocations from this cache that
> > might omit GFP_DMA.
> >
> > Fixes: 3b5fcc9ac2f4 ("usb: dwc2: host: use kmem cache to allocate descriptors")
> >
> > Signed-off-by: Karthikeyan K S <karthiproffesional@...il.com>
>
> Nit, no blank line needed after the Fixes: line and before your s-o-b
> line.
>
> Also, should this go to stable kernels?
>
> But:
>
> > ---
> > v2: Resend with proper formatting (previous was corrupted by email client)
> > ---
> >  drivers/usb/dwc2/hcd.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> > index 30eb85066..556d6ab36 100644
> > --- a/drivers/usb/dwc2/hcd.c
> > +++ b/drivers/usb/dwc2/hcd.c
> > @@ -5273,7 +5273,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg)
> >
> >               hsotg->desc_hsisoc_cache = kmem_cache_create("dwc2-hsisoc-desc",
> >                               sizeof(struct dwc2_dma_desc) *
> > -                             MAX_DMA_DESC_NUM_HS_ISOC, 512, 0, NULL);
> > +                             MAX_DMA_DESC_NUM_HS_ISOC, 512, SLAB_CACHE_DMA, NULL);
>
> Are you sure this is ok?  You are now taking from a _very_ limited chunk
> of memory for this controller.  What platform is this that requires
> this, and what changed to suddenly need this to be this way?  The driver
> has been working for a very long time without this, and I am loath to
> change this now as it might hit many existing systems that have a very
> limited GFP_DMA memory range that did not expect a new allocation there
> now.
>
> So I would like to find out why this is needed now, all these years
> later.  What caused this to show up at this point in time?
>
> thanks,
>
> greg k-h