From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Roland McGrath <roland@redhat.com>,
stable@kernel.org
Subject: Re: [PATCH] posix-cpu-timers: workaround to suppress the problems with mt exec
Date: Tue, 9 Nov 2010 15:54:20 +0100 [thread overview]
Message-ID: <20101109145419.GA26445@redhat.com> (raw)
In-Reply-To: <20101105155342.GA13606@redhat.com>
On Fri, Nov 05, 2010 at 04:53:42PM +0100, Oleg Nesterov wrote:
> posix-cpu-timers.c correctly assumes that the dying process does
> posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD
> timers from signal->cpu_timers list.
>
> But, it also assumes that timer->it.cpu.task is always the group
> leader, and thus the dead ->task means the dead thread group.
>
> This is obviously not true after de_thread() changes the leader.
> After that almost every posix_cpu_timer_ method has problems.
>
> It is not simple to fix this bug correctly. First of all, I think
> that timer->it.cpu should use struct pid instead of task_struct.
> Also, the locking should be reworked completely. In particular,
> tasklist_lock should not be used at all. This all needs a lot of
> nontrivial and hard-to-test changes.
>
> Change __exit_signal() to do posix_cpu_timers_exit_group() when
> the old leader dies during exec. This is not the fix, just the
> temporary hack to hide the problem for 2.6.37 and stable. IOW,
> this is obviously wrong but this is what we currently have anyway:
> cpu timers do not work after mt exec.
>
> In theory this change adds another race. The exiting leader can
> detach the timers which were attached to the new leader. However,
> the window between de_thread() and release_task() is small, we
> can pretend that sys_timer_create() was called before de_thread().
>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
prev parent reply other threads:[~2010-11-09 14:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-02 13:58 [PATCH] posix-cpu-timers: rcu_read_lock/unlock protect find_task_by_vpid call Sergey Senozhatsky
2010-11-02 15:31 ` Thomas Gleixner
2010-11-02 16:02 ` Sergey Senozhatsky
2010-11-02 16:04 ` Thomas Gleixner
2010-11-02 18:33 ` Oleg Nesterov
2010-11-03 10:58 ` Sergey Senozhatsky
2010-11-03 12:48 ` Oleg Nesterov
2010-11-03 16:10 ` Oleg Nesterov
2010-11-03 16:38 ` Sergey Senozhatsky
2010-11-03 16:52 ` Sergey Senozhatsky
2010-11-03 17:17 ` Oleg Nesterov
2010-11-05 15:53 ` [PATCH] posix-cpu-timers: workaround to suppress the problems with mt exec Oleg Nesterov
2010-11-08 18:14 ` Roland McGrath
2010-11-09 14:54 ` Stanislaw Gruszka [this message]
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=20101109145419.GA26445@redhat.com \
--to=sgruszka@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=stable@kernel.org \
--cc=tglx@linutronix.de \
/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.