From patchwork Tue Aug 11 20:20:05 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 6994511 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 77AA0C05AC for ; Tue, 11 Aug 2015 20:22:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9F5A720606 for ; Tue, 11 Aug 2015 20:22:39 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C072020605 for ; Tue, 11 Aug 2015 20:22:38 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZPG2F-0001iK-1p; Tue, 11 Aug 2015 20:20:35 +0000 Received: from relais.videotron.ca ([24.201.245.36]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZPG2B-0001cY-F5 for linux-arm-kernel@lists.infradead.org; Tue, 11 Aug 2015 20:20:31 +0000 MIME-version: 1.0 Received: from yoda.home ([96.23.157.65]) by VL-VM-MR003.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0NSX00I9KPTI7W70@VL-VM-MR003.ip.videotron.ca> for linux-arm-kernel@lists.infradead.org; Tue, 11 Aug 2015 16:20:08 -0400 (EDT) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id 0D76B2DA01EA; Tue, 11 Aug 2015 16:20:06 -0400 (EDT) Date: Tue, 11 Aug 2015 16:20:05 -0400 (EDT) From: Nicolas Pitre To: Russell King - ARM Linux Subject: Re: arm kernel oops in highmem.c with 4.2 In-reply-to: <20150811195638.GC7557@n2100.arm.linux.org.uk> Message-id: References: <20150805100701.GV7557@n2100.arm.linux.org.uk> <20150805112713.GY7557@n2100.arm.linux.org.uk> <1439315290.3153.11.camel@redhat.com> <20150811181008.GA7557@n2100.arm.linux.org.uk> <20150811195638.GC7557@n2100.arm.linux.org.uk> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150811_132031_590875_105D2DA8 X-CRM114-Status: GOOD ( 19.23 ) X-Spam-Score: -2.6 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Robinson , linux-arm-kernel@lists.infradead.org, Mark Salter Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, 11 Aug 2015, Russell King - ARM Linux wrote: > On Tue, Aug 11, 2015 at 03:41:52PM -0400, Nicolas Pitre wrote: > > I'd agree. But first I'd like to know why the fedora kernel is using > > CONFIG_UACCESS_WITH_MEMCPY? If it's just because it sounded cool then > > that's a bad reason. > > > > That code was created to work around inneficiency in the Orion CPU core > > that didn't coalesce writes from STRT instructions, and by using plain > > STR and/or STM the actual throughput was more than doubled. This was > > fixed in later cores. However Orion users (if they still exist) might > > like the added performance. I don't have Orion-based targets anymore > > (they took the way of the recycling facility a while ago). > > Irrespective of that, what has been found is that the implementation is > unsafe - it is taking a semaphore when page faults are disabled. In > other words, notwithstanding the above, it's buggy no matter if it's > an Orion CPU core, or highmem, or what. Any place in the kernel which > uses pagefault_disable() and then calls into this code will be buggy. > > It needs fixing or removing. Absolutely. I'm not disputing that. I'm only asking so we can wisely choose between fixing or removing. Personally I'd be inclined towards the later, unless the following is sufficient to fix it: > Even if it is fixed, making it _depend_ on CPU_FEROCEON sounds like a > good idea if non-orion stuff isn't supposed to be enabling it. Or > something like that. It is not clear to me exactly which cores are affected. That's why the Kconfig entry was left open to all, in case it could benefit others. In theory it shouldn't be harmful to anyone notwithstanding the caveat mentioned in the help text. Nicolas diff --git a/arch/arm/lib/uaccess_with_memcpy.c b/arch/arm/lib/uaccess_with_memcpy.c index 3e58d71001..4b39af2dfd 100644 --- a/arch/arm/lib/uaccess_with_memcpy.c +++ b/arch/arm/lib/uaccess_with_memcpy.c @@ -96,7 +96,7 @@ __copy_to_user_memcpy(void __user *to, const void *from, unsigned long n) } /* the mmap semaphore is taken only if not in an atomic context */ - atomic = in_atomic(); + atomic = faulthandler_disabled(); if (!atomic) down_read(¤t->mm->mmap_sem);