Messages in this thread | | | Subject | Re: [PATCH v2] powerpc/32: Don't use a struct based type for pte_t | From | Christophe Leroy <> | Date | Sat, 18 Sep 2021 10:37:21 +0200 |
| |
Le 18/09/2021 à 05:26, Michael Ellerman a écrit : > Christophe Leroy <christophe.leroy@csgroup.eu> writes: >> Long time ago we had a config item called STRICT_MM_TYPECHECKS >> to build the kernel with pte_t defined as a structure in order >> to perform additional build checks or build it with pte_t >> defined as a simple type in order to get simpler generated code. >> >> Commit 670eea924198 ("powerpc/mm: Always use STRICT_MM_TYPECHECKS") >> made the struct based definition the only one, considering that the >> generated code was similar in both cases. >> >> That's right on ppc64 because the ABI is such that the content of a >> struct having a single simple type element is passed as register, >> but on ppc32 such a structure is passed via the stack like any >> structure. >> >> Simple test function: >> >> pte_t test(pte_t pte) >> { >> return pte; >> } >> >> Before this patch we get >> >> c00108ec <test>: >> c00108ec: 81 24 00 00 lwz r9,0(r4) >> c00108f0: 91 23 00 00 stw r9,0(r3) >> c00108f4: 4e 80 00 20 blr >> >> So, for PPC32, restore the simple type behaviour we got before >> commit 670eea924198, but instead of adding a config option to >> activate type check, do it when __CHECKER__ is set so that type >> checking is performed by 'sparse' and provides feedback like: >> >> arch/powerpc/mm/pgtable.c:466:16: warning: incorrect type in return expression (different base types) >> arch/powerpc/mm/pgtable.c:466:16: expected unsigned long >> arch/powerpc/mm/pgtable.c:466:16: got struct pte_t [usertype] x > > OK that's a good trade off. > > One question below ... > >> diff --git a/arch/powerpc/include/asm/pgtable-types.h b/arch/powerpc/include/asm/pgtable-types.h >> index d11b4c61d686..c60199fc6fa6 100644 >> --- a/arch/powerpc/include/asm/pgtable-types.h >> +++ b/arch/powerpc/include/asm/pgtable-types.h >> @@ -5,14 +5,26 @@ >> /* PTE level */ >> #if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES) >> typedef struct { pte_basic_t pte, pte1, pte2, pte3; } pte_t; >> -#else >> +#elif defined(__CHECKER__) || !defined(CONFIG_PPC32) > > It would be nicer if this logic was in Kconfig. > > eg. restore config STRICT_MM_TYPECHECKS but make it always enabled for > 64-bit, and depend on CHECKER for 32-bit. > > The only thing is I'm not sure if we can test __CHECKER__ in Kconfig?
I think Kconfig doesn't see __CHECKER__, otherwise it would mean that a build may get different whether you build with C=1/2 or not.
__CHECKER__ is a define added by sparse when doing the CHECK on a per object basis.
What I can do is to add:
#if defined(__CHECKER__) || !defined(CONFIG_PPC32) #define STRICT_MM_TYPECHECKS #endif
Christophe
| |