From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: linux-next: manual merge of the akpm-current tree with the tip tree Date: Tue, 14 Jan 2014 07:48:22 -0800 Message-ID: <52D55C46.6010701@zytor.com> References: <20140114155331.88d170d3c991b9465c23a537@canb.auug.org.au> <20140114125153.GY7572@laptop.programming.kicks-ass.net> <52D55479.9010802@zytor.com> <20140114154142.GG7572@laptop.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from terminus.zytor.com ([198.137.202.10]:51684 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751631AbaANPtM (ORCPT ); Tue, 14 Jan 2014 10:49:12 -0500 In-Reply-To: <20140114154142.GG7572@laptop.programming.kicks-ass.net> Sender: linux-next-owner@vger.kernel.org List-ID: To: Peter Zijlstra , Geert Uytterhoeven Cc: Stephen Rothwell , Andrew Morton , Thomas Gleixner , Ingo Molnar , Linux-Next , "linux-kernel@vger.kernel.org" , Davidlohr Bueso On 01/14/2014 07:41 AM, Peter Zijlstra wrote: >>> >>> I am *guessing* that m68k is has get_fs() == KERNEL_DS at the point that >>> futex_init() is called. This would seem a bit of a peculiarity to m68k, >>> and as such it would seem like it would be better for it to belong in >>> the m68k-specific code, but since futex_init() is init code and only >>> called once anyway it shouldn't cause any harm... >> >> Yes it does. So when getting the exception on 68030, we notice it's a kernel >> space access error, not a user space access error, and crash. > > Is there a good reason m68k works like this? That is, shouldn't we fix > the arch code instead of littering the generic code with weirdness like > this? > Given that futex_init is called from initcall, this seems *really* weird on the part of m68k. I agree this should be fixed where the problem sits. -hpa