Messages in this thread | | | Date | Wed, 05 Jul 2000 10:40:54 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: spinlocks() are severely broken in 2.2.X and 2.4.X for modules |
| |
Andi,
Sorry I was gone for most of the weekend and did not get back to you sooner (4th of July here -- Independence Day). Had a lot of fun though. Went to a favorite spot on the backside of Lone Peak with my hydrostatic dry washer and got several ounces of gold off the side of the mountain. If you are ever in Utah, I'll take you out there for an afternoon. :-)
Did some more digging on the spinlock problem Sunday night and the good news is that after rebuilding both GLIB and EGCS from rpm, the spinlock code started showing up at the right addresses (???). The bad news is that the binaries in OpenLinux 2.4 (GLIB/EGCS) seem to casue this problem when installed by default -- RedHat 6.2 and the latest Suse Linux were both clean and I did not see bogus addresses when I dumped the NWFS code with gdb /usr/src/vmlinux /proc/kcore (all of the emails from folks seeing this problem were using OpenLinux 2.4) and the .text.lock segments were showing up where they should. The LRU bug is fixed now, and the corruption is gone. Tools/Linker/Loader bugs like these are very scary :-/.
However, the issues raised relative to the cross platform lock/irq function semantics raised by folks are significant. Typically on Intel, you want to disable interrupts around a spinlock/unlock pair for any code paths that can be re-entered via an interrupt, timer, etc. Most spinlock implementations I've seen may also enable interrupts while they are spining, then disable them inside the lock to avoid deadlocks caused by an interrupt breaking into a code section holding the spinlock because interrupts were enabled. Whatever semantic is used, however, should be general enough to allow:
ints_off() spinlock()
spinunlock() ints_on()
or something to that effect for all the SMP capable architectures. :-)
Jeff
Andi Kleen wrote: > > On Sat, Jul 01, 2000 at 11:59:11AM +0200, Manfred Spraul wrote: > > Andi Kleen wrote: > > > > > > I had it happen to me in the past too for my sysctl rewrite. In this > > > case it happened in the main kernel for a .sysctl -> .data relocation. > > > It happened in the main vmlinux. It seems to require some complex > > > input to trigger (it is not as simple as intersegment relocation does not > > > work). In my case I had a few hundred relocations and one was wrong > > > and caused crashes. > > > > > > > Is it possible to detect the problem automatically until binutils is > > fixed? (objdump + script) > > We could add a postprocessing step after the linker, and if relocations > > are wrong, then make should fail. > > Maybe, but the test cases are very big (nwfs or in my case the whole > kernel). Of course you could test for the particular missing relocation > that was tracked down, but that would be probably fragile because it could > move with code changes. Generating a reliable test would require full > understanding of the bug (and that would probably lead to a fix) > > It would be better just to fix the bug in the linker and check the version > number :-) > > > Changing the spinlock code is IMHO not a solution: we rely on > > .text.somewhere_else very often (spinlock, semaphore, exception handler > > table, init functions, initcall,...) > > I agree. > In the automatic sysctl code it is needed too (no more ugly register_sysctl, > but automatic initialisation from a segment like in BSD) > > -Andi > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |