linux-kernel - Re: [PATCH 01/26] mm: Do page fault accounting in handle_mm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200624203412.GB64004@xz-x1>
Date:   Wed, 24 Jun 2020 16:34:12 -0400
From:   Peter Xu <peterx@...hat.com>
To:     Gerald Schaefer <gerald.schaefer@...ibm.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Will Deacon <will@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 01/26] mm: Do page fault accounting in handle_mm_fault

On Wed, Jun 24, 2020 at 08:49:03PM +0200, Gerald Schaefer wrote:
> On Fri, 19 Jun 2020 12:05:13 -0400
> Peter Xu <peterx@...hat.com> wrote:
> 
> [...]
> 
> > @@ -4393,6 +4425,38 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> >  			mem_cgroup_oom_synchronize(false);
> >  	}
> > 
> > +	if (ret & VM_FAULT_RETRY)
> > +		return ret;
> 
> I'm wondering if this also needs a check and exit for VM_FAULT_ERROR.
> In arch code (s390 and all others I briefly checked), the accounting
> was skipped for VM_FAULT_ERROR case.

Yes. I didn't explicitly add the check because I thought it's still OK to count
the error cases, especially after we've discussed about
PERF_COUNT_SW_PAGE_FAULTS in v1.  So far, the major reason (iiuc) to have
PERF_COUNT_SW_PAGE_FAULTS still in per-arch handlers is to also cover these
corner cases like VM_FAULT_ERROR.  So to me it makes sense too to also count
them in here.  But I agree it changes the old counting on most archs.

Again, I don't have strong opinion either on this, just like the same to
PERF_COUNT_SW_PAGE_FAULTS...  But if no one disagree, I will change this to:

  if (ret & (VM_FAULT_RETRY | VM_FAULT_ERROR))
      return ret;

So we try our best to follow the past.

Btw, note that there will still be some even more special corner cases. E.g.,
for ARM64 it's also not accounted for some ARM64 specific fault errors
(VM_FAULT_BADMAP, VM_FAULT_BADACCESS).  So even if we don't count
VM_FAULT_ERROR, we might still count these for ARM64.  We can try to redefine
VM_FAULT_ERROR in ARM64 to cover all the arch-specific errors, however that
seems an overkill to me sololy for fault accountings, so hopefully I can ignore
that difference.

> 
> > +
> > +	/*
> > +	 * Do accounting in the common code, to avoid unnecessary
> > +	 * architecture differences or duplicated code.
> > +	 *
> > +	 * We arbitrarily make the rules be:
> > +	 *
> > +	 *  - faults that never even got here (because the address
> > +	 *    wasn't valid). That includes arch_vma_access_permitted()
> 
> Missing "do not count" at the end of the first sentence?
> 
> > +	 *    failing above.
> > +	 *
> > +	 *    So this is expressly not a "this many hardware page
> > +	 *    faults" counter. Use the hw profiling for that.
> > +	 *
> > +	 *  - incomplete faults (ie RETRY) do not count (see above).
> > +	 *    They will only count once completed.
> > +	 *
> > +	 *  - the fault counts as a "major" fault when the final
> > +	 *    successful fault is VM_FAULT_MAJOR, or if it was a
> > +	 *    retry (which implies that we couldn't handle it
> > +	 *    immediately previously).
> > +	 *
> > +	 *  - if the fault is done for GUP, regs wil be NULL and
> 
> wil -> will

Will fix both places.  Thanks,

-- 
Peter Xu