From: Kees Cook <keescook@chromium.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Huang Ying <ying.huang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Zi Yan <ziy@nvidia.com>, Yang Shi <shy828301@gmail.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Oscar Salvador <osalvador@suse.de>,
Matthew Wilcox <willy@infradead.org>,
Bharata B Rao <bharata@amd.com>,
Alistair Popple <apopple@nvidia.com>,
haoxin <xhao@linux.alibaba.com>
Subject: Re: [PATCH 4/8] migrate_pages: split unmap_and_move() to _unmap() and _move()
Date: Thu, 5 Jan 2023 10:57:16 -0800 [thread overview]
Message-ID: <202301051056.9D8CB1C24@keescook> (raw)
In-Reply-To: <Y7cWb2aP1+wAWR8N@dev-arch.thelio-3990X>
On Thu, Jan 05, 2023 at 11:26:55AM -0700, Nathan Chancellor wrote:
> Hi Ying,
>
> On Tue, Dec 27, 2022 at 08:28:55AM +0800, Huang Ying wrote:
> > This is a preparation patch to batch the folio unmapping and moving.
> >
> > In this patch, unmap_and_move() is split to migrate_folio_unmap() and
> > migrate_folio_move(). So, we can batch _unmap() and _move() in
> > different loops later. To pass some information between unmap and
> > move, the original unused dst->mapping and dst->private are used.
> >
> > Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
> > Cc: Zi Yan <ziy@nvidia.com>
> > Cc: Yang Shi <shy828301@gmail.com>
> > Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
> > Cc: Oscar Salvador <osalvador@suse.de>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Bharata B Rao <bharata@amd.com>
> > Cc: Alistair Popple <apopple@nvidia.com>
> > Cc: haoxin <xhao@linux.alibaba.com>
> > ---
> > include/linux/migrate.h | 1 +
> > mm/migrate.c | 162 +++++++++++++++++++++++++++++-----------
> > 2 files changed, 121 insertions(+), 42 deletions(-)
> >
> > diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> > index 3ef77f52a4f0..7376074f2e1e 100644
> > --- a/include/linux/migrate.h
> > +++ b/include/linux/migrate.h
> > @@ -18,6 +18,7 @@ struct migration_target_control;
> > * - zero on page migration success;
> > */
> > #define MIGRATEPAGE_SUCCESS 0
> > +#define MIGRATEPAGE_UNMAP 1
> >
> > /**
> > * struct movable_operations - Driver page migration
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 97ea0737ab2b..e2383b430932 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -1009,11 +1009,29 @@ static int move_to_new_folio(struct folio *dst, struct folio *src,
> > return rc;
> > }
> >
> > -static int __unmap_and_move(struct folio *src, struct folio *dst,
> > +static void __migrate_folio_record(struct folio *dst,
> > + unsigned long page_was_mapped,
> > + struct anon_vma *anon_vma)
> > +{
> > + dst->mapping = (struct address_space *)anon_vma;
> > + dst->private = (void *)page_was_mapped;
> > +}
> > +
> > +static void __migrate_folio_extract(struct folio *dst,
> > + int *page_was_mappedp,
> > + struct anon_vma **anon_vmap)
> > +{
> > + *anon_vmap = (struct anon_vma *)dst->mapping;
> > + *page_was_mappedp = (unsigned long)dst->private;
> > + dst->mapping = NULL;
> > + dst->private = NULL;
> > +}
>
> This patch as commit 42871c600cad ("migrate_pages: split
> unmap_and_move() to _unmap() and _move()") in next-20230105 causes the
> following error with clang when CONFIG_RANDSTRUCT is enabled, which is
> the case with allmodconfig:
>
> ../mm/migrate.c:1041:15: error: casting from randomized structure pointer type 'struct address_space *' to 'struct anon_vma *'
> *anon_vmap = (struct anon_vma *)dst->mapping;
> ^
> 1 error generated.
>
> With GCC, there is only a note:
>
> ../mm/migrate.c: In function '__migrate_folio_extract':
> ../mm/migrate.c:1041:20: note: randstruct: casting between randomized structure pointer types (ssa): 'struct anon_vma' and 'struct address_space'
>
> 1041 | *anon_vmap = (struct anon_vma *)dst->mapping;
> | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Kees has done fixes for warnings and errors like this in the past (I
> just ran
>
> $ git log -p --grep='randomized structure pointer type'
>
> to find them) but I did not see any that would seem appropriate here
> hence just the report :)
If this struct is literally just a scratch space and the original struct
layout doesn't matter, it may be possible to silence this cast by using
"(void *)" instead of the explicit struct type pointer.
--
Kees Cook
next prev parent reply other threads:[~2023-01-05 18:57 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-27 0:28 [PATCH 0/8] migrate_pages(): batch TLB flushing Huang Ying
2022-12-27 0:28 ` [PATCH 1/8] migrate_pages: organize stats with struct migrate_pages_stats Huang Ying
2023-01-03 18:06 ` Zi Yan
2023-01-05 3:02 ` Alistair Popple
2023-01-05 5:53 ` Huang, Ying
2023-01-05 6:50 ` Alistair Popple
2023-01-05 7:06 ` Huang, Ying
2022-12-27 0:28 ` [PATCH 2/8] migrate_pages: separate hugetlb folios migration Huang Ying
2022-12-28 23:17 ` Andrew Morton
2023-01-02 23:53 ` Huang, Ying
2023-01-05 4:13 ` Alistair Popple
2023-01-05 5:51 ` Huang, Ying
2023-01-05 6:43 ` Alistair Popple
2023-01-05 7:31 ` Huang, Ying
2023-01-05 7:39 ` Alistair Popple
2023-01-09 7:23 ` Huang, Ying
2023-01-10 1:37 ` Alistair Popple
2022-12-27 0:28 ` [PATCH 3/8] migrate_pages: restrict number of pages to migrate in batch Huang Ying
2023-01-03 18:40 ` Zi Yan
2023-01-04 0:24 ` Huang, Ying
2022-12-27 0:28 ` [PATCH 4/8] migrate_pages: split unmap_and_move() to _unmap() and _move() Huang Ying
2023-01-03 18:55 ` Zi Yan
2023-01-05 18:26 ` Nathan Chancellor
2023-01-05 18:57 ` Kees Cook [this message]
2023-01-08 23:33 ` Huang, Ying
2022-12-27 0:28 ` [PATCH 5/8] migrate_pages: batch _unmap and _move Huang Ying
2022-12-28 23:22 ` Andrew Morton
2023-01-02 23:29 ` Huang, Ying
2023-01-03 19:01 ` Zi Yan
2023-01-04 0:34 ` Huang, Ying
2022-12-27 0:28 ` [PATCH 6/8] migrate_pages: move migrate_folio_done() and migrate_folio_unmap() Huang Ying
2023-01-03 19:02 ` Zi Yan
2023-01-04 1:26 ` Huang, Ying
2022-12-27 0:28 ` [PATCH 7/8] migrate_pages: share more code between _unmap and _move Huang Ying
2023-01-04 7:12 ` Alistair Popple
2023-01-06 4:15 ` Huang, Ying
2022-12-27 0:28 ` [PATCH 8/8] migrate_pages: batch flushing TLB Huang Ying
2023-01-03 19:19 ` Zi Yan
2023-01-04 1:41 ` Huang, Ying
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=202301051056.9D8CB1C24@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=bharata@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nathan@kernel.org \
--cc=osalvador@suse.de \
--cc=shy828301@gmail.com \
--cc=willy@infradead.org \
--cc=xhao@linux.alibaba.com \
--cc=ying.huang@intel.com \
--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.