Re: [RFC 02/23] ARM: LPAE: use signed arithmetic for mask definitions

From: Cyril Chemparathy
Date: Tue Jul 31 2012 - 11:35:13 EST


Hi Catalin,

On 7/24/2012 6:05 AM, Catalin Marinas wrote:
On Tue, Jul 24, 2012 at 02:09:04AM +0100, Cyril Chemparathy wrote:
This patch applies to PAGE_MASK, PMD_MASK, and PGDIR_MASK, where forcing
unsigned long math truncates the mask at the 32-bits. This clearly does bad
things on PAE systems.

This patch fixes this problem by defining these masks as signed quantities.
We then rely on sign extension to do the right thing.

Signed-off-by: Cyril Chemparathy <cyril@xxxxxx>
Signed-off-by: Vitaly Andrianov <vitalya@xxxxxx>
---
arch/arm/include/asm/page.h | 7 ++++++-
arch/arm/include/asm/pgtable-3level.h | 6 +++---
2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index ecf9019..1c810d2 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -13,7 +13,12 @@
/* PAGE_SHIFT determines the page size */
#define PAGE_SHIFT 12
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
-#define PAGE_MASK (~(PAGE_SIZE-1))
+
+/*
+ * We do not use PAGE_SIZE in the following because we rely on sign
+ * extension to appropriately extend upper bits for PAE systems
+ */
+#define PAGE_MASK (~((1 << PAGE_SHIFT) - 1))

Would it work if we use a 1ULL here and avoid the sign trick? I'm
worried about some context where this would lose the sign. We could have
an #ifdef here while the PGDIR/PMD masks are in a separate file already.


I tried out this approach, and it spews size mismatch warnings in a few places when the mask is applied to a virtual address and casted to a pointer. Rather than having to scatter fixes in all these places, relying on sign extension may be cleaner.

Are there any particular areas that you are concerned about, that could potentially break with the sign extension approach?

--
Thanks
- Cyril
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/