Re: [PATCH -mm] sys_unshare: simplify the not-really-implementedCLONE_THREAD/SIGHAND/VM code

[Oleg Nesterov]

On 03/23, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@xxxxxxxxxx> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/