All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Robin Murphy <robin.murphy@arm.com>, joro@8bytes.org
Cc: ashok.raj@intel.com, leedom@chelsio.com, Harsh@chelsio.com,
	herbert@gondor.apana.org.au, iommu@lists.linux-foundation.org,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling
Date: Tue, 03 Oct 2017 23:16:16 +0100	[thread overview]
Message-ID: <1507068976.29211.156.camel@infradead.org> (raw)
In-Reply-To: <db8c70d7-5978-20e8-d29a-91a4312f97dd@arm.com>

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Tue, 2017-10-03 at 19:05 +0100, Robin Murphy wrote:
> 
> Now, there are indeed plenty of drivers and subsystems which do work on
> lists of explicitly single pages - anything doing some variant of
> "addr = kmap_atomic(sg_page(sg)) + sg->offset;" is easy to spot - but I
> don't think DMA API implementations are in a position to make any kind
> of assumption; nearly all of them just shut up and handle sg->length
> bytes from sg_phys(sg) without questioning the caller, and I reckon
> that's exactly what they should be doing.

So what's the point in sg->page in the first place? If even the
*offset* can be greater than page size, it isn't even the *first* page
(as you called it). Why aren't we just using a physical address,
instead of an arbitrary page and an offset from that?

Can we have *negative* sg->offset too? :)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]

  reply	other threads:[~2017-10-03 22:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-28 14:14 [PATCH] iommu/vt-d: Fix scatterlist offset handling Robin Murphy
2017-09-28 16:17 ` Casey Leedom
2017-09-28 13:29   ` Raj, Ashok
2017-09-28 16:59     ` Robin Murphy
2017-09-28 15:43       ` Raj, Ashok
2017-10-03 19:36         ` Raj, Ashok
2017-09-29  8:14 ` Harsh Jain
     [not found]   ` <fe25071a-18bf-e468-01e7-36515f2110e2-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
2017-09-29 16:18     ` Casey Leedom
2017-09-29 16:18       ` Casey Leedom
     [not found]       ` <MWHPR12MB160034E91A834504FE85C07BC87E0-Gy0DoCVfaSVsWITs4OkDoAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-10-03 12:22         ` Harsh Jain
2017-10-03 22:22           ` Casey Leedom
     [not found] ` <644c3e01654f8bd48d669c36e424959d6ef0e27e.1506607370.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2017-10-03 12:55   ` David Woodhouse
2017-10-03 12:55     ` David Woodhouse
2017-10-03 18:05     ` Robin Murphy
2017-10-03 22:16       ` David Woodhouse [this message]
2017-10-04 11:18         ` Robin Murphy
2017-10-06 14:43       ` Joerg Roedel
2017-10-06 12:54         ` Raj, Ashok
     [not found]         ` <20171006144309.GA30803-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-11-06 18:47           ` Jacob Pan
2017-11-06 18:47             ` Jacob Pan
2017-11-15 23:54             ` Jacob Pan
2017-11-15 23:54               ` Jacob Pan
2017-11-16 21:32               ` Alex Williamson
     [not found]                 ` <20171116143244.2583d044-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2017-11-16 21:09                   ` Raj, Ashok
2017-11-16 21:09                     ` Raj, Ashok
2017-11-17 16:18                     ` Alex Williamson
2017-11-17 16:18                       ` Alex Williamson
2017-11-17 15:48                       ` Raj, Ashok
2017-11-17 17:44                         ` Casey Leedom
2017-11-17 17:44                           ` Casey Leedom
2017-11-17 17:44                           ` Casey Leedom
     [not found]                           ` <SN1PR12MB035214EF471935B6F4220E36C82F0-z7L1TMIYDg4e2a8M8f4RFAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-11-17 18:09                             ` Jacob Pan
2017-11-17 18:09                               ` Jacob Pan

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=1507068976.29211.156.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=Harsh@chelsio.com \
    --cc=ashok.raj@intel.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=leedom@chelsio.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.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.