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 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).