2018-01-08 13:03:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 00/22] 4.4.111-stable review

This is the start of the stable review cycle for the 4.4.111 release.
There are 22 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.111-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.4.111-rc1

Borislav Petkov <[email protected]>
Map the vsyscall page with _PAGE_USER

Alexey Dobriyan <[email protected]>
proc: much faster /proc/vmstat

Libor Pechacek <[email protected]>
module: Issue warnings when tainting kernel

Miroslav Benes <[email protected]>
module: keep percpu symbols in module's symtab

Michal Marek <[email protected]>
genksyms: Handle string literals with spaces in reference files

Thomas Gleixner <[email protected]>
x86/tlb: Drop the _GPL from the cpu_tlbstate export

Boris Brezillon <[email protected]>
mtd: nand: pxa3xx: Fix READOOB implementation

Helge Deller <[email protected]>
parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel

Tom Lendacky <[email protected]>
x86/microcode/AMD: Add support for fam17h microcode loading

Aaron Ma <[email protected]>
Input: elantech - add new icbody type 15

Vineet Gupta <[email protected]>
ARC: uaccess: dont use "l" gcc inline asm constraint modifier

Oleg Nesterov <[email protected]>
kernel/signal.c: remove the no longer needed SIGNAL_UNKILLABLE check in complete_signal()

Oleg Nesterov <[email protected]>
kernel/signal.c: protect the SIGNAL_UNKILLABLE tasks from !sig_kernel_only() signals

Oleg Nesterov <[email protected]>
kernel/signal.c: protect the traced SIGNAL_UNKILLABLE tasks from SIGKILL

Thiago Rafael Becker <[email protected]>
kernel: make groups_sort calling a responsibility group_info allocators

David Howells <[email protected]>
fscache: Fix the default for fscache_maybe_release_page()

Stefan Brüns <[email protected]>
sunxi-rsb: Include OF based modalias in device uevent

Eric Biggers <[email protected]>
crypto: pcrypt - fix freeing pcrypt instances

Eric Biggers <[email protected]>
crypto: chacha20poly1305 - validate the digest size

Jan Engelhardt <[email protected]>
crypto: n2 - cure use after free

Oleg Nesterov <[email protected]>
kernel/acct.c: fix the acct->needcheck check in check_free_space()

Andrey Ryabinin <[email protected]>
x86/kasan: Write protect kasan zero shadow


-------------

Diffstat:

Makefile | 4 ++--
arch/arc/include/asm/uaccess.h | 5 +++--
arch/parisc/include/asm/ldcw.h | 2 ++
arch/parisc/kernel/entry.S | 13 +++++++++++--
arch/parisc/kernel/pacache.S | 9 +++++++--
arch/s390/kernel/compat_linux.c | 1 +
arch/x86/entry/vsyscall/vsyscall_64.c | 5 +++++
arch/x86/include/asm/vsyscall.h | 2 ++
arch/x86/kernel/cpu/microcode/amd.c | 4 ++++
arch/x86/mm/init.c | 2 +-
arch/x86/mm/kaiser.c | 34 ++++++++++++++++++++++++++++++----
arch/x86/mm/kasan_init_64.c | 10 ++++++++--
crypto/chacha20poly1305.c | 6 +++++-
crypto/pcrypt.c | 19 ++++++++++---------
drivers/bus/sunxi-rsb.c | 1 +
drivers/crypto/n2_core.c | 3 +++
drivers/input/mouse/elantech.c | 2 +-
drivers/mtd/nand/pxa3xx_nand.c | 1 +
fs/nfsd/auth.c | 3 +++
include/linux/cred.h | 1 +
include/linux/fscache.h | 2 +-
kernel/acct.c | 2 +-
kernel/groups.c | 5 +++--
kernel/module.c | 26 +++++++++++++++++++++-----
kernel/signal.c | 18 ++++++++++--------
kernel/uid16.c | 1 +
mm/vmstat.c | 4 +++-
net/sunrpc/auth_gss/gss_rpc_xdr.c | 1 +
net/sunrpc/auth_gss/svcauth_gss.c | 1 +
net/sunrpc/svcauth_unix.c | 2 ++
scripts/genksyms/genksyms.c | 6 ++++--
31 files changed, 149 insertions(+), 46 deletions(-)



2018-01-08 13:02:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 01/22] x86/kasan: Write protect kasan zero shadow

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andrey Ryabinin <[email protected]>

commit 063fb3e56f6dd29b2633b678b837e1d904200e6f upstream.

After kasan_init() executed, no one is allowed to write to kasan_zero_page,
so write protect it.

Signed-off-by: Andrey Ryabinin <[email protected]>
Reviewed-by: Borislav Petkov <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Toshi Kani <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/mm/kasan_init_64.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -126,10 +126,16 @@ void __init kasan_init(void)

/*
* kasan_zero_page has been used as early shadow memory, thus it may
- * contain some garbage. Now we can clear it, since after the TLB flush
- * no one should write to it.
+ * contain some garbage. Now we can clear and write protect it, since
+ * after the TLB flush no one should write to it.
*/
memset(kasan_zero_page, 0, PAGE_SIZE);
+ for (i = 0; i < PTRS_PER_PTE; i++) {
+ pte_t pte = __pte(__pa(kasan_zero_page) | __PAGE_KERNEL_RO);
+ set_pte(&kasan_zero_pte[i], pte);
+ }
+ /* Flush TLBs again to be sure that write protection applied. */
+ __flush_tlb_all();

init_task.kasan_depth = 0;
pr_info("KernelAddressSanitizer initialized\n");


2018-01-08 13:02:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 11/22] kernel/signal.c: remove the no longer needed SIGNAL_UNKILLABLE check in complete_signal()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oleg Nesterov <[email protected]>

commit 426915796ccaf9c2bd9bb06dc5702225957bc2e5 upstream.

complete_signal() checks SIGNAL_UNKILLABLE before it starts to destroy
the thread group, today this is wrong in many ways.

If nothing else, fatal_signal_pending() should always imply that the
whole thread group (except ->group_exit_task if it is not NULL) is
killed, this check breaks the rule.

After the previous changes we can rely on sig_task_ignored();
sig_fatal(sig) && SIGNAL_UNKILLABLE can only be true if we actually want
to kill this task and sig == SIGKILL OR it is traced and debugger can
intercept the signal.

This should hopefully fix the problem reported by Dmitry. This
test-case

static int init(void *arg)
{
for (;;)
pause();
}

int main(void)
{
char stack[16 * 1024];

for (;;) {
int pid = clone(init, stack + sizeof(stack)/2,
CLONE_NEWPID | SIGCHLD, NULL);
assert(pid > 0);

assert(ptrace(PTRACE_ATTACH, pid, 0, 0) == 0);
assert(waitpid(-1, NULL, WSTOPPED) == pid);

assert(ptrace(PTRACE_DETACH, pid, 0, SIGSTOP) == 0);
assert(syscall(__NR_tkill, pid, SIGKILL) == 0);
assert(pid == wait(NULL));
}
}

triggers the WARN_ON_ONCE(!(task->jobctl & JOBCTL_STOP_PENDING)) in
task_participate_group_stop(). do_signal_stop()->signal_group_exit()
checks SIGNAL_GROUP_EXIT and return false, but task_set_jobctl_pending()
checks fatal_signal_pending() and does not set JOBCTL_STOP_PENDING.

