linux-kernel - Re: [PATCH v2 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] [day] [month] [year] [list]

Message-ID: <h7ovqshmy4s6kehal3gywuxxj6zf4uajqpu6lxdmo6id5mpvs5@e47v6d5tfe4q>
Date: Tue, 1 Jul 2025 17:32:03 +0800
From: Xu Yang <xu.yang_2@....com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Alan Stern <stern@...land.harvard.edu>, Christoph Hellwig <hch@....de>, 
	ezequiel@...guardiasur.com.ar, mchehab@...nel.org, 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, 
	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 v2 1/3] usb: core: add dma-noncoherent buffer alloc and
 free API

Hi Alan and Laurent,

On Mon, Jun 30, 2025 at 08:38:51PM +0300, Laurent Pinchart wrote:
> Hi Alan,
> 
> On Mon, Jun 30, 2025 at 10:16:30AM -0400, Alan Stern wrote:
> > On Mon, Jun 30, 2025 at 04:18:51PM +0800, Xu Yang wrote:
> > > > Also, the material that this routine replaces in the uvc and stk1160 
> > > > drivers do not call flush_kernel_vmap_range().  Why did you add that 
> > > > here?  Was this omission a bug in those drivers?
> > > 
> > > According to dma-api.rst:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/tree/Documentation/core-api/dma-api.rst?h=linux-6.15.y#n664
> > > 
> > > "Once a non-contiguous allocation is mapped using this function, the
> > > flush_kernel_vmap_range() and invalidate_kernel_vmap_range() APIs must
> > > be used to manage the coherency between the kernel mapping, the device
> > > and user space mappings (if any)."
> > > 
> > > Possibly the uvc and stk1160 missed calling it, but since they won't be
> > > the only user of the USB core, so we'd better call these APIs.
> > 
> > Documentation/core-api/cachetbl.rst says:
> > 
> >   ``void flush_kernel_vmap_range(void *vaddr, int size)``
> > 
> >        flushes the kernel cache for a given virtual address range in
> >        the vmap area.  This is to make sure that any data the kernel
> >        modified in the vmap range is made visible to the physical
> >        page.  The design is to make this area safe to perform I/O on.
> >        Note that this API does *not* also flush the offset map alias
> >        of the area.
> > 
> >   ``void invalidate_kernel_vmap_range(void *vaddr, int size) invalidates``
> > 
> >        the cache for a given virtual address range in the vmap area
> >        which prevents the processor from making the cache stale by
> >        speculatively reading data while the I/O was occurring to the
> >        physical pages.  This is only necessary for data reads into the
> >        vmap area.
> > 
> > So invalidate_kernel_vmap_range() is not needed for data writes, that 
> > is, for OUT transfers.  And ironically, flush_kernel_vmap_range() _is_ 
> > needed (but only for OUT transfers).
> 
> flush_kernel_vmap_range() for OUT transfers and
> invalidate_kernel_vmap_range() for IN transfers make sense to me.

Many thanks for your suggestions!
I'll do it in next version.

Thanks,
Xu Yang

> 
> > On the other hand, Christoph may think these call should be included 
> > regardless.  Let's see what he recommends.  Christoph?
> > 
> > (Actually, I would expect dma_sync_sgtable_for_cpu() and 
> > dma_sync_sgtable_for_device() to handle all of this for us 
> > automatically, but never mind...)
> 
> -- 
> Regards,
> 
> Laurent Pinchart