Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp160973ybn; Tue, 24 Sep 2019 20:24:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwc/lb4v9uuyDWSYOYcZgTHRdY/e/roBZplPJP31jKD9upRj8oqzZwaHF0UoFilKBbltewu X-Received: by 2002:a5d:6ac8:: with SMTP id u8mr6441928wrw.104.1569381858147; Tue, 24 Sep 2019 20:24:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569381858; cv=none; d=google.com; s=arc-20160816; b=OE/tq9dDKE7Ee56qQQDIDR2FH1zU6GZwYz9p9Hi2mY1IkUtja0f0X6pNaQyV/JhHV1 3MjeFu9D4GiklRzE8dd0K11sdTSAI426GaYI7ZKpH3NFa83LNywBHEsEKnOQoWAyH/HA eTYXMAwE6luUHrf1lvVoQNS1YxJnIz1vYiNDIS/nZ4afOLa3+VC7ggnQMAylteq/6Hyg sooqc9RRJxd75T3+/FwzMORiOOhMmfYC7jiRnAwD2Z3BwR3Mq+YjGcchDb/MsEK7b7dJ Q/IBPgGYSB/JJya0AUu+CZsoO1e0dcJWJj0z8RDhStqbNiKnuJMHBN6EPuFMdWazgBm0 y63g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=hmCNR49q9HpXGRvKjuRuWGZM/G5xvOD8IvISTorYf1k=; b=ivatuMdMUY3qbCIKeaiNL3hwzMJ4ftHg/qc3LbTI/+TMy768zhrtKYTb4jCJjL3eo7 leW3olch2iBVTSA4P32kOvGMLWhGHCIZXtSCd0npfE4w3Q3avhVAHFjGadlLTehExubR 9VdUxdGzn+O5ke79qlYuqD8HrWXo+3zHdB3Oy/NtXWq9znkmu/TnwNKu+iVtcecLd0VD t9/NvmE5870zPXaXuDMqYzkea4ITljMaMlgR1mynMJl85Yy7MNIxpQ+xdeOjnhj/ya8w fcjA8Blr7SA89mDQESn9iJz1wxU3dciYO92l8T4mCPTV9wa56o+Lvw9DdE0tN+OnTcN0 JcmA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s54si2664489edm.215.2019.09.24.20.23.54; Tue, 24 Sep 2019 20:24:18 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404163AbfIWE02 (ORCPT + 99 others); Mon, 23 Sep 2019 00:26:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58172 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403797AbfIWE00 (ORCPT ); Mon, 23 Sep 2019 00:26:26 -0400 Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) (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 503C2C056808 for ; Mon, 23 Sep 2019 04:26:26 +0000 (UTC) Received: by mail-pf1-f200.google.com with SMTP id s139so9382610pfc.21 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=NB8HZJbD6nArOGR+1GN2PbBPCk0qeZ3DqiXnWxZHbb9+lSOKZCw7O32K03rFa9kVJR niUJgGhOv5paq9kVyISTOWD7/EbMDBOjDOJU2WQY0P10jDBx2MpdxFov1/hAEpKZLjOw RnFZ/bX7MmWd/fpkhwab1zQ5GvjFtnymEyF6EUJNzcQtTUgBpaWpstIELsbz6dpKWSvu 4OvSImf/TJu578y6WxilE+zgB8NY6llBIY2om5wMEL+bIG8q2h/RmQ3mdNAIzEHFJJUc qtB9fSlH8gCyj2hBSrJ6km0f1uYuDKjPsCbWijEIdj95/wEGGKhf+l3JgBgUFHMm1R4X 5utg== X-Gm-Message-State: APjAAAVVTplAzu0NTW3xRdeE98OR/Yg0mnxAklkhhsOnzYTwKGO0oInT ikbqKbAkCRazzY1bAI1u/FaLEpterewFiO2OYlnhz6+P0bn+6mDfUqceeoa7I1frMvm6YPovQE4 JmRhEfhNA18ttEkVMP91lBFzC X-Received: by 2002:a65:5546:: with SMTP id t6mr27177520pgr.441.1569212785758; Sun, 22 Sep 2019 21:26:25 -0700 (PDT) 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 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 -- 2.21.0