From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EC0DC43331 for ; Thu, 2 Apr 2020 04:08:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 03979208E4 for ; Thu, 2 Apr 2020 04:08:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="PkXOBvrq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03979208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A82438E005E; Thu, 2 Apr 2020 00:08:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A31338E000D; Thu, 2 Apr 2020 00:08:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 920428E005E; Thu, 2 Apr 2020 00:08:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id 73B708E000D for ; Thu, 2 Apr 2020 00:08:32 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 33539180AD807 for ; Thu, 2 Apr 2020 04:08:32 +0000 (UTC) X-FDA: 76661583264.27.cloud95_4a8026a30911f X-HE-Tag: cloud95_4a8026a30911f X-Filterd-Recvd-Size: 4121 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Apr 2020 04:08:31 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5F83D208E0; Thu, 2 Apr 2020 04:08:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585800511; bh=lK1hMBfrKaJMH6oKKZzYLxYBXHgn2pLyY5Xi9fSYepI=; h=Date:From:To:Subject:In-Reply-To:From; b=PkXOBvrq1tqTGm9CoH7xFPpBnxutoyRlN8P8TzzhxVuxCYoMHWwxsw28KZ9gxEEwi lLKJr+jwCoBUT5fT2SFh5qmyaDN4FJTkhTeCVVVbuQTT3zYKNFykwCnQO/NjVRD15E 4PpPcBy4o1Rip0cT10p7H/Bc4KTrNlUcvbmGIxsE= Date: Wed, 01 Apr 2020 21:08:29 -0700 From: Andrew Morton To: aarcange@redhat.com, akpm@linux-foundation.org, bgeffon@google.com, bobbypowers@gmail.com, cracauer@cons.org, david@redhat.com, dgilbert@redhat.com, dplotnikov@virtuozzo.com, gokhale2@llnl.gov, hannes@cmpxchg.org, hughd@google.com, jglisse@redhat.com, kirill@shutemov.name, linux-mm@kvack.org, mcfadden8@llnl.gov, mgorman@suse.de, mike.kravetz@oracle.com, mm-commits@vger.kernel.org, peterx@redhat.com, rppt@linux.vnet.ibm.com, torvalds@linux-foundation.org, willy@infradead.org, xemul@openvz.org Subject: [patch 094/155] mm: return faster for non-fatal signals in user mode faults Message-ID: <20200402040829.N5c0ja2Rp%akpm@linux-foundation.org> In-Reply-To: <20200401210155.09e3b9742e1c6e732f5a7250@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Peter Xu Subject: mm: return faster for non-fatal signals in user mode faults The idea comes from the upstream discussion between Linus and Andrea: https://lore.kernel.org/lkml/20171102193644.GB22686@redhat.com/ A summary to the issue: there was a special path in handle_userfault() in the past that we'll return a VM_FAULT_NOPAGE when we detected non-fatal signals when waiting for userfault handling. We did that by reacquiring the mmap_sem before returning. However that brings a risk in that the vmas might have changed when we retake the mmap_sem and even we could be holding an invalid vma structure. This patch is a preparation of removing that special path by allowing the page fault to return even faster if we were interrupted by a non-fatal signal during a user-mode page fault handling routine. Link: http://lkml.kernel.org/r/20200220160230.9598-1-peterx@redhat.com Signed-off-by: Peter Xu Suggested-by: Linus Torvalds Suggested-by: Andrea Arcangeli Tested-by: Brian Geffon Cc: Bobby Powers Cc: David Hildenbrand Cc: Denis Plotnikov Cc: "Dr . David Alan Gilbert" Cc: Hugh Dickins Cc: Jerome Glisse Cc: Johannes Weiner Cc: "Kirill A . Shutemov" Cc: Martin Cracauer Cc: Marty McFadden Cc: Matthew Wilcox Cc: Maya Gokhale Cc: Mel Gorman Cc: Mike Kravetz Cc: Mike Rapoport Cc: Pavel Emelyanov Signed-off-by: Andrew Morton --- include/linux/sched/signal.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/include/linux/sched/signal.h~mm-return-faster-for-non-fatal-signals-in-user-mode-faults +++ a/include/linux/sched/signal.h @@ -381,7 +381,8 @@ static inline bool fault_signal_pending( struct pt_regs *regs) { return unlikely((fault_flags & VM_FAULT_RETRY) && - fatal_signal_pending(current)); + (fatal_signal_pending(current) || + (user_mode(regs) && signal_pending(current)))); } /* _