linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Badari Pulavarty <pbadari@us.ibm.com>,
	Christoph Hellwig <hch@lst.de>, Janak Desai <janak@us.ibm.com>,
	Roland McGrath <roland@redhat.com>,
	Stanislaw Gruszka <sgruszka@redhat.com>,
	Sukadev Bhattiprolu <sukadev@us.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] sys_unshare: simplify the not-really-implemented CLONE_THREAD/SIGHAND/VM code
Date: Wed, 24 Mar 2010 00:05:26 +0100	[thread overview]
Message-ID: <20100323230526.GA9932@redhat.com> (raw)
In-Reply-To: <m1hbo6u4xs.fsf@fess.ebiederm.org>

On 03/23, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > (on top of check_unshare_flags-kill-the-bogus-clone_sighand-sig-count-check.patch)
> >
> > Cleanup.
> >
> > sys_unshare(CLONE_THREAD/SIGHAND/VM) is not really implemented, and I doubt
> > very much it will ever work. At least, nobody even tried since the original
> > "unshare system call -v5: system call handler function" commit
> > 99d1419d96d7df9cfa56bc977810be831bd5ef64 was applied more than 4 years ago.
> >
> > And the code is not consistent. unshare_thread() always fails unconditionally,
> > while unshare_sighand() and unshare_vm() pretend to work if there is nothing
> > to unshare.
>
> This is setting off alarm bells in my head.
>
> I haven't traced this all through but I like your logic a lot less, and
> I think it is buggy.  Why don't we need to look at sigh->count ?

CLONE_SIGHAND needs CLONE_VM in copy_process(). It is not possible that
sighand->count > 1 while mm->mm_users <= 1.

> The current logic is very fine grained but it does a lot of simple logical
> checks and it ties those checks together if a very maintainable way.

I'd say the current simple logic is simple but wrong ;)

Before the recent changes check_unshare_flags() did

	if (*flags_ptr & CLONE_THREAD)
		*flags_ptr |= CLONE_VM;

	...
	
	if ((*flags_ptr & CLONE_SIGHAND) &&
	    (atomic_read(&current->signal->count) > 1))
		*flags_ptr |= CLONE_THREAD;

Now, if we add CLONE_THREAD, why we do not add CLONE_VM here? This is
not right.

And why unshare_thread() always fails even in single-threaded case?

But,

> You require that we know upfront all of the dependencies, which is things
> change subtlety can be a maintenance challenge.

Fortunately this all is not implemented anyway.

My point was: lets simplify this code, mainly to reduce the output from, say,
"grep CLONE_SIGHAND". In my opinion, it is a bit strange that the code which
doesn't really work adds the unnecessary dependencies to CLONE_THREAD/etc
subtleness.

> > Note: with or without this patch "atomic_read(mm->mm_users) > 1" can give
> > a false positive due to get_task_mm().
>
> I think the number of times get_task_mm is called on not current this isn't
> an interesting race.

Sure. I just meant that this check is wrong, but it was copied from the
current code. We could use current_is_single_threaded() though.


That said, I do not really care about this cleanup. I did it just because
I sent another patch which touches check_unshare_flags(), and I was really
surprised that ~70 lines in kernel/fork.c do nothing but confuse the reader.

Please nack this patch and lets forget it ;)

Oleg.


  reply	other threads:[~2010-03-23 23:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-23 17:08 [PATCH -mm] sys_unshare: simplify the not-really-implemented CLONE_THREAD/SIGHAND/VM code Oleg Nesterov
2010-03-23 21:02 ` Eric W. Biederman
2010-03-23 23:05   ` Oleg Nesterov [this message]
2010-03-31 23:53     ` Oleg Nesterov
2010-04-09 20:03 ` Roland McGrath

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=20100323230526.GA9932@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hch@lst.de \
    --cc=janak@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=roland@redhat.com \
    --cc=sgruszka@redhat.com \
    --cc=sukadev@us.ibm.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;
as well as URLs for NNTP newsgroup(s).