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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15CD5C77B72 for ; Fri, 14 Apr 2023 22:14:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 836D3900004; Fri, 14 Apr 2023 18:14:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E6DD900002; Fri, 14 Apr 2023 18:14:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D633900004; Fri, 14 Apr 2023 18:14:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5ED7C900002 for ; Fri, 14 Apr 2023 18:14:37 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2EE73A040D for ; Fri, 14 Apr 2023 22:14:37 +0000 (UTC) X-FDA: 80681401794.02.19DF711 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf07.hostedemail.com (Postfix) with ESMTP id 6788040008 for ; Fri, 14 Apr 2023 22:14:35 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=ZyvI9Iyb; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681510475; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gk9HExao/5Lprbj05MOjxLiOOiVyd+QICb9ACljDPzk=; b=mn5YcWn9IS5x/r3K2WfYV3lSIhMxI/E1YQgK8+/Zh8H9JivzAPIaqcplnp/SG5DU9P0Gfg O0QGHjRJhOoRhal77/NhHOZwXJ8lFUUNn7PXNvZZ9uPGpCHW27Je61BPy5IA+6Rdt2ltyk ECyxu6vwWQNsdt1FpAyv0uM8sY36+2o= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=ZyvI9Iyb; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681510475; a=rsa-sha256; cv=none; b=B0+6NSf6yH3l3JcavBRseb7TNNSUAkUx4l9VIg8HzDdG+Pw779Isp+6V1yKxZ7IOBFOv1g iq1Xl+pB7mSp8VNEBEvD8JFDDbwKueTWxDyP8sXpzy0XDcj/eFSBhN0TNBBF98FmoSdsSO mvuE6+R6ih06x+vJmL/f+NXOmYGAgNY= Received: by mail-yb1-f182.google.com with SMTP id c7so5665717ybn.3 for ; Fri, 14 Apr 2023 15:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681510474; x=1684102474; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gk9HExao/5Lprbj05MOjxLiOOiVyd+QICb9ACljDPzk=; b=ZyvI9IybYfMNYJJE07KMHPpyLAH9ShtcjdZaTAwhJfvFMs6GAdxS0P6nnYwotzyL6b gUJt4LtoR3ww3RtJ2kmeUHuAq9P9aeulSOpauhHqaXeWZGbAcRp5xSTZBkcYFrB8Hs+G Smd0mGESjmOpjq0cLp9RBl5+bqU/GgesqxzeeV4kkJncq5m3cZiJuOiyg3kXNjNtjR1M k/q8rY9qD2iskEY0Ob5heYTrx+0nPA8yC9zVriritQgSmhoXVL1dOEGbYtYqSDN8vFUJ yAsU+el9ghlzhd/t2sfrqz5D4tT9qkZeiegpRtMvf8jXkNV+oRVqzLqmGMvvvs4x4vLg Bd6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681510474; x=1684102474; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gk9HExao/5Lprbj05MOjxLiOOiVyd+QICb9ACljDPzk=; b=EmuH/wKUtXn1kZ4Cg9e2C83vKTKwvAM+j/55YbpPKO4tb8WZjSZrf/BO5TBPU1LHrV JQGb+B6CtssGDTHI4DHUS0pwtIGzOvQskg7W3G4NxYAZKKEnabcJJTPdtFbMOnAuENLr 7ZAM1d57zoTUsOf6OuQQHLgqRID4/1qTuiMtpTMEevIx9JXFdt97rzNzXU3lXfsGhn8p EKr6FynNoF/pwEdord9rTPRQ3ka38rH01+amYMKNyOo/zNfAnobf5P4S+VfuRK+i1Q/0 yyuDOZQladLWOeQfweESNFEoZy2okdK8UZ1B3JaWVlkGmEYkTl4O94uXbPFvRPadTtHz IChA== X-Gm-Message-State: AAQBX9e8m1rf/SfiJ+QRwLhdptMoLMxJFXGTcQgZp0t2Wf0zm2IzGcVC VBxnSATJkH025RndVSayW4Voor8wMLqn7FMMd6fIEA== X-Google-Smtp-Source: AKy350bdcNTMkS8kPRv3/QqPPMSqZGRAUWwPk2r8fetAqkMEbCKrX6QZjbKVZkhlg6M1f6KCtmRJDTCfgSuBmnojKdk= X-Received: by 2002:a25:7411:0:b0:b8f:6d23:3c7a with SMTP id p17-20020a257411000000b00b8f6d233c7amr2609939ybc.12.1681510474260; Fri, 14 Apr 2023 15:14:34 -0700 (PDT) MIME-Version: 1.0 References: <20230414175444.1837474-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 14 Apr 2023 15:14:23 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: do not increment pgfault stats when page fault handler retries To: Peter Xu Cc: akpm@linux-foundation.org, willy@infradead.org, hannes@cmpxchg.org, mhocko@suse.com, josef@toxicpanda.com, jack@suse.cz, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, michel@lespinasse.org, liam.howlett@oracle.com, jglisse@google.com, vbabka@suse.cz, minchan@google.com, dave@stgolabs.net, punit.agrawal@bytedance.com, lstoakes@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6788040008 X-Stat-Signature: mig39gx3rpxjjt4szkbpk7a1m8e51as9 X-Rspam-User: X-HE-Tag: 1681510475-401513 X-HE-Meta: U2FsdGVkX18abtmxde9oIN4sYQmfAbZKujGPHBRsu70rnA25prx21SbZ1a29ZifvE702rYgBh4vEAbRbx4RjyxOO0xc+UMKhZnssuuemznyi5mzc2B7HTdBNiUp6HdnsgiMGRokKaguHTBVr5orAiE5nH7td+qnY2xqcODZuI07eqmhot7+FevuUsOVKuDwknd/UtiBQIvJ+/zsJGiAQz7eFIaiXhCRsx0ddk2LJY9G+L0WCgB+mxzVsymctxGHKn5aivN8rw8nYGge8OpJJPoop1TBg35mqQO+OPcW93u23mIyXYykjMHuEYhfAuueO6ZXp6ssp7t4/havzkLAAv87BIcbMVIUFm1K2T+HWBimwaxCGF51IU9mw78rCGQJ+eAOrFOBOj8d6SX5hC1aqdvjJJ4zPy3I2eOx3RTxoCPUD5B5u5endJGNVnhfI+KOgHvkg0E3E3i4nKvBXn5QYMn/W1w7qpOWqpwI/DQOxhmQda4BHY8prdUtb+AWaadXy7p8ApX8hrTcPDz33PWqewXT9MDMrO3bqLQOjcI5j3JLpJvgCXQNV1koqz/q7phDEp+18IxLIXneR4lE9RcNEQ594gsQ7WDlX/qSyTBfUz2o+6cyo6N2r+1wLaKcB0/XbJLO+hAJ3uSQjjcX7a6FKVPoE3cX6AKTg9PjntYvHv5SwV/yTknM+HiqEYmyY/Edjew1HQPbCGILHOm7tGNj0etLIjdQnIBtKeALyeXP18gey3gG7jxty91nolTw1ujyUbm/bBdRB2xAIvVURqwuw8C0+wRz+jrwGxs2ZEI1KKFfnT5MhisxYv+CapH9LwnrPD/5G0GJDwYJsAyhJ11qxxvaK5ue5Krw/dOfSQLT4OU6AC2HNgLwRv2TP2kDp9TOj2wi1RtdbLT4001pRbt639u7ddzAHsTgbz6NmfmUhLZeJxMhT7pdb1Uraztv1GWWeByhubevKpYVfD9BegV+ 0QkdOU19 NDjguPGUtCUeoWGQgaNZCo6rufVxhiZHrb3EeruDgdxs8ARTDBEOuwjTi79K+EHgBq7JjsjAYdAgkm+LKtF1WBO6ON34MH0gpI5x/7wEsu31k9qFhVlxmjDwM9+m6JOguxp8Ctdne3pimAA7MasyabJQz9Pa1kJWvSgbXlgDlODXVMf2N3WJUfTDKd5bzg1tWHotJX2Oeuu08KSJvdGYN/BVuYVkEy9GXeSrK27InMTs1maR83hDJ9mKYg9zCfYzS5My9M6WIyVyeQ6nfrqulfVdGRmmEDA+KN7gf7EvBaelRqRKNovuoKD7a2d2mJ64TtZdsI2vK+7/fv3QGxmivMkV/kNL0XbkdFkCAlkRTdTN66/7bCJmw0idd4UC3wXYDhAhzSM/44F7KUWSAUgd+B0ZOCA== 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: On Fri, Apr 14, 2023 at 2:47=E2=80=AFPM Peter Xu wrote: > > Hi, Suren, Hi Peter, > > On Fri, Apr 14, 2023 at 10:54:44AM -0700, Suren Baghdasaryan wrote: > > If the page fault handler requests a retry, we will count the fault > > multiple times. This is a relatively harmless problem as the retry pat= hs > > are not often requested, and the only user-visible problem is that the > > fault counter will be slightly higher than it should be. Nevertheless, > > userspace only took one fault, and should not see the fact that the > > kernel had to retry the fault multiple times. > > > > Fixes: 6b4c9f446981 ("filemap: drop the mmap_sem for all blocking opera= tions") > > Signed-off-by: Suren Baghdasaryan > > Reviewed-by: Matthew Wilcox (Oracle) > > --- > > Patch applies cleanly over linux-next and mm-unstable > > > > mm/memory.c | 16 ++++++++++------ > > 1 file changed, 10 insertions(+), 6 deletions(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index 1c5b231fe6e3..d88f370eacd1 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -5212,17 +5212,16 @@ vm_fault_t handle_mm_fault(struct vm_area_struc= t *vma, unsigned long address, > > > > __set_current_state(TASK_RUNNING); > > > > - count_vm_event(PGFAULT); > > - count_memcg_event_mm(vma->vm_mm, PGFAULT); > > - > > ret =3D sanitize_fault_flags(vma, &flags); > > if (ret) > > - return ret; > > + goto out; > > > > if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE, > > flags & FAULT_FLAG_INSTRUCTIO= N, > > - flags & FAULT_FLAG_REMOTE)) > > - return VM_FAULT_SIGSEGV; > > + flags & FAULT_FLAG_REMOTE)) { > > + ret =3D VM_FAULT_SIGSEGV; > > + goto out; > > + } > > > > /* > > * Enable the memcg OOM handling for faults triggered in user > > @@ -5253,6 +5252,11 @@ vm_fault_t handle_mm_fault(struct vm_area_struct= *vma, unsigned long address, > > } > > > > mm_account_fault(regs, address, flags, ret); > > Here is the mm_account_fault() function taking care of some other > accountings. Perhaps good to put things into it? That seems appropriate. Let me take a closer look. > > It also already ignores invalid faults: > > if (ret & (VM_FAULT_ERROR | VM_FAULT_RETRY)) > return; Can there be a case of (!VM_FAULT_ERROR && VM_FAULT_RETRY) - basically we need to retry but no errors happened? If so then this condition would double-count pagefaults in such cases. If such return code is impossible then it's the same as checking for VM_FAULT_RETRY. > > I see that you may also want to account for sigbus, however I really don'= t > know why. Explanations would be great when it would matter. So far it > makes sense to me if we skip both RETRY or ERROR cases. Accounting in case of a sigbus is not affected by this patch I think. We account for sigbus or any other error cases because there was a pagefault and we need to account for it. Whether we failed to handle it or not should not affect the count. We skip the retry case because we know the same fault will be retried. If we don't skip then we will double-count this fault. > > > +out: > > + if (!(ret & VM_FAULT_RETRY)) { > > + count_vm_event(PGFAULT); > > + count_memcg_event_mm(vma->vm_mm, PGFAULT); > > There is one thing worth noticing is here vma may or may not be valid > depending on the retval of the fault. > > RETRY is exactly one of the cases that accessing vma may be unsafe due to > releasing of mmap read lock. The other one is the recently added > VM_FAULT_COMPLETE. So if we want to move this chunk (or any vma referenc= e) > to be later we need to consider a valid vma / mm being there first, or > we're prone to accessing a vma that has already been released, I think. Good catch! I think you are right and I should have stored vma->vm_mm in the beginning and used it when calling count_memcg_event_mm(). I'll prepare a new patch which handles this correctly. Thanks, Suren. > > > + } > > > > return ret; > > } > > -- > > 2.40.0.634.g4ca3ef3211-goog > > > > > > Thanks, > > -- > Peter Xu > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >