generic memory addresses

generic memory addresses

[Tobin C. Harding]

Why is there code in-tree that declares generic memory addresses as
unsigned int?

Linux Device Drivers 3rd Edition page 289
 Therefore, generic memory addresses in the kernel are usually unsigned
 long, exploiting the fact that pointers and long integers are always
 the same size, at least on all the platforms currently supported by
 Linux.

It would therefore seem like a bug to declare a generic memory address
as an unsigned int in code that can run on 64 bit machines.

What is the explanation for such declarations in the kernel please?

$ cd KERNEL_TREE
$ git grep 'unsigned int addr' | wc -l
556

thanks,
Tobin.

generic memory addresses

[Greg KH]

On Thu, Apr 06, 2017 at 10:31:01AM +1000, Tobin C. Harding wrote:
> Why is there code in-tree that declares generic memory addresses as
> unsigned int?
> 
> Linux Device Drivers 3rd Edition page 289
>  Therefore, generic memory addresses in the kernel are usually unsigned
>  long, exploiting the fact that pointers and long integers are always
>  the same size, at least on all the platforms currently supported by
>  Linux.
> 
> It would therefore seem like a bug to declare a generic memory address
> as an unsigned int in code that can run on 64 bit machines.

I agree, that does seem like a bug.

> What is the explanation for such declarations in the kernel please?
> 
> $ cd KERNEL_TREE
> $ git grep 'unsigned int addr' | wc -l
> 556

Make sure those really are being used to store a real address, sometimes
they are not...

thanks,

greg k-h

generic memory addresses

[Tobin C. Harding]

On Thu, Apr 06, 2017 at 08:08:20AM +0200, Greg KH wrote:
> On Thu, Apr 06, 2017 at 10:31:01AM +1000, Tobin C. Harding wrote:
> > Why is there code in-tree that declares generic memory addresses as
> > unsigned int?
> > 
> > Linux Device Drivers 3rd Edition page 289
> >  Therefore, generic memory addresses in the kernel are usually unsigned
> >  long, exploiting the fact that pointers and long integers are always
> >  the same size, at least on all the platforms currently supported by
> >  Linux.
> > 
> > It would therefore seem like a bug to declare a generic memory address
> > as an unsigned int in code that can run on 64 bit machines.
> 
> I agree, that does seem like a bug.

The example that started me looking at this is in
drivers/mmc/core/sdio_io.c

int sdio_memcpy_fromio(struct sdio_func *func, void *dst,
	unsigned int addr, int count)
{
	return sdio_io_rw_ext_helper(func, 0, addr, 1, dst, count);
}

Is there perhaps some reason that it can be guaranteed that this
address is for 32 bit architecture. Is it acceptable to think that mmc
cards are never more than 32 bit and this code will never have its use
extended to where 64 bit addresses are used?

> > What is the explanation for such declarations in the kernel please?
> > 
> > $ cd KERNEL_TREE
> > $ git grep 'unsigned int addr' | wc -l
> > 556
> 
> Make sure those really are being used to store a real address, sometimes
> they are not...

righto.

thanks,
Tobin.

generic memory addresses

[Greg KH]

On Thu, Apr 06, 2017 at 08:11:34PM +1000, Tobin C. Harding wrote:
> On Thu, Apr 06, 2017 at 08:08:20AM +0200, Greg KH wrote:
> > On Thu, Apr 06, 2017 at 10:31:01AM +1000, Tobin C. Harding wrote:
> > > Why is there code in-tree that declares generic memory addresses as
> > > unsigned int?
> > > 
> > > Linux Device Drivers 3rd Edition page 289
> > >  Therefore, generic memory addresses in the kernel are usually unsigned
> > >  long, exploiting the fact that pointers and long integers are always
> > >  the same size, at least on all the platforms currently supported by
> > >  Linux.
> > > 
> > > It would therefore seem like a bug to declare a generic memory address
> > > as an unsigned int in code that can run on 64 bit machines.
> > 
> > I agree, that does seem like a bug.
> 
> The example that started me looking at this is in
> drivers/mmc/core/sdio_io.c
> 
> int sdio_memcpy_fromio(struct sdio_func *func, void *dst,
> 	unsigned int addr, int count)
> {
> 	return sdio_io_rw_ext_helper(func, 0, addr, 1, dst, count);
> }
> 
> Is there perhaps some reason that it can be guaranteed that this
> address is for 32 bit architecture. Is it acceptable to think that mmc
> cards are never more than 32 bit and this code will never have its use
> extended to where 64 bit addresses are used?

How do you know this is a "real" address, and not just an sdio
"address"?  The two are very different.  See the SDIO spec for details
about how that protocol works if you are curious.

So here, this isn't an issue, and yes, sdio drivers do work just fine on
64bit systems, lots of us use these drivers all the time on both laptops
and embedded systems running a 64bit kernel.

hope this helps,

greg k-h

generic memory addresses

[Tobin C. Harding]

On Thu, Apr 06, 2017 at 06:59:02PM +0200, Greg KH wrote:
> On Thu, Apr 06, 2017 at 08:11:34PM +1000, Tobin C. Harding wrote:
> > On Thu, Apr 06, 2017 at 08:08:20AM +0200, Greg KH wrote:
> > > On Thu, Apr 06, 2017 at 10:31:01AM +1000, Tobin C. Harding wrote:
> > > > Why is there code in-tree that declares generic memory addresses as
> > > > unsigned int?
> > > > 
> > > > Linux Device Drivers 3rd Edition page 289
> > > >  Therefore, generic memory addresses in the kernel are usually unsigned
> > > >  long, exploiting the fact that pointers and long integers are always
> > > >  the same size, at least on all the platforms currently supported by
> > > >  Linux.
> > > > 
> > > > It would therefore seem like a bug to declare a generic memory address
> > > > as an unsigned int in code that can run on 64 bit machines.
> > > 
> > > I agree, that does seem like a bug.
> > 
> > The example that started me looking at this is in
> > drivers/mmc/core/sdio_io.c
> > 
> > int sdio_memcpy_fromio(struct sdio_func *func, void *dst,
> > 	unsigned int addr, int count)
> > {
> > 	return sdio_io_rw_ext_helper(func, 0, addr, 1, dst, count);
> > }
> > 
> > Is there perhaps some reason that it can be guaranteed that this
> > address is for 32 bit architecture. Is it acceptable to think that mmc
> > cards are never more than 32 bit and this code will never have its use
> > extended to where 64 bit addresses are used?
> 
> How do you know this is a "real" address, and not just an sdio
> "address"?  The two are very different.  See the SDIO spec for details
> about how that protocol works if you are curious.

Ok. I need to learn some more. Thanks for the tip to read the SDIO spec.

thanks,
Tobin.