user/sven/linux.git/Makefile, branch v4.4.257

Linux 4.4.257

2021-02-10T08:07:28Z

Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Jason Self Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210208145805.279815326@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

x86/build: Disable CET instrumentation in the kernel

2021-02-10T08:07:28Z

commit 20bf2b378729c4a0366a53e2018a0b70ace94bcd upstream. With retpolines disabled, some configurations of GCC, and specifically the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation to the kernel by default. That breaks certain tracing scenarios by adding a superfluous ENDBR64 instruction before the fentry call, for functions which can be called indirectly. CET instrumentation isn't currently necessary in the kernel, as CET is only supported in user space. Disable it unconditionally and move it into the x86's Makefile as CET/CFI... enablement should be a per-arch decision anyway. [ bp: Massage and extend commit message. ] Fixes: 29be86d7f9cb ("kbuild: add -fcf-protection=none when using retpoline flags") Reported-by: Nikolay Borisov Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Reviewed-by: Nikolay Borisov Tested-by: Nikolay Borisov Cc: Cc: Seth Forshee Cc: Masahiro Yamada Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble Signed-off-by: Greg Kroah-Hartman

stable: clamp SUBLEVEL in 4.4 and 4.9

2021-02-10T08:07:26Z

Right now SUBLEVEL is overflowing, and some userspace may start treating 4.9.256 as 4.10. While out of tree modules have different ways of extracting the version number (and we're generally ok with breaking them), we do care about breaking userspace and it would appear that this overflow might do just that. Our rules around userspace ABI in the stable kernel are pretty simple: we don't break it. Thus, while userspace may be checking major/minor, it shouldn't be doing anything with sublevel. This patch applies a big band-aid to the 4.9 and 4.4 kernels in the form of clamping their sublevel to 255. The clamp is done for the purpose of LINUX_VERSION_CODE only, and extracting the version number from the Makefile or "make kernelversion" will continue to work as intended. We might need to do it later in newer trees, but maybe we'll have a better solution by then, so I'm ignoring that problem for now. Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Linux 4.4.256

2021-02-05T13:07:43Z

"Empty" release where we roll the .y number over... Signed-off-by: Greg Kroah-Hartman

Linux 4.4.255

2021-02-03T22:16:18Z

Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20210202132941.180062901@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

Linux 4.4.254

2021-01-30T12:25:58Z

Tested-by: Pavel Machek (CIP) Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210129105909.630107942@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

Linux 4.4.253

2021-01-23T14:36:57Z

Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20210122160822.198606273@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

Linux 4.4.252

2021-01-17T12:55:14Z

Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Link: https://lore.kernel.org/r/20210115121955.112329537@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

Linux 4.4.251

2021-01-12T18:47:57Z

Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210111130032.469630231@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

kbuild: don't hardcode depmod path

2021-01-12T18:47:53Z

commit 436e980e2ed526832de822cbf13c317a458b78e1 upstream. depmod is not guaranteed to be in /sbin, just let make look for it in the path like all the other invoked programs Signed-off-by: Dominique Martinet Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman