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 5AFACC77B72 for ; Fri, 14 Apr 2023 21:47:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9EF32900002; Fri, 14 Apr 2023 17:47:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 978D96B0075; Fri, 14 Apr 2023 17:47:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F177900002; Fri, 14 Apr 2023 17:47:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6CD386B0072 for ; Fri, 14 Apr 2023 17:47:09 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 39E9214044D for ; Fri, 14 Apr 2023 21:47:09 +0000 (UTC) X-FDA: 80681332578.18.7DD694D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id BA7C7160006 for ; Fri, 14 Apr 2023 21:47:06 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VU+S350s; spf=pass (imf08.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681508827; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/JZtBnf+Q/vz66UT0GWX180v95wsOpJkHZixtsU6vGs=; b=7Ou+n6+AtroPJvDzsOKbjoZTdHyjYt8RI23Gmw5nHAZViih7VjJNuGS41d+z0CuLd4boxh rwFscwa2Grf0sPIR+QbfmasLNC3FkeVPe8RNS93gOLuk2isFsT27nNyYo0q3+ak4Q14NfV cve4czLUWuRGD8tLmvJofZ52vTC0COQ= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VU+S350s; spf=pass (imf08.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681508827; a=rsa-sha256; cv=none; b=esH1p/ZYCkVIE+/rbDTBHM2fXxCstFk9Y/7k52KxFXHFe/pMGYm0XFEUAJ3+9jRV2PUF4x JSim3ugWbIsLEDwwb60Sub5XMI23TAjRF+ldWdszoZc0RwRpBEW3y7IR3QwWBPgKJ0LOz/ kvfwjpI4/nAtlLXB5vKWYqtSfmXKKEU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681508826; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/JZtBnf+Q/vz66UT0GWX180v95wsOpJkHZixtsU6vGs=; b=VU+S350s/GdXbxzVnABsa/60TJ93M3NIwyT56+IHQNsx61dCTr+NKDAGxSNKGGZDzPVlIf 8Qog8R0hS42bJs63dDKmfkAgRpFC4vOzWdXncZAfcHOFt7XVNbL1C/2wlZjpU4VL5kDo3j Isugl79WoeJoKhFoejB/nJxmI6+VXug= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-70-TmtzTldDOwO9xYa2T5SX9g-1; Fri, 14 Apr 2023 17:47:04 -0400 X-MC-Unique: TmtzTldDOwO9xYa2T5SX9g-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-74a7c661208so114319185a.1 for ; Fri, 14 Apr 2023 14:47:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681508824; x=1684100824; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/JZtBnf+Q/vz66UT0GWX180v95wsOpJkHZixtsU6vGs=; b=ax0EbUp6/tFU0ZjRj/zgpapZ94U+vxuNzOanPGcGfl0mHg30PNf6O0/eSzUfo+xg5t zaWJIlR4WZ8qHb++J0TY+3/GFzXTKehZSnbEjirGPADlaM8+V2Xhx6QvTUqK/7VCe1ud 2dGAFFJXgL1nADqxdSxz1/B2UpFm9wSDKo3ByOgt2tPZAzGiSd3ARzLE3NWTzz6vQQ7Q pw604Y5x12lxEFW7eYJ0lzujnF8aB6D3ChFumHKHnimN+uzVTahKVVI0w8Zv7RE7vCEH MF7x5fxSblK7D3qVCd+HtPD+sQwkl18t1PHe9YHxjXsBT8jN2f8Fc3wtrBTW+jc9HyId mgwg== X-Gm-Message-State: AAQBX9fJlgMMUU7Ve6EwU7WX+GUCa4OOMGk55ZyDf9RLfWzsw/MlvbPM iFqLTDzDPF8T9V24W+XSYt/on1NYkutrnbzRctkfOs1JTZo0XyVNe6ZEBA6yPfyJigiYriPkQXh 6CZzgn6A0MjM= X-Received: by 2002:a05:6214:518c:b0:5e9:2bad:c920 with SMTP id kl12-20020a056214518c00b005e92badc920mr5846924qvb.5.1681508824351; Fri, 14 Apr 2023 14:47:04 -0700 (PDT) X-Google-Smtp-Source: AKy350Zg9zm4iUKiGldo8x6g+huann62DVqlW+cmQWxx4tINf3p7pg3r1wJO2bKnEZRBgERyzW+SLA== X-Received: by 2002:a05:6214:518c:b0:5e9:2bad:c920 with SMTP id kl12-20020a056214518c00b005e92badc920mr5846898qvb.5.1681508824097; Fri, 14 Apr 2023 14:47:04 -0700 (PDT) Received: from x1n (bras-base-aurron9127w-grc-40-70-52-229-124.dsl.bell.ca. [70.52.229.124]) by smtp.gmail.com with ESMTPSA id mf10-20020a0562145d8a00b005dd8b9345d2sm1358694qvb.106.2023.04.14.14.47.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Apr 2023 14:47:03 -0700 (PDT) Date: Fri, 14 Apr 2023 17:47:01 -0400 From: Peter Xu To: Suren Baghdasaryan 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 Subject: Re: [PATCH 1/1] mm: do not increment pgfault stats when page fault handler retries Message-ID: References: <20230414175444.1837474-1-surenb@google.com> MIME-Version: 1.0 In-Reply-To: <20230414175444.1837474-1-surenb@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BA7C7160006 X-Rspam-User: X-Stat-Signature: ampcpqxqj8bk7unecaepci4afnt3pteh X-HE-Tag: 1681508826-59842 X-HE-Meta: U2FsdGVkX19IHS9mu18ln66BElYNN+IEbEhKkgdMeOZtcG7HzdJOO+vkARFkcZmlliPV8py/8BwWkEx2xsqXLMwI3lJedbTjkepC4iEBaIb3P6LzAO8MOam4vgrOLiPAzVgGKYo41Z4LUiQaeO5galCoVRSRfDuIoyiMMy9BSDXTZa2RvRDOKyH149W3W+yGBhN9a0GggeTS1WswEJqEIh8vo9FKFkabY3hS9kT66VR3s3MzYs8wAyNoiy2xJPUARa4R67zttgqhmnCwpv0ML7+e4VY2uPX/CrxTk3rcI52F0/GbNQYWp/bfc7Rv7Z55ap6mKxKsdbL83R+aE53HSXdd0lKwJfQ098o7IxdCV+rCfgUOH+3p858eAl2VsPH2VJz422fOoqz3/mImY6v7ivJy4SbuHVcSzgIK+sHirsVTmfynd26TW0vuIH5KW16qoLyRYvgVgxncHd6hlOTDZUcSPGgddFh714YHGQ7Gk+2kPskNOmijJPYE+A6MELmvYz9yzxTVaNTD+MB2pFM2bqaFp4gu05Gk0/s73QD34D13xx6pAc3jW9ehc4gXW/XPZYZGNLH41hkBh1vUlVGZp0PTdtwqkmqb/wEB822Y75InRIEZRixgiOgVyvEBzaQkjCsz6SVgqtnrP7JhIYz3EXJp+43bq+6M6AVMPPcra7RyssPPm/UNYsx7q3dDim6viG2ohQ+YDA9OCo6JnMAukdV9SijanZPbeD8HHmZGovq0B/YNwJHRvP3WAC4chZXcb3itqaKcS3eRAp1kqhO0edB+e145QnQ+9pL1w0HObfoy81Mfaogcgvxt8a4mCLsOcT/DPvGu/p749NMWSoWEKUY4GN9hnI29K2duXhtVKykgUtrcSsgCGLKj8mQnTnWxPQ0M7b7sU2chVxWPMGVgp1f1zVT0bdKEWC+fk43ykwpZ7OpOMII1sZNkTXDOuiVh9QEsCXVC1dL2cHiA7f2 6H+h/y1F fBiL9sNSfZl+xfKHyyW6i5ilQWpgYiKNp1XxOL7jtufGKCohoZW1WlKBBvHvE+S22/6R9OANqHBZtFFt4MFBP1OYz1xGGODN0Rj6FdVJVtDi9iygUgR5hxKnShnbNp6xZsc8Mra+fTqEnTt5Zb5CAJPIWeFglRRXwz+VM02q5hghI3HzdiHlvnz9wAxc4J0SzqyZZTq1TY4elvY1NsHGVpid+VDO2BigwyZdZACTfjoPXrA++0VWWXAQguv4ioqBI8Cfkh6rLJQQPmJNyyEwCQRTN9ogTBFzg61NygLCWO09blHR4JI4COT/R9u3tmr9sxJ9ZXw7I5HaeWU/OdPD4VY4MKMeJXz9VmIHa8zxdMRvyoKoMFrr1q+r828LJi2KALQRDA3tTbsq9H9C1AALh4vnquCayrHamH6sABaD9xzRPyzeflf9jR6+mFPE5+eSaf4IAyeoTAxZoyz9K225N6WfB5g== 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: Hi, Suren, 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 paths > 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 operations") > 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_struct *vma, unsigned long address, > > __set_current_state(TASK_RUNNING); > > - count_vm_event(PGFAULT); > - count_memcg_event_mm(vma->vm_mm, PGFAULT); > - > ret = sanitize_fault_flags(vma, &flags); > if (ret) > - return ret; > + goto out; > > if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE, > flags & FAULT_FLAG_INSTRUCTION, > - flags & FAULT_FLAG_REMOTE)) > - return VM_FAULT_SIGSEGV; > + flags & FAULT_FLAG_REMOTE)) { > + ret = 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? It also already ignores invalid faults: if (ret & (VM_FAULT_ERROR | VM_FAULT_RETRY)) return; 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. > +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 reference) 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. > + } > > return ret; > } > -- > 2.40.0.634.g4ca3ef3211-goog > > Thanks, -- Peter Xu