From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: naveen yadav <yad.naveen@gmail.com>,
Vaibhav Shinde <v.bhav.shinde@gmail.com>,
Ajeet Yadav <ajeet.yadav.77@gmail.com>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] secure unlock_task_sighand() call
Date: Sun, 22 Dec 2013 15:34:27 +0100 [thread overview]
Message-ID: <20131222143427.GA12544@redhat.com> (raw)
In-Reply-To: <CA+55aFyVrrvDzUt0OU4d9YZM8C-N+ycSKEa3+-5nowUoZ=rb8w@mail.gmail.com>
Naveen,
sorry for the terse and neglectful reply yesterday.
Actually, when I re-read the Linus's email, I think he already explained
everything, so let me repeat:
On 12/21, Linus Torvalds wrote:
>
> Did you actually *see* the problem, or was this just from looking at the code?
Yes. Because this code assumes that lock_task_sighand() must not fail.
If it fails, we have a problem which should be fixed.
> We have coredump serialization in exit_mm() that I think *should* make
> this all ok - if we still see p->mm matching our mm, I don't think it
> should be able to get to __exit_signal() and make the sighand go away,
> so the lock_task_sighand() shouldn't ever fail.
Yes, exactly.
Note that if we ignore exec, we do not need lock_task_sighand() at all,
we could simply do spin_lock_irq(p->sighand->siglock).
The caller holds mm->mmap_sem for writing, if we see p->mm == mm it
simply can not pass exit_mm() which does down_read(&mm->mmap_sem), so
this task can not exit.
The problem is, this task can change its ->sighand in de_thread(), that
is why we need lock_task_sighand(). But if it does exec, it can't pass
exec_mmap() by the same reason, we hold mmap_sem.
> > if (p->mm) {
> > if (unlikely(p->mm == mm)) {
> > - lock_task_sighand(p, &flags);
> > - nr += zap_process(p, exit_code);
> > - unlock_task_sighand(p, &flags);
> > + if (lock_task_sighand(p, &flags) {
> > + nr += zap_process(p, exit_code);
But we can't silently skip a process with the same ->mm. We can't even
skip the execing thread task if it is going to change its ->mm, even if
it is single-threaded. Note that exec_mmap() will notice mm->core_state
and fail. So every task with the same mm should be accounted because it
will play with core_state->nr_threads in exit_mm(). And it should be
killed because otherwise coredump_wait() can sleep "forever".
So this is not the right change in any case. If lock_task_sighand() can
fail we should fix something else.
Oleg.
next prev parent reply other threads:[~2013-12-22 14:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-21 9:55 [PATCH] secure unlock_task_sighand() call naveen yadav
2013-12-21 17:41 ` Linus Torvalds
2013-12-21 18:27 ` Oleg Nesterov
2013-12-22 14:34 ` Oleg Nesterov [this message]
2013-12-23 12:29 ` naveen yadav
2013-12-23 14:26 ` Oleg Nesterov
2013-12-23 18:17 ` Linus Torvalds
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=20131222143427.GA12544@redhat.com \
--to=oleg@redhat.com \
--cc=ajeet.yadav.77@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=v.bhav.shinde@gmail.com \
--cc=yad.naveen@gmail.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.