Subject: 64-bit sysinfo

From: Trevor Woerner <[email-masked]>
Date: Thu, 12 Jun 2003 06:59:26 -0400

Hi everyone,

(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?

	Trevor

---

From: Andrew Clausen <[email-masked]>
Date: Thu, 12 Jun 2003 21:36:25 +0000

> to be the same between user space and kernel space. Does some such 

No, the kernel should provide 32 bit values.  This is a bug.

I *thought* I sent a patch for this a while ago... I'm not sure now.

Cheers,
Andrew

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 12 Jun 2003 13:35:20 +0200

> to be the same between user space and kernel space. Does some such 

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

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 12 Jun 2003 13:44:57 +0200

> I *thought* I sent a patch for this a while ago... I'm not sure now.

You sent it and I applied your patch on February 21.  Old mail appended
below again for Trevor's reference.  It doesn't explain why he sees
64-bit values though.  Trevor, what kernel exactly are you running?

  Ralf

Date:	Thu, 20 Feb 2003 11:26:55 +1100
From:	Andrew Clausen <[email-masked]>
To:	Linux-MIPS <[email-masked]>
Cc:	[email-masked], [email-masked]
Subject: [patch] sys32_sysinfo broken on mips64 and ia64
Message-ID: <[email-masked]>

Hi all,

The sys32_sysinfo() calls are currently using an old version of
"struct sysinfo32", in both the mips64 and ia64 ports.

busybox's init can't cope with the bogus output on my Origin 200,
so this bug prevents the Debian installer from bootstrapping.

This is the mips64 version of the patch.  A very similar patch
could be constructed for ia64... it's very obvious what to do,
so I'll leave it to you ia64 people :)

Cheers,
Andrew

diff -u -r1.42.2.23 linux32.c
--- arch/mips64/kernel/linux32.c	23 Jan 2003 02:12:59 -0000	1.42.2.23
+++ arch/mips64/kernel/linux32.c	20 Feb 2003 00:05:41 -0000
@@ -672,8 +672,11 @@
         u32 bufferram;
         u32 totalswap;
         u32 freeswap;
-        unsigned short procs;
-        char _f[22];
+        u16 procs;
+	u32 totalhigh;
+	u32 freehigh;
+	u32 mem_unit;
+	char _f[8];
 };
 
 extern asmlinkage int sys_sysinfo(struct sysinfo *info);
@@ -698,6 +701,9 @@
 	err |= __put_user (s.totalswap, &info->totalswap);
 	err |= __put_user (s.freeswap, &info->freeswap);
 	err |= __put_user (s.procs, &info->procs);
+	err |= __put_user (s.totalhigh, &info->totalhigh);
+	err |= __put_user (s.freehigh, &info->freehigh);
+	err |= __put_user (s.mem_unit, &info->mem_unit);
 	if (err)
 		return -EFAULT;
 	return ret;

---

From: Trevor Woerner <[email-masked]>
Date: Thu, 12 Jun 2003 08:02:57 -0400

On June 12, 2003 07:44 am, Ralf Baechle wrote:
> Trevor, what kernel exactly are you
> running?

I'm running Broadcom's SWARM board (sb1, 1250), so I'm running the most 
recent Broadcom kernel that comes with it (2.4.20-rc6 with patches).

---

From: Trevor Woerner <[email-masked]>
Date: Thu, 12 Jun 2003 08:07:59 -0400

On June 12, 2003 07:35 am, Ralf Baechle wrote:
> The kernel has a wrapper for 32-bit code (see sys32_sysinfo) and that
> one seems to look correct to me.
>
> that is syscall number 4116?  If it's using 5097 it's using the
> native 64-bit syscall which obviously would explain your observation.

Thanks for your (and everyone's suggestions) I'll have a look at this 
today. I put a printk in kernel/proc.c:sys_sysinfo() so that's the one 
being called. I also put another printk in 
arch/mips64/mm/init.c:si_meminfo() (??? i think...) and it was being 
called from 'sys_info()'. I don't remember seeing sys32_sysinfo() but 
I'll look again.

	Trevor

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 12 Jun 2003 14:27:50 +0200

> called from 'sys_info()'. I don't remember seeing sys32_sysinfo() but 

sys32_sysinfo calls sys_sysinfo.  So if you see a direct call to
sys_sysinfo this might proof something is using the wrong syscall.
Strace is your friend ...  Oh, and verify that your kernel has Andrew's
patch from my previous mail applied.

  Ralf