linux-kernel - Re: [PATCH v3 1/3] usb: core: add dma-noncoherent buffer alloc and free API

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3fgwq3edev4lwm4rumh5zekdhq74e6r6qxb65i5kc5s2o3gfs3@eal5mr7cpnfh>
Date: Thu, 3 Jul 2025 16:42:57 +0800
From: Xu Yang <xu.yang_2@....com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: ezequiel@...guardiasur.com.ar, mchehab@...nel.org, 
	laurent.pinchart@...asonboard.com, hdegoede@...hat.com, gregkh@...uxfoundation.org, 
	mingo@...nel.org, tglx@...utronix.de, andriy.shevchenko@...ux.intel.com, 
	viro@...iv.linux.org.uk, thomas.weissschuh@...utronix.de, dafna.hirschfeld@...labora.com, 
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org, 
	imx@...ts.linux.dev, jun.li@....com
Subject: Re: [PATCH v3 1/3] usb: core: add dma-noncoherent buffer alloc and
 free API

On Wed, Jul 02, 2025 at 10:32:01AM -0400, Alan Stern wrote:
> On Wed, Jul 02, 2025 at 07:02:20PM +0800, Xu Yang wrote:
> > This will add usb_alloc_noncoherent() and usb_free_noncoherent()
> > functions to support alloc and free buffer in a dma-noncoherent way.
> > 
> > To explicit manage the memory ownership for the kernel and device,
> > this will also add usb_dma_noncoherent_sync_for_cpu/device() functions
> > and call it at proper time.  The management requires the user save
> > sg_table returned by usb_alloc_noncoherent() to urb->sgt.
> > 
> > Signed-off-by: Xu Yang <xu.yang_2@....com>
> > 
> > ---
> > Changes in v3:
> >  - put Return section at the end of description
> >  - correct some abbreviations
> >  - remove usb_dma_noncoherent_sync_for_cpu() and
> >    usb_dma_noncoherent_sync_for_device()
> >  - do DMA sync in usb_hcd_map_urb_for_dma() and
> >    usb_hcd_unmap_urb_for_dma()
> >  - call flush_kernel_vmap_range() for OUT transfers
> >    and invalidate_kernel_vmap_range() for IN transfers
> > ---
> >  drivers/usb/core/hcd.c | 19 ++++++++++
> >  drivers/usb/core/usb.c | 80 ++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/usb.h    | 11 ++++++
> >  3 files changed, 110 insertions(+)
> > 
> > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> > index c22de97432a0..e0fa6d6d273b 100644
> > --- a/drivers/usb/core/hcd.c
> > +++ b/drivers/usb/core/hcd.c
> > @@ -1366,6 +1366,14 @@ void usb_hcd_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
> >  				urb->transfer_buffer_length,
> >  				dir);
> >  
> > +	if ((urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) &&
> > +	    urb->sgt) {
> 
> Shouldn't this be "else if"?  There aren't any circumstances where a 
> driver might want to do two DMA mappings for the same buffer, are there?

Yes, right. I'll put these line to "else if".

Thanks,
Xu Yang

> 
> > +		dma_sync_sgtable_for_cpu(hcd->self.sysdev, urb->sgt, dir);
> > +		if (dir == DMA_FROM_DEVICE)
> > +			invalidate_kernel_vmap_range(urb->transfer_buffer,
> > +						     urb->transfer_buffer_length);
> > +	}
> > +
> 
> Alan Stern