lkml.org 
[lkml]   [2002]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: spin-locks
Date
On Fri, 10 May 2002 08:58:47 -0400 (EDT), 
"Richard B. Johnson" <root@chaos.analogic.com> wrote:
>First, if I create a spin-lock in the ".data" segment it
>doesn't work on a SMP machine with two CPUs. I know I am
>supposed to use the macros, but I have some high-speed stuff
>written in assembly that needs a spin-lock. The 'doesn't work'
>is that the spin-lock seems to dead-lock, i.e., they loop
>forever with the interrupts disabled. I think what's really
>happening is that .data was paged and can't be paged back in
>with the interrupts off. I don't know. This stuff used to
>work....

Kernel .data sections are not paged. They are identity[*] mapped along
with the rest of the kernel text and data and are locked down.

[*] Ignoring NUMA machines which may use non-identity mappings on each
node.

>In earlier versions of Linux, the locks were in .text_lock.
>Now they are in : _text_lock_KBUILD_BASENAME

Not quite. They were all in section .text.lock but that broke when
binutils started detecting dangling references to discarded sections.

The fix was to store the lock code in the same section that called the
lock, so .text locks are in the .text section, .text.exit locks are in
the .text.exit section, no dangling references when .text.exit is
discarded.

The locks are now at the end of the section that references the lock,
preceded by a label (not a section) of _text_lock_KBUILD_BASENAME.

>So, what is special about this area that allows locks to work?

There is nothing special about the text lock code. It is just moving
the failure path out of line to speed up the normal case.

>And, what is special about .data that prevents them from working?

Again nothing. The spin lock area goes in .data, the code goes in the
relevant text section.

>Also, there is a potential bug (ducks and hides under the desk) in
>the existing spin-lock unlocking. To unlock, the lock is simply
>set to 1. This works if you have two CPUs, but what about more?
>
>Shouldn't the lock/unlock just be incremented/decremented so 'N' CPUs
>can pound on it?

Spinlocks are single cpu. Only one cpu at a time can modify the data
that is being protected by obtaining the lock.

From your description, you are confused about spinlocking. Perhaps if
you mailed your code instead of assuming where the error was ...

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