From: "Jeffrey V. Merkey" <jmerkey@wolfmountaingroup.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Recursive spinlocks for Network Recursion Bugs in 2.6.18
Date: Sat, 09 Dec 2006 00:31:03 -0700 [thread overview]
Message-ID: <457A6637.3060101@wolfmountaingroup.com> (raw)
This code segment in /net/core/dev.c is a prime example of the need for
recursive spin locks.
if (dev->flags & IFF_UP) {
int cpu = smp_processor_id(); /* ok because BHs are off */
if (dev->xmit_lock_owner != cpu) {
HARD_TX_LOCK(dev, cpu);
if (!netif_queue_stopped(dev)) {
rc = 0;
if (!dev_hard_start_xmit(skb, dev)) {
HARD_TX_UNLOCK(dev);
goto out;
}
}
HARD_TX_UNLOCK(dev);
if (net_ratelimit())
printk(KERN_CRIT "Virtual device %s asks
to "
"queue packet!\n", dev->name);
} else {
/* Recursion is detected! It is possible,
* unfortunately */
if (net_ratelimit())
printk(KERN_CRIT "Dead loop on virtual
device "
"%s, fix it urgently!\n", dev->name);
}
}
Recursive spinlocks perform the logic
rspin_lock(spin_lock)
{
if (spin_lock->lock->cpu_owner = cpu I am on) && (spin_lock->lock)
{
spin_lock->use_count++;
}
else
{
spin_lock(lock)
lock->cpu_owner = cpu I am on;
lock->use_count++;
}
}
rspin_unlock(spin_lock)
{
if (spin_lock->lock->cpu_owner = cpu I am on) && (spin_lock->use_count)
{
spin_lock->use_count--;
}
else
{
lock->use_count++;
lock->cpu_owner = cpu I am on;
spin_unlock(lock)
}
}
One implementation of this is:
LONG rspin_lock(rlock_t *rlock)
{
register LONG proc = get_processor_id();
register LONG retCode;
if (rlock->lockValue && rlock->processor == (proc + 1))
{
rlock->count++;
retCode = 1;
}
else
{
dspin_lock(&rlock->lockValue);
rlock->processor = (proc + 1);
retCode = 0;
}
return retCode;
}
LONG rspin_unlock(rlock_t *rlock)
{
register LONG retCode;
if (rlock->count)
{
rlock->count--;
retCode = 1;
}
else
{
rlock->processor = 0;
dspin_unlock(&rlock->lockValue);
retCode = 0;
}
return retCode;
}
Just a suggestion. Would be a useful primitive for a lot of context
implementations where users turn on interrupts inside of nested spin
lock code.
Jeff
next reply other threads:[~2006-12-09 6:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-09 7:31 Jeffrey V. Merkey [this message]
2006-12-12 9:20 ` Recursive spinlocks for Network Recursion Bugs in 2.6.18 Jarek Poplawski
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=457A6637.3060101@wolfmountaingroup.com \
--to=jmerkey@wolfmountaingroup.com \
--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