archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Joerg Roedel <>
Cc: Guenter Roeck <>,
	Andrew Morton <>,
	Andy Lutomirski <>,
	Peter Zijlstra <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH] mm/vmalloc: track which page-table levels were modified
Date: Thu, 4 Jun 2020 10:16:07 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jun 4, 2020 at 1:35 AM Joerg Roedel <> wrote:
> I posted the fix for this already:


I was going to apply this directly, but as I looked at the patch I
just found it fairly illegible.

Is there some reason why the 5level-fixup.h versions use that
very-hard-to-follow macro, rather than the inline functions that the
main mm.h file uses?

I'm _assuming_ it's because it gets included in some place where not
everything is defined yet, so making it a macro means that it works
(later on) when everything has come together..

But the solution to that would seem to make all the p.._alloc_track()
macros just be in a different header file, and make them be all
together. We already have that


in linux/mm.h, so it's not like we really have isolated that issue
into just 5level-fixup.h anyway, and creating a new
<linux/pagetable-alloc.h> header that has all the variations in one
place, and that is only included by the two (!) users of these things
would seem to be a good idea regardless.

Because <linux/mm.h> is included by pretty much everything. Why do we
have those alloc_track functions defined in such a common header when
they are _so_ special?

Please? I'd obviously like this to be fixed on ppc asap, but I'd also
like the fix to improve on the current somewhat confusing situation..

For extra point, the p??_alloc_track() functions could even be
generated from a macro pattern, because the pattern is pretty much set
in stone.

I think the only thing that really differs is the types and the
PGTBL_xyz_MODIFIED mask, and which entry is tested for "none" (which
is also the only thing that makes the 5level fixup case different -


  reply	other threads:[~2020-06-04 17:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 23:23 [PATCH] mm/vmalloc: track which page-table levels were modified Guenter Roeck
2020-06-04  8:35 ` Joerg Roedel
2020-06-04 17:16   ` Linus Torvalds [this message]
2020-06-04 21:06     ` Andrew Morton
2020-06-04 21:12       ` Linus Torvalds
2020-06-05  8:16         ` Joerg Roedel
2020-06-05 10:00           ` Mike Rapoport
2020-06-09 12:10             ` Joerg Roedel
2020-06-09 14:15               ` Guenter Roeck
2020-06-09 16:23                 ` Joerg Roedel
2020-06-09 17:07                   ` Guenter Roeck
2020-06-10  7:59                 ` Mike Rapoport
2020-06-09 15:24               ` Mike Rapoport
2020-06-05  8:12     ` Joerg Roedel

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).