v2.4.19-rmk4 slab.c: /proc/slabinfo uses broken instead of slab labels
Quoted 8 lines
Quoted 6 lines
1. Is the ARM
__get_user()broken?
2. Could I be doing something else broken that is confusing__get_user()?
3. What was/is the intent of the test? Or stated differently, why on earth wouldcachep->namebe a user address?
get_user is the standard test for bad pointers: If the pointer is bad, then the exception handler will prevent an oops.
Could you backport the get_fs()/set_fs() calls around the get_user() from 2.5? I assume that ARM needs it to distiguish between kernel and user addresses.
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.
--
Manfred
Quoted 2 lines · Manfred Spraul
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())
That's how things like sys_execve() can read the binary headers, etc. See linux/fs/exec.c:kernel_read() for one such example.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 12 lines · Russell King
Quoted 3 lines · Manfred Spraul
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().
--
Manfred
Quoted 15 lines · Manfred Spraul
Quoted 13 lines · Russell King
Quoted 4 lines · Manfred Spraul
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
Quoted 8 lines
__get_user(). is equivalent to set_fs(KERNEL_DS) get_user()
arch/i386/kernel/traps.cuses 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?
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 7 lines · Russell King
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?
There was no change - i386 just permits something that doesn't work on all archs.