Re: 64-bit sysinfo

[Ralf Baechle <ralf@linux-mips.org>]

On Thu, Jun 12, 2003 at 06:59:26AM -0400, Trevor Woerner wrote:

> (good to see some familiar and friendly faces from the PPC list! :-)
> 
> I ran into a problem yesterday and I just don't know how I'm going to 
> approach solving it.
> 
> I compiled a 64-bit MIPS kernel, then built a busybox-based ramdisk. At 
> first I couldn't get busybox's 'init' to work but later solved it by 
> disabling the 'check_memory()' call.
> 
> Further investigation into why the 'check_memory()' call was failing 
> revealed a problem with the 'sysinfo()' system call. The kernel is 
> 64-bit, therefore when it fills in the 'struct sysinfo' (as it does 
> when 'sys_meminfo()' is called) unsigned int's are 64 bits. But back in 
> userspace, the 'struct sysinfo' that gets allocated thinks that 
> unsigned int's are 32 bits.
> 
> This causes a crash if the 'struct sysinfo' is allocated on the stack 
> back in userspace, and causes seg faults if it's allocated in the .data 
> section (globally).
> 
> I'm crossing my fingers and hoping that my solution is to build all 
> user-space apps with some switch that will set the sizes of data types 
> to be the same between user space and kernel space. Does some such 
> option exist?

Userspace really shouldn't need to know what kind of kernel it's running
on ...

The kernel has a wrapper for 32-bit code (see sys32_sysinfo) and that one
seems to look correct to me.

Can you check that your program is actually using the right syscall,
that is syscall number 4116?  If it's using 5097 it's using the native
64-bit syscall which obviously would explain your observation.

Any piece of usercode that's directly using <asm/unistd.h> is likely
to do something like this.  In short, using <asm/unistd.h> from userspace
is a really bad idea ...

  Ralf