linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Hellwig <hch@lst.de>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	boris.ostrovsky@oracle.com, jgross@suse.com,
	sstabellini@kernel.org, x86@kernel.org,
	jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	rodrigo.vivi@intel.com, chris@chris-wilson.co.uk,
	intel-gfx@lists.freedesktop.org, linux-mm@kvack.org,
	keescook@chromium.org
Subject: Re: [PATCH 4/7] mm: Introduce verify_page_range()
Date: Mon, 12 Apr 2021 11:17:36 +0200	[thread overview]
Message-ID: <YHQQMPvsO5LtuI+/@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210412082805.GD4372@lst.de>

On Mon, Apr 12, 2021 at 10:28:05AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > +extern int verify_page_range(struct mm_struct *mm,
> 
> No need for the extern here.

It's consistent with the rest of the functions there. Also, I personally
like that extern.

> > +int verify_page_range(struct mm_struct *mm,
> > +		      unsigned long addr, unsigned long size,
> > +		      int (*fn)(pte_t pte, unsigned long addr, void *data),
> > +		      void *data)
> 
> A kerneldoc comment would be nice for this function.
> 
> Otherwise this looks fine.

Something like so?

/**
 * verify_page_range() - Scan (and fill) a range of virtual memory and validate PTEs
 * @mm: mm identifying the virtual memory map
 * @addr: starting virtual address of the range
 * @size: size of the range
 * @fn: function that verifies the PTEs
 * @data: opaque data passed to @fn
 *
 * Scan a region of virtual memory, filling in page tables as necessary and
 * calling a provided function on each leaf, providing a copy of the
 * page-table-entry.
 *
 * Similar apply_to_page_range(), but does not provide direct access to the
 * page-tables.
 *
 * NOTE! this function does not work correctly vs large pages.
 *
 * Return: the first !0 return of the provided function, or 0 on completion.
 */
int verify_page_range(struct mm_struct *mm,
		      unsigned long addr, unsigned long size,
		      int (*fn)(pte_t pte, unsigned long addr, void *data),
		      void *data)


  reply	other threads:[~2021-04-12  9:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12  8:00 [PATCH 0/7] mm: Unexport apply_to_page_range() Peter Zijlstra
2021-04-12  8:00 ` [PATCH 1/7] mm: Unexport apply_to_existing_page_range() Peter Zijlstra
2021-04-12  8:13   ` Christoph Hellwig
2021-04-12  8:00 ` [PATCH 2/7] xen/gntdev,x86: Remove apply_to_page_range() use from module Peter Zijlstra
2021-04-12  8:26   ` Christoph Hellwig
2021-04-12  9:20     ` Peter Zijlstra
2021-04-12  9:26     ` Juergen Gross
2021-04-12  8:00 ` [PATCH 3/7] xen/gntdev: " Peter Zijlstra
2021-04-12  8:27   ` Christoph Hellwig
2021-04-12  9:02     ` Peter Zijlstra
2021-04-12  8:00 ` [PATCH 4/7] mm: Introduce verify_page_range() Peter Zijlstra
2021-04-12  8:28   ` Christoph Hellwig
2021-04-12  9:17     ` Peter Zijlstra [this message]
2021-04-12 20:05   ` Kees Cook
2021-04-13  6:54     ` Peter Zijlstra
2021-04-19 23:36       ` Kees Cook
2021-04-13  7:36     ` Peter Zijlstra
2021-04-14  3:01       ` Kees Cook
2021-04-14  7:00         ` Peter Zijlstra
2021-04-12  8:00 ` [PATCH 5/7] xen/privcmd: Use verify_page_range() Peter Zijlstra
2021-04-12  8:28   ` Christoph Hellwig
2021-04-12  8:00 ` [PATCH 6/7] i915: Convert to verify_page_range() Peter Zijlstra
2021-04-12  8:28   ` Christoph Hellwig
2021-04-12 20:08   ` Kees Cook
2021-04-13  6:54     ` Peter Zijlstra
2021-04-14  3:04   ` Kees Cook
2021-04-12  8:00 ` [PATCH 7/7] mm: Unexport apply_to_page_range() Peter Zijlstra
2021-04-12  8:28   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YHQQMPvsO5LtuI+/@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=hch@lst.de \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jgross@suse.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox