lkml.org 
[lkml]   [2004]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.6] busybox EFAULT on sparc64
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.089 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site