Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752370AbdI0WAd (ORCPT ); Wed, 27 Sep 2017 18:00:33 -0400 Received: from mga09.intel.com ([134.134.136.24]:59661 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212AbdI0WAK (ORCPT ); Wed, 27 Sep 2017 18:00:10 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,446,1500966000"; d="scan'208";a="1019203931" Date: Wed, 27 Sep 2017 12:07:45 -0700 From: "Raj, Ashok" To: Casey Leedom Cc: Robin Murphy , Dan Williams , Harsh Jain , Herbert Xu , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "linux-crypto@vger.kernel.org" , "dwmw2@infradead.org" , Michael Werner , "nd@arm.com" Subject: Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU Message-ID: <20170927190745.GA96373@otc-nc-03> References: <6d2af675-7b97-6eaf-4daa-d7bf80a05923@chelsio.com> <437a9bd8-d4d6-22ca-1a64-1a3e73f1101a@arm.com> <20170927181802.3dcd7efb@m750.lan> <20170927144847.GA95654@otc-nc-03> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1713 Lines: 42 Hi Casey 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 f2910000 [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. On Wed, Sep 27, 2017 at 09:29:23PM +0000, 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 list. > > With Robin's comments, I'm almost sure that the: > > (iov_pfn + sg->offset) << VTD_PAGE_SHIFT) true, but this is the IOVA- IO Virtual address generated by the dma_map call. Thought in cases when sg->offset is beyond a page, then the new iov_pfn should fall on the next page. But we can't randomly adjust here, unless IOMMU has also allocated IOVA for the page overflow. Cheers, Ashok