All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: dhowells@redhat.com, James Morris <jmorris@namei.org>,
	linux-kernel@vger.kernel.org
Subject: Re: what is_single_threaded() does?
Date: Thu, 02 Apr 2009 12:07:06 +0100	[thread overview]
Message-ID: <2360.1238670426@redhat.com> (raw)
In-Reply-To: <20090331205703.GA21030@redhat.com>


Oleg Nesterov <oleg@redhat.com> wrote:

> But this is not what the code does? The "t->mm == mm" check below means
> it also returns false if ->mm is shared with another CLONE_VM process ?

It's a matter of defining what is meant by single-threaded, I suppose.  For
the purposes of security checks, that means not being part of the same group
of threads and not sharing VM space.

Linux has a very fuzzy view of threads, whereby different tasks can share
different sets of things.  In my opinion it's excessive and unnecessary, and
probably mostly unused.

> 		if (atomic_read(&p->signal->count) != 1)
> 			goto no;
>
> Is this correct? Let's suppose the main thread dies, and the thread group
> has only one live thread. In that case signal->count == 2.

Doesn't exit() kill the subsidiary threads in such a case?  I don't recall.

It appears that the zombie would retain a pointer to p->signal so that
wait_task_zombie() can get stuff out of it - but can wait_task_zombie()
actually access a thread group that still has active threads?

I don't think this is a real problem, at least for the two security users of
it.  It is still effectively multithreaded, even though one of the threads is
a zombie, and indeed it would appear the process is busy imploding.

> Why do_each_thread() ? for_each_process() is enough, all sub-threads use
> the same ->mm.

Firstly, that's what the original code that I extract out to this function
did; secondly, it doesn't make much difference: do_each_thread() does the
filtering for us that we'd have to do ourselves if we used for_each_process();
and thirdly, it is neither required nor enforced that all sub-threads use the
same ->mm.

Actually, a better way of doing things may be to use a list of threads rooted
on signal_struct.

> What about use_mm() ? Looks like this needs PF_KTHREAD check.

I'm not sure what you mean.  Are you suggesting this should use use_mm()?  Or
are you suggesting that use_mm() is wrong?

> Perhaps it should be current_is_single_thread(void) ...

Perhaps.

  reply	other threads:[~2009-04-02 11:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-31 20:57 what is_single_threaded() does? Oleg Nesterov
2009-04-02 11:07 ` David Howells [this message]
2009-04-02 14:43   ` Oleg Nesterov

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=2360.1238670426@redhat.com \
    --to=dhowells@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@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.