From patchwork Wed Mar 14 16:36:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexey Brodkin X-Patchwork-Id: 885911 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:e::133; helo=bombadil.infradead.org; envelope-from=linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=synopsys.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="o1medloT"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 401cn21xnKz9sTs for ; Thu, 15 Mar 2018 03:36:38 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Content-ID:Message-ID:Date :Subject:To:From:Reply-To:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=hUjIjlM49JW/eLGgQ+74shTqqwMKJ+hjpdXIIGwZZL8=; b=o1medloTWaAtYV lvGxHU03VeyLrPROt4HljDimh4VF/YSFPu4hscWu/RAzMdpJNeGS2Pdcf7V6G+d3s9pFMbdTojQv6 IIfz4rSA54eDFb1nhpSaiLb38BKg9Nbk9hCNU0NeTlp/RQaZXS4RzEmIR3I1+EgLZp+ei8r55tI1I 4GfmZwaZCgA7zqjAFzKhLbs+VQwLgsVLVR6YqS0rL2qIwbET/mPKU/AKZzrUPcNkmpipvGiEsDYT/ qnki+NRrauLmsuoSJdqxdfICB9q4G4+XVVBwHbiW6R/LMkzgutj1DbTqLQNgLg+jMER4+uFzfN6wh BrJm0/oswcc7cjoZNS7w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1ew9OG-0001PQ-Bn; Wed, 14 Mar 2018 16:36:36 +0000 Received: from smtprelay2.synopsys.com ([198.182.60.111] helo=smtprelay.synopsys.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1ew9OC-0001Oe-OQ for linux-snps-arc@lists.infradead.org; Wed, 14 Mar 2018 16:36:34 +0000 Received: from mailhost.synopsys.com (mailhost3.synopsys.com [10.12.238.238]) by smtprelay.synopsys.com (Postfix) with ESMTP id 74B8410C0D36 for ; Wed, 14 Mar 2018 09:36:20 -0700 (PDT) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id 6159433F1 for ; Wed, 14 Mar 2018 09:36:20 -0700 (PDT) Received: from US01WEHTC3.internal.synopsys.com (us01wehtc3.internal.synopsys.com [10.15.84.232]) by mailhost.synopsys.com (Postfix) with ESMTP id 501DD33EF for ; Wed, 14 Mar 2018 09:36:20 -0700 (PDT) Received: from DE02WEHTCB.internal.synopsys.com (10.225.19.94) by US01WEHTC3.internal.synopsys.com (10.15.84.232) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 14 Mar 2018 09:36:19 -0700 Received: from DE02WEMBXB.internal.synopsys.com ([fe80::95ce:118a:8321:a099]) by DE02WEHTCB.internal.synopsys.com ([::1]) with mapi id 14.03.0361.001; Wed, 14 Mar 2018 17:36:17 +0100 From: Alexey Brodkin To: Vineet Gupta Subject: arc_usr_cmpxchg and preemption Thread-Topic: arc_usr_cmpxchg and preemption Thread-Index: AQHTu7KSgtMaj81NvU2WaxKl+xOkrg== Date: Wed, 14 Mar 2018 16:36:16 +0000 Message-ID: <1521045375.11552.27.camel@synopsys.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.225.15.87] Content-ID: <89B854BDC3914C4ABE0AC37BFAC56D71@internal.synopsys.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180314_093632_935016_67601BF6 X-CRM114-Status: UNSURE ( 9.65 ) X-CRM114-Notice: Please train this message. X-Spam-Score: -0.0 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.182.60.111 listed in list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-snps-arc@lists.infradead.org" Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Hi Vineet, While debugging a segfault of user-space app on system without atomic ops (I mean LLOCK/SCOND) I understood the root-cause is in implementation of kernel's __NR_arc_usr_cmpxchg syscall which is supposed to emulate mentioned atomic ops for user-space. So here's a problem. 1. User-space app [via libc] triggers __NR_arc_usr_cmpxchg syscall, we enter arc_usr_cmpxchg()which basically does: ---------------------------->8------------------------------- preempt_disable(); __get_user(uval, uaddr); __put_user(new, uaddr); preempt_enable(); ---------------------------->8------------------------------- 2. Most of the time everything is fine because __get_user()/__put_user() for ARC is just LD/ST. 3. Rarely user's variable is situated in not yet allocated page. Here I mean copy-on-write case, when a page has read-only flag in TLB. In that case __get_user() succeeds but __put_user() causes Privilege Violation exception and we enter do_page_fault() where new page allocation with proper access bits is supposed to happen... but that never happens because with preempt_disable() we set in_atomic() which set faulthandler_disabled() and so we exit early from page fault handler effectively with nothing done, i.e. user's variable is left unchanged which in its turn causes very strange problems later down the line because we don't notify user-space app about failed data modification. The simplest fix is to not mess with preemption: ---------------------------->8------------------------------- But I'm not really sure how safe is that. Especially if we think about PREEMPT_RT for example. Any thoughts? -Alexey P.S. In our emulation of unaligned access we don't seem to disable preemption so it might be a good idea to "align" syscall implementation is both cases. diff --git a/arch/arc/kernel/process.c b/arch/arc/kernel/process.c index 5ac3b547453f..d1713d8d3981 100644 --- a/arch/arc/kernel/process.c +++ b/arch/arc/kernel/process.c @@ -63,8 +63,6 @@ SYSCALL_DEFINE3(arc_usr_cmpxchg, int *, uaddr, int, expected, int, new) if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int))) return -EFAULT; - preempt_disable(); - if (__get_user(uval, uaddr)) goto done; @@ -74,8 +72,6 @@ SYSCALL_DEFINE3(arc_usr_cmpxchg, int *, uaddr, int, expected, int, new) } done: - preempt_enable(); - return uval; } ---------------------------->8-------------------------------