From: Matthew Wilcox <willy@infradead.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jaya Kumar <jayalk@intworks.biz>, Simona Vetter <simona@ffwll.ch>,
Helge Deller <deller@gmx.de>,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
David Hildenbrand <david@redhat.com>
Subject: Re: [RFC PATCH 1/3] mm: refactor rmap_walk_file() to separate out traversal logic
Date: Wed, 8 Jan 2025 16:38:57 +0000 [thread overview]
Message-ID: <Z36qIbm82vMLW7w_@casper.infradead.org> (raw)
In-Reply-To: <0c53589f34a6195938eeb58c3a88594fa30cc90a.1736352361.git.lorenzo.stoakes@oracle.com>
On Wed, Jan 08, 2025 at 04:18:40PM +0000, Lorenzo Stoakes wrote:
> +/*
> + * rmap_walk_file - do something to file page using the object-based rmap method
> + * @folio: the folio to be handled
> + * @rwc: control variable according to each walk type
> + * @locked: caller holds relevant rmap lock
> + *
> + * Find all the mappings of a folio using the mapping pointer and the vma chains
> + * contained in the address_space struct it points to.
> + */
> +static void rmap_walk_file(struct folio *folio,
> + struct rmap_walk_control *rwc, bool locked)
> +{
> + struct address_space *mapping = folio_mapping(folio);
I'm unconvinced this shouldn't be just folio->mapping. On the face of
it, we're saying that we're walking a file, and file folios just want
to use folio->mapping. But let's dig a little deeper.
The folio passed in is locked, so it can't be changed during this call.
In folio_mapping(), folio_test_slab() is guaranteed untrue.
folio_test_swapcache() doesn't seem likely to be true either; unless
it's shmem, it can't be in the swapcache, and if it's shmem and in the
swap cache, it can't be mapped to userspace (they're swizzled back from
the swapcache to the pagecache before being mapped). And then the
check for PAGE_MAPPING_FLAGS is guaranteed to be untrue (we know it's
not anon/ksm/movable). So I think this should just be folio->mapping.
> + /*
> + * The page lock not only makes sure that page->mapping cannot
> + * suddenly be NULLified by truncation, it makes sure that the
> + * structure at mapping cannot be freed and reused yet,
> + * so we can safely take mapping->i_mmap_rwsem.
> + */
I know you only moved this comment, but please fix it to refer to
folios, not pages.
> + VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
> +
> + if (!mapping)
> + return;
Maybe make this a WARN_ON_ONCE?
> + __rmap_walk_file(folio, mapping, folio_pgoff(folio),
> + folio_nr_pages(folio), rwc, locked);
folio_pgoff() can go too. Just use folio->index.
next prev parent reply other threads:[~2025-01-08 16:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 16:18 [RFC PATCH 0/3] expose mapping wrprotect, fix fb_defio use Lorenzo Stoakes
2025-01-08 16:18 ` [RFC PATCH 1/3] mm: refactor rmap_walk_file() to separate out traversal logic Lorenzo Stoakes
2025-01-08 16:38 ` Matthew Wilcox [this message]
2025-01-08 19:23 ` Lorenzo Stoakes
2025-01-08 16:18 ` [RFC PATCH 2/3] mm: provide rmap_wrprotect_file_page() function Lorenzo Stoakes
2025-01-08 17:25 ` Matthew Wilcox
2025-01-08 19:35 ` Lorenzo Stoakes
2025-01-08 16:18 ` [RFC PATCH 3/3] fb_defio: do not use deprecated page->mapping, index fields Lorenzo Stoakes
2025-01-08 17:32 ` Matthew Wilcox
2025-01-08 19:41 ` Lorenzo Stoakes
2025-01-13 23:01 ` Lorenzo Stoakes
2025-01-08 20:14 ` David Hildenbrand
2025-01-08 20:54 ` Matthew Wilcox
2025-01-08 21:12 ` David Hildenbrand
2025-01-08 21:55 ` Matthew Wilcox
2025-01-08 22:02 ` David Hildenbrand
2025-01-13 17:18 ` Lorenzo Stoakes
2025-01-13 17:48 ` Lorenzo Stoakes
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=Z36qIbm82vMLW7w_@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=jayalk@intworks.biz \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=simona@ffwll.ch \
/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