And his should fix the minor security problem reported by Kyle,
SECCOMP_RET_TRACE can miss fatal_signal_pending() the same way if the
task is the root of a pid namespace.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Oleg Nesterov <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
Reported-by: Kyle Huey <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Tested-by: Kyle Huey <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/signal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -919,9 +919,9 @@ static void complete_signal(int sig, str
* then start taking the whole group down immediately.
*/
if (sig_fatal(p, sig) &&
- !(signal->flags & (SIGNAL_UNKILLABLE | SIGNAL_GROUP_EXIT)) &&
+ !(signal->flags & SIGNAL_GROUP_EXIT) &&
!sigismember(&t->real_blocked, sig) &&
- (sig == SIGKILL || !t->ptrace)) {
+ (sig == SIGKILL || !p->ptrace)) {
/*
* This signal will be fatal to the whole group.
*/


2018-01-08 13:02:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 15/22] parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helge Deller <[email protected]>

commit 88776c0e70be0290f8357019d844aae15edaa967 upstream.

Qemu for PARISC reported on a 32bit SMP parisc kernel strange failures
about "Not-handled unaligned insn 0x0e8011d6 and 0x0c2011c9."

Those opcodes evaluate to the ldcw() assembly instruction which requires
(on 32bit) an alignment of 16 bytes to ensure atomicity.

As it turns out, qemu is correct and in our assembly code in entry.S and
pacache.S we don't pay attention to the required alignment.

This patch fixes the problem by aligning the lock offset in assembly
code in the same manner as we do in our C-code.

Signed-off-by: Helge Deller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/parisc/include/asm/ldcw.h | 2 ++
arch/parisc/kernel/entry.S | 13 +++++++++++--
arch/parisc/kernel/pacache.S | 9 +++++++--
3 files changed, 20 insertions(+), 4 deletions(-)

--- a/arch/parisc/include/asm/ldcw.h
+++ b/arch/parisc/include/asm/ldcw.h
@@ -11,6 +11,7 @@
for the semaphore. */

#define __PA_LDCW_ALIGNMENT 16
+#define __PA_LDCW_ALIGN_ORDER 4
#define __ldcw_align(a) ({ \
unsigned long __ret = (unsigned long) &(a)->lock[0]; \
__ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \
@@ -28,6 +29,7 @@
ldcd). */

#define __PA_LDCW_ALIGNMENT 4
+#define __PA_LDCW_ALIGN_ORDER 2
#define __ldcw_align(a) (&(a)->slock)
#define __LDCW "ldcw,co"

--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -35,6 +35,7 @@
#include <asm/pgtable.h>
#include <asm/signal.h>
#include <asm/unistd.h>
+#include <asm/ldcw.h>
#include <asm/thread_info.h>

#include <linux/linkage.h>
@@ -46,6 +47,14 @@
#endif

.import pa_tlb_lock,data
+ .macro load_pa_tlb_lock reg
+#if __PA_LDCW_ALIGNMENT > 4
+ load32 PA(pa_tlb_lock) + __PA_LDCW_ALIGNMENT-1, \reg
+ depi 0,31,__PA_LDCW_ALIGN_ORDER, \reg
+#else
+ load32 PA(pa_tlb_lock), \reg
+#endif
+ .endm

/* space_to_prot macro creates a prot id from a space id */

@@ -457,7 +466,7 @@
.macro tlb_lock spc,ptp,pte,tmp,tmp1,fault
#ifdef CONFIG_SMP
cmpib,COND(=),n 0,\spc,2f
- load32 PA(pa_tlb_lock),\tmp
+ load_pa_tlb_lock \tmp
1: LDCW 0(\tmp),\tmp1
cmpib,COND(=) 0,\tmp1,1b
nop
@@ -480,7 +489,7 @@
/* Release pa_tlb_lock lock. */
.macro tlb_unlock1 spc,tmp
#ifdef CONFIG_SMP
- load32 PA(pa_tlb_lock),\tmp
+ load_pa_tlb_lock \tmp
tlb_unlock0 \spc,\tmp
#endif
.endm
--- a/arch/parisc/kernel/pacache.S
+++ b/arch/parisc/kernel/pacache.S
@@ -36,6 +36,7 @@
#include <asm/assembly.h>
#include <asm/pgtable.h>
#include <asm/cache.h>
+#include <asm/ldcw.h>
#include <linux/linkage.h>

.text
@@ -333,8 +334,12 @@ ENDPROC(flush_data_cache_local)

.macro tlb_lock la,flags,tmp
#ifdef CONFIG_SMP
- ldil L%pa_tlb_lock,%r1
- ldo R%pa_tlb_lock(%r1),\la
+#if __PA_LDCW_ALIGNMENT > 4
+ load32 pa_tlb_lock + __PA_LDCW_ALIGNMENT-1, \la
+ depi 0,31,__PA_LDCW_ALIGN_ORDER, \la
+#else
+ load32 pa_tlb_lock, \la
+#endif
rsm PSW_SM_I,\flags
1: LDCW 0(\la),\tmp
cmpib,<>,n 0,\tmp,3f


2018-01-08 13:03:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 17/22] x86/tlb: Drop the _GPL from the cpu_tlbstate export

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Gleixner <[email protected]>

commit 1e5476815fd7f98b888e01a0f9522b63085f96c9 upstream.

The recent changes for PTI touch cpu_tlbstate from various tlb_flush
inlines. cpu_tlbstate is exported as GPL symbol, so this causes a
regression when building out of tree drivers for certain graphics cards.

Aside of that the export was wrong since it was introduced as it should
have been EXPORT_PER_CPU_SYMBOL_GPL().

Use the correct PER_CPU export and drop the _GPL to restore the previous
state which allows users to utilize the cards they payed for.

As always I'm really thrilled to make this kind of change to support the
#friends (or however the hot hashtag of today is spelled) from that closet
sauce graphics corp.

Fixes: 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
Fixes: 6fd166aae78c ("x86/mm: Use/Fix PCID to optimize user/kernel switches")
Reported-by: Kees Cook <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Thomas Backlund <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -757,7 +757,7 @@ DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb
.state = 0,
.cr4 = ~0UL, /* fail hard if we screw up cr4 shadow initialization */
};
-EXPORT_SYMBOL_GPL(cpu_tlbstate);
+EXPORT_PER_CPU_SYMBOL(cpu_tlbstate);

void update_cache_mode_entry(unsigned entry, enum page_cache_mode cache)
{


2018-01-08 13:03:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 18/22] genksyms: Handle string literals with spaces in reference files

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michal Marek <[email protected]>

commit a78f70e8d65e88b9f631d073f68cb26dcd746298 upstream.

The reference files use spaces to separate tokens, however, we must
preserve spaces inside string literals. Currently the only case in the
tree is struct edac_raw_error_desc in <linux/edac.h>:

$ KBUILD_SYMTYPES=1 make -s drivers/edac/amd64_edac.symtypes
$ mv drivers/edac/amd64_edac.{symtypes,symref}
$ KBUILD_SYMTYPES=1 make -s drivers/edac/amd64_edac.symtypes
drivers/edac/amd64_edac.c:527: warning: amd64_get_dram_hole_info: modversion changed because of changes in struct edac_raw_error_desc

