From: Robin Murphy <robin.murphy@arm.com>
To: Casey Leedom <leedom@chelsio.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
"Harsh Jain" <Harsh@chelsio.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
Michael Werner <werner@chelsio.com>,
nd@arm.com
Subject: Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU
Date: Wed, 27 Sep 2017 18:18:02 +0100 [thread overview]
Message-ID: <20170927181802.3dcd7efb@m750.lan> (raw)
In-Reply-To: <MWHPR12MB160060436AC70CB5BE8C0C6EC8780@MWHPR12MB1600.namprd12.prod.outlook.com>
On Wed, 27 Sep 2017 16:31:04 +0000
Casey Leedom <leedom@chelsio.com> wrote:
> | From: Dan Williams <dan.j.williams@intel.com>
> | Sent: Tuesday, September 26, 2017 9:10 AM
> |
> | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom <leedom@chelsio.com>
> wrote: | > | From: Robin Murphy <robin.murphy@arm.com>
> | > | Sent: Tuesday, September 26, 2017 7:22 AM
> | > |...
> | > ...
> | > Regardless, it seems that you agree that there's an issue with
> the Intel | > I/O MMU support code with regard to the legal values
> which a (struct | > scatterlist) can take on? I still can't find any
> documentation for this | > and, personally, I'm a bit baffled by a
> Page-oriented Scatter/Gather List | > representation where [Offset,
> Offset+Length) can reside outside the Page. |
> | Consider the case where the page represents a huge page, then an
> | offset greater than PAGE_SIZE (up to HPAGE_SIZE) makes sense.
>
> Okay, but whatever the underlaying Page Size is, should [Offset,
> Offset+Length) completely reside within the referenced Page? I'm just
> trying to understand the Invariance Conditions which are assumed by
> all of the code which processes Scatter/gather Lists ...
From my experience, in general terms each scatterlist segment
represents some contiguous quantity of pages, of which sg->page is the
first, while sg->length and sg->offset describe the specific bounds of
that segment's data. As such, the length may certainly (and frequently
does) exceed PAGE_SIZE; for the offset, it's unlikely that the producer
would initially construct one greater than PAGE_SIZE instead of just
pointing sg->page further forward, but it seems reasonable for it to
come about if some intermediate subsystem is processing an existing
list in-place (as seems to be the case with crypto here).
My opinion is that this may be a slightly unusual case, but I would
not consider it an illegal one. I think most DMA mapping
implementations would handle it whether intentionally or not.
Robin.
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Casey Leedom <leedom@chelsio.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
"Harsh Jain" <Harsh@chelsio.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
Michael Werner <werner@chelsio.com>,
nd@arm.com
Subject: Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU
Date: Wed, 27 Sep 2017 18:18:02 +0100 [thread overview]
Message-ID: <20170927181802.3dcd7efb@m750.lan> (raw)
In-Reply-To: <MWHPR12MB160060436AC70CB5BE8C0C6EC8780@MWHPR12MB1600.namprd12.prod.outlook.com>
On Wed, 27 Sep 2017 16:31:04 +0000
Casey Leedom <leedom@chelsio.com> wrote:
> | From: Dan Williams <dan.j.williams@intel.com>
> | Sent: Tuesday, September 26, 2017 9:10 AM
> |
> | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom <leedom@chelsio.com>
> wrote: | > | From: Robin Murphy <robin.murphy@arm.com>
> | > | Sent: Tuesday, September 26, 2017 7:22 AM
> | > |...
> | > ...
> | > Regardless, it seems that you agree that there's an issue with
> the Intel | > I/O MMU support code with regard to the legal values
> which a (struct | > scatterlist) can take on? I still can't find any
> documentation for this | > and, personally, I'm a bit baffled by a
> Page-oriented Scatter/Gather List | > representation where [Offset,
> Offset+Length) can reside outside the Page. |
> | Consider the case where the page represents a huge page, then an
> | offset greater than PAGE_SIZE (up to HPAGE_SIZE) makes sense.
>
> Okay, but whatever the underlaying Page Size is, should [Offset,
> Offset+Length) completely reside within the referenced Page? I'm just
> trying to understand the Invariance Conditions which are assumed by
> all of the code which processes Scatter/gather Lists ...
>From my experience, in general terms each scatterlist segment
represents some contiguous quantity of pages, of which sg->page is the
first, while sg->length and sg->offset describe the specific bounds of
that segment's data. As such, the length may certainly (and frequently
does) exceed PAGE_SIZE; for the offset, it's unlikely that the producer
would initially construct one greater than PAGE_SIZE instead of just
pointing sg->page further forward, but it seems reasonable for it to
come about if some intermediate subsystem is processing an existing
list in-place (as seems to be the case with crypto here).
My opinion is that this may be a slightly unusual case, but I would
not consider it an illegal one. I think most DMA mapping
implementations would handle it whether intentionally or not.
Robin.
next prev parent reply other threads:[~2017-09-27 17:18 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-16 6:11 DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU Harsh Jain
2017-09-20 8:01 ` Herbert Xu
2017-09-20 10:12 ` Robin Murphy
2017-09-20 11:20 ` Harsh Jain
2017-09-25 17:46 ` Casey Leedom
2017-09-25 15:54 ` Raj, Ashok
2017-09-25 18:46 ` Casey Leedom
2017-09-26 3:46 ` Harsh Jain
[not found] ` <afa02763-4556-0e14-7d1b-1c044cdc1ff7-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
2017-09-26 12:21 ` Harsh Jain
2017-09-26 12:21 ` Harsh Jain
2017-09-26 14:22 ` Robin Murphy
2017-09-26 14:34 ` Raj, Ashok
2017-09-26 14:40 ` Raj, Ashok
2017-09-26 20:50 ` Casey Leedom
2017-09-26 20:50 ` Casey Leedom
2017-09-26 18:15 ` Robin Murphy
[not found] ` <437a9bd8-d4d6-22ca-1a64-1a3e73f1101a-5wv7dgnIgG8@public.gmane.org>
2017-09-26 16:06 ` Casey Leedom
2017-09-26 16:10 ` Dan Williams
2017-09-27 16:31 ` Casey Leedom
[not found] ` <MWHPR12MB160060436AC70CB5BE8C0C6EC8780-Gy0DoCVfaSVsWITs4OkDoAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-09-27 17:13 ` Dan Williams
2017-09-27 17:13 ` Dan Williams
2017-10-01 8:59 ` Christoph Hellwig
2017-09-27 17:18 ` Robin Murphy [this message]
2017-09-27 17:18 ` Robin Murphy
[not found] ` <20170927181802.3dcd7efb-h2/QxWiDqNo@public.gmane.org>
2017-09-27 14:48 ` Raj, Ashok
2017-09-27 14:48 ` Raj, Ashok
2017-09-27 21:29 ` Casey Leedom
[not found] ` <MWHPR12MB16005D59D7A33F3D5BE43395C8780-Gy0DoCVfaSVsWITs4OkDoAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-09-27 19:07 ` Raj, Ashok
2017-09-27 19:07 ` Raj, Ashok
2017-09-27 22:13 ` Casey Leedom
2017-09-28 5:01 ` Harsh Jain
[not found] ` <MWHPR12MB16007E5363E79173C52BFA19C8780-Gy0DoCVfaSVsWITs4OkDoAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-09-28 10:33 ` Herbert Xu
2017-09-28 10:33 ` Herbert Xu
[not found] ` <20170928103312.GB8118-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2017-09-28 11:11 ` Harsh Jain
2017-09-28 13:38 ` Harsh Jain
2017-09-28 13:38 ` Harsh Jain
2017-09-28 13:05 ` Raj, Ashok
2017-09-29 5:37 ` Harsh Jain
2017-09-27 17:30 ` Casey Leedom
2017-09-26 17:30 ` Casey Leedom
2017-09-26 17:30 ` Casey Leedom
2017-09-25 19:31 ` Dan Williams
[not found] ` <CAPcyv4j3J41eY2eR07nTvo75F0yCbL9bNHM8GmXEFOHDQUuf8Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-09-25 20:05 ` Casey Leedom
2017-09-25 20:05 ` Casey Leedom
[not found] ` <MWHPR12MB1600948B2F57696189FC7C22C87A0-Gy0DoCVfaSVsWITs4OkDoAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-09-25 20:11 ` Dan Williams
2017-09-25 20:11 ` Dan Williams
2017-09-25 19:03 ` Raj, Ashok
2017-09-25 23:41 ` Casey Leedom
2017-09-26 13:04 ` Harsh Jain
2017-09-20 11:30 ` Harsh Jain
2017-09-25 18:45 ` David Woodhouse
2017-09-25 20:19 ` Casey Leedom
2017-09-26 11:17 ` Harsh Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170927181802.3dcd7efb@m750.lan \
--to=robin.murphy@arm.com \
--cc=Harsh@chelsio.com \
--cc=ashok.raj@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dwmw2@infradead.org \
--cc=herbert@gondor.apana.org.au \
--cc=iommu@lists.linux-foundation.org \
--cc=leedom@chelsio.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nd@arm.com \
--cc=werner@chelsio.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.