On Wed, Feb 14, 2018 at 11:12:24PM +0100, Arnd Bergmann wrote: > On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> wrote: > > On 12/06/2017 07:03 AM, Arnd Bergmann wrote: > >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > >>> This changes the type to u64 in the architecture-independent dummy, > >>> and to pteval_t in the x86 specific portion that is used when KAISER > >>> is enabled, ensuring that the flags can always fit. Unfortunately, > >>> pteval_t is not provided by most other architectures, so we are > >>> a little bit inconsistent here. > >> > >> I ran into a new regression with my patch applied, after doing more randconfig > >> builds: > >> > >> In file included from /git/arm-soc/include/linux/kaiser.h:5, > >> from /git/arm-soc/arch/x86/events/intel/ds.c:4: > >> arch/x86/include/asm/kaiser.h:34:10: error: unknown type name > >> 'pteval_t'; did you mean 'dev_t'? > >> > >> Maybe it's better to just to the last one-line change in include/linux/kaiser.h. > > > > Hi Arnd, > > > > Are you hitting this in -next? > > > > The newest version of this code has a single kpti_init() function that > > shouldn't have any of these problems. > > Coming back to an old thread... > > I did some randconfig testing on 4.9.80, and now I see the same problem there, > since that version uses the KAISER patches rather than PTI: > > /git/arm-soc/arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct': > /git/arm-soc/arch/x86/include/asm/pgtable_types.h:208:24: error: large > integer implicitly truncated to unsigned type [-Werror=overflow] > #define __PAGE_KERNEL (__PAGE_KERNEL_EXEC | _PAGE_NX) > ^ > /git/arm-soc/arch/x86/kernel/ldt.c:81:6: note: in expansion of macro > '__PAGE_KERNEL' > __PAGE_KERNEL); > ^~~~~~~~~~~~~ > > I also saw another warning: > > /git/arm-soc/arch/x86/mm/kaiser.c: In function 'kaiser_init': > /git/arm-soc/arch/x86/mm/kaiser.c:347:8: error: 'vsyscall_pgprot' > undeclared (first use in this function); did you mean > 'massage_pgprot'? > > I can send this as proper patches for inclusion in 4.9-stable, unless > someone has a better idea or finds a problem proper patches would be good :) thanks, greg k-h