Messages in this thread | | | From | Keith Owens <> | Subject | Re: spin-locks | Date | Fri, 10 May 2002 23:24:42 +1000 |
| |
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/
| |