From: Ingo Molnar <mingo@elte.hu>
To: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] de_thread: eliminate unneccessary sighand locking
Date: Tue, 28 Jun 2005 09:16:24 +0200 [thread overview]
Message-ID: <20050628071624.GA2302@elte.hu> (raw)
In-Reply-To: <200506280708.j5S78FtD027410@magilla.sf.frob.com>
* Roland McGrath <roland@redhat.com> wrote:
> > do you know any such code?
>
> I was thinking it would look more like:
>
> read_lock(&tasklist_lock);
> p = find_task_by_pid(pid);
> get_task_struct(p);
> read_unlock(&tasklist_lock);
> ...
> spin_lock_irq(&p->sighand->siglock);
> ...
the amount of potentially affected code (assuming all the locking is
done in a single .[ch] file) is even smaller:
kernel/posix-cpu-timers.c
kernel/exit.c
kernel/posix-timers.c
include/linux/sched.h
checked these, we dont seem to do that.
> I am not sure whether such code exists or not. It won't look quite
> like that, in that the siglock use may be far away from the
> extraction. There are things that store pointers like that (like
> real_timer.data, and posix_timers stuff). But it may well be that all
> those places take tasklist_lock before using the saved task_struct, in
> which case it's fine. (Anything doing signals stuff usually needs
> tasklist_lock anyway in case it has to traverse the thread group.)
this reminds me about the patch below: it gets rid of tasklist_lock use
in the POSIX timer signal delivery critical path.
> You mean those are the files that use all three of those, or what?
> That's clearly not the complete list of siglock uses. Any code using
> siglock needs to be grokked adequately to see if tasklist_lock is
> always held around looking at ->sighand.
yeah.
Ingo
---
dont use the tasklist_lock in the POSIX timer-delivery critical path.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
--- linux/kernel/signal.c.orig
+++ linux/kernel/signal.c
@@ -1384,7 +1384,7 @@ send_sigqueue(int sig, struct sigqueue *
* going away or changing from under us.
*/
BUG_ON(!(q->flags & SIGQUEUE_PREALLOC));
- read_lock(&tasklist_lock);
+ task_lock(p);
spin_lock_irqsave(&p->sighand->siglock, flags);
if (unlikely(!list_empty(&q->list))) {
@@ -1411,7 +1411,7 @@ send_sigqueue(int sig, struct sigqueue *
out:
spin_unlock_irqrestore(&p->sighand->siglock, flags);
- read_unlock(&tasklist_lock);
+ task_unlock(p);
return(ret);
}
next prev parent reply other threads:[~2005-06-28 7:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-19 16:13 [PATCH] de_thread: eliminate unneccessary sighand locking Oleg Nesterov
2005-06-28 1:50 ` Roland McGrath
2005-06-28 6:17 ` Oleg Nesterov
2005-06-28 6:27 ` Roland McGrath
2005-06-28 6:42 ` Ingo Molnar
2005-06-28 7:08 ` Roland McGrath
2005-06-28 7:16 ` Ingo Molnar [this message]
2005-06-28 7:26 ` Roland McGrath
2005-06-28 8:26 ` Ingo Molnar
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=20050628071624.GA2302@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=roland@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.