[PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Arnd Bergmann]

The new kaiser_add_mapping() function is provided globally and
called from x86 code that can be used in configurations without
KAISER but with 64-bit page flags, in particular _PAGE_NX, which
uses bit 63, leading to a compiler warning:

arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':
arch/x86/include/asm/pgtable_types.h:183:24: error: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '9223372036854776163' to '355' [-Werror=overflow]
 #define __PAGE_KERNEL  (__PAGE_KERNEL_EXEC | _PAGE_NX)
                        ^
arch/x86/kernel/ldt.c:104:6: note: in expansion of macro '__PAGE_KERNEL'
      __PAGE_KERNEL | _PAGE_GLOBAL);
arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':
arch/x86/include/asm/pgtable_types.h:183:24: error: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '9223372036854776163' to '355' [-Werror=overflow]
 #define __PAGE_KERNEL  (__PAGE_KERNEL_EXEC | _PAGE_NX)
                        ^
arch/x86/kernel/ldt.c:104:6: note: in expansion of macro '__PAGE_KERNEL'
      __PAGE_KERNEL | _PAGE_GLOBAL);

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.

Fixes: efd9d1a6b30b ("x86/mm/kaiser: Unmap kernel mappings from userspace page tables, core patch")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I only started building linux-next again today, so this probably
got noticed by others already, and it's possible someone had a better
fix for it. If so, please just ignore my version.
---
 arch/x86/include/asm/kaiser.h | 2 +-
 arch/x86/mm/kaiser.c          | 6 +++---
 include/linux/kaiser.h        | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/kaiser.h b/arch/x86/include/asm/kaiser.h
index 7c636cd25d65..5fcb9f81e615 100644
--- a/arch/x86/include/asm/kaiser.h
+++ b/arch/x86/include/asm/kaiser.h
@@ -31,7 +31,7 @@
  *  table.
  */
 extern int kaiser_add_mapping(unsigned long addr, unsigned long size,
-			      unsigned long flags);
+			      pteval_t flags);
 
 /**
  *  kaiser_add_mapping_cpu_entry - map the cpu entry area
diff --git a/arch/x86/mm/kaiser.c b/arch/x86/mm/kaiser.c
index 0ff502fa655b..2e2d340edbf0 100644
--- a/arch/x86/mm/kaiser.c
+++ b/arch/x86/mm/kaiser.c
@@ -261,7 +261,7 @@ static pte_t *kaiser_shadow_pagetable_walk(unsigned long address,
  * table pages.
  */
 int kaiser_add_user_map(const void *__start_addr, unsigned long size,
-			unsigned long flags)
+			pteval_t flags)
 {
 	unsigned long start_addr = (unsigned long)__start_addr;
 	unsigned long address = start_addr & PAGE_MASK;
@@ -312,7 +312,7 @@ int kaiser_add_user_map(const void *__start_addr, unsigned long size,
 
 int kaiser_add_user_map_ptrs(const void *__start_addr,
 			     const void *__end_addr,
-			     unsigned long flags)
+			     pteval_t flags)
 {
 	return kaiser_add_user_map(__start_addr,
 				   __end_addr - __start_addr,
@@ -470,7 +470,7 @@ static int __init kaiser_boottime_control(void)
 subsys_initcall(kaiser_boottime_control);
 
 int kaiser_add_mapping(unsigned long addr, unsigned long size,
-		       unsigned long flags)
+		       pteval_t flags)
 {
 	return kaiser_add_user_map((const void *)addr, size, flags);
 }
diff --git a/include/linux/kaiser.h b/include/linux/kaiser.h
index 77db4230a0dd..795fccf76849 100644
--- a/include/linux/kaiser.h
+++ b/include/linux/kaiser.h
@@ -20,7 +20,7 @@ static inline void kaiser_remove_mapping(unsigned long start, unsigned long size
 }
 
 static inline int kaiser_add_mapping(unsigned long addr, unsigned long size,
-				     unsigned long flags)
+				     u64 flags)
 {
 	return 0;
 }
-- 
2.9.0

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Arnd Bergmann]

On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> 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.

       Arnd

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Dave Hansen]

On 12/06/2017 07:03 AM, Arnd Bergmann wrote:
> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> 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.

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Arnd Bergmann]

On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
> On 12/06/2017 07:03 AM, Arnd Bergmann wrote:
>> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> 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.

Yes, this is next-20171206, apparently it came in through tip/auto-latest,
which still has the same version.

       Arnd

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Ingo Molnar]

* Arnd Bergmann <arnd@arndb.de> wrote:

> On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
> > On 12/06/2017 07:03 AM, Arnd Bergmann wrote:
> >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> 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.
> 
> Yes, this is next-20171206, apparently it came in through tip/auto-latest,
> which still has the same version.

