Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755327Ab0BAP6J (ORCPT ); Mon, 1 Feb 2010 10:58:09 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:57251 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754733Ab0BAP6H (ORCPT ); Mon, 1 Feb 2010 10:58:07 -0500 Date: Mon, 1 Feb 2010 07:57:34 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Michal Simek cc: LKML , hpa@zytor.com, John Williams Subject: Re: Split 'flush_old_exec' into two functions - 221af7f87b97431e3ee21ce4b0e77d5411cf1549 In-Reply-To: <4B66DE64.8010101@petalogix.com> Message-ID: References: <4B66DE64.8010101@petalogix.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2027 Lines: 44 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/