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

On 28-09-2017 18:35, Raj, Ashok wrote: > Thanks for trying that Harsh. > > sp_off turns of super page support. Which this mode, do you still see offsets > greater than 4k? Yes, offset greater than 4k is still there. Refer below. [56732.774872] offset 4110 len 76 dma addr 3a531200e dma len 76

Re: [lkp-robot] [mac80211] 31e9170bde: hwsim.sta_dynamic_down_up.fail

Thanks, I will look into it. Xiang Gao 2017-09-28 4:06 GMT-04:00 kernel test robot : > > FYI, we noticed the following commit: > > commit: 31e9170bdeb6ebe66426337b4e2b9924683a412b ("mac80211: aead api to > reduce redundancy") > url: >

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

Hi Robin thanks.. i have no idea.. i see all the other patches from you :-) my email has decided to play games with me i suppose :-) On Thu, Sep 28, 2017 at 05:59:11PM +0100, Robin Murphy wrote: > I hope our email server hasn't got blacklisted again... Said patch is > the top of this very thread

Re: [v2 PATCH 5/5] Bluetooth: let the crypto subsystem generate the ecc privkey

Hi Tudor, > That Bluetooth SMP knows about the private key is pointless, since the > detection of debug key usage is actually via the public key portion. > With this patch, the Bluetooth SMP will stop keeping a copy of the > ecdh private key and will let the crypto subsystem to generate and >

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

Hi Casey On Thu, Sep 28, 2017 at 04:17:59PM +, Casey Leedom wrote: > Thanks Robin. Harsh can certainly test your latest patch as soon as he's > back in the office tomorrow morning India time. If your patch works and is > accepted, it sounds like the commit would be important enough to

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

Thanks Robin. Harsh can certainly test your latest patch as soon as he's back in the office tomorrow morning India time. If your patch works and is accepted, it sounds like the commit would be important enough to consider backporting into various Long-Term Support releases and the affected

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

Thanks for trying that Harsh. sp_off turns of super page support. Which this mode, do you still see offsets greater than 4k? On Thu, Sep 28, 2017 at 07:08:21PM +0530, Harsh Jain wrote: > > > Today I tried with "Intel_iommu=sp_off" boot option. Traffic runs without any > error for more than

[v2 PATCH 5/5] Bluetooth: let the crypto subsystem generate the ecc privkey

That Bluetooth SMP knows about the private key is pointless, since the detection of debug key usage is actually via the public key portion. With this patch, the Bluetooth SMP will stop keeping a copy of the ecdh private key and will let the crypto subsystem to generate and handle the ecdh private

[v2 PATCH 3/5] Bluetooth: selftest - check for errors when computing ZZ

Signed-off-by: Tudor Ambarus --- net/bluetooth/selftest.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/selftest.c b/net/bluetooth/selftest.c index 126bdc5..ce99648 100644 --- a/net/bluetooth/selftest.c +++

[v2 PATCH 4/5] Bluetooth: ecdh_helper - fix leak of private key

tmp buffer contains the swapped private key. In case the setkey call failed, the tmp buffer was freed without clearing the private key. Zeroize the temporary buffer so we don't leak the private key. Signed-off-by: Tudor Ambarus --- net/bluetooth/ecdh_helper.c | 2

[v2 PATCH 2/5] Bluetooth: ecdh_helper - reveal error codes

ecdh_helper functions were hiding the error codes and chose to return the return value of an relational operator, "==". Remove the unnecessary query and reveal the error codes. While updating the return values, code in a way that compilers will warn in case of uninitialized err. Signed-off-by:

[v2 PATCH 1/5] Bluetooth: move ecdh allocation outside of ecdh_helper

Before this change, a new crypto tfm was allocated, each time, for both key generation and shared secret computation. Allocate a single tfm for both cases. Signed-off-by: Tudor Ambarus --- net/bluetooth/ecdh_helper.c | 32 -

[v2 PATCH 0/5] Bluetooth: let the crypto subsystem generate the ecc privkey

That Bluetooth SMP knows about the private key is pointless, since the detection of debug key usage is actually via the public key portion. With this patch set, the Bluetooth SMP will stop keeping a copy of the ecdh private key. We let the crypto subsystem to generate and handle the ecdh private

[PATCH] iommu/vt-d: Fix scatterlist offset handling

The intel-iommu DMA ops fail to correctly handle scatterlists where sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed appropriately based on the page-aligned portion of the offset, but the mapping is set up relative to sg->page, which means it fails to actually cover the whole

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

On 28-09-2017 02:59, Casey Leedom wrote: > Hey Raj, > > Let us know if you need help in gathering more debugging information. For > the time being we've decided to ERRATA the use of the Intel I/O MMU with > IPsec till we Root Cause the issue. But this is still at the top of Harsh's > bug

Re: [GIT PULL] KEYS: Fixes and crypto fixes

On Thu, Sep 28, 2017 at 12:08:36PM +1000, James Morris wrote: > On Wed, 27 Sep 2017, Eric Biggers wrote: > > > On Thu, Sep 28, 2017 at 09:14:58AM +1000, James Morris wrote: > > > On Wed, 27 Sep 2017, David Howells wrote: > > > > > > > (2) Fixing big_key to use safe crypto from Jason A.

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

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

Re: Question about ahash export and import

On Wed, Sep 27, 2017 at 04:59:56PM +0200, Christophe LEROY wrote: > > Can we consider that once an export has been done, no new update call will > be performed prior to doing an init or an import ? Or should it be possible > to continue with an update or a final/finup call after an export ? No