lkml.org 
[lkml]   [2002]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: v2.4.19-rmk4 slab.c: /proc/slabinfo uses broken instead of slab labels
On Fri, Nov 29, 2002 at 07:24:02PM +0100, Manfred Spraul wrote:
> Russell King wrote:
> >On Thu, Nov 28, 2002 at 11:34:20PM +0100, Manfred Spraul wrote:
> >
> >
> >>On i386, it's possible to skip set_fs() and use __get_user() - but
> >>that's i386 specific. For example the i386 oops code uses that.
> >>
> >>
> >
> >That isn't actually an x86 specific feature - it is a requirement across
> >all architectures that get_user() and friends can access kernel areas
> >after set_fs(get_ds())
> >
> >
> It's i386 specific that
> __get_user().
> is equivalent to
> set_fs(KERNEL_DS)
> get_user()
> arch/i386/kernel/traps.c uses that in the fault code.
>
> Portable code must use set_fs()/get_user(), i386 specific code can
> continue to use __get_user().

That seems broken to me. IIRC, when all this uaccess stuff went in back
in 2.1 times, the original intention was that __get_user() would fault
even when used from kernel mode, unless set_fs(KERNEL_DS) was in effect.

__get_user() at that time was always meant to be used as a faster version
of get_user(), even by generic code, and relied solely on the TLB protection
mechanisms, whereas get_user() verified the address.

Gah, I _really_ wish that we had a method to notify architecture maintainers
when this type of stuff changes. Are we supposed to re-read the x86
implementation of everything for each kernel release to try to discover
what subtle semantics have changed?

--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

-
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 13:31    [W:0.067 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site