All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zack Rusin <zackr@vmware.com>
To: <linux-kernel@vger.kernel.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Thomas Hellström" <thomas_os@shipmail.org>,
	linux-mm@kvack.org
Subject: [PATCH v2] mm/mapping_dirty_helpers: Guard hugepage pud's usage
Date: Fri, 9 Apr 2021 12:51:51 -0400	[thread overview]
Message-ID: <20210409165151.694574-1-zackr@vmware.com> (raw)

Mapping dirty helpers have, so far, been only used on X86, but
a port of vmwgfx to ARM64 exposed a problem which results
in a compilation error on ARM64 systems:
mm/mapping_dirty_helpers.c: In function ‘wp_clean_pud_entry’:
mm/mapping_dirty_helpers.c:172:32: error: implicit declaration of function ‘pud_dirty’; did you mean ‘pmd_dirty’? [-Werror=implicit-function-declaration]

This is due to the fact that mapping_dirty_helpers code assumes
that pud_dirty is always defined, which is not the case for
architectures that don't define CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD.

ARM64 arch is a little inconsistent when it comes to PUD
hugepage helpers, e.g. it defines pud_young but not pud_dirty
but regardless of that the core kernel code shouldn't assume
that any of the PUD hugepage helpers are available unless
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD is defined. This
prevents compilation errors whenever one of the drivers
is ported to new architectures.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Hellström (Intel) <thomas_os@shipmail.org>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/mapping_dirty_helpers.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c
index b59054ef2e10..b890854ec761 100644
--- a/mm/mapping_dirty_helpers.c
+++ b/mm/mapping_dirty_helpers.c
@@ -165,10 +165,12 @@ static int wp_clean_pud_entry(pud_t *pud, unsigned long addr, unsigned long end,
 		return 0;
 	}
 
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
 	/* Huge pud */
 	walk->action = ACTION_CONTINUE;
 	if (pud_trans_huge(pudval) || pud_devmap(pudval))
 		WARN_ON(pud_write(pudval) || pud_dirty(pudval));
+#endif
 
 	return 0;
 }
-- 
2.27.0


                 reply	other threads:[~2021-04-09 16:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20210409165151.694574-1-zackr@vmware.com \
    --to=zackr@vmware.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=thomas_os@shipmail.org \
    /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.