Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1244235imu; Mon, 5 Nov 2018 16:50:36 -0800 (PST) X-Google-Smtp-Source: AJdET5eQiryC1/CmH1Y0kKeP32SLx785/7yL8LUOqu+AfUr83EgvGfT/N2TtYfv5AAYBkIRyq5ZG X-Received: by 2002:a63:9dca:: with SMTP id i193-v6mr20428467pgd.98.1541465436752; Mon, 05 Nov 2018 16:50:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541465436; cv=none; d=google.com; s=arc-20160816; b=PXXAeKJm+WOzIQgzsWTCqAcLo5pDkVt7Ogoq6Lv/V2jYImuVz3yLWvkOUNCeWNcO0I nsRUuR6jQstobf15U2pAZSCCl1iVM1OdIWBx9aJPnq3FWIzPp58gSTz1e5/mH75bQb/a 4oX5UG8UYmc50S8NxDMsmLjm8kN4y1UWyAgIPfgnarn+3LH42SwuIiJjR4C0DC1ooKZa ySaM3JffpgCQBxRtWDHgHVY7zk9u2bwi2wMKL9c3uFJEl8bj4VhkU7e6m8i0ri23NPPQ N21p4EjTXPSoamsYf7VGJnxaDDiL01U86OE4qI263ayRK6bV8smzLXvbuSnfW11+gQ8y d2MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from:dkim-signature; bh=xxXsp6v9r+3ulTIQ4em0nFoY7nv3+bABdty4jJSYBTU=; b=H+es2poB+IYru9viFQ2Y8v/gXp7/OC9G1TYz9VLP3tRe3FaNDE0JuhJM6Yli3fGuPC YH7VWuPztIcIdghTEy89o+FbsToW/zKMrcmtietlaOldk3NNuSTRm5HtMzg8ejb68TCx e+B68yAM0yq8jBDO8gbIWrkIDRqJ/ulbwEn5VLo9sV84d1SMwvj9fYcgpwUjVGlPXFA6 4XLcE/RKx7Y7RMI486Wvz9RycHdL9m0Fi1lF4FzgMfBxLkhRxS5IxbzDiLNxyibUDmfk lXtT5HAnffuduJQSfnZI3wqmoiFf5kzPVHguSSYKpe2mdsH5xJhc2YQ8N7up83fh+A0A BTPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@synopsys.com header.s=mail header.b=EowAh7NY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 7-v6si40309902pgm.171.2018.11.05.16.50.20; Mon, 05 Nov 2018 16:50:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@synopsys.com header.s=mail header.b=EowAh7NY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728874AbeKFKLB (ORCPT + 99 others); Tue, 6 Nov 2018 05:11:01 -0500 Received: from smtprelay2.synopsys.com ([198.182.60.111]:50904 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725839AbeKFKLA (ORCPT ); Tue, 6 Nov 2018 05:11:00 -0500 Received: from mailhost.synopsys.com (mailhost1.synopsys.com [10.12.238.239]) by smtprelay.synopsys.com (Postfix) with ESMTP id 5677110C0266; Mon, 5 Nov 2018 16:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synopsys.com; s=mail; t=1541465312; bh=edo+WmzUiBruAdNRiTVkFrkXQXJ/Q3lX7GQp7PE5elk=; h=From:To:CC:Subject:Date:References:From; b=EowAh7NYwGokBAqOltdnAnk+19ued/4TkD/w2qTJ0ocJ+LazjiS3uucYyRlKI8i0p BhcPWSHo3tP2HUvvUuJRA14MKUW9y6BLNbiqYctTgt2YS0xajODVYnSIYp2/Etk9sc CNYSvsYpQT5UGaDcAnzE4GGRKxBelqU7b624D9c7wx0/U/wpkGcoW88NPv+z3rbsv5 H9aBjp/hBVjjhOV7N+99GR1clwDNEZ25iNrlg5kE4lroSSLtHyx4FkiRnzrokUHfOu GTSZ/Kh8iUq58WaRRKoTe4pvC2CYtDL7IvoiC1PNga98cmVojhb8hX7MnRjdVYyGSG NsxXvjzOdyCQA== Received: from US01WEHTC3.internal.synopsys.com (us01wehtc3.internal.synopsys.com [10.15.84.232]) by mailhost.synopsys.com (Postfix) with ESMTP id 1776156FD; Mon, 5 Nov 2018 16:48:32 -0800 (PST) Received: from us01wembx1.internal.synopsys.com ([169.254.1.228]) by US01WEHTC3.internal.synopsys.com ([::1]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 16:48:32 -0800 From: Vineet Gupta To: Peter Xu , "linux-kernel@vger.kernel.org" CC: Alexey Brodkin , "Eric W. Biederman" , Andrew Morton , "Souptick Joarder" , Andrea Arcangeli , "linux-snps-arc@lists.infradead.org" Subject: Re: [PATCH RFC] mm: arc: fix potential double realease of mmap_sem Thread-Topic: [PATCH RFC] mm: arc: fix potential double realease of mmap_sem Thread-Index: AQHUcZJWAhL05uLd1Uaujch30fnJhg== Date: Tue, 6 Nov 2018 00:48:31 +0000 Message-ID: References: <20181101032354.19351-1-peterx@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.199.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/31/18 8:24 PM, Peter Xu wrote:=0A= > In do_page_fault() of ARC we have:=0A= >=0A= > ...=0A= > fault =3D handle_mm_fault(vma, address, flags);=0A= >=0A= > /* If Pagefault was interrupted by SIGKILL, exit page fault "earl= y" */=0A= > if (unlikely(fatal_signal_pending(current))) {=0A= > if ((fault & VM_FAULT_ERROR) && !(fault & VM_FAULT_RETRY)= )=0A= > up_read(&mm->mmap_sem); <---------------- [1]= =0A= > if (user_mode(regs))=0A= > return;=0A= > }=0A= > ...=0A= > if (likely(!(fault & VM_FAULT_ERROR))) {=0A= > ...=0A= > return;=0A= > }=0A= >=0A= > if (fault & VM_FAULT_OOM)=0A= > goto out_of_memory; <----------------- [2]=0A= > else if (fault & VM_FAULT_SIGSEGV)=0A= > goto bad_area; <----------------- [3]=0A= > else if (fault & VM_FAULT_SIGBUS)=0A= > goto do_sigbus; <----------------- [4]=0A= >=0A= > Logically it's possible that we might try to release the mmap_sem twice= =0A= > by having a scenario like:=0A= >=0A= > - task received SIGKILL,=0A= > - task handled kernel mode page fault,=0A= > - handle_mm_fault() returned with one of VM_FAULT_ERROR,=0A= >=0A= > Then we'll go into path [1] to release the mmap_sem, however we won't=0A= > return immediately since user_mode(regs) check will fail (a kernel page= =0A= > fault). Then we might go into either [2]-[4] and either of them will=0A= > try to release the mmap_sem again.=0A= >=0A= > To fix this, we only release the mmap_sem at [1] when we're sure we'll=0A= > quit immediately (after we checked with user_mode(regs)).=0A= =0A= Hmm, do_page_fault() needs a serious makeover. There's a known problem in t= he area=0A= you touched (with test case) where we fail to relinquish the mmap_sem for w= hich=0A= Alexey had provided a fix. But I'm going to redo this part now and CC you f= olks=0A= for review. OK ?=0A= =0A= >=0A= > CC: Vineet Gupta =0A= > CC: "Eric W. Biederman" =0A= > CC: Peter Xu =0A= > CC: Andrew Morton =0A= > CC: Souptick Joarder =0A= > CC: Andrea Arcangeli =0A= > CC: linux-snps-arc@lists.infradead.org=0A= > CC: linux-kernel@vger.kernel.org=0A= > Signed-off-by: Peter Xu =0A= > ---=0A= >=0A= > I noticed this only by reading the code. Neither have I verified the=0A= > issue, nor have I tested the patch since I even don't know how to (I'm=0A= > totally unfamiliar with the arc architecture). However I'm posting this= =0A= > out first to see whether there's any quick feedback, and in case it's a= =0A= > valid issue that we've ignored.=0A= > ---=0A= > arch/arc/mm/fault.c | 7 +++----=0A= > 1 file changed, 3 insertions(+), 4 deletions(-)=0A= >=0A= > diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c=0A= > index c9da6102eb4f..2d28c3dad5c1 100644=0A= > --- a/arch/arc/mm/fault.c=0A= > +++ b/arch/arc/mm/fault.c=0A= > @@ -142,11 +142,10 @@ void do_page_fault(unsigned long address, struct pt= _regs *regs)=0A= > fault =3D handle_mm_fault(vma, address, flags);=0A= > =0A= > /* If Pagefault was interrupted by SIGKILL, exit page fault "early" */= =0A= > - if (unlikely(fatal_signal_pending(current))) {=0A= > - if ((fault & VM_FAULT_ERROR) && !(fault & VM_FAULT_RETRY))=0A= > + if (unlikely(fatal_signal_pending(current) && user_mode(regs))) {=0A= > + if (!(fault & VM_FAULT_RETRY))=0A= > up_read(&mm->mmap_sem);=0A= > - if (user_mode(regs))=0A= > - return;=0A= > + return;=0A= > }=0A= > =0A= > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);=0A= =0A=