linux-kernel - Re: [RFC PATCH 2/3] mm: provide rmap_wrprotect_file

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z3607T2A-pukkuQj@casper.infradead.org>
Date: Wed, 8 Jan 2025 17:25:01 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Jaya Kumar <jayalk@...works.biz>, Simona Vetter <simona@...ll.ch>,
	Helge Deller <deller@....de>, linux-fbdev@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, David Hildenbrand <david@...hat.com>
Subject: Re: [RFC PATCH 2/3] mm: provide rmap_wrprotect_file_page() function

On Wed, Jan 08, 2025 at 04:18:41PM +0000, Lorenzo Stoakes wrote:
> +++ b/include/linux/rmap.h
> @@ -754,6 +754,26 @@ unsigned long page_address_in_vma(const struct folio *folio,
>   */
>  int folio_mkclean(struct folio *);
>  
> +/**

The kerneldoc comment should be with the implementation, not the
prototype.

> + * rmap_wrprotect_file_page() - Traverses the reverse mapping, finding all VMAs
> + * which contain a shared mapping of the single page at PFN @pfn in @mapping at
> + * offset @pgoff and write-protecting the mappings.

After the '-' should come a _short_ description ... maybe "Write protect
all mappings of this page".

> + * The PFN mapped does not have to be a folio, but rather can be a kernel
> + * allocation that is mapped into userland. We therefore do not require that the
> + * PFN maps to a folio with a valid mapping or index field, rather these are
> + * specified in @mapping and @pgoff.
> + *
> + * @mapping:	The mapping whose reverse mapping should be traversed.
> + * @pgoff:	The page offset at which @pfn is mapped within @mapping.
> + * @nr_pages:	The number of physically contiguous base pages spanned.
> + * @pfn:	The PFN of the memory mapped in @mapping at @pgoff.

The description of the params comes between the short and full
description of the function.

> + * Return the number of write-protected PTEs, or an error.

colon after Return: so it becomes a section.

> +int rmap_wrprotect_file_page(struct address_space *mapping, pgoff_t pgoff,
> +		unsigned long nr_pages, unsigned long pfn)
> +{
> +	struct wrprotect_file_state state = {
> +		.cleaned = 0,
> +		.pgoff = pgoff,
> +		.pfn = pfn,
> +		.nr_pages = nr_pages,
> +	};
> +	struct rmap_walk_control rwc = {
> +		.arg = (void *)&state,
> +		.rmap_one = rmap_wrprotect_file_one,
> +		.invalid_vma = invalid_mkclean_vma,
> +	};
> +
> +	if (!mapping)
> +		return 0;

Should it be valid to pass in NULL?