[PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Hugh Dickins]

x86_32 CONFIG_HIGHMEM64G with 5GB RAM hung when booting, after issuing
some "request_module: runaway loop modprobe binfmt-0000" messages in
trying to exec /sbin/init.

The binprm buf doesn't see the right ".ELF" header because sg_phys()
is providing the wrong physical addresses for high pages: a 32-bit
unsigned long is too small in this case, we need to use dma_addr_t.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
Whether this is a complete patch, suitable for all architectures,
I'm not sure: it builds, boots and runs correctly on the x86_32 box
in question, but you'll be a lot wiser than me about using dma_addr_t
for everyone.  (Seems a bit of a shame to include <asm/types.h> here,
when I think all arches already get to include it one way or another,
typically via asm/scatterlist.h; but I guess it's safest to repeat it.)

 include/linux/scatterlist.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- 2.6.24-rc1/include/linux/scatterlist.h	2007-10-24 12:42:16.000000000 +0100
+++ linux/include/linux/scatterlist.h	2007-10-24 19:17:13.000000000 +0100
@@ -1,6 +1,7 @@
 #ifndef _LINUX_SCATTERLIST_H
 #define _LINUX_SCATTERLIST_H
 
+#include <asm/types.h>
 #include <asm/scatterlist.h>
 #include <linux/mm.h>
 #include <linux/string.h>
@@ -237,7 +238,7 @@ static inline void sg_init_table(struct 
  *   on the sg page.
  *
  **/
-static inline unsigned long sg_phys(struct scatterlist *sg)
+static inline dma_addr_t sg_phys(struct scatterlist *sg)
 {
 	return page_to_phys(sg_page(sg)) + sg->offset;
 }

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Arjan van de Ven]

> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
> Whether this is a complete patch, suitable for all architectures,
> I'm not sure: it builds, boots and runs correctly on the x86_32 box
> in question, but you'll be a lot wiser than me about using dma_addr_t
> for everyone.  (Seems a bit of a shame to include <asm/types.h> here,
> when I think all arches already get to include it one way or another,
> typically via asm/scatterlist.h; but I guess it's safest to repeat
> it.)

there is a problem with this... sg_phys doesn't return an actual *dma*
address.... at least not an address you can give to the device.
Using dma_addr_t is thus a bit misleading.....

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Hugh Dickins]

On Wed, 24 Oct 2007, Arjan van de Ven wrote:
> > Signed-off-by: Hugh Dickins <hugh@veritas.com>
> > ---
> > Whether this is a complete patch, suitable for all architectures,
> > I'm not sure: it builds, boots and runs correctly on the x86_32 box
> > in question, but you'll be a lot wiser than me about using dma_addr_t
> > for everyone.  (Seems a bit of a shame to include <asm/types.h> here,
> > when I think all arches already get to include it one way or another,
> > typically via asm/scatterlist.h; but I guess it's safest to repeat
> > it.)
> 
> there is a problem with this... sg_phys doesn't return an actual *dma*
> address.... at least not an address you can give to the device.
> Using dma_addr_t is thus a bit misleading.....

True.  Perhaps sg_phys() should use its own sg_phys_addr_t, defined
or typedefed to be the same as dma_addr_t.  But would this inline
function then be the only place in the tree which uses that type?
If so, then it'd probably be better just to let sg_phys() carry on
using dma_addr_t, but insert a comment there to make your point.

But I'll leave it to Jens to fix up the patch appropriately: for
all I know, there might be arches on which using dma_addr_t there
actually does the wrong thing - I don't think so, but I know too
little about it.

Hugh

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Jens Axboe]

