Re: Split 'flush_old_exec' into two functions - 221af7f87b97431e3ee21ce4b0e77d5411cf1549

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 1 Feb 2010, Michal Simek wrote:
>
> Hi Peter and Linus,
> 
> commit 221af7f87b97431e3ee21ce4b0e77d5411cf1549 breaks anything on Microblaze.

Gaah. My original version of that patch very much tried to make it a no-op 
semantically, but then Peter made some preparatory changes for the next 
patch, so it actually changes semantics a bit. I was expecting that to be 
benign, but clearly there are issues.

> None reported any problem that's why I think that is Microblaze related.

Well, our previous handling of the critical stage of 'execve()' when we 
actually switch from the old process to the new was _so_ grotty that many 
architectures ended up playing some really subtle games there. The whole 
point of the patch is to get rid of the games, but it's entirely possible 
that Microblaze (and others) had crazy things going on that broke when we 
made the ordering more straightforward.

That said, Microblaze is not one of the architectures I would have 
expected to have problems. It has one of the most straightforward 
"flush_thread()" implementations in the whole kernel (it's a no-op ;), and 
that's where most of the hacky things were for the architectures that 
needed the change. And it has no "arch_pick_mmap_layout()" issues or 
anything else that tends to depend on personality bits or whatever.

Microblaze is a no-MMU platform, isn't it? Which binary format does it 
use? It looks like _some_ binaries work (it seems to happily be running a 
shell to actually do those startup scripts) while others have problems. Is 
there a difference between "/bin/sh" and the binaries that seem to be 
problematic (like /bin/mount and /bin/ifup).

Are the failing binaries all setuid ones, for example? Or shared vs 
non-shared? Or ELF vs FLAT or whatever?

		Linus