I'll update the -next version probably later today.

Thanks,

	Ingo

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Arnd Bergmann]

On Wed, Dec 6, 2017 at 6:16 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
>> > On 12/06/2017 07:03 AM, Arnd Bergmann wrote:
>> >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >>
>> >> 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.
>>
>> Yes, this is next-20171206, apparently it came in through tip/auto-latest,
>> which still has the same version.
>
> I'll update the -next version probably later today.

Thanks!

 I just ran into another build error with KAISER:

arch/x86/mm/kaiser.c:173:28: error: '__GFP_NOTRACK' undeclared (first
use in this function); did you mean '__GFP_NOFAIL'?

When you do the update, can you check that it doesn't reference __GFP_NOTRACK?
Apparently the flag got removed in 4.15-rc1.

     Arnd

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Ingo Molnar]

* Arnd Bergmann <arnd@arndb.de> wrote:

> On Wed, Dec 6, 2017 at 6:16 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Arnd Bergmann <arnd@arndb.de> wrote:
> >
> >> On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
> >> > On 12/06/2017 07:03 AM, Arnd Bergmann wrote:
> >> >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> >>
> >> >> 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.
> >>
> >> Yes, this is next-20171206, apparently it came in through tip/auto-latest,
> >> which still has the same version.
> >
> > I'll update the -next version probably later today.
> 
> Thanks!
> 
>  I just ran into another build error with KAISER:
> 
> arch/x86/mm/kaiser.c:173:28: error: '__GFP_NOTRACK' undeclared (first
> use in this function); did you mean '__GFP_NOFAIL'?
> 
> When you do the update, can you check that it doesn't reference __GFP_NOTRACK?
> Apparently the flag got removed in 4.15-rc1.

Yeah, saw it too and fixed this one as well.

Thanks,

	Ingo

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Arnd Bergmann]

On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
> On 12/06/2017 07:03 AM, Arnd Bergmann wrote:
>> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> 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

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/include/linux/kaiser.h b/include/linux/kaiser.h
index 58c55b1589d0..b56c19010480 100644
--- a/include/linux/kaiser.h
+++ b/include/linux/kaiser.h
@@ -32,7 +32,7 @@ static inline void kaiser_init(void)
 {
 }
 static inline int kaiser_add_mapping(unsigned long addr,
-                                    unsigned long size, unsigned long flags)
+                                    unsigned long size, u64 flags)
 {
        return 0;
 }
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -13,7 +13,6 @@ extern void map_vsyscall(void);
  */
 extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address);
 extern bool vsyscall_enabled(void);
-extern unsigned long vsyscall_pgprot;
 #else
 static inline void map_vsyscall(void) {}
 static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned
long address)
@@ -23,4 +22,6 @@ static inline bool emulate_vsyscall(struct pt_regs
*regs, unsigned long address)
 static inline bool vsyscall_enabled(void) { return false; }
 #endif

+extern unsigned long vsyscall_pgprot;
+
 #endif /* _ASM_X86_VSYSCALL_H */

      Arnd

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Greg KH]

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@linux.intel.com> wrote:
> > On 12/06/2017 07:03 AM, Arnd Bergmann wrote:
> >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> 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

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Arnd Bergmann]

On Thu, Feb 15, 2018 at 6:43 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> 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@linux.intel.com> wrote:

>>
>> 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 :)

Sent two patches now. I want to make sure I haven't missed anything there,
especially as my first approach at fixing it ended up causing other build
failures.

In order to test this, I backported some 35 other (mostly trivial) patches later
kernels, and now I have a 4.9.80 based tree that produces a clean randconfig
build every time on arm64 and x86_64. If you want, I'll send you the list
of the required backports as well. From what I can tell, they are all
harmless (unused functions, missing Kconfig dependencies etc), but
being able to do randconfig builds reliable gives us an additional tool for
regression testing the stable kernels.

For 4.14-stable, we only need a handful of patches, but only one of those
is upstream, I'll try my best to get the others merged with a Cc stable tag
so 4.14 randconfig should build cleanly soon.

I suspect 4.4 would require even more patches, but I have not looked.

      Arnd

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Greg KH]

On Thu, Feb 15, 2018 at 04:37:10PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 15, 2018 at 6:43 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > 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@linux.intel.com> wrote:
> 
> >>
> >> 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 :)
> 
> Sent two patches now. I want to make sure I haven't missed anything there,
> especially as my first approach at fixing it ended up causing other build
> failures.
> 
> In order to test this, I backported some 35 other (mostly trivial) patches later
> kernels, and now I have a 4.9.80 based tree that produces a clean randconfig
> build every time on arm64 and x86_64. If you want, I'll send you the list
> of the required backports as well. From what I can tell, they are all
> harmless (unused functions, missing Kconfig dependencies etc), but
> being able to do randconfig builds reliable gives us an additional tool for
> regression testing the stable kernels.

