Re: [2.6] busybox EFAULT on sparc64

["David S. Miller" <davem@redhat.com>]

On Wed, 18 Aug 2004 16:55:28 -0700
joshk@triplehelix.org (Joshua Kwan) wrote:

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264482

Joshua, I think I have some more clues.

failing call:
| mount(0x14e060: 'none', 0x150070: '/proc', 0xefffffc5: 'proc', c0ed0000, 0x14e050: '')
successful call:
| mount(0x14e060: 'none', 0x14f068: '/proc', 0x151208: 'proc', c0ed0000, 0x14e050: '')

In the on-stack failing case, we have 0xefffffc5 which is very high up on
the user stack.  The top of stack is at 0xf0000000, that puts this string
pointer less than 64 bytes below that top of stack, this is important.

This confuses copy_mount_options()'s logic.  copy_from_user() for large sizes
tries to copy 64-byte blocks at a time, and this will fail for the first
block access that copy_from_user() tries, so copy_from_user() will say the
whole thing failed.  This causes fs/namespace.c:copy_mount_options() to return
-EFAULT to the mount system call implementation and thus back down to the
implementation.

The is an amazing corner case of this optimistic user space copying scheme that
copy_mount_options() is using.  I've never liked it, but technically it is
copy_from_user() which is buggy... I'll try and fix it.

I do not believe the fork problem is related at all, please try to strace
into the child of klogd using '-f' or similar.