On Thu, Oct 25 2007, Hugh Dickins wrote:
> On Wed, 24 Oct 2007, Arjan van de Ven wrote:
> > > Signed-off-by: Hugh Dickins <hugh@veritas.com>
> > > ---
> > > Whether this is a complete patch, suitable for all architectures,
> > > I'm not sure: it builds, boots and runs correctly on the x86_32 box
> > > in question, but you'll be a lot wiser than me about using dma_addr_t
> > > for everyone.  (Seems a bit of a shame to include <asm/types.h> here,
> > > when I think all arches already get to include it one way or another,
> > > typically via asm/scatterlist.h; but I guess it's safest to repeat
> > > it.)
> > 
> > there is a problem with this... sg_phys doesn't return an actual *dma*
> > address.... at least not an address you can give to the device.
> > Using dma_addr_t is thus a bit misleading.....
> 
> True.  Perhaps sg_phys() should use its own sg_phys_addr_t, defined
> or typedefed to be the same as dma_addr_t.  But would this inline
> function then be the only place in the tree which uses that type?
> If so, then it'd probably be better just to let sg_phys() carry on
> using dma_addr_t, but insert a comment there to make your point.
> 
> But I'll leave it to Jens to fix up the patch appropriately: for
> all I know, there might be arches on which using dma_addr_t there
> actually does the wrong thing - I don't think so, but I know too
> little about it.

dma_addr_t would seem OK to me, given the lack of phys_addr_t.

-- 
Jens Axboe

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Rolf Eike Beer]

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

Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
> > Signed-off-by: Hugh Dickins <hugh@veritas.com>
> > ---
> > Whether this is a complete patch, suitable for all architectures,
> > I'm not sure: it builds, boots and runs correctly on the x86_32 box
> > in question, but you'll be a lot wiser than me about using dma_addr_t
> > for everyone.  (Seems a bit of a shame to include <asm/types.h> here,
> > when I think all arches already get to include it one way or another,
> > typically via asm/scatterlist.h; but I guess it's safest to repeat
> > it.)
>
> there is a problem with this... sg_phys doesn't return an actual *dma*
> address.... at least not an address you can give to the device.
> Using dma_addr_t is thus a bit misleading.....

Ok, then: how do I actually get such an address?

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Jens Axboe]

On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
> > > Signed-off-by: Hugh Dickins <hugh@veritas.com>
> > > ---
> > > Whether this is a complete patch, suitable for all architectures,
> > > I'm not sure: it builds, boots and runs correctly on the x86_32 box
> > > in question, but you'll be a lot wiser than me about using dma_addr_t
> > > for everyone.  (Seems a bit of a shame to include <asm/types.h> here,
> > > when I think all arches already get to include it one way or another,
> > > typically via asm/scatterlist.h; but I guess it's safest to repeat
> > > it.)
> >
> > there is a problem with this... sg_phys doesn't return an actual *dma*
> > address.... at least not an address you can give to the device.
> > Using dma_addr_t is thus a bit misleading.....
> 
> Ok, then: how do I actually get such an address?

You use the dma mapping api, Documentation/DMA-mapping.txt

-- 
Jens Axboe

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Rolf Eike Beer]

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

Jens Axboe wrote:
> On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> > Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
> > > > Signed-off-by: Hugh Dickins <hugh@veritas.com>
> > > > ---
> > > > Whether this is a complete patch, suitable for all architectures,
> > > > I'm not sure: it builds, boots and runs correctly on the x86_32 box
> > > > in question, but you'll be a lot wiser than me about using dma_addr_t
> > > > for everyone.  (Seems a bit of a shame to include <asm/types.h> here,
> > > > when I think all arches already get to include it one way or another,
> > > > typically via asm/scatterlist.h; but I guess it's safest to repeat
> > > > it.)
> > >
> > > there is a problem with this... sg_phys doesn't return an actual *dma*
> > > address.... at least not an address you can give to the device.
> > > Using dma_addr_t is thus a bit misleading.....
> >
> > Ok, then: how do I actually get such an address?
>
> You use the dma mapping api, Documentation/DMA-mapping.txt

Which comes back always to the same point: if I get a buffer from userspace to 
use for DMA: what can I do then? I need to convert a given list of (physical, 
pinned) pages to DMA addresses.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Jens Axboe]

