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(¤t->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.
next prev parent 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 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.