From: SeongJae Park <sj@kernel.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
SeongJae Park <sj@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Uladzislau Rezki <urezki@gmail.com>, Zi Yan <ziy@nvidia.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
damon@lists.linux.dev, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v2 5/5] mm: ptep_deref() conversion
Date: Thu, 18 May 2023 17:22:11 +0000 [thread overview]
Message-ID: <20230518172211.84101-1-sj@kernel.org> (raw)
In-Reply-To: <20230518110727.2106156-6-ryan.roberts@arm.com>
On Thu, 18 May 2023 12:07:27 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:
> Convert all instances of direct pte_t* dereferencing to instead use
> ptep_deref() helper. By default, the helper does a direct dereference as
> before, but it can (and will) be overridden by the architecture to fully
> encapsulate the contents of the pte. Arch code is deliberately not
> converted, as the arch code knows best.
>
> Conversion was done using Coccinelle:
>
> ----
>
> // $ make coccicheck \
> // COCCI=ptepderef.cocci \
> // SPFLAGS="--include-headers" \
> // MODE=patch
>
> virtual patch
>
> @ depends on patch @
> pte_t *v;
> @@
>
> - *v
> + ptep_deref(v)
>
> ----
>
> Then reviewed and hand-edited to avoid multiple unnecessary calls to
> ptep_deref(), instead opting to store the result of a single in a
> variable, where it is correct to do so. This will benefit arch-overrides
> that may be more complex than a simple (optimizable) pointer
> dereference.
>
> Included is a fix for an issue in an earlier version of this patch that
> was pointed out by kernel test robot. The issue arose because config
> MMU=n elides definition of the ptep helper functions, including
> ptep_deref(). HUGETLB_PAGE=n configs still define a simple
> huge_ptep_clear_flush() for linking purposes, which dereferences the
> ptep. So when both configs are disabled, this caused a build error
> because ptep_deref() is not defined. Fix by continuing to do a direct
> dereference when MMU=n. This is safe because for this config the arch
> code cannot be trying to virtualize the ptes because none of the ptep
> helpers are defined.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
[...]
> mm/damon/ops-common.c | 2 +-
> mm/damon/paddr.c | 2 +-
> mm/damon/vaddr.c | 10 +-
For above mm/damon/ part,
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
prev parent reply other threads:[~2023-05-18 17:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 11:07 [PATCH v2 0/5] Encapsulate PTE contents from non-arch code Ryan Roberts
2023-05-18 11:07 ` [PATCH v2 1/5] mm: vmalloc must set pte via arch code Ryan Roberts
2023-05-19 12:09 ` Uladzislau Rezki
2023-05-24 18:47 ` Mike Rapoport
2023-05-18 11:07 ` [PATCH v2 2/5] mm: damon must atomically clear young on ptes and pmds Ryan Roberts
2023-05-18 17:13 ` SeongJae Park
2023-05-19 8:53 ` Ryan Roberts
2023-05-18 23:19 ` Yu Zhao
2023-05-19 9:02 ` Ryan Roberts
2023-05-19 19:54 ` SeongJae Park
2023-05-22 8:53 ` Ryan Roberts
2023-05-24 18:49 ` Mike Rapoport
2023-05-18 11:07 ` [PATCH v2 3/5] mm: Fix failure to unmap pte on highmem systems Ryan Roberts
2023-05-24 18:59 ` Mike Rapoport
2023-05-18 11:07 ` [PATCH v2 4/5] mm: Add new ptep_deref() helper to fully encapsulate pte_t Ryan Roberts
2023-05-18 19:28 ` Yu Zhao
2023-05-19 9:12 ` Ryan Roberts
2023-05-25 9:08 ` Ryan Roberts
2023-05-26 2:02 ` Yu Zhao
2023-05-24 19:06 ` Mike Rapoport
2023-05-24 19:11 ` Ryan Roberts
2023-05-18 11:07 ` [PATCH v2 5/5] mm: ptep_deref() conversion Ryan Roberts
2023-05-18 12:08 ` Jason Gunthorpe
2023-05-18 17:22 ` SeongJae Park [this message]
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=20230518172211.84101-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=hch@infradead.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=lstoakes@gmail.com \
--cc=ryan.roberts@arm.com \
--cc=urezki@gmail.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.