From patchwork Mon Sep 23 04:25:19 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 11156031 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B17E91599 for ; Mon, 23 Sep 2019 04:26:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 879F820820 for ; Mon, 23 Sep 2019 04:26:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 879F820820 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CA6046B0270; Mon, 23 Sep 2019 00:26:28 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id C7CFF6B0271; Mon, 23 Sep 2019 00:26:28 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B94DB6B0272; Mon, 23 Sep 2019 00:26:28 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id 990116B0270 for ; Mon, 23 Sep 2019 00:26:28 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 47EAF3A87 for ; Mon, 23 Sep 2019 04:26:28 +0000 (UTC) X-FDA: 75964898856.24.burst89_7299b3119d956 X-Spam-Summary: 1,0,0,,d41d8cd98f00b204,peterx@redhat.com,::linux-kernel@vger.kernel.org:david@redhat.com:hughd@google.com:gokhale2@llnl.gov:jglisse@redhat.com:xemul@virtuozzo.com:hannes@cmpxchg.org:peterx@redhat.com:cracauer@cons.org:mcfadden8@llnl.gov:shli@fb.com:aarcange@redhat.com:mike.kravetz@oracle.com:dplotnikov@virtuozzo.com:rppt@linux.vnet.ibm.com:torvalds@linux-foundation.org:mgorman@suse.de:kirill@shutemov.name:dgilbert@redhat.com,RULES_HIT:30012:30054:30091,0,RBL:209.132.183.28:@redhat.com:.lbl8.mailshell.net-62.18.0.0 64.10.201.10,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:ft,MSBL:0,DNSBL:neutral,Custom_rules:0:1:0,LFtime:25,LUA_SUMMARY:none X-HE-Tag: burst89_7299b3119d956 X-Filterd-Recvd-Size: 5148 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Sep 2019 04:26:27 +0000 (UTC) Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8B6A6756 for ; Mon, 23 Sep 2019 04:26:26 +0000 (UTC) Received: by mail-pf1-f199.google.com with SMTP id w16so9416488pfj.9 for ; Sun, 22 Sep 2019 21:26:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=hmCNR49q9HpXGRvKjuRuWGZM/G5xvOD8IvISTorYf1k=; b=AbjUDoXbDXvTbUaZ0PT3/W4yLGrC9zsLw9NBmQfU6sCJVxFElLu6RIda7aH0pWyioN GpY/HG6r+jA7TVmm3Yjqc42ufbyV0ZAMjK1qWc09sh39/Js5+kEau/91OKvqz3scLjvF D8TKKpvwEn4lz04rIoNMaZ2gCqwsZOCuQJC70jKElezivjXyOQKVSXiJppP2+6XNHAoM TRDS8WLkW40rrVF5rJFQz7t7qFg9R9F04VBbFrVA6AqYUQO/8QHbg35JBTjx02/t5psV XbrCuaarkP9/SWFHhEcNpn+srx3v4WBt8Fovys1ppjycQb5cZU547JeVTFEL7lQDMZAX rqOQ== X-Gm-Message-State: APjAAAUrlAB7EBMgsfYTMIrh4+g+JcO+CwZRqNH63BV08NYx8b4z5tDw mpuA9d3AYjUxjF8a+lfmNMZBLApgUbM8JmiKKR/+ESdTkzmtI6XroLvv0T0iGi3zF5SMVeUmonH u4Er1zPQ+hzY= X-Received: by 2002:a65:5546:: with SMTP id t6mr27177514pgr.441.1569212785747; Sun, 22 Sep 2019 21:26:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqygb3V/LkvF1CW/oddzTISxP+CyZpRHXEfJdMfg/L+uhJ5pN2m1AqoDMJvxWgNhDIwD+LUMWA== X-Received: by 2002:a65:5546:: with SMTP id t6mr27177491pgr.441.1569212785463; Sun, 22 Sep 2019 21:26:25 -0700 (PDT) Received: from xz-x1.redhat.com ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id x20sm11781867pfp.120.2019.09.22.21.26.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Sep 2019 21:26:24 -0700 (PDT) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: David Hildenbrand , Hugh Dickins , Maya Gokhale , Jerome Glisse , Pavel Emelyanov , Johannes Weiner , peterx@redhat.com, Martin Cracauer , Marty McFadden , Shaohua Li , Andrea Arcangeli , Mike Kravetz , Denis Plotnikov , Mike Rapoport , Linus Torvalds , Mel Gorman , "Kirill A . Shutemov" , "Dr . David Alan Gilbert" Subject: [PATCH v4 06/10] userfaultfd: Don't retake mmap_sem to emulate NOPAGE Date: Mon, 23 Sep 2019 12:25:19 +0800 Message-Id: <20190923042523.10027-7-peterx@redhat.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190923042523.10027-1-peterx@redhat.com> References: <20190923042523.10027-1-peterx@redhat.com> MIME-Version: 1.0 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: This patch removes the risk path in handle_userfault() then we will be sure that the callers of handle_mm_fault() will know that the VMAs might have changed. Meanwhile with previous patch we don't lose responsiveness as well since the core mm code now can handle the nonfatal userspace signals even if we return VM_FAULT_RETRY. Suggested-by: Andrea Arcangeli Suggested-by: Linus Torvalds Reviewed-by: Jerome Glisse Signed-off-by: Peter Xu --- fs/userfaultfd.c | 24 ------------------------ 1 file changed, 24 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 3c55ee64bcb1..2b3b48e94ae4 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -522,30 +522,6 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason) __set_current_state(TASK_RUNNING); - if (return_to_userland) { - if (signal_pending(current) && - !fatal_signal_pending(current)) { - /* - * If we got a SIGSTOP or SIGCONT and this is - * a normal userland page fault, just let - * userland return so the signal will be - * handled and gdb debugging works. The page - * fault code immediately after we return from - * this function is going to release the - * mmap_sem and it's not depending on it - * (unlike gup would if we were not to return - * VM_FAULT_RETRY). - * - * If a fatal signal is pending we still take - * the streamlined VM_FAULT_RETRY failure path - * and there's no need to retake the mmap_sem - * in such case. - */ - down_read(&mm->mmap_sem); - ret = VM_FAULT_NOPAGE; - } - } - /* * Here we race with the list_del; list_add in * userfaultfd_ctx_read(), however because we don't ever run