Subject: Re: [BusyBox] 0.48 - Can't mount /proc

From: Michael Shmulevich <[email-masked]>
Date: Thu, 11 Jan 2001 09:28:28 +0200

Erik,

No, doesn't help.

bash# mount proc /proc -t proc                                          
       
mount: Mounting proc on /proc failed: Unknown error 716878944           

Maybe people in mips-linux know something about this?

Erik Andersen wrote:

> On Wed Jan 10, 2001 at 08:39:15PM +0200, Michael Shmulevich wrote:
> 
>> Hello,
>> 
>> This is my first mail to this list, but I have already seen similar 
>> question being unanswered.
>> I am developing an embedded system based on MIPS board. I am 
>> cross-compiling the BusyBox 0.48 on x86 with gcc 2.90.29 (egcs 1.0.3a).
>> 
>> While trying to mount /proc either atomatically in script or by hand, 
>> the command fails with following message:
>> 
>> bash# mount /proc -t proc
>> mount: Mounting none on /proc failed: Unknown error 716878944
> 
> 
> mount proc /proc -t proc
> 
>  -Erik
> 
> --
> Erik B. Andersen   email:  [email-masked]
> --This message was written using 73% post-consumer electrons--

---

From: Erik Andersen <[email-masked]>
Date: Thu, 11 Jan 2001 04:48:08 -0700

> Maybe people in mips-linux know something about this?

Yes, this does sound like a kernel specific problem then,
since this works on (at least) arm, ppc, sh, and x86.
I havn't tried it on anything else.

 -Erik

---

From: Florian Lohoff <[email-masked]>
Date: Thu, 11 Jan 2001 13:04:50 +0100

> I havn't tried it on anything else.

Henning Heinold has done a lot with busybox on mips (debian installer)
Might this be due to kernel 2.4 and /proc/mounts includeing a / in front
of proc 

(flo@ping)~# cat /proc/mounts 
/dev/root / ext2 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/sda7 /usr ext2 rw 0 0
/dev/sda8 /var ext2 rw 0 0
/dev/sda9 /tmp ext2 rw 0 0
/dev/sda10 /home ext2 rw 0 0
/dev/hda5 /var/tmp ext3 rw 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
automount(pid19472) /mnt autofs rw 0 0
(flo@ping)~# uname -a
Linux ping.mediaways.net 2.2.18ext3 #1 Thu Dec 14 18:24:45 CET 2000 i686 unknown

Or 

flo@resume:~$ cat /proc/mounts 
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/sdb1 /home2 ext2 rw 0 0
/dev/sdc1 /home3 ext2 rw 0 0
/dev/sdd1 /ftp.rfc822.org ext2 rw 0 0
/dev/sde1 /home4 ext2 rw 0 0
shmfs /var/shm shm rw 0 0
devpts /home4/dev/pts devpts rw 0 0
proc /home4/proc proc rw 0 0
flo@resume:~$ uname -a
Linux resume.rfc822.org 2.4.0-test6 #2 Sun Aug 27 12:37:51 GMT 2000 mips unknown

Henning has fought with this IIRC.

Flo
-- 
Florian Lohoff                  [email-masked]             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

---

From: Quinn Jensen <[email-masked]>
Date: Thu, 11 Jan 2001 08:52:08 -0700

Here's a kernel patch.  The __access_ok macro looks one byte
too far and fails.  Since copy_mount_options() isn't
sure how long the string arguments are, it just copies
to the end of the page.  Since this is on busybox's
stack, the copy wants to go all the way to 0x7FFFFFF
and hits this corner case.

Quinn Jensen
[email-masked]

--- linux-sgi-2.4.0-test11-pristine/include/asm-mips/uaccess.h  Wed Oct  4 19:19:02 2000
+++ linux/include/asm-mips/uaccess.h    Wed Jan 10 16:20:35 2001
@@ -46,7 +46,7 @@
   *  - OR we are in kernel mode.
   */
  #define __access_ok(addr,size,mask) \
-        (((__signed__ long)((mask)&(addr | size | (addr+size)))) >= 0)
+        (((__signed__ long)((mask)&(addr | size | (addr+size-1)))) >= 0)
  #define __access_mask ((long)(get_fs().seg))

  #define access_ok(type,addr,size) \

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 11 Jan 2001 18:25:50 -0200

> mount: Mounting proc on /proc failed: Unknown error 716878944           

716878944 is 0x2abab460, a typical address of a shared library or malloced
memory allocated via mmap(2).

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 Jan 2001 05:13:29 -0200

> and hits this corner case.

I don't like this solution as it inflates the kernel noticably.  Actually
even the bug itself hasn't been one; this off by one mistake was deliberatly
accepted in the - obviously wrong - assumption that nobody would ever try to
use the last byte of userspace.  See also the Alpha variant of the code;
looks like they suffer from the same problem.

My solution will be to truncate userspace by by at least 4kb.  I've choosen
to even truncate it by 32kb; this will also make the layout of the address
space for 32-bit processes on 64-bit kernels and 32-bit kernel identical
again.

  Ralf