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;
}
> 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.....
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
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
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
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
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
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
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
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