Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 17 Apr 2023 17:26:04 -0400
From:   Peter Xu <peterx@redhat.com>
To:     Suren Baghdasaryan <surenb@google.com>
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 v2 1/1] mm: do not increment pgfault stats when page
 fault handler retries
Message-ID: <ZD25bBPbZYSb7grA@x1n>
References: <20230415000818.1955007-1-surenb@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230415000818.1955007-1-surenb@google.com>
Precedence: bulk

On Fri, Apr 14, 2023 at 05:08:18PM -0700, Suren Baghdasaryan wrote:
> @@ -5223,8 +5230,8 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
>  		if (task_in_memcg_oom(current) && !(ret & VM_FAULT_OOM))
>  			mem_cgroup_oom_synchronize(false);
>  	}
> -
> -	mm_account_fault(regs, address, flags, ret);
> +out:
> +	mm_account_fault(mm, regs, address, flags, ret);

Ah, one more question.. can this cached mm race with a destroying mm (just
like the vma race we wanted to avoid)?  Still a question only applies to
COMPLETE case when mmap read lock can be released.  Thanks,

>  
>  	return ret;
>  }

-- 
Peter Xu