Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1215157ybn; Wed, 25 Sep 2019 14:21:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqzVQLYalvBhG5j4O/PlahpmKgkCgiRgSJ67Z8qre8SdRgJaDe+xA/znjSga/3x/QeN+cWd0 X-Received: by 2002:a17:906:90c1:: with SMTP id v1mr156272ejw.259.1569446513274; Wed, 25 Sep 2019 14:21:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569446513; cv=none; d=google.com; s=arc-20160816; b=kBb9O/kJ62UJeohts0AE7UMFsTvoGfTeLU3bskvNCCeLj+NcDiqHqIeylFrKd3CTDQ XGHmu40QhCZ+36a6VQALKH6QfoGXYgjaepYcD7sKXWRRw44R7Jiy84i4PZH5McCS3vsK lhts9D0EUxDhIlH99qZiYfTM4AUW3SHMPtyV/EgDAKR4lnMUjTBNNbbUkRz2lBtXMVoN wL2P/pKfKHIfiGlabl0Lv+S9IZIo16erl6/B9ejU2Q6udA5mugb+QBbxlcsuOcIZZvsd CeGH5qFq8YrszRKedrb4w4/gTD3Y797yFp0m43SQe4h5YF3LfA/fHMLoRChj3FcarTp9 1HMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=1kR+G8ndtoJyKRtN7szpcKy6yBwnoxfBwdrDmTb45aE=; b=PWIu0nXxL5gzj2tPPhORrsgEURoP+KnlgkQ8oPvqajmYBDU5emnG37Z2tWoceVjOGP gRsKzURmqDMOD8TJUQvdb5H1XzlFwRfoYJYU7HPQaBOKs45ufjFua9rF63wJ+Tu2m3rn sGc/Eqf1zQ5isulM1wXt3XI1ExAvaXrSDaSvrlDQ/OuUPeQccsAFFASi6K8fZ9bFF6tz eLLScf7kuHeWL+dEH43GCGQUwcaAfnciS+SulIUKvAjKnmOpUxTHhPGHILlDqMoJ6YgH 4W5JQ3F9SIQm1tAoBu4WoIJJIhBf1o8kKNe28Tzj1YRFWmqVzA4R0fFzDwglIniISYqL V52g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=EDc55+Us; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 26si29722ejl.292.2019.09.25.14.21.29; Wed, 25 Sep 2019 14:21:53 -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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=EDc55+Us; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2440288AbfIWSEJ (ORCPT + 99 others); Mon, 23 Sep 2019 14:04:09 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:44553 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2440281AbfIWSEJ (ORCPT ); Mon, 23 Sep 2019 14:04:09 -0400 Received: by mail-lj1-f193.google.com with SMTP id m13so14577397ljj.11 for ; Mon, 23 Sep 2019 11:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1kR+G8ndtoJyKRtN7szpcKy6yBwnoxfBwdrDmTb45aE=; b=EDc55+UsUt1hlLqTRQpm9TOS1K4q0juc5fBusxwSGEQlx/lYD5sqi5FdaUC/djpdP9 fDW9guWgKyH5BjpKHGpvmcwvc2vRi5SCMb7hmXB4ugChfSwNDNWcht7pLo3VtEFR5Mug PetSOXu5wrIuFLoWC3lwUyfioMD/N0vuwvNWQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1kR+G8ndtoJyKRtN7szpcKy6yBwnoxfBwdrDmTb45aE=; b=aT1psBtCt3BYNPJjbhnxGtMK9TMU0Q15xlZ6Gti9Rf8nQGK2F+MtoBBQx0713kH31U fz5ZJ0A8Vx9J+BJxaNbh/dvRa85CXJAu0qcMTqCJFKVgJpWVSi+/hqNspDmRt8xQyHkG VDYpra7uRP2E1MAX7Ds0dTPiRxBlb5o+0AW0leVmMT/hn7hDfMFVnxanhq0Te/XXlKtg ANs17wv67yyRt+gm3xMVyYfbMxXQYsbwLDl65Fm8SMDf6yfyEh7la2P8mUu8Nu5D/g6u byDmH6MHxcA/we8ZVUYfc/LUbiu76WEg+Kkl/0urIn+7pl+1tqxVhc8A8ASCOTsInSp6 87Hg== X-Gm-Message-State: APjAAAUzPKYjOXLJ+wZoU9Qp4AXEUk7urJiVT8Qu4otOX5TE8QZ7OSKo NwPGZLyr1CpbzYKhV1lmwjmNJyDEP3c= X-Received: by 2002:a2e:96d5:: with SMTP id d21mr358102ljj.187.1569261846954; Mon, 23 Sep 2019 11:04:06 -0700 (PDT) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id r75sm2366407lff.7.2019.09.23.11.04.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Sep 2019 11:04:05 -0700 (PDT) Received: by mail-lf1-f44.google.com with SMTP id r134so10826066lff.12 for ; Mon, 23 Sep 2019 11:04:05 -0700 (PDT) X-Received: by 2002:a19:2489:: with SMTP id k131mr508976lfk.52.1569261845024; Mon, 23 Sep 2019 11:04:05 -0700 (PDT) MIME-Version: 1.0 References: <20190923042523.10027-1-peterx@redhat.com> <20190923042523.10027-6-peterx@redhat.com> In-Reply-To: <20190923042523.10027-6-peterx@redhat.com> From: Linus Torvalds Date: Mon, 23 Sep 2019 11:03:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 05/10] mm: Return faster for non-fatal signals in user mode faults To: Peter Xu Cc: Linux-MM , Linux Kernel Mailing List , David Hildenbrand , Hugh Dickins , Maya Gokhale , Jerome Glisse , Pavel Emelyanov , Johannes Weiner , Martin Cracauer , Marty McFadden , Shaohua Li , Andrea Arcangeli , Mike Kravetz , Denis Plotnikov , Mike Rapoport , Mel Gorman , "Kirill A . Shutemov" , "Dr . David Alan Gilbert" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 22, 2019 at 9:26 PM Peter Xu wrote: > > 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. So I really wish saome other vm person would also review these things, but looking over this series once more, this is the patch I probably like the least. And the reason I like it the least is that I have a hard time explaining to myself what the code does and why, and why it's so full of this pattern: > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) > + if ((fault & VM_FAULT_RETRY) && > + fault_should_check_signal(user_mode(regs))) > return; which isn't all that pretty. Why isn't this just static bool fault_signal_pending(unsigned int fault_flags, struct pt_regs *regs) { return (fault_flags & VM_FAULT_RETRY) && (fatal_signal_pending(current) || (user_mode(regs) && signal_pending(current))); } and then most of the users would be something like if (fault_signal_pending(fault, regs)) return; and the exceptions could do their own thing. Now the code is prettier and more understandable, I feel. And if something doesn't follow this pattern, maybe it either _should_ follow that pattern or it should just not use the helper but explain why it has an unusual pattern. Linus