Re: [PATCH] crypto: qat - stop using iommu_present()

2022-04-15 Thread Herbert Xu
On Tue, Apr 05, 2022 at 01:25:11PM +0100, Robin Murphy wrote:
> Even if an IOMMU might be present for some PCI segment in the system,
> that doesn't necessarily mean it provides translation for the device
> we care about. Replace iommu_present() with a more appropriate check.
> 
> Signed-off-by: Robin Murphy 
> ---
>  drivers/crypto/qat/qat_common/adf_sriov.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] uacce: unmap remaining mmapping from user space

2020-03-05 Thread Herbert Xu
On Wed, Feb 26, 2020 at 03:12:06PM +0800, Zhangfei Gao wrote:
> When uacce parent device module is removed, user app may
> still keep the mmaped area, which can be accessed unsafely.
> When rmmod, Parent device driver will call uacce_remove,
> which unmap all remaining mapping from user space for safety.
> VM_FAULT_SIGBUS is also reported to user space accordingly.
> 
> Suggested-by: Dave Jiang 
> Signed-off-by: Zhangfei Gao 
> ---
>  v2: Unmap before put_queue, where memory is freed, commented from Zaibo.
> 
>  drivers/misc/uacce/uacce.c | 16 
>  include/linux/uacce.h  |  2 ++
>  2 files changed, 18 insertions(+)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] MAINTAINERS: add maintainers for uacce

2020-03-05 Thread Herbert Xu
On Wed, Feb 26, 2020 at 09:28:28AM +0800, Zhangfei Gao wrote:
> Add Zhangfei Gao and Zhou Wang as maintainers for uacce
> 
> Signed-off-by: Zhangfei Gao 
> Signed-off-by: Zhou Wang 
> ---
> Add list, suggested by Dave
> 
> MAINTAINERS | 12 
>  1 file changed, 12 insertions(+)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v13 0/4] Add uacce module for Accelerator

2020-02-21 Thread Herbert Xu
emory in place.  This is flexible. But it can cause other problems. For
> example, if the user process fork a child process. The COW procedure may make
> the parent process lost its pages which are sharing with the device. These may
> be fixed in the future. But is not going to be easy. (There is a discussion
> about this on Linux Plumbers Conference 2018 [1])
> 
> So we choose to build the solution directly on top of IOMMU interface. IOMMU
> is the essential way for device and process to share their page mapping from
> the hardware perspective. It will be safe to create a software solution on
> this assumption.  Uacce manages the IOMMU interface for the accelerator
> device, so the device driver can export some of the resources to the user
> space. Uacce than can make sure the device and the process have the same
> address space.
> 
> 
> References
> ==
> .. [1] https://lwn.net/Articles/774411/
> 
> Kenneth Lee (2):
>   uacce: Add documents for uacce
>   uacce: add uacce driver
> 
> Zhangfei Gao (2):
>   crypto: hisilicon - Remove module_param uacce_mode
>   crypto: hisilicon - register zip engine to uacce
> 
>  Documentation/ABI/testing/sysfs-driver-uacce |  39 ++
>  Documentation/misc-devices/uacce.rst | 176 ++
>  drivers/crypto/hisilicon/qm.c| 239 ++-
>  drivers/crypto/hisilicon/qm.h|  11 +
>  drivers/crypto/hisilicon/zip/zip_main.c  |  49 +-
>  drivers/misc/Kconfig |   1 +
>  drivers/misc/Makefile    |   1 +
>  drivers/misc/uacce/Kconfig   |  13 +
>  drivers/misc/uacce/Makefile  |   2 +
>  drivers/misc/uacce/uacce.c   | 617 +++
>  include/linux/uacce.h| 161 +
>  include/uapi/misc/uacce/hisi_qm.h|  23 +
>  include/uapi/misc/uacce/uacce.h  |  38 ++
>  13 files changed, 1337 insertions(+), 33 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-uacce
>  create mode 100644 Documentation/misc-devices/uacce.rst
>  create mode 100644 drivers/misc/uacce/Kconfig
>  create mode 100644 drivers/misc/uacce/Makefile
>  create mode 100644 drivers/misc/uacce/uacce.c
>  create mode 100644 include/linux/uacce.h
>  create mode 100644 include/uapi/misc/uacce/hisi_qm.h
>  create mode 100644 include/uapi/misc/uacce/uacce.h

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v12 2/4] uacce: add uacce driver

2020-02-13 Thread Herbert Xu
On Mon, Feb 10, 2020 at 03:37:11PM -0800, Greg Kroah-Hartman wrote:
>
> Looks much saner now, thanks for all of the work on this:
> 
> Reviewed-by: Greg Kroah-Hartman 
> 
> Or am I supposed to take this in my tree?  If so, I can, but I need an
> ack for the crypto parts.

I can take this series through the crypto tree if that's fine with
you.

Thank,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/3] crypto: marvell: Use kzfree rather than its implementation

2019-09-09 Thread Herbert Xu
On Wed, Sep 04, 2019 at 11:01:17AM +0800, zhong jiang wrote:
> Use kzfree instead of memset() + kfree().
> 
> Signed-off-by: zhong jiang 
> ---
>  drivers/crypto/marvell/hash.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 03/20] crypto: Remove depends on HAS_DMA in case of platform dependency

