2007-10-25 01:43:32

by Hugh Dickins

[permalink] [raw]
Subject: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t

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 <[email protected]>
---
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;
}


2007-10-25 02:33:24

by Arjan van de Ven

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


> Signed-off-by: Hugh Dickins <[email protected]>
> ---
> 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.....

2007-10-25 06:42:23

by Hugh Dickins

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

On Wed, 24 Oct 2007, Arjan van de Ven wrote:
> > Signed-off-by: Hugh Dickins <[email protected]>
> > ---
> > 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

2007-10-25 07:56:20

by Jens Axboe

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

On Thu, Oct 25 2007, Hugh Dickins wrote:
> On Wed, 24 Oct 2007, Arjan van de Ven wrote:
> > > Signed-off-by: Hugh Dickins <[email protected]>
> > > ---
> > > 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

2007-10-25 08:51:52

by Rolf Eike Beer

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

Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
> > Signed-off-by: Hugh Dickins <[email protected]>
> > ---
> > 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


Attachments:
(No filename) (807.00 B)
signature.asc (194.00 B)
This is a digitally signed message part.
Download all attachments

2007-10-25 08:54:31

by Jens Axboe

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

On Thu, Oct 25 2007, Rolf Eike Beer wrote:
> Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
> > > Signed-off-by: Hugh Dickins <[email protected]>
> > > ---
> > > 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

2007-10-25 09:00:40

by Rolf Eike Beer

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

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 <[email protected]>
> > > > ---
> > > > 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


Attachments:
(No filename) (1.16 kB)
signature.asc (194.00 B)
This is a digitally signed message part.
Download all attachments

2007-10-25 09:08:39

by Jens Axboe

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

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 <[email protected]>
> > > > > ---
> > > > > 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

2007-10-25 11:25:00

by Rolf Eike Beer

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

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 <[email protected]>
> > > > > > ---
> > > > > > 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


Attachments:
(No filename) (1.44 kB)
signature.asc (194.00 B)
This is a digitally signed message part.
Download all attachments

2007-10-25 11:32:09

by Jens Axboe

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

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 <[email protected]>
> > > > > > > ---
> > > > > > > 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