Sure, I'll be glad to take those.

> For 4.14-stable, we only need a handful of patches, but only one of those
> is upstream, I'll try my best to get the others merged with a Cc stable tag
> so 4.14 randconfig should build cleanly soon.

Again, I'll be glad to take them as well.

> I suspect 4.4 would require even more patches, but I have not looked.

If the above doesn't clean up 4.4 as well, that would be surprising :)

Anyway, 4.4 might be nice to have "clean" if possible, and it's not too
much trouble.

thanks,

greg k-h

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Arnd Bergmann]

On Thu, Feb 15, 2018 at 5:43 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Feb 15, 2018 at 04:37:10PM +0100, Arnd Bergmann wrote:
>> On Thu, Feb 15, 2018 at 6:43 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > 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@linux.intel.com> wrote:
>>
>> >>
>> >> 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 :)
>>
>> Sent two patches now. I want to make sure I haven't missed anything there,
>> especially as my first approach at fixing it ended up causing other build
>> failures.
>>
>> In order to test this, I backported some 35 other (mostly trivial) patches later
>> kernels, and now I have a 4.9.80 based tree that produces a clean randconfig
>> build every time on arm64 and x86_64. If you want, I'll send you the list
>> of the required backports as well. From what I can tell, they are all
>> harmless (unused functions, missing Kconfig dependencies etc), but
>> being able to do randconfig builds reliable gives us an additional tool for
>> regression testing the stable kernels.
>
> Sure, I'll be glad to take those.

Here are the ones that I think should apply cleanly

ac29fc66855b drm/i915: fix intel_backlight_device_register declaration
23f919d4ad0e shmem: avoid maybe-uninitialized warning
aa01338c0184 clk: sunxi-ng: fix build error without CONFIG_RESET_CONTROLLER
fbdf0e28d061 vmxnet3: prevent building with 64K pages
11d8b05855f3 perf/x86: Shut up false-positive -Wmaybe-uninitialized warning
42db500a551f PCI: vmd: Fix suspend handlers defined-but-not-used warning
fbc2a294f29e gpio: intel-mid: Fix build warning when !CONFIG_PM
b4aca383f9af platform/x86: intel_mid_thermal: Fix suspend handlers
unused warning
c8bd2ac3b4c6 usb: musb: fix compilation warning on unused function
de5bbdd01cf9 PCI: Change pci_host_common_probe() visibility
c0bfc549e962 perf: xgene: Include module.h
484c7bbf2649 video: fbdev: via: remove possibly unused variables
067fdeb2f391 dmaengine: zx: fix build warning
f46e7cd36b5f scsi: advansys: fix build warning for PCI=n
d4b2ac63b0ea x86/ras/inject: Make it depend on X86_LOCAL_APIC=y
b115bebc07f2 gpio: xgene: mark PM functions as __maybe_unused
f13d52cb3fad arm64: define BUG() instruction without CONFIG_BUG
75e2f0a6b161 x86/fpu/math-emu: Fix possible uninitialized variable use
e572d0887137 tools build: Add tools tree support for 'make -s'
d460131dd505 x86/build: Silence the build with "make -s"
68fd77cf8a4b thermal: fix INTEL_SOC_DTS_IOSF_CORE dependencies
c2ce3f5d89d5 x86: add MULTIUSER dependency for KVM
d689c64d189e x86/platform: Add PCI dependency for PUNIT_ATOM_DEBUG
3ba5b5ea7dc3 x86/vm86: Fix unused variable warning if THP is disabled
44a5b977128c scsi: advansys: fix uninitialized data access
2e449048a25e arm64: Kconfig: select COMPAT_BINFMT_ELF only when
BINFMT_ELF is set
46a049dae771 ALSA: hda/ca0132 - fix possible NULL pointer use
ab4949640d66 reiserfs: avoid a -Wmaybe-uninitialized warning

For the rest, some need context changes, and some need a new patch
as the patch that avoided the warning or error in later kernels is not
a backportable fix (e.g. driver removed).

>> I suspect 4.4 would require even more patches, but I have not looked.
>
> If the above doesn't clean up 4.4 as well, that would be surprising :)
>
> Anyway, 4.4 might be nice to have "clean" if possible, and it's not too
> much trouble.

I think it was before 4.9 that I started doing randconfig testing on x86
and arm64, so I would expect some additional backports mostly.
I used to do randconfig testing for arm32 only, as that caught the
most bugs from arm-soc. However, there is still a large number of
issues for arm32 that require non-upstream workarounds, mostly for
the more esoteric configurations that other architectures don't have.

       Arnd

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

[Arnd Bergmann]

