Re: [update] Re: new execve/kernel_thread design

[Al Viro <viro@ZenIV.linux.org.uk>]

On Fri, Oct 26, 2012 at 07:31:07PM +0100, Al Viro wrote:
> 	The situation got much better by now.  More than a half of
> architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
> parisc sparc tile um unicore32 and x86.
> 
> 	Two more avait ACKs from maintainers - powerpc and s390.  Should work,
> AFAICS.
> 
> 	xtensa - Max was going to repost updated patches; waiting for that
> to happen, but essentially it's done and tested.
> 
> 	microblaze - Michal was debugging kernel_execve side of it the last
> time I've heard from him...
> 
> 	frv, mn10300 - dhowells was going to test those
> 
> 	sh - Paul Mundt was going to test and send fixes
> 
> 	avr32, blackfin, cris, h8300, m32r, score - no signs of life from
> maintainers.  Folks, please show up and at least test the damn patchsets.
> Hell knows, they might even work - unicore32 one did, modulo trivial typo,
> to my deep surprise...

BTW, there's a tangentially related issue: several architectures have
very odd clone(2).  Namely, blackfin, h8300, no-MMU microblaze and sh64 (==sh5)
silently ignore child_tidptr and parent_tidptr arguments.  I.e. treat them
as NULL - or as if CLONE_PARENT_SETTID/CLONE_CHILD_SETTID/CLONE_CHILD_CLEARTID
were never set.  With the patchset in the local part of queue it would be
trivial to switch to normal semantics; strictly speaking, it's an ABI change.
Somebody doing
	n = 0x69696969;
	if (clone(CLONE_PARENT_SETTID, 0, &n) > 0) {
		if (n != 0x69696969) {
			printf("oh, shit, we are not on blackfin\n");
			exit(-1);
		}
	}
would run into a user-visible behaviour change, but IMO that's in the realm
of testing for known architecture-dependent bugs and finding them fixed...

Opinions, vetoes?  Should we preserve the current behaviour in this case?
I would obviously prefer to just go ahead and fix the sucker - the odds of
any actual software depending on that behaviour are pretty much nil.
Linus, does that cross the boundary between bug fix and ABI breakage?

Another curious thing happens on blackfin; there we subtract 12 from usp
when it's non-zero (zero == inherit the parent's usp, as always).  No idea
why is that done; this one definitely has to be preserved, so I'm just
wondering about the reasons behind that oddity...  Mike?