On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> Jens Axboe wrote:
> > On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> > > Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
> > > > > Signed-off-by: Hugh Dickins <hugh@veritas.com>
> > > > > ---
> > > > > Whether this is a complete patch, suitable for all architectures,
> > > > > I'm not sure: it builds, boots and runs correctly on the x86_32 box
> > > > > in question, but you'll be a lot wiser than me about using dma_addr_t
> > > > > for everyone.  (Seems a bit of a shame to include <asm/types.h> here,
> > > > > when I think all arches already get to include it one way or another,
> > > > > typically via asm/scatterlist.h; but I guess it's safest to repeat
> > > > > it.)
> > > >
> > > > there is a problem with this... sg_phys doesn't return an actual *dma*
> > > > address.... at least not an address you can give to the device.
> > > > Using dma_addr_t is thus a bit misleading.....
> > >
> > > Ok, then: how do I actually get such an address?
> >
> > You use the dma mapping api, Documentation/DMA-mapping.txt
> 
> Which comes back always to the same point: if I get a buffer from
> userspace to use for DMA: what can I do then? I need to convert a
> given list of (physical, pinned) pages to DMA addresses.

get_user_pages() -> fill in sg table -> pci/dma_map_sg()

-- 
Jens Axboe

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Rolf Eike Beer]

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

Jens Axboe wrote:
> On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> > Jens Axboe wrote:
> > > On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> > > > Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
> > > > > > Signed-off-by: Hugh Dickins <hugh@veritas.com>
> > > > > > ---
> > > > > > Whether this is a complete patch, suitable for all architectures,
> > > > > > I'm not sure: it builds, boots and runs correctly on the x86_32
> > > > > > box in question, but you'll be a lot wiser than me about using
> > > > > > dma_addr_t for everyone.  (Seems a bit of a shame to include
> > > > > > <asm/types.h> here, when I think all arches already get to
> > > > > > include it one way or another, typically via asm/scatterlist.h;
> > > > > > but I guess it's safest to repeat it.)
> > > > >
> > > > > there is a problem with this... sg_phys doesn't return an actual
> > > > > *dma* address.... at least not an address you can give to the
> > > > > device. Using dma_addr_t is thus a bit misleading.....
> > > >
> > > > Ok, then: how do I actually get such an address?
> > >
> > > You use the dma mapping api, Documentation/DMA-mapping.txt
> >
> > Which comes back always to the same point: if I get a buffer from
> > userspace to use for DMA: what can I do then? I need to convert a
> > given list of (physical, pinned) pages to DMA addresses.
>
> get_user_pages() -> fill in sg table -> pci/dma_map_sg()

So the answer to the first question should have been sg_dma_address() ;)

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

[Jens Axboe]

On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> Jens Axboe wrote:
> > On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> > > Jens Axboe wrote:
> > > > On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> > > > > Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
> > > > > > > Signed-off-by: Hugh Dickins <hugh@veritas.com>
> > > > > > > ---
> > > > > > > Whether this is a complete patch, suitable for all architectures,
> > > > > > > I'm not sure: it builds, boots and runs correctly on the x86_32
> > > > > > > box in question, but you'll be a lot wiser than me about using
> > > > > > > dma_addr_t for everyone.  (Seems a bit of a shame to include
> > > > > > > <asm/types.h> here, when I think all arches already get to
> > > > > > > include it one way or another, typically via asm/scatterlist.h;
> > > > > > > but I guess it's safest to repeat it.)
> > > > > >
> > > > > > there is a problem with this... sg_phys doesn't return an actual
> > > > > > *dma* address.... at least not an address you can give to the
> > > > > > device. Using dma_addr_t is thus a bit misleading.....
> > > > >
> > > > > Ok, then: how do I actually get such an address?
> > > >
> > > > You use the dma mapping api, Documentation/DMA-mapping.txt
> > >
> > > Which comes back always to the same point: if I get a buffer from
> > > userspace to use for DMA: what can I do then? I need to convert a
> > > given list of (physical, pinned) pages to DMA addresses.
> >
> > get_user_pages() -> fill in sg table -> pci/dma_map_sg()
> 
> So the answer to the first question should have been sg_dma_address() ;)

Yes, provided it's mapped you use sg_dma_address() and sg_dma_len() :-)

-- 
Jens Axboe