On Thu, Feb 15, 2018 at 10:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Feb 15, 2018 at 5:43 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Thu, Feb 15, 2018 at 04:37:10PM +0100, Arnd Bergmann wrote:
>>> In order to test this, I backported some 35 other (mostly trivial) patches later
>>> kernels, and now I have a 4.9.80 based tree that produces a clean randconfig
>>> build every time on arm64 and x86_64. If you want, I'll send you the list
>>> of the required backports as well. From what I can tell, they are all
>>> harmless (unused functions, missing Kconfig dependencies etc), but
>>> being able to do randconfig builds reliable gives us an additional tool for
>>> regression testing the stable kernels.
>>
>> Sure, I'll be glad to take those.
>
> Here are the ones that I think should apply cleanly
>
> ac29fc66855b drm/i915: fix intel_backlight_device_register declaration
> 23f919d4ad0e shmem: avoid maybe-uninitialized warning
> aa01338c0184 clk: sunxi-ng: fix build error without CONFIG_RESET_CONTROLLER
> fbdf0e28d061 vmxnet3: prevent building with 64K pages
> 11d8b05855f3 perf/x86: Shut up false-positive -Wmaybe-uninitialized warning
> 42db500a551f PCI: vmd: Fix suspend handlers defined-but-not-used warning
> fbc2a294f29e gpio: intel-mid: Fix build warning when !CONFIG_PM
> b4aca383f9af platform/x86: intel_mid_thermal: Fix suspend handlers
> unused warning
> c8bd2ac3b4c6 usb: musb: fix compilation warning on unused function
> de5bbdd01cf9 PCI: Change pci_host_common_probe() visibility
> c0bfc549e962 perf: xgene: Include module.h
> 484c7bbf2649 video: fbdev: via: remove possibly unused variables
> 067fdeb2f391 dmaengine: zx: fix build warning
> f46e7cd36b5f scsi: advansys: fix build warning for PCI=n
> d4b2ac63b0ea x86/ras/inject: Make it depend on X86_LOCAL_APIC=y
> b115bebc07f2 gpio: xgene: mark PM functions as __maybe_unused
> f13d52cb3fad arm64: define BUG() instruction without CONFIG_BUG
> 75e2f0a6b161 x86/fpu/math-emu: Fix possible uninitialized variable use
> e572d0887137 tools build: Add tools tree support for 'make -s'
> d460131dd505 x86/build: Silence the build with "make -s"
> 68fd77cf8a4b thermal: fix INTEL_SOC_DTS_IOSF_CORE dependencies
> c2ce3f5d89d5 x86: add MULTIUSER dependency for KVM
> d689c64d189e x86/platform: Add PCI dependency for PUNIT_ATOM_DEBUG
> 3ba5b5ea7dc3 x86/vm86: Fix unused variable warning if THP is disabled
> 44a5b977128c scsi: advansys: fix uninitialized data access
> 2e449048a25e arm64: Kconfig: select COMPAT_BINFMT_ELF only when
> BINFMT_ELF is set
> 46a049dae771 ALSA: hda/ca0132 - fix possible NULL pointer use
> ab4949640d66 reiserfs: avoid a -Wmaybe-uninitialized warning

and some more:

7fc1503c906f cw1200: fix bogus maybe-uninitialized warning
3cd18d198173 security/keys: BIG_KEY requires CONFIG_CRYPTO
7e1751001818 drm: exynos: mark pm functions as __maybe_unused
9e343e87d2c4 mtd: cfi: convert inline functions to macros
3cd890dbe2a4 media: dvb-frontends: fix i2c access helpers for KASAN
d4c2269b3d5d rbd: silence bogus -Wmaybe-uninitialized warning
b74c0a9969f2 drm/nouveau: hide gcc-4.9 -Wmaybe-uninitialized
ea4348c8462a Input: tca8418_keypad - hide gcc-4.9 -Wmaybe-uninitialized warning
16c3ada89cff media: r820t: fix r820t_write_reg for KASAN
e42eef4ba388 KVM: add X86_LOCAL_APIC dependency
f1f5929cd971 shmem: fix compilation warnings on unused functions
3538aa6ecfb2 [media] tc358743: fix register i2c_rd/wr functions
fa6317eedd63 [media] go7007: add MEDIA_CAMERA_SUPPORT dependency
190b23b4eb99 [media] em28xx: only use mt9v011 if camera support is enabled
27430d19a916 [media] tw5864: use dev_warn instead of WARN to shut up warning
27d807180ae0 ISDN: eicon: reduce stack size of sig_ind function
dbed87a9d3a8 clk: meson: gxbb: fix build error without RESET_CONTROLLER

There are a few more that that don't apply cleanly or that I had to
write from scratch,
I'll follow up with a patch series to stable@v.k.o.

      Arnd