lkml.org 
[lkml]   [2023]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH -next v2] arm64: fix build warning for ARM64_MEMSTART_SHIFT
    From

    在 2023/7/25 18:15, Catalin Marinas 写道:
    > On Tue, Jul 25, 2023 at 04:47:46PM +0800, zhangjianhua (E) wrote:
    >> 在 2023/7/25 12:22, Anshuman Khandual 写道:
    >>> On 7/24/23 20:41, Catalin Marinas wrote:
    >>>> On Mon, Jul 24, 2023 at 05:27:51PM +0000, Zhang Jianhua wrote:
    >>>>> When building with W=1, the following warning occurs.
    >>>>>
    >>>>> arch/arm64/include/asm/kernel-pgtable.h:129:41: error: "PUD_SHIFT" is not defined, evaluates to 0 [-Werror=undef]
    >>>>> 129 | #define ARM64_MEMSTART_SHIFT PUD_SHIFT
    >>>>> | ^~~~~~~~~
    >>>>> arch/arm64/include/asm/kernel-pgtable.h:142:5: note: in expansion of macro ‘ARM64_MEMSTART_SHIFT’
    >>>>> 142 | #if ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS
    >>>>> | ^~~~~~~~~~~~~~~~~~~~
    >>>> Another thing that's missing here is that the warning is probably when
    >>>> this file is included from asm-offests.h or some .S file.
    >>>>
    >>>>> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
    >>>>> index 577773870b66..51bdce66885d 100644
    >>>>> --- a/arch/arm64/include/asm/kernel-pgtable.h
    >>>>> +++ b/arch/arm64/include/asm/kernel-pgtable.h
    >>>>> @@ -125,12 +125,14 @@
    >>>>> * (64k granule), or a multiple that can be mapped using contiguous bits
    >>>>> * in the page tables: 32 * PMD_SIZE (16k granule)
    >>>>> */
    >>>>> -#if defined(CONFIG_ARM64_4K_PAGES)
    >>>>> +#if defined(CONFIG_ARM64_4K_PAGES) && defined(PUD_SHIFT)
    >>>>> #define ARM64_MEMSTART_SHIFT PUD_SHIFT
    >>>> That's not the correct fix since PUD_SHIFT should always be defined.
    >>>> When CONFIG_PGTABLE_LEVELS == 3, pgtable-types.h includes
    >>>> asm-generic/pgtable-nopud.h and this defines PUD_SHIFT. We either got
    >>> Right, PUD_SHIFT is always defined irrespective of page table levels.
    >>>
    >>>> ARM64_MEMSTART_SHIFT defined in the wrong file or kernel-pgtable.h does
    >>>> not pull the relevant headers (either directly or via an included
    >>>> header). Even if kernel-pgtable.h ends up including the nopud/nopmd
    >>>> headers, P*D_SHIFT is guarded by an #indef __ASSEMBLY__ in those files.
    >>>>
    >>>> Something like below appears to fix this, though I'm not particularly
    >>>> fond of guarding the ARM64_MEMSTART_* definitions by #ifndef
    >>>> __ASSEMBLY__ for no apparent reason (could add a comment though):
    >>>>
    >>>> -----------------------8<---------------------------
    >>>> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
    >>>> index 577773870b66..fcea7e87a6ca 100644
    >>>> --- a/arch/arm64/include/asm/kernel-pgtable.h
    >>>> +++ b/arch/arm64/include/asm/kernel-pgtable.h
    >>>> @@ -118,6 +118,8 @@
    >>>> #define SWAPPER_RX_MMUFLAGS (SWAPPER_RW_MMUFLAGS | PTE_RDONLY)
    >>>> #endif
    >>>> +#ifndef __ASSEMBLY__
    >>>> +
    >>>> /*
    >>>> * To make optimal use of block mappings when laying out the linear
    >>>> * mapping, round down the base of physical memory to a size that can
    >>>> @@ -145,4 +147,6 @@
    >>>> #define ARM64_MEMSTART_ALIGN (1UL << ARM64_MEMSTART_SHIFT)
    >>>> #endif
    >>>> +#endif /* __ASSEMBLY__ */
    >>>> +
    >>>> #endif /* __ASM_KERNEL_PGTABLE_H */
    >>>> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
    >>>> index e4944d517c99..22b36f2d5d93 100644
    >>>> --- a/arch/arm64/include/asm/pgtable-hwdef.h
    >>>> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
    >>>> @@ -6,6 +6,7 @@
    >>>> #define __ASM_PGTABLE_HWDEF_H
    >>>> #include <asm/memory.h>
    >>>> +#include <asm/pgtable-types.h>
    >>>> /*
    >>>> * Number of page-table levels required to address 'va_bits' wide
    >>>> diff --git a/arch/arm64/include/asm/pgtable-types.h b/arch/arm64/include/asm/pgtable-types.h
    >>>> index b8f158ae2527..ae86e66fdb11 100644
    >>>> --- a/arch/arm64/include/asm/pgtable-types.h
    >>>> +++ b/arch/arm64/include/asm/pgtable-types.h
    >>>> @@ -11,6 +11,8 @@
    >>>> #include <asm/types.h>
    >>>> +#ifndef __ASSEMBLY__
    >>>> +
    >>>> typedef u64 pteval_t;
    >>>> typedef u64 pmdval_t;
    >>>> typedef u64 pudval_t;
    >>>> @@ -44,6 +46,8 @@ typedef struct { pteval_t pgprot; } pgprot_t;
    >>>> #define pgprot_val(x) ((x).pgprot)
    >>>> #define __pgprot(x) ((pgprot_t) { (x) } )
    >>>> +#endif /* __ASSEMBLY__ */
    >>>> +
    >>>> #if CONFIG_PGTABLE_LEVELS == 2
    >>>> #include <asm-generic/pgtable-nopmd.h>
    >>>> #elif CONFIG_PGTABLE_LEVELS == 3
    >>>> -----------------------8<---------------------------
    >>>>
    >>>> To avoid guarding the ARM64_MEMSTART_* definitions, we could instead
    >>>> move the P*D_SHIFT definitions in asm-generic/pgtable-nop*d.h outside
    >>>> the #ifndef __ASSEMBLY__ block.
    >>> OR could ARM64_MEMSTART_SHIFT and ARM64_MEMSTART_ALIGN computation blocks
    >>> be moved inside arch/arm64/mm/init.c, where it is used exclusively. Seems
    >>> to be solving the problem as well.
    > That's fine by me, better than adding the #ifndef __ASSEMBLY__ around
    > them.
    >
    >> This method can avoid the current compilation warning, but does not
    >> solve the problem that PUD_SHIFT and PMD_SHIFT undefined in fact, and
    >> it is contrary to XXX_SHIFT should always be defined. Maybe it would
    >> be more appropriate to solve this issue directly.
    > For .c files, we can solve this by including asm/pgtable-types.h in
    > asm/pgtable-hwdef.h. This still leaves P*D_SHIFT undefined for .S files
    > since the generic nop*d.h headers guard the shifts with !__ASSEMBLY__
    > but do we really care about this? I haven't seen any other warning of
    > P*D_SHIFT not being defined. If you do want to solve these, just go and
    > change the generic headers to take the shift out of the asm guard. I
    > don't think it's worth it.
    OK, agree, I will send a new patch for Anshuman's method.

    \
     
     \ /
      Last update: 2023-07-25 14:04    [W:4.143 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site