From: Nick Piggin <npiggin@suse.de>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: [rfc] "fair" rw spinlocks
Date: Wed, 25 Nov 2009 07:52:53 +0100 [thread overview]
Message-ID: <20091125065253.GC17484@wotan.suse.de> (raw)
In-Reply-To: <20091124.121959.35689494.davem@davemloft.net>
On Tue, Nov 24, 2009 at 12:19:59PM -0800, David Miller wrote:
> From: Nick Piggin <npiggin@suse.de>
> Date: Mon, 23 Nov 2009 15:54:09 +0100
>
> > This was basically reproduced by several cores executing wait
> > with WNOHANG.
> >
> > Of course it would always be nice to improve locking so
> > contention isn't an issue, but so long as we have rwlocks, we
> > could possibly get into a situation where starvation is
> > triggered *somehow*. So I'd really like to fix this.
> >
> > This particular starvation on tasklist lock I guess is a local
> > DoS vulnerability even if the workload is not particularly
> > realistic.
> >
> > Anyway, I don't have a patch yet. I'm sure it can be done
> > without extra atomics in fastpaths. Comments?
>
> I think nobody would notice if you changed tasklist_lock into
> a spinlock_t, and this would solve the DoS because at least on
> x86 you'd end up with the ticket spinlocks.
>
> And this is a repeating theme every time the topic of rwlocks come up.
> All uses should just simply be converted gradually to some other
> locking mechanism over time, the cases causing problems taking
> priority.
For tasklist_lock, I'm not so sure. It gets taken fairly often
for read, and has some quite long critical sections. I think
we might start running into contention on lock hold times.
For other locks, I agree. In fact there are a couple of them in
the vfs which I think should be just spinlocks. I'll send some
patches for those.
next prev parent reply other threads:[~2009-11-25 6:53 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-23 14:54 Nick Piggin
2009-11-24 20:19 ` David Miller
2009-11-25 6:52 ` Nick Piggin [this message]
2009-11-25 8:49 ` Andi Kleen
2009-11-25 8:56 ` Nick Piggin
2009-11-24 20:47 ` Andi Kleen
2009-11-25 6:54 ` Nick Piggin
2009-11-25 8:48 ` Andi Kleen
2009-11-25 13:09 ` Arnd Bergmann
2009-11-28 2:07 ` Paul E. McKenney
2009-11-28 11:15 ` Andi Kleen
2009-11-28 15:20 ` Paul E. McKenney
2009-11-28 17:30 ` Linus Torvalds
2009-11-29 18:51 ` Paul E. McKenney
2009-11-30 7:57 ` Nick Piggin
2009-11-30 7:55 ` Nick Piggin
2009-11-30 15:22 ` Linus Torvalds
2009-11-30 15:40 ` Nick Piggin
2009-11-30 16:07 ` Linus Torvalds
2009-11-30 16:17 ` Nick Piggin
2009-11-30 16:39 ` Paul E. McKenney
2009-11-30 17:05 ` Linus Torvalds
2009-11-30 17:13 ` Nick Piggin
2009-11-30 17:18 ` Linus Torvalds
2009-12-01 17:03 ` Arnd Bergmann
2009-12-01 17:15 ` Linus Torvalds
2009-11-30 18:29 ` Paul E. McKenney
2009-11-30 16:20 ` Paul E. McKenney
2009-11-30 10:00 ` Christoph Hellwig
2009-11-30 15:52 ` Linus Torvalds
2009-11-30 17:46 ` Ingo Molnar
2009-11-30 21:12 ` Thomas Gleixner
2009-11-30 21:27 ` Peter Zijlstra
2009-11-30 22:02 ` Thomas Gleixner
2009-11-30 22:11 ` Linus Torvalds
2009-11-30 22:37 ` Thomas Gleixner
2009-11-30 22:49 ` Linus Torvalds
2009-12-01 17:37 ` [PATCH] audit: Call tty_audit_push_task() outside preempt disabled region Thomas Gleixner
2009-12-01 18:22 ` Oleg Nesterov
2009-12-01 19:53 ` Thomas Gleixner
2009-12-06 3:12 ` [rfc] "fair" rw spinlocks Eric W. Biederman
2009-12-07 18:18 ` Paul E. McKenney
2009-12-07 22:24 ` Eric W. Biederman
2009-12-07 22:35 ` Andi Kleen
2009-12-07 23:19 ` Eric W. Biederman
2009-12-08 1:39 ` Paul E. McKenney
2009-12-08 2:11 ` Eric W. Biederman
2009-12-08 2:37 ` Paul E. McKenney
2009-12-07 18:32 ` Oleg Nesterov
2009-12-07 20:38 ` Peter Zijlstra
2009-12-09 15:55 ` Oleg Nesterov
2009-12-07 22:10 ` Eric W. Biederman
2009-12-09 15:37 ` Oleg Nesterov
2009-12-10 3:36 ` Eric W. Biederman
2009-12-10 6:22 ` Paul E. McKenney
2009-12-10 10:31 ` Eric W. Biederman
2009-12-10 16:41 ` Paul E. McKenney
2009-12-01 19:01 ` Mathieu Desnoyers
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=20091125065253.GC17484@wotan.suse.de \
--to=npiggin@suse.de \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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
Powered by JetHome