2018-04-28 Thread Herbert Xu
On Tue, Apr 17, 2018 at 07:49:03PM +0200, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
> 
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
> 
> This simplifies the dependencies, and allows to improve compile-testing.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Mark Brown 
> Acked-by: Robin Murphy 
> Acked-by: Herbert Xu 
> ---
> v3:
>   - Add Acked-by,
>   - Rebase to v4.17-rc1,
> 
> v2:
>   - Add Reviewed-by, Acked-by,
>   - Drop RFC state,
>   - Split per subsystem.
> ---
>  drivers/crypto/Kconfig | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

2018-03-16 Thread Herbert Xu
On Fri, Mar 16, 2018 at 04:41:57PM +0100, Geert Uytterhoeven wrote:
>
> | To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
> | this (drivers) series should be applied after the previous (core)
> | series (but not many people may notice/care ;-)

Oops, didn't notice it :)

> Apart from introducing build failures in allmodconfig/allyesconfig builds on
> (uncommon) NO_DMA=y platforms, they can be applied directly and individually.

I think I'll leave this with you then.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 03/21] crypto: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Herbert Xu
On Fri, Mar 16, 2018 at 02:51:36PM +0100, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
> 
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
> 
> This simplifies the dependencies, and allows to improve compile-testing.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Mark Brown 
> Acked-by: Robin Murphy 

Acked-by: Herbert Xu 
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

2018-03-16 Thread Herbert Xu
On Fri, Mar 16, 2018 at 02:51:33PM +0100, Geert Uytterhoeven wrote:
>
> This patch series:
>   - Removes dependencies on HAS_DMA for symbols that already have
> platform dependencies implying HAS_DMA.
> 
> To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
> this (drivers) series should be applied after the previous (core)
> series (but not many people may notice/care ;-)
> 
> Changes compared to v1:
>   - Add Reviewed-by, Acked-by,
>   - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
>   - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
>   - Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
> MTD_NAND_MARVELL on HAS_DMA,
>   - Split in per-subsystem patches,
>   - Split-off the core part in a separate series.
> 
> This series is against v4.16-rc5. It can also be found at
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2
> 
> It has been compile-tested with allmodconfig and allyesconfig for
> m68k/sun3, and has received attention from the kbuild test robot.

Do these patches have any dependencies? Can they be applied directly
in a subsystem tree?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

2017-09-28 Thread Herbert Xu
On Wed, Sep 27, 2017 at 10:13:04PM +, Casey Leedom wrote:
> | From: Raj, Ashok 
> | Sent: Wednesday, September 27, 2017 12:07 PM
> |
> | looking at the debug output i got from Harsh it still looks like a bug in
> | the code.
> |
> | [  538.284589] __domain_mapping nr_pages 0x1
> | [ 538.284600] __domain_mapping sg_res 0x1 sg->dma_address 0xf291000e dma len
> | 0x38 pteval 0x3cbce3003 phys_pfn 0x3cbce3
> | [ 538.284604] chelsio driver - offset 4110 len 56 dma addr f291000e dma len
> | 56
> | [  538.284667] DMAR: DRHD: handling fault status reg 2
> | [ 538.290017] DMAR: [DMA Write] Request device [02:00.4] fault addr f291
> | [fault reason 05] PTE Write access is not set
> |
> | somehow when crypto_authenc_encrypt() -> scatterwalk_ffwd()-> sg_set_page()
> |
> | ->sg_set_page(dst, sg_page(src), src->length - len, src->offset + len);
> |
> | src->offset + len gets set as sg->offset in sg_set_page(). Either the
> | assumption that there should be room is incorrect, or some higher order
> | crypto
> | code that ends up setting the offset did the wrong calculation.
> |
> | if src->offset is already towards the end of the page, then offset+len will
> | go beyond the end of page.
> 
>   Hhmmm, it seems like we need Herbert to comment on this.
> 
>   Herbert, is there any specific debugging information that you'd like to
> see here?

OK I was mistaken.  While SG lists can contain entries that are
larger than PAGE_SIZE, there is no reason why scatterwalk_ffwd
should gratuitously insert a page_offset that is greater than
PAGE_SIZE.

Harsh, can you please submit your original patch with a sign-off?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

2017-09-20 Thread Herbert Xu
Harsh Jain  wrote:
> 
> While debugging DMA mapping error in chelsio crypto driver we observed that 
> when scatter/gather list received by driver has some entry with page->offset 
> > 4096 (PAGE_SIZE). It starts giving DMA error.  Without IOMMU it works fine.

This is not a bug.  The network stack can and will feed us such
SG lists.

> 2) It cannot be driver's responsibilty to update received sg entries to 
> adjust offset and page 
> because we are not the only one who directly uses received sg list.

No the driver must deal with this.  Having said that, if we can
improve our driver helper interface to make this easier then we
should do that too.  What we certainly shouldn't do is to take a
whack-a-mole approach like this patch does.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu