From: Keith Owens <kaos@ocs.com.au>
To: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: spin-locks
Date: Fri, 10 May 2002 23:24:42 +1000 [thread overview]
Message-ID: <30386.1021037082@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Fri, 10 May 2002 08:58:47 -0400." <Pine.LNX.3.95.1020510084519.1902A-100000@chaos.analogic.com>
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 ...
next prev parent reply other threads:[~2002-05-10 13:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-10 12:58 spin-locks Richard B. Johnson
2002-05-10 13:24 ` Keith Owens [this message]
2002-05-10 14:06 ` spin-locks Richard B. Johnson
2002-05-10 14:17 ` spin-locks David Woodhouse
2002-05-10 14:28 ` spin-locks Richard B. Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30386.1021037082@ocs3.intra.ocs.com.au \
--to=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®