Signed-off-by: Michal Marek <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
scripts/genksyms/genksyms.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/scripts/genksyms/genksyms.c
+++ b/scripts/genksyms/genksyms.c
@@ -423,13 +423,15 @@ static struct string_list *read_node(FIL
struct string_list node = {
.string = buffer,
.tag = SYM_NORMAL };
- int c;
+ int c, in_string = 0;

while ((c = fgetc(f)) != EOF) {
- if (c == ' ') {
+ if (!in_string && c == ' ') {
if (node.string == buffer)
continue;
break;
+ } else if (c == '"') {
+ in_string = !in_string;
} else if (c == '\n') {
if (node.string == buffer)
return NULL;


2018-01-08 13:03:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 02/22] kernel/acct.c: fix the acct->needcheck check in check_free_space()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oleg Nesterov <[email protected]>

commit 4d9570158b6260f449e317a5f9ed030c2504a615 upstream.

As Tsukada explains, the time_is_before_jiffies(acct->needcheck) check
is very wrong, we need time_is_after_jiffies() to make sys_acct() work.

Ignoring the overflows, the code should "goto out" if needcheck >
jiffies, while currently it checks "needcheck < jiffies" and thus in the
likely case check_free_space() does nothing until jiffies overflow.

In particular this means that sys_acct() is simply broken, acct_on()
sets acct->needcheck = jiffies and expects that check_free_space()
should set acct->active = 1 after the free-space check, but this won't
happen if jiffies increments in between.

This was broken by commit 32dc73086015 ("get rid of timer in
kern/acct.c") in 2011, then another (correct) commit 795a2f22a8ea
("acct() should honour the limits from the very beginning") made the
problem more visible.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: 32dc73086015 ("get rid of timer in kern/acct.c")
Reported-by: TSUKADA Koutaro <[email protected]>
Suggested-by: TSUKADA Koutaro <[email protected]>
Signed-off-by: Oleg Nesterov <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/acct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -99,7 +99,7 @@ static int check_free_space(struct bsd_a
{
struct kstatfs sbuf;

- if (time_is_before_jiffies(acct->needcheck))
+ if (time_is_after_jiffies(acct->needcheck))
goto out;

/* May block */


2018-01-08 13:03:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 20/22] module: Issue warnings when tainting kernel

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Libor Pechacek <[email protected]>

commit 3205c36cf7d96024626f92d65f560035df1abcb2 upstream.

While most of the locations where a kernel taint bit is set are accompanied
with a warning message, there are two which set their bits silently. If
the tainting module gets unloaded later on, it is almost impossible to tell
what was the reason for setting the flag.

Signed-off-by: Libor Pechacek <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/module.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2888,8 +2888,12 @@ static int check_modinfo(struct module *
return -ENOEXEC;
}

- if (!get_modinfo(info, "intree"))
+ if (!get_modinfo(info, "intree")) {
+ if (!test_taint(TAINT_OOT_MODULE))
+ pr_warn("%s: loading out-of-tree module taints kernel.\n",
+ mod->name);
add_taint_module(mod, TAINT_OOT_MODULE, LOCKDEP_STILL_OK);
+ }

if (get_modinfo(info, "staging")) {
add_taint_module(mod, TAINT_CRAP, LOCKDEP_STILL_OK);
@@ -3054,6 +3058,8 @@ static int move_module(struct module *mo

static int check_module_license_and_versions(struct module *mod)
{
+ int prev_taint = test_taint(TAINT_PROPRIETARY_MODULE);
+
/*
* ndiswrapper is under GPL by itself, but loads proprietary modules.
* Don't use add_taint_module(), as it would prevent ndiswrapper from
@@ -3072,6 +3078,9 @@ static int check_module_license_and_vers
add_taint_module(mod, TAINT_PROPRIETARY_MODULE,
LOCKDEP_NOW_UNRELIABLE);

+ if (!prev_taint && test_taint(TAINT_PROPRIETARY_MODULE))
+ pr_warn("%s: module license taints kernel.\n", mod->name);
+
#ifdef CONFIG_MODVERSIONS
if ((mod->num_syms && !mod->crcs)
|| (mod->num_gpl_syms && !mod->gpl_crcs)


2018-01-08 13:03:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 22/22] Map the vsyscall page with _PAGE_USER

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Borislav Petkov <[email protected]>

This needs to happen early in kaiser_pagetable_walk(), before the
hierarchy is established so that _PAGE_USER permission can be really
set.

A proper fix would be to teach kaiser_pagetable_walk() to update those
permissions but the vsyscall page is the only exception here so ...

Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/entry/vsyscall/vsyscall_64.c | 5 +++++
arch/x86/include/asm/vsyscall.h | 2 ++
arch/x86/mm/kaiser.c | 34 ++++++++++++++++++++++++++++++----
3 files changed, 37 insertions(+), 4 deletions(-)

--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -66,6 +66,11 @@ static int __init vsyscall_setup(char *s
}
early_param("vsyscall", vsyscall_setup);

+bool vsyscall_enabled(void)
+{
+ return vsyscall_mode != NONE;
+}
+
static void warn_bad_vsyscall(const char *level, struct pt_regs *regs,
const char *message)
{
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -12,12 +12,14 @@ extern void map_vsyscall(void);
* Returns true if handled.
*/
extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address);
+extern bool vsyscall_enabled(void);
#else
static inline void map_vsyscall(void) {}
static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
{
return false;
}
+bool vsyscall_enabled(void) { return false; }
#endif

#endif /* _ASM_X86_VSYSCALL_H */
--- a/arch/x86/mm/kaiser.c
+++ b/arch/x86/mm/kaiser.c
@@ -20,6 +20,7 @@
#include <asm/pgalloc.h>
#include <asm/desc.h>
#include <asm/cmdline.h>
+#include <asm/vsyscall.h>

int kaiser_enabled __read_mostly = 1;
EXPORT_SYMBOL(kaiser_enabled); /* for inlined TLB flush functions */
@@ -111,12 +112,13 @@ static inline unsigned long get_pa_from_
*
* Returns a pointer to a PTE on success, or NULL on failure.
*/
-static pte_t *kaiser_pagetable_walk(unsigned long address)
+static pte_t *kaiser_pagetable_walk(unsigned long address, bool user)
{
pmd_t *pmd;
pud_t *pud;
pgd_t *pgd = native_get_shadow_pgd(pgd_offset_k(address));
gfp_t gfp = (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO);
+ unsigned long prot = _KERNPG_TABLE;

if (pgd_none(*pgd)) {
WARN_ONCE(1, "All shadow pgds should have been populated");
@@ -124,6 +126,17 @@ static pte_t *kaiser_pagetable_walk(unsi
}
BUILD_BUG_ON(pgd_large(*pgd) != 0);

+ if (user) {
+ /*
+ * The vsyscall page is the only page that will have
+ * _PAGE_USER set. Catch everything else.
+ */
+ BUG_ON(address != VSYSCALL_ADDR);
+
+ set_pgd(pgd, __pgd(pgd_val(*pgd) | _PAGE_USER));
+ prot = _PAGE_TABLE;
+ }
+
pud = pud_offset(pgd, address);
/* The shadow page tables do not use large mappings: */
if (pud_large(*pud)) {
@@ -136,7 +149,7 @@ static pte_t *kaiser_pagetable_walk(unsi
return NULL;
spin_lock(&shadow_table_allocation_lock);
if (pud_none(*pud)) {
- set_pud(pud, __pud(_KERNPG_TABLE | __pa(new_pmd_page)));
+ set_pud(pud, __pud(prot | __pa(new_pmd_page)));
__inc_zone_page_state(virt_to_page((void *)
new_pmd_page), NR_KAISERTABLE);
} else
@@ -156,7 +169,7 @@ static pte_t *kaiser_pagetable_walk(unsi
return NULL;
spin_lock(&shadow_table_allocation_lock);
if (pmd_none(*pmd)) {
- set_pmd(pmd, __pmd(_KERNPG_TABLE | __pa(new_pte_page)));
+ set_pmd(pmd, __pmd(prot | __pa(new_pte_page)));
__inc_zone_page_state(virt_to_page((void *)
new_pte_page), NR_KAISERTABLE);
} else
@@ -192,7 +205,7 @@ static int kaiser_add_user_map(const voi
ret = -EIO;
break;
}
- pte = kaiser_pagetable_walk(address);
+ pte = kaiser_pagetable_walk(address, flags & _PAGE_USER);
if (!pte) {
ret = -ENOMEM;
break;
@@ -319,6 +332,19 @@ void __init kaiser_init(void)

kaiser_init_all_pgds();

+ /*
+ * Note that this sets _PAGE_USER and it needs to happen when the
+ * pagetable hierarchy gets created, i.e., early. Otherwise
+ * kaiser_pagetable_walk() will encounter initialized PTEs in the
+ * hierarchy and not set the proper permissions, leading to the
+ * pagefaults with page-protection violations when trying to read the
+ * vsyscall page. For example.
+ */
+ if (vsyscall_enabled())
+ kaiser_add_user_map_early((void *)VSYSCALL_ADDR,
+ PAGE_SIZE,
+ __PAGE_KERNEL_VSYSCALL);
+
for_each_possible_cpu(cpu) {
void *percpu_vaddr = __per_cpu_user_mapped_start +
per_cpu_offset(cpu);


2018-01-08 13:03:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 03/22] crypto: n2 - cure use after free

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Engelhardt <[email protected]>

commit 203f45003a3d03eea8fa28d74cfc74c354416fdb upstream.

queue_cache_init is first called for the Control Word Queue
(n2_crypto_probe). At that time, queue_cache[0] is NULL and a new
kmem_cache will be allocated. If the subsequent n2_register_algs call
fails, the kmem_cache will be released in queue_cache_destroy, but
queue_cache_init[0] is not set back to NULL.

So when the Module Arithmetic Unit gets probed next (n2_mau_probe),
queue_cache_init will not allocate a kmem_cache again, but leave it
as its bogus value, causing a BUG() to trigger when queue_cache[0] is
eventually passed to kmem_cache_zalloc:

n2_crypto: Found N2CP at /virtual-devices@100/n2cp@7
n2_crypto: Registered NCS HVAPI version 2.0
called queue_cache_init
n2_crypto: md5 alg registration failed
n2cp f028687c: /virtual-devices@100/n2cp@7: Unable to register algorithms.
called queue_cache_destroy
n2cp: probe of f028687c failed with error -22
n2_crypto: Found NCP at /virtual-devices@100/ncp@6
n2_crypto: Registered NCS HVAPI version 2.0
called queue_cache_init
kernel BUG at mm/slab.c:2993!
Call Trace:
[0000000000604488] kmem_cache_alloc+0x1a8/0x1e0
(inlined) kmem_cache_zalloc
(inlined) new_queue
(inlined) spu_queue_setup
(inlined) handle_exec_unit
[0000000010c61eb4] spu_mdesc_scan+0x1f4/0x460 [n2_crypto]
[0000000010c62b80] n2_mau_probe+0x100/0x220 [n2_crypto]
[000000000084b174] platform_drv_probe+0x34/0xc0

Signed-off-by: Jan Engelhardt <[email protected]>
Acked-by: David S. Miller <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/n2_core.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -1641,6 +1641,7 @@ static int queue_cache_init(void)
CWQ_ENTRY_SIZE, 0, NULL);
if (!queue_cache[HV_NCS_QTYPE_CWQ - 1]) {
kmem_cache_destroy(queue_cache[HV_NCS_QTYPE_MAU - 1]);
+ queue_cache[HV_NCS_QTYPE_MAU - 1] = NULL;
return -ENOMEM;
}
return 0;
@@ -1650,6 +1651,8 @@ static void queue_cache_destroy(void)
{
kmem_cache_destroy(queue_cache[HV_NCS_QTYPE_MAU - 1]);
kmem_cache_destroy(queue_cache[HV_NCS_QTYPE_CWQ - 1]);
+ queue_cache[HV_NCS_QTYPE_MAU - 1] = NULL;
+ queue_cache[HV_NCS_QTYPE_CWQ - 1] = NULL;
}

static int spu_queue_register(struct spu_queue *p, unsigned long q_type)


2018-01-08 13:03:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 05/22] crypto: pcrypt - fix freeing pcrypt instances

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit d76c68109f37cb85b243a1cf0f40313afd2bae68 upstream.

pcrypt is using the old way of freeing instances, where the ->free()
method specified in the 'struct crypto_template' is passed a pointer to
the 'struct crypto_instance'. But the crypto_instance is being
kfree()'d directly, which is incorrect because the memory was actually
allocated as an aead_instance, which contains the crypto_instance at a
nonzero offset. Thus, the wrong pointer was being kfree()'d.

Fix it by switching to the new way to free aead_instance's where the
->free() method is specified in the aead_instance itself.

Reported-by: syzbot <[email protected]>
Fixes: 0496f56065e0 ("crypto: pcrypt - Add support for new AEAD interface")
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
crypto/pcrypt.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)

--- a/crypto/pcrypt.c
+++ b/crypto/pcrypt.c
@@ -254,6 +254,14 @@ static void pcrypt_aead_exit_tfm(struct
crypto_free_aead(ctx->child);
}

+static void pcrypt_free(struct aead_instance *inst)
+{
+ struct pcrypt_instance_ctx *ctx = aead_instance_ctx(inst);
+
+ crypto_drop_aead(&ctx->spawn);
+ kfree(inst);
+}
+
static int pcrypt_init_instance(struct crypto_instance *inst,
struct crypto_alg *alg)
{
@@ -319,6 +327,8 @@ static int pcrypt_create_aead(struct cry
inst->alg.encrypt = pcrypt_aead_encrypt;
inst->alg.decrypt = pcrypt_aead_decrypt;

+ inst->free = pcrypt_free;
+
err = aead_register_instance(tmpl, inst);
if (err)
goto out_drop_aead;
@@ -349,14 +359,6 @@ static int pcrypt_create(struct crypto_t
return -EINVAL;
}

-static void pcrypt_free(struct crypto_instance *inst)
-{
- struct pcrypt_instance_ctx *ctx = crypto_instance_ctx(inst);
-
- crypto_drop_aead(&ctx->spawn);
- kfree(inst);
-}
-
static int pcrypt_cpumask_change_notify(struct notifier_block *self,
unsigned long val, void *data)
{
@@ -469,7 +471,6 @@ static void pcrypt_fini_padata(struct pa
static struct crypto_template pcrypt_tmpl = {
.name = "pcrypt",
.create = pcrypt_create,
- .free = pcrypt_free,
.module = THIS_MODULE,
};



2018-01-08 13:03:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 07/22] fscache: Fix the default for fscache_maybe_release_page()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Howells <[email protected]>

commit 98801506552593c9b8ac11021b0cdad12cab4f6b upstream.

Fix the default for fscache_maybe_release_page() for when the cookie isn't
valid or the page isn't cached. It mustn't return false as that indicates
the page cannot yet be freed.

The problem with the default is that if, say, there's no cache, but a
network filesystem's pages are using up almost all the available memory, a
system can OOM because the filesystem ->releasepage() op will not allow
them to be released as fscache_maybe_release_page() incorrectly prevents
it.

This can be tested by writing a sequence of 512MiB files to an AFS mount.
It does not affect NFS or CIFS because both of those wrap the call in a
check of PG_fscache and it shouldn't bother Ceph as that only has
PG_private set whilst writeback is in progress. This might be an issue for
9P, however.

Note that the pages aren't entirely stuck. Removing a file or unmounting
will clear things because that uses ->invalidatepage() instead.

Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions")
Reported-by: Marc Dionne <[email protected]>
Signed-off-by: David Howells <[email protected]>
Reviewed-by: Jeff Layton <[email protected]>
Acked-by: Al Viro <[email protected]>
Tested-by: Marc Dionne <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/linux/fscache.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/linux/fscache.h
+++ b/include/linux/fscache.h
@@ -764,7 +764,7 @@ bool fscache_maybe_release_page(struct f
{
if (fscache_cookie_valid(cookie) && PageFsCache(page))
return __fscache_maybe_release_page(cookie, page, gfp);
- return false;
+ return true;
}

/**


2018-01-08 13:03:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 09/22] kernel/signal.c: protect the traced SIGNAL_UNKILLABLE tasks from SIGKILL

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oleg Nesterov <[email protected]>

commit 628c1bcba204052d19b686b5bac149a644cdb72e upstream.

The comment in sig_ignored() says "Tracers may want to know about even
ignored signals" but SIGKILL can not be reported to debugger and it is
just wrong to return 0 in this case: SIGKILL should only kill the
SIGNAL_UNKILLABLE task if it comes from the parent ns.

Change sig_ignored() to ignore ->ptrace if sig == SIGKILL and rely on
sig_task_ignored().

SISGTOP coming from within the namespace is not really right too but at
least debugger can intercept it, and we can't drop it here because this
will break "gdb -p 1": ptrace_attach() won't work. Perhaps we will add
another ->ptrace check later, we will see.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Oleg Nesterov <[email protected]>
Tested-by: Kyle Huey <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/signal.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -88,13 +88,15 @@ static int sig_ignored(struct task_struc
if (sigismember(&t->blocked, sig) || sigismember(&t->real_blocked, sig))
return 0;

- if (!sig_task_ignored(t, sig, force))
- return 0;
-
/*
- * Tracers may want to know about even ignored signals.
+ * Tracers may want to know about even ignored signal unless it
+ * is SIGKILL which can't be reported anyway but can be ignored
+ * by SIGNAL_UNKILLABLE task.
*/
- return !t->ptrace;
+ if (t->ptrace && sig != SIGKILL)
+ return 0;
+
+ return sig_task_ignored(t, sig, force);
}

/*


2018-01-08 13:04:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 08/22] kernel: make groups_sort calling a responsibility group_info allocators

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thiago Rafael Becker <[email protected]>

commit bdcf0a423ea1c40bbb40e7ee483b50fc8aa3d758 upstream.

In testing, we found that nfsd threads may call set_groups in parallel
for the same entry cached in auth.unix.gid, racing in the call of
groups_sort, corrupting the groups for that entry and leading to
permission denials for the client.

This patch:
- Make groups_sort globally visible.
- Move the call to groups_sort to the modifiers of group_info
- Remove the call to groups_sort from set_groups

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thiago Rafael Becker <[email protected]>
Reviewed-by: Matthew Wilcox <[email protected]>
Reviewed-by: NeilBrown <[email protected]>
Acked-by: "J. Bruce Fields" <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Martin Schwidefsky <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/s390/kernel/compat_linux.c | 1 +
fs/nfsd/auth.c | 3 +++
include/linux/cred.h | 1 +
kernel/groups.c | 5 +++--
kernel/uid16.c | 1 +
net/sunrpc/auth_gss/gss_rpc_xdr.c | 1 +
net/sunrpc/auth_gss/svcauth_gss.c | 1 +
net/sunrpc/svcauth_unix.c | 2 ++
8 files changed, 13 insertions(+), 2 deletions(-)

--- a/arch/s390/kernel/compat_linux.c
+++ b/arch/s390/kernel/compat_linux.c
@@ -263,6 +263,7 @@ COMPAT_SYSCALL_DEFINE2(s390_setgroups16,
return retval;
}

+ groups_sort(group_info);
retval = set_current_groups(group_info);
put_group_info(group_info);

--- a/fs/nfsd/auth.c
+++ b/fs/nfsd/auth.c
@@ -59,6 +59,9 @@ int nfsd_setuser(struct svc_rqst *rqstp,
GROUP_AT(gi, i) = exp->ex_anon_gid;
else
GROUP_AT(gi, i) = GROUP_AT(rqgi, i);
+
+ /* Each thread allocates its own gi, no race */
+ groups_sort(gi);
}
} else {
gi = get_group_info(rqgi);
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -87,6 +87,7 @@ extern int set_current_groups(struct gro
extern void set_groups(struct cred *, struct group_info *);
extern int groups_search(const struct group_info *, kgid_t);
extern bool may_setgroups(void);
+extern void groups_sort(struct group_info *);

/* access the groups "array" with this macro */
#define GROUP_AT(gi, i) \
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -101,7 +101,7 @@ static int groups_from_user(struct group
}

/* a simple Shell sort */
-static void groups_sort(struct group_info *group_info)
+void groups_sort(struct group_info *group_info)
{
int base, max, stride;
int gidsetsize = group_info->ngroups;
@@ -128,6 +128,7 @@ static void groups_sort(struct group_inf
stride /= 3;
}
}
+EXPORT_SYMBOL(groups_sort);

/* a simple bsearch */
int groups_search(const struct group_info *group_info, kgid_t grp)
@@ -159,7 +160,6 @@ int groups_search(const struct group_inf
void set_groups(struct cred *new, struct group_info *group_info)
{
put_group_info(new->group_info);
- groups_sort(group_info);
get_group_info(group_info);
new->group_info = group_info;
}
@@ -243,6 +243,7 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsi
return retval;
}

+ groups_sort(group_info);
retval = set_current_groups(group_info);
put_group_info(group_info);

--- a/kernel/uid16.c
+++ b/kernel/uid16.c
@@ -190,6 +190,7 @@ SYSCALL_DEFINE2(setgroups16, int, gidset
return retval;
}

+ groups_sort(group_info);
retval = set_current_groups(group_info);
put_group_info(group_info);

--- a/net/sunrpc/auth_gss/gss_rpc_xdr.c
+++ b/net/sunrpc/auth_gss/gss_rpc_xdr.c
@@ -231,6 +231,7 @@ static int gssx_dec_linux_creds(struct x
goto out_free_groups;
GROUP_AT(creds->cr_group_info, i) = kgid;
}
+ groups_sort(creds->cr_group_info);

return 0;
out_free_groups:
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -481,6 +481,7 @@ static int rsc_parse(struct cache_detail
goto out;
GROUP_AT(rsci.cred.cr_group_info, i) = kgid;
}
+ groups_sort(rsci.cred.cr_group_info);

/* mech name */
len = qword_get(&mesg, buf, mlen);
--- a/net/sunrpc/svcauth_unix.c
+++ b/net/sunrpc/svcauth_unix.c
@@ -520,6 +520,7 @@ static int unix_gid_parse(struct cache_d
GROUP_AT(ug.gi, i) = kgid;
}

+ groups_sort(ug.gi);
ugp = unix_gid_lookup(cd, uid);
if (ugp) {
struct cache_head *ch;
@@ -827,6 +828,7 @@ svcauth_unix_accept(struct svc_rqst *rqs
kgid_t kgid = make_kgid(&init_user_ns, svc_getnl(argv));
GROUP_AT(cred->cr_group_info, i) = kgid;
}
+ groups_sort(cred->cr_group_info);
if (svc_getu32(argv) != htonl(RPC_AUTH_NULL) || svc_getu32(argv) != 0) {
*authp = rpc_autherr_badverf;
return SVC_DENIED;


2018-01-08 13:04:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 04/22] crypto: chacha20poly1305 - validate the digest size

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit e57121d08c38dabec15cf3e1e2ad46721af30cae upstream.

If the rfc7539 template was instantiated with a hash algorithm with
digest size larger than 16 bytes (POLY1305_DIGEST_SIZE), then the digest
overran the 'tag' buffer in 'struct chachapoly_req_ctx', corrupting the
subsequent memory, including 'cryptlen'. This caused a crash during
crypto_skcipher_decrypt().

Fix it by, when instantiating the template, requiring that the
underlying hash algorithm has the digest size expected for Poly1305.

Reproducer:

#include <linux/if_alg.h>
#include <sys/socket.h>
#include <unistd.h>

int main()
{
int algfd, reqfd;
struct sockaddr_alg addr = {
.salg_type = "aead",
.salg_name = "rfc7539(chacha20,sha256)",
};
unsigned char buf[32] = { 0 };

algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (void *)&addr, sizeof(addr));
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, buf, sizeof(buf));
reqfd = accept(algfd, 0, 0);
write(reqfd, buf, 16);
read(reqfd, buf, 16);
}

Reported-by: syzbot <[email protected]>
Fixes: 71ebc4d1b27d ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
crypto/chacha20poly1305.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -600,6 +600,11 @@ static int chachapoly_create(struct cryp
CRYPTO_ALG_TYPE_AHASH_MASK);
if (IS_ERR(poly))
return PTR_ERR(poly);
+ poly_hash = __crypto_hash_alg_common(poly);
+
+ err = -EINVAL;
+ if (poly_hash->digestsize != POLY1305_DIGEST_SIZE)
+ goto out_put_poly;

err = -ENOMEM;
inst = kzalloc(sizeof(*inst) + sizeof(*ctx), GFP_KERNEL);
@@ -608,7 +613,6 @@ static int chachapoly_create(struct cryp

ctx = aead_instance_ctx(inst);
ctx->saltlen = CHACHAPOLY_IV_SIZE - ivsize;
- poly_hash = __crypto_hash_alg_common(poly);
err = crypto_init_ahash_spawn(&ctx->poly, poly_hash,
aead_crypto_instance(inst));
if (err)


2018-01-08 13:05:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 21/22] proc: much faster /proc/vmstat

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexey Dobriyan <[email protected]>

commit 68ba0326b4e14988f9e0c24a6e12a85cf2acd1ca upstream.

Every current KDE system has process named ksysguardd polling files
below once in several seconds:

$ strace -e trace=open -p $(pidof ksysguardd)
Process 1812 attached
open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8
open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8
open("/proc/net/dev", O_RDONLY) = 8
open("/proc/net/wireless", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/proc/stat", O_RDONLY) = 8
open("/proc/vmstat", O_RDONLY) = 8

Hell knows what it is doing but speed up reading /proc/vmstat by 33%!

Benchmark is open+read+close 1.000.000 times.

BEFORE
$ perf stat -r 10 taskset -c 3 ./proc-vmstat

Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs):

13146.768464 task-clock (msec) # 0.960 CPUs utilized ( +- 0.60% )
15 context-switches # 0.001 K/sec ( +- 1.41% )
1 cpu-migrations # 0.000 K/sec ( +- 11.11% )
104 page-faults # 0.008 K/sec ( +- 0.57% )
45,489,799,349 cycles # 3.460 GHz ( +- 0.03% )
9,970,175,743 stalled-cycles-frontend # 21.92% frontend cycles idle ( +- 0.10% )
2,800,298,015 stalled-cycles-backend # 6.16% backend cycles idle ( +- 0.32% )
79,241,190,850 instructions # 1.74 insn per cycle
# 0.13 stalled cycles per insn ( +- 0.00% )
17,616,096,146 branches # 1339.956 M/sec ( +- 0.00% )
176,106,232 branch-misses # 1.00% of all branches ( +- 0.18% )

13.691078109 seconds time elapsed ( +- 0.03% )
^^^^^^^^^^^^

AFTER
$ perf stat -r 10 taskset -c 3 ./proc-vmstat

Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs):

8688.353749 task-clock (msec) # 0.950 CPUs utilized ( +- 1.25% )
10 context-switches # 0.001 K/sec ( +- 2.13% )
1 cpu-migrations # 0.000 K/sec
104 page-faults # 0.012 K/sec ( +- 0.56% )
30,384,010,730 cycles # 3.497 GHz ( +- 0.07% )
12,296,259,407 stalled-cycles-frontend # 40.47% frontend cycles idle ( +- 0.13% )
3,370,668,651 stalled-cycles-backend # 11.09% backend cycles idle ( +- 0.69% )
28,969,052,879 instructions # 0.95 insn per cycle
# 0.42 stalled cycles per insn ( +- 0.01% )
6,308,245,891 branches # 726.058 M/sec ( +- 0.00% )
214,685,502 branch-misses # 3.40% of all branches ( +- 0.26% )

9.146081052 seconds time elapsed ( +- 0.07% )
^^^^^^^^^^^

vsnprintf() is slow because:

1. format_decode() is busy looking for format specifier: 2 branches
per character (not in this case, but in others)

2. approximately million branches while parsing format mini language
and everywhere

3. just look at what string() does /proc/vmstat is good case because
most of its content are strings

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Alexey Dobriyan <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Mel Gorman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/vmstat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1351,7 +1351,9 @@ static int vmstat_show(struct seq_file *
unsigned long *l = arg;
unsigned long off = l - (unsigned long *)m->private;

- seq_printf(m, "%s %lu\n", vmstat_text[off], *l);
+ seq_puts(m, vmstat_text[off]);
+ seq_put_decimal_ull(m, ' ', *l);
+ seq_putc(m, '\n');
return 0;
}



2018-01-08 13:06:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 19/22] module: keep percpu symbols in modules symtab

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Miroslav Benes <[email protected]>

commit e0224418516b4d8a6c2160574bac18447c354ef0 upstream.

Currently, percpu symbols from .data..percpu ELF section of a module are
not copied over and stored in final symtab array of struct module.
Consequently such symbol cannot be returned via kallsyms API (for
example kallsyms_lookup_name). This can be especially confusing when the
percpu symbol is exported. Only its __ksymtab et al. are present in its
symtab.

The culprit is in layout_and_allocate() function where SHF_ALLOC flag is
dropped for .data..percpu section. There is in fact no need to copy the
section to final struct module, because kernel module loader allocates
extra percpu section by itself. Unfortunately only symbols from
SHF_ALLOC sections are copied due to a check in is_core_symbol().

The patch changes is_core_symbol() function to copy over also percpu
symbols (their st_shndx points to .data..percpu ELF section). We do it
only if CONFIG_KALLSYMS_ALL is set to be consistent with the rest of the
function (ELF section is SHF_ALLOC but !SHF_EXECINSTR). Finally
elf_type() returns type 'a' for a percpu symbol because its address is
absolute.

Signed-off-by: Miroslav Benes <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/module.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2404,7 +2404,7 @@ static char elf_type(const Elf_Sym *sym,
}
if (sym->st_shndx == SHN_UNDEF)
return 'U';
- if (sym->st_shndx == SHN_ABS)
+ if (sym->st_shndx == SHN_ABS || sym->st_shndx == info->index.pcpu)
return 'a';
if (sym->st_shndx >= SHN_LORESERVE)
return '?';
@@ -2433,7 +2433,7 @@ static char elf_type(const Elf_Sym *sym,
}

static bool is_core_symbol(const Elf_Sym *src, const Elf_Shdr *sechdrs,
- unsigned int shnum)
+ unsigned int shnum, unsigned int pcpundx)
{
const Elf_Shdr *sec;

@@ -2442,6 +2442,11 @@ static bool is_core_symbol(const Elf_Sym
|| !src->st_name)
return false;

+#ifdef CONFIG_KALLSYMS_ALL
+ if (src->st_shndx == pcpundx)
+ return true;
+#endif
+
sec = sechdrs + src->st_shndx;
if (!(sec->sh_flags & SHF_ALLOC)
#ifndef CONFIG_KALLSYMS_ALL
@@ -2479,7 +2484,8 @@ static void layout_symtab(struct module
/* Compute total space required for the core symbols' strtab. */
for (ndst = i = 0; i < nsrc; i++) {
if (i == 0 ||
- is_core_symbol(src+i, info->sechdrs, info->hdr->e_shnum)) {
+ is_core_symbol(src+i, info->sechdrs, info->hdr->e_shnum,
+ info->index.pcpu)) {
strtab_size += strlen(&info->strtab[src[i].st_name])+1;
ndst++;
}
@@ -2537,7 +2543,8 @@ static void add_kallsyms(struct module *
src = mod->kallsyms->symtab;
for (ndst = i = 0; i < mod->kallsyms->num_symtab; i++) {
if (i == 0 ||
- is_core_symbol(src+i, info->sechdrs, info->hdr->e_shnum)) {
+ is_core_symbol(src+i, info->sechdrs, info->hdr->e_shnum,
+ info->index.pcpu)) {
dst[ndst] = src[i];
dst[ndst++].st_name = s - mod->core_kallsyms.strtab;
s += strlcpy(s, &mod->kallsyms->strtab[src[i].st_name],


2018-01-08 13:02:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 14/22] x86/microcode/AMD: Add support for fam17h microcode loading

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tom Lendacky <[email protected]>

commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf upstream.

The size for the Microcode Patch Block (MPB) for an AMD family 17h
processor is 3200 bytes. Add a #define for fam17h so that it does
not default to 2048 bytes and fail a microcode load/update.

Signed-off-by: Tom Lendacky <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Borislav Petkov <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Cc: Alice Ferrazzi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/cpu/microcode/amd.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -580,6 +580,7 @@ static unsigned int verify_patch_size(u8
#define F14H_MPB_MAX_SIZE 1824
#define F15H_MPB_MAX_SIZE 4096
#define F16H_MPB_MAX_SIZE 3458
+#define F17H_MPB_MAX_SIZE 3200

switch (family) {
case 0x14:
@@ -591,6 +592,9 @@ static unsigned int verify_patch_size(u8
case 0x16:
max_size = F16H_MPB_MAX_SIZE;
break;
+ case 0x17:
+ max_size = F17H_MPB_MAX_SIZE;
+ break;
default:
max_size = F1XH_MPB_MAX_SIZE;
break;


2018-01-08 13:02:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 12/22] ARC: uaccess: dont use "l" gcc inline asm constraint modifier

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vineet Gupta <[email protected]>

commit 79435ac78d160e4c245544d457850a56f805ac0d upstream.

This used to setup the LP_COUNT register automatically, but now has been
removed.

There was an earlier fix 3c7c7a2fc8811 which fixed instance in delay.h but
somehow missed this one as gcc change had not made its way into
production toolchains and was not pedantic as it is now !

Signed-off-by: Vineet Gupta <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arc/include/asm/uaccess.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/arch/arc/include/asm/uaccess.h
+++ b/arch/arc/include/asm/uaccess.h
@@ -673,6 +673,7 @@ __arc_strncpy_from_user(char *dst, const
return 0;

__asm__ __volatile__(
+ " mov lp_count, %5 \n"
" lp 3f \n"
"1: ldb.ab %3, [%2, 1] \n"
" breq.d %3, 0, 3f \n"
@@ -689,8 +690,8 @@ __arc_strncpy_from_user(char *dst, const
" .word 1b, 4b \n"
" .previous \n"
: "+r"(res), "+r"(dst), "+r"(src), "=r"(val)
- : "g"(-EFAULT), "l"(count)
- : "memory");
+ : "g"(-EFAULT), "r"(count)
+ : "lp_count", "lp_start", "lp_end", "memory");

return res;
}


2018-01-08 13:06:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 13/22] Input: elantech - add new icbody type 15

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Aaron Ma <[email protected]>

commit 10d900303f1c3a821eb0bef4e7b7ece16768fba4 upstream.

The touchpad of Lenovo Thinkpad L480 reports it's version as 15.

Signed-off-by: Aaron Ma <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/mouse/elantech.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1613,7 +1613,7 @@ static int elantech_set_properties(struc
case 5:
etd->hw_version = 3;
break;
- case 6 ... 14:
+ case 6 ... 15:
etd->hw_version = 4;
break;
default:


2018-01-08 13:07:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 10/22] kernel/signal.c: protect the SIGNAL_UNKILLABLE tasks from !sig_kernel_only() signals

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oleg Nesterov <[email protected]>

commit ac25385089f673560867eb5179228a44ade0cfc1 upstream.

Change sig_task_ignored() to drop the SIG_DFL && !sig_kernel_only()
signals even if force == T. This simplifies the next change and this
matches the same check in get_signal() which will drop these signals
anyway.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Oleg Nesterov <[email protected]>
Tested-by: Kyle Huey <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -72,7 +72,7 @@ static int sig_task_ignored(struct task_
handler = sig_handler(t, sig);

if (unlikely(t->signal->flags & SIGNAL_UNKILLABLE) &&
- handler == SIG_DFL && !force)
+ handler == SIG_DFL && !(force && sig_kernel_only(sig)))
return 1;

return sig_handler_ignored(handler, sig);


2018-01-08 14:25:32

by Nathan Chancellor

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On Mon, Jan 08, 2018 at 01:59:27PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.111 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.111-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 4.4.111-rc1
>
> Borislav Petkov <[email protected]>
> Map the vsyscall page with _PAGE_USER
>
> Alexey Dobriyan <[email protected]>
> proc: much faster /proc/vmstat
>
> Libor Pechacek <[email protected]>
> module: Issue warnings when tainting kernel
>
> Miroslav Benes <[email protected]>
> module: keep percpu symbols in module's symtab
>
> Michal Marek <[email protected]>
> genksyms: Handle string literals with spaces in reference files
>
> Thomas Gleixner <[email protected]>
> x86/tlb: Drop the _GPL from the cpu_tlbstate export
>
> Boris Brezillon <[email protected]>
> mtd: nand: pxa3xx: Fix READOOB implementation
>
> Helge Deller <[email protected]>
> parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel
>
> Tom Lendacky <[email protected]>
> x86/microcode/AMD: Add support for fam17h microcode loading
>
> Aaron Ma <[email protected]>
> Input: elantech - add new icbody type 15
>
> Vineet Gupta <[email protected]>
> ARC: uaccess: dont use "l" gcc inline asm constraint modifier
>
> Oleg Nesterov <[email protected]>
> kernel/signal.c: remove the no longer needed SIGNAL_UNKILLABLE check in complete_signal()
>
> Oleg Nesterov <[email protected]>
> kernel/signal.c: protect the SIGNAL_UNKILLABLE tasks from !sig_kernel_only() signals
>
> Oleg Nesterov <[email protected]>
> kernel/signal.c: protect the traced SIGNAL_UNKILLABLE tasks from SIGKILL
>
> Thiago Rafael Becker <[email protected]>
> kernel: make groups_sort calling a responsibility group_info allocators
>
> David Howells <[email protected]>
> fscache: Fix the default for fscache_maybe_release_page()
>
> Stefan Br?ns <[email protected]>
> sunxi-rsb: Include OF based modalias in device uevent
>
> Eric Biggers <[email protected]>
> crypto: pcrypt - fix freeing pcrypt instances
>
> Eric Biggers <[email protected]>
> crypto: chacha20poly1305 - validate the digest size
>
> Jan Engelhardt <[email protected]>
> crypto: n2 - cure use after free
>
> Oleg Nesterov <[email protected]>
> kernel/acct.c: fix the acct->needcheck check in check_free_space()
>
> Andrey Ryabinin <[email protected]>
> x86/kasan: Write protect kasan zero shadow
>
>
> -------------
>
> Diffstat:
>
> Makefile | 4 ++--
> arch/arc/include/asm/uaccess.h | 5 +++--
> arch/parisc/include/asm/ldcw.h | 2 ++
> arch/parisc/kernel/entry.S | 13 +++++++++++--
> arch/parisc/kernel/pacache.S | 9 +++++++--
> arch/s390/kernel/compat_linux.c | 1 +
> arch/x86/entry/vsyscall/vsyscall_64.c | 5 +++++
> arch/x86/include/asm/vsyscall.h | 2 ++
> arch/x86/kernel/cpu/microcode/amd.c | 4 ++++
> arch/x86/mm/init.c | 2 +-
> arch/x86/mm/kaiser.c | 34 ++++++++++++++++++++++++++++++----
> arch/x86/mm/kasan_init_64.c | 10 ++++++++--
> crypto/chacha20poly1305.c | 6 +++++-
> crypto/pcrypt.c | 19 ++++++++++---------
> drivers/bus/sunxi-rsb.c | 1 +
> drivers/crypto/n2_core.c | 3 +++
> drivers/input/mouse/elantech.c | 2 +-
> drivers/mtd/nand/pxa3xx_nand.c | 1 +
> fs/nfsd/auth.c | 3 +++
> include/linux/cred.h | 1 +
> include/linux/fscache.h | 2 +-
> kernel/acct.c | 2 +-
> kernel/groups.c | 5 +++--
> kernel/module.c | 26 +++++++++++++++++++++-----
> kernel/signal.c | 18 ++++++++++--------
> kernel/uid16.c | 1 +
> mm/vmstat.c | 4 +++-
> net/sunrpc/auth_gss/gss_rpc_xdr.c | 1 +
> net/sunrpc/auth_gss/svcauth_gss.c | 1 +
> net/sunrpc/svcauth_unix.c | 2 ++
> scripts/genksyms/genksyms.c | 6 ++++--
> 31 files changed, 149 insertions(+), 46 deletions(-)
>
>

Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.

No issues noticed in general usage or dmesg.

Thanks!
Nathan

2018-01-08 15:21:15

by 王金浦

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

2018-01-08 13:59 GMT+01:00 Greg Kroah-Hartman <[email protected]>:
> This is the start of the stable review cycle for the 4.4.111 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.111-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Merged, build, boot fine on my test machine.

No issues noticed in general usage or dmesg.

Thanks,
Jack

2018-01-08 16:32:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On Mon, Jan 08, 2018 at 07:25:25AM -0700, Nathan Chancellor wrote:
> Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.
>
> No issues noticed in general usage or dmesg.

Wonderful, thanks for testing and letting me know.

greg k-h

2018-01-08 16:32:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On Mon, Jan 08, 2018 at 04:21:10PM +0100, 王金浦 wrote:
> 2018-01-08 13:59 GMT+01:00 Greg Kroah-Hartman <[email protected]>:
> > This is the start of the stable review cycle for the 4.4.111 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.111-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> Merged, build, boot fine on my test machine.
>
> No issues noticed in general usage or dmesg.

Great, thanks for testing and letting me know.

greg k-h

2018-01-08 21:00:33

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On 01/08/2018 05:59 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.111 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.111-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

2018-01-08 23:29:12

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On Mon, Jan 08, 2018 at 01:59:27PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.111 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> Anything received after that time might be too late.
>

x86:64:allnoconfig still fails to build.

To reproduce:
make ARCH=x86_64 allnoconfig
make ARCH=x86_64 arch/x86/entry/vdso/vma.o

arch/x86/entry/vdso/vma.c: In function ‘map_vdso’:
arch/x86/entry/vdso/vma.c:175:9: error:
implicit declaration of function ‘pvclock_pvti_cpu0_va’

The function is declared in arch/x86/include/asm/pvclock.h, which is only
indirectly included. For 32-bit allnoconfig builds, the include path is:
arch/x86/entry/vdso/vma.c
include/linux/mm.h
./arch/x86/include/asm/pgtable.h
./arch/x86/include/asm/pgtable_32.h

but pgtable_64.h doesn't include pgtable_32.h, and the declaration is
missing as result.

The include of asm/pvclock.h was added upstream with commit cc1e24fdb064d
("x86/vdso: Remove pvclock fixmap machinery") which applies cleanly to
v4.4.y. Please consider adding it, or at least add the missing include.

Thanks,
Guenter

2018-01-09 09:13:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On Mon, Jan 08, 2018 at 03:29:07PM -0800, Guenter Roeck wrote:
> On Mon, Jan 08, 2018 at 01:59:27PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.111 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> x86:64:allnoconfig still fails to build.
>
> To reproduce:
> make ARCH=x86_64 allnoconfig
> make ARCH=x86_64 arch/x86/entry/vdso/vma.o
>
> arch/x86/entry/vdso/vma.c: In function ‘map_vdso’:
> arch/x86/entry/vdso/vma.c:175:9: error:
> implicit declaration of function ‘pvclock_pvti_cpu0_va’
>
> The function is declared in arch/x86/include/asm/pvclock.h, which is only
> indirectly included. For 32-bit allnoconfig builds, the include path is:
> arch/x86/entry/vdso/vma.c
> include/linux/mm.h
> ./arch/x86/include/asm/pgtable.h
> ./arch/x86/include/asm/pgtable_32.h
>
> but pgtable_64.h doesn't include pgtable_32.h, and the declaration is
> missing as result.

Yeah, I haven't had the chance to work on that yet, sorry.

> The include of asm/pvclock.h was added upstream with commit cc1e24fdb064d
> ("x86/vdso: Remove pvclock fixmap machinery") which applies cleanly to
> v4.4.y. Please consider adding it, or at least add the missing include.

Is it really that easy? Hey, nice, let me queue that up and test...

thanks,

greg k-h

2018-01-09 09:23:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On Mon, Jan 08, 2018 at 03:29:07PM -0800, Guenter Roeck wrote:
> On Mon, Jan 08, 2018 at 01:59:27PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.111 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> x86:64:allnoconfig still fails to build.
>
> To reproduce:
> make ARCH=x86_64 allnoconfig
> make ARCH=x86_64 arch/x86/entry/vdso/vma.o
>
> arch/x86/entry/vdso/vma.c: In function ‘map_vdso’:
> arch/x86/entry/vdso/vma.c:175:9: error:
> implicit declaration of function ‘pvclock_pvti_cpu0_va’

Ok, forcing ARCH=x86_64 shows this now for me, strange it did not
without it, which worries me...

Anyway, a simple <include> line seems to have solved this, let me push
that out now, I couldn't take the full patch you referenced as that
causes build errors.

thanks,

greg k-h

2018-01-09 09:51:40

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On 8 January 2018 at 18:29, Greg Kroah-Hartman
<[email protected]> wrote:
> This is the start of the stable review cycle for the 4.4.111 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.111-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
There were multiple pushes to 4.4.111-rc1 here is what we have the
latest results.
We will report results again soon with latest builds.

Summary
------------------------------------------------------------------------

kernel: 4.4.111-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 63a9e592115272f40a530920b40596c131d01cae
git describe: v4.4.110-22-g63a9e5921152
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.110-22-g63a9e5921152


No regressions (compared to build v4.4.110-23-g49278737d445)

Boards, architectures and test suites:
-------------------------------------

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 29, pass: 32,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 36, pass: 28,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 124, pass: 984,
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 29, pass: 31,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 67, pass: 1036,
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 32, pass: 44,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 117, pass: 1015,
* ltp-timers-tests - pass: 12,

Hikey device test results,

Summary
------------------------------------------------------------------------
kernel: 4.4.111-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.111-rc1-hikey-20180108-99
git commit: 53993e01618204a658d8fe84cc344bdc9e21cb6a
git describe: 4.4.111-rc1-hikey-20180108-99
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.111-rc1-hikey-20180108-99

No regressions (compared to build 4.4.111-rc1-hikey-20180108-98)

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 30, skip: 31
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 980, skip: 124
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju <[email protected]>

2018-01-09 10:50:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On Tue, Jan 09, 2018 at 03:21:35PM +0530, Naresh Kamboju wrote:
> On 8 January 2018 at 18:29, Greg Kroah-Hartman
> <[email protected]> wrote:
> > This is the start of the stable review cycle for the 4.4.111 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.111-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.
>
> NOTE:
> There were multiple pushes to 4.4.111-rc1 here is what we have the
> latest results.
> We will report results again soon with latest builds.

I just pushed a build-fix that you aren't seeing, but it should work the
same as what you have already tested (i.e. it only fixed a build
problem.)

thanks,

greg k-h

2018-01-09 13:50:18

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On 01/09/2018 01:23 AM, Greg Kroah-Hartman wrote:
> On Mon, Jan 08, 2018 at 03:29:07PM -0800, Guenter Roeck wrote:
>> On Mon, Jan 08, 2018 at 01:59:27PM +0100, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.4.111 release.
>>> There are 22 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
>>> Anything received after that time might be too late.
>>>
>>
>> x86:64:allnoconfig still fails to build.
>>
>> To reproduce:
>> make ARCH=x86_64 allnoconfig
>> make ARCH=x86_64 arch/x86/entry/vdso/vma.o
>>
>> arch/x86/entry/vdso/vma.c: In function ‘map_vdso’:
>> arch/x86/entry/vdso/vma.c:175:9: error:
>> implicit declaration of function ‘pvclock_pvti_cpu0_va’
>
> Ok, forcing ARCH=x86_64 shows this now for me, strange it did not
> without it, which worries me...
>

For whatever reason, "make allnoconfig" configures the system for 32 bit,
even if the native system is 64 bit.

> Anyway, a simple <include> line seems to have solved this, let me push
> that out now, I couldn't take the full patch you referenced as that
> causes build errors.
>
Too bad. But as long as it works ...

Thanks,
Guenter

2018-01-09 16:17:05

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/22] 4.4.111-stable review

On Mon, Jan 08, 2018 at 01:59:27PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.111 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jan 10 12:59:14 UTC 2018.
> Anything received after that time might be too late.
>

For v4.4.110-23-ga736c68:

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 118 pass: 118 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter