lkml.org 
[lkml]   [2000]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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