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

From: Michal Simek
Date: Tue Feb 02 2010 - 05:18:33 EST


Linus Torvalds wrote:

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.

Would it be possible to cc me or send that patches to linux-next? I am doing every day tests and report results on my site. I would be able to catch up bugs earlier.


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?

Microblaze has support for both platforms MMU and noMMU. Only MMU version is affected. noMMU version is without any problem.

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

Most of them is busybox ELF with shared libraries. I tried non-shared ELF and the problem is the same.


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

no setuid.

Thanks,
Michal



Linus


--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
--
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/