From: Roland McGrath <roland@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Salman Qazi <sqazi@google.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: A possible sys_wait* bug
Date: Wed, 30 Jun 2010 22:34:42 -0700 (PDT) [thread overview]
Message-ID: <20100701053442.D59F04C33C@magilla.sf.frob.com> (raw)
In-Reply-To: KOSAKI Motohiro's message of Thursday, 1 July 2010 09:47:30 +0900 <20100701093621.DA24.A69D9226@jp.fujitsu.com>
There are several other ways than wait that pathological user processes can
arrange to do tight loops taking tasklist_lock. So if you call that a DoS
risk then it's not solved with anything specific to the wait syscalls.
Using different rwlock behavior (at least for that lock) would be one way
to address it. Of course, changing the contention dynamics might have
other effects that you don't want (i.e. fork/exec/exit/reap drowning out
the reader uses, cascading to some bad pattern). I don't have an opinion
on that, and wish you good luck figuring it out.
In the long run, things have been moving to finer-grained locking and/or
less direct locking. We can imagine tasklist_lock might go this way one
day too, removing the general bottleneck (i.e. slicing it up into different
smaller, bottlenecks). As things stand today, it's a bit hard to see
exactly how we might get there e.g. for wait/exit with the synchronization
requirements for reparenting and all that. But it's clear that eventually
the big system-wide bottlenecks like tasklist_lock all get reduced. I
don't know of anything like this to expect to see any time soon, however.
Thanks,
Roland
next prev parent reply other threads:[~2010-07-01 5:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-20 20:32 Salman Qazi
2010-07-01 0:47 ` KOSAKI Motohiro
2010-07-01 5:00 ` Salman Qazi
2010-07-01 5:34 ` Roland McGrath [this message]
2010-07-01 14:08 ` Oleg Nesterov
2010-07-02 6:18 ` KOSAKI Motohiro
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=20100701053442.D59F04C33C@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=sqazi@google.com \
/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®