* [PATCH 06/13] sh: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()
char buffer[KSYM_SYMBOL_LEN];
sprint_symbol(buffer, address);
printk(fmt, buffer);
Replace print_symbol() with a direct printk("%pS") call.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
---
arch/sh/kernel/process_32.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/sh/kernel/process_32.c b/arch/sh/kernel/process_32.c
index 2c7bdf8cb934..5c88e7cb9c18 100644
--- a/arch/sh/kernel/process_32.c
+++ b/arch/sh/kernel/process_32.c
@@ -20,7 +20,6 @@
#include <linux/sched/task_stack.h>
#include <linux/slab.h>
#include <linux/elfcore.h>
-#include <linux/kallsyms.h>
#include <linux/fs.h>
#include <linux/ftrace.h>
#include <linux/hw_breakpoint.h>
@@ -37,8 +36,8 @@ void show_regs(struct pt_regs * regs)
printk("\n");
show_regs_print_info(KERN_DEFAULT);
- print_symbol("PC is at %s\n", instruction_pointer(regs));
- print_symbol("PR is at %s\n", regs->pr);
+ printk("PC is at %pS\n", instruction_pointer(regs));
+ printk("PR is at %pS\n", (void *)regs->pr);
printk("PC : %08lx SP : %08lx SR : %08lx ",
regs->pc, regs->regs[15], regs->sr);
--
2.15.1
^ permalink raw reply related
* [PATCH 07/13] unicore32: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()
char buffer[KSYM_SYMBOL_LEN];
sprint_symbol(buffer, address);
printk(fmt, buffer);
Replace print_symbol() with a direct printk("%pS") call.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
---
arch/unicore32/kernel/process.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index ddaf78ae6854..9a9d49bccc02 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -23,7 +23,6 @@
#include <linux/delay.h>
#include <linux/reboot.h>
#include <linux/interrupt.h>
-#include <linux/kallsyms.h>
#include <linux/init.h>
#include <linux/cpu.h>
#include <linux/elfcore.h>
@@ -139,8 +138,8 @@ void __show_regs(struct pt_regs *regs)
char buf[64];
show_regs_print_info(KERN_DEFAULT);
- print_symbol("PC is at %s\n", instruction_pointer(regs));
- print_symbol("LR is at %s\n", regs->UCreg_lr);
+ printk("PC is at %pS\n", instruction_pointer(regs));
+ printk("LR is at %pS\n", (void *)regs->UCreg_lr);
printk(KERN_DEFAULT "pc : [<%08lx>] lr : [<%08lx>] psr: %08lx\n"
"sp : %08lx ip : %08lx fp : %08lx\n",
regs->UCreg_pc, regs->UCreg_lr, regs->UCreg_asr,
--
2.15.1
^ permalink raw reply related
* [PATCH 08/13] x86: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()
char buffer[KSYM_SYMBOL_LEN];
sprint_symbol(buffer, address);
printk(fmt, buffer);
Replace print_symbol() with a direct printk("%pS") call.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
arch/x86/kernel/cpu/mcheck/mce.c | 3 +--
arch/x86/mm/mmio-mod.c | 5 ++---
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index b1d616d08eee..8ca8f6eb32db 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -14,7 +14,6 @@
#include <linux/capability.h>
#include <linux/miscdevice.h>
#include <linux/ratelimit.h>
-#include <linux/kallsyms.h>
#include <linux/rcupdate.h>
#include <linux/kobject.h>
#include <linux/uaccess.h>
@@ -235,7 +234,7 @@ static void __print_mce(struct mce *m)
m->cs, m->ip);
if (m->cs == __KERNEL_CS)
- print_symbol("{%s}", m->ip);
+ pr_cont("{%pS}", (void *)m->ip);
pr_cont("\n");
}
diff --git a/arch/x86/mm/mmio-mod.c b/arch/x86/mm/mmio-mod.c
index 4d434ddb75db..2c1ecf4763c4 100644
--- a/arch/x86/mm/mmio-mod.c
+++ b/arch/x86/mm/mmio-mod.c
@@ -29,7 +29,6 @@
#include <linux/slab.h>
#include <linux/uaccess.h>
#include <linux/io.h>
-#include <linux/kallsyms.h>
#include <asm/pgtable.h>
#include <linux/mmiotrace.h>
#include <asm/e820/api.h> /* for ISA_START_ADDRESS */
@@ -123,8 +122,8 @@ static void die_kmmio_nesting_error(struct pt_regs *regs, unsigned long addr)
pr_emerg("unexpected fault for address: 0x%08lx, last fault for address: 0x%08lx\n",
addr, my_reason->addr);
print_pte(addr);
- print_symbol(KERN_EMERG "faulting IP is at %s\n", regs->ip);
- print_symbol(KERN_EMERG "last faulting IP was at %s\n", my_reason->ip);
+ pr_emerg("faulting IP is at %pS\n", (void *)regs->ip);
+ pr_emerg("last faulting IP was at %pS\n", (void *)my_reason->ip);
#ifdef __i386__
pr_emerg("eax: %08lx ebx: %08lx ecx: %08lx edx: %08lx\n",
regs->ax, regs->bx, regs->cx, regs->dx);
--
2.15.1
^ permalink raw reply related
* [PATCH 09/13] drivers: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()
char buffer[KSYM_SYMBOL_LEN];
sprint_symbol(buffer, address);
printk(fmt, buffer);
Replace print_symbol() with a direct printk("%pS") call.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bf45587bcb46..36e20498159b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -20,7 +20,6 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/genhd.h>
-#include <linux/kallsyms.h>
#include <linux/mutex.h>
#include <linux/pm_runtime.h>
#include <linux/netdevice.h>
@@ -685,8 +684,8 @@ static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
- print_symbol("dev_attr_show: %s returned bad count\n",
- (unsigned long)dev_attr->show);
+ printk("dev_attr_show: %pS returned bad count\n",
+ dev_attr->show);
}
return ret;
}
--
2.15.1
^ permalink raw reply related
* [PATCH 10/13] sysfs: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()
char buffer[KSYM_SYMBOL_LEN];
sprint_symbol(buffer, address);
printk(fmt, buffer);
Replace print_symbol() with a direct printk("%pS") call.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/sysfs/file.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 39c75a86c67f..bfcbe486d385 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -12,7 +12,6 @@
#include <linux/module.h>
#include <linux/kobject.h>
-#include <linux/kallsyms.h>
#include <linux/slab.h>
#include <linux/list.h>
#include <linux/mutex.h>
@@ -70,8 +69,8 @@ static int sysfs_kf_seq_show(struct seq_file *sf, void *v)
* indicate truncated result or overflow in normal use cases.
*/
if (count >= (ssize_t)PAGE_SIZE) {
- print_symbol("fill_read_buffer: %s returned bad count\n",
- (unsigned long)ops->show);
+ printk("fill_read_buffer: %pS returned bad count\n",
+ ops->show);
/* Try to struggle along */
count = PAGE_SIZE - 1;
}
--
2.15.1
^ permalink raw reply related
* [PATCH 11/13] irq debug: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()
char buffer[KSYM_SYMBOL_LEN];
sprint_symbol(buffer, address);
printk(fmt, buffer);
Replace print_symbol() with a direct printk("%pS") call.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
kernel/irq/debug.h | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/kernel/irq/debug.h b/kernel/irq/debug.h
index 17f05ef8f575..5766e15c1160 100644
--- a/kernel/irq/debug.h
+++ b/kernel/irq/debug.h
@@ -3,8 +3,6 @@
* Debugging printout:
*/
-#include <linux/kallsyms.h>
-
#define ___P(f) if (desc->status_use_accessors & f) printk("%14s set\n", #f)
#define ___PS(f) if (desc->istate & f) printk("%14s set\n", #f)
/* FIXME */
@@ -15,13 +13,13 @@ static inline void print_irq_desc(unsigned int irq, struct irq_desc *desc)
printk("irq %d, desc: %p, depth: %d, count: %d, unhandled: %d\n",
irq, desc, desc->depth, desc->irq_count, desc->irqs_unhandled);
printk("->handle_irq(): %p, ", desc->handle_irq);
- print_symbol("%s\n", (unsigned long)desc->handle_irq);
+ pr_cont("%pS\n", desc->handle_irq);
printk("->irq_data.chip(): %p, ", desc->irq_data.chip);
- print_symbol("%s\n", (unsigned long)desc->irq_data.chip);
+ pr_cont("%pS\n", desc->irq_data.chip);
printk("->action(): %p\n", desc->action);
if (desc->action) {
printk("->action->handler(): %p, ", desc->action->handler);
- print_symbol("%s\n", (unsigned long)desc->action->handler);
+ pr_cont("%pS\n", desc->action->handler);
}
___P(IRQ_LEVEL);
--
2.15.1
^ permalink raw reply related
* [PATCH 12/13] lib: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()
char buffer[KSYM_SYMBOL_LEN];
sprint_symbol(buffer, address);
printk(fmt, buffer);
Replace print_symbol() with a direct printk("%pS") call.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
lib/smp_processor_id.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c
index 835cc6df2776..85925aaa4fff 100644
--- a/lib/smp_processor_id.c
+++ b/lib/smp_processor_id.c
@@ -5,7 +5,6 @@
* DEBUG_PREEMPT variant of smp_processor_id().
*/
#include <linux/export.h>
-#include <linux/kallsyms.h>
#include <linux/sched.h>
notrace static unsigned int check_preemption_disabled(const char *what1,
@@ -43,7 +42,7 @@ notrace static unsigned int check_preemption_disabled(const char *what1,
printk(KERN_ERR "BUG: using %s%s() in preemptible [%08x] code: %s/%d\n",
what1, what2, preempt_count() - 1, current->comm, current->pid);
- print_symbol("caller is %s\n", (long)__builtin_return_address(0));
+ printk("caller is %pS\n", __builtin_return_address(0));
dump_stack();
out_enable:
--
2.15.1
^ permalink raw reply related
* [PATCH 13/13] arc: do not use __print_symbol()
From: Sergey Senozhatsky @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
__print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()
char buffer[KSYM_SYMBOL_LEN];
sprint_symbol(buffer, address);
printk(fmt, buffer);
Replace __print_symbol() with a direct printk("%pS") call.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
---
arch/arc/kernel/stacktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index 74315f302971..bf40e06f3fb8 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -163,7 +163,7 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs,
*/
static int __print_sym(unsigned int address, void *unused)
{
- __print_symbol(" %s\n", address);
+ printk(" %pS\n", (void *)address);
return 0;
}
--
2.15.1
^ permalink raw reply related
* [kernel-hardening][PATCH] arm: hw_breakpoint: Mark variables as __ro_after_init
From: Jinbum Park @ 2017-12-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
core_num_brps, core_num_wrps, debug_arch, has_ossr,
max_watchpoint_len are setup once while init stage,
and never changed after that.
so it is good candidate for __ro_after_init.
Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
---
arch/arm/kernel/hw_breakpoint.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index af2a7f1..629e251 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -44,17 +44,17 @@
static DEFINE_PER_CPU(struct perf_event *, wp_on_reg[ARM_MAX_WRP]);
/* Number of BRP/WRP registers on this CPU. */
-static int core_num_brps;
-static int core_num_wrps;
+static int core_num_brps __ro_after_init;
+static int core_num_wrps __ro_after_init;
/* Debug architecture version. */
-static u8 debug_arch;
+static u8 debug_arch __ro_after_init;
/* Does debug architecture support OS Save and Restore? */
-static bool has_ossr;
+static bool has_ossr __ro_after_init;
/* Maximum supported watchpoint length. */
-static u8 max_watchpoint_len;
+static u8 max_watchpoint_len __ro_after_init;
#define READ_WB_REG_CASE(OP2, M, VAL) \
case ((OP2 << 4) + M): \
--
1.9.1
^ permalink raw reply related
* [PATCH 11/13] irq debug: do not use print_symbol()
From: David Laight @ 2017-12-11 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-12-sergey.senozhatsky@gmail.com>
From: Sergey Senozhatsky
> Sent: 11 December 2017 12:50
> print_symbol() uses extra stack space to sprintf() symbol
> information and then to feed that buffer to printk()
>
> char buffer[KSYM_SYMBOL_LEN];
>
> sprint_symbol(buffer, address);
> printk(fmt, buffer);
>
> Replace print_symbol() with a direct printk("%pS") call.
>
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> kernel/irq/debug.h | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/irq/debug.h b/kernel/irq/debug.h
> index 17f05ef8f575..5766e15c1160 100644
> --- a/kernel/irq/debug.h
> +++ b/kernel/irq/debug.h
...
> @@ -15,13 +13,13 @@ static inline void print_irq_desc(unsigned int irq, struct irq_desc *desc)
> printk("irq %d, desc: %p, depth: %d, count: %d, unhandled: %d\n",
> irq, desc, desc->depth, desc->irq_count, desc->irqs_unhandled);
> printk("->handle_irq(): %p, ", desc->handle_irq);
> - print_symbol("%s\n", (unsigned long)desc->handle_irq);
> + pr_cont("%pS\n", desc->handle_irq);
Looks like you can (and should) use a single printk() instead of pr_cont.
David
^ permalink raw reply
* [PATCH v3 14/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl
From: Cornelia Huck @ 2017-12-11 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-15-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:36 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move the calls to vcpu_load() and vcpu_put() in to the architecture
> specific implementations of kvm_arch_vcpu_ioctl() which dispatches
> further architecture-specific ioctls on to other functions.
>
> Some architectures support asynchronous vcpu ioctls which cannot call
> vcpu_load() or take the vcpu->mutex, because that would prevent
> concurrent execution with a running VCPU, which is the intended purpose
> of these ioctls, for example because they inject interrupts.
>
> We repeat the separate checks for these specifics in the architecture
> code for MIPS, S390 and PPC, and avoid taking the vcpu->mutex and
> calling vcpu_load for these ioctls.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/mips/kvm/mips.c | 49 +++++++++++++++++++++++----------------
> arch/powerpc/kvm/powerpc.c | 13 ++++++-----
> arch/s390/kvm/kvm-s390.c | 19 ++++++++-------
> arch/x86/kvm/x86.c | 22 +++++++++++++-----
> virt/kvm/arm/arm.c | 58 ++++++++++++++++++++++++++++++++--------------
> virt/kvm/kvm_main.c | 2 --
> 6 files changed, 103 insertions(+), 60 deletions(-)
>
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index 3a898712d6cd..4a039341dc29 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -913,56 +913,65 @@ long kvm_arch_vcpu_ioctl(struct file *filp, unsigned int ioctl,
> void __user *argp = (void __user *)arg;
> long r;
>
> + if (ioctl == KVM_INTERRUPT) {
I would add a comment here that this ioctl is async to vcpu execution,
so it is understandable why you skip the vcpu_load().
[As an aside, it is nice that this is now more obvious when looking at
the architectures' handlers.]
> + struct kvm_mips_interrupt irq;
> +
> + if (copy_from_user(&irq, argp, sizeof(irq)))
> + return -EFAULT;
> + kvm_debug("[%d] %s: irq: %d\n", vcpu->vcpu_id, __func__,
> + irq.irq);
> +
> + return kvm_vcpu_ioctl_interrupt(vcpu, &irq);
> + }
> +
> + vcpu_load(vcpu);
> +
> switch (ioctl) {
(...)
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index c06bc9552438..6b5dd3a25fe8 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -1617,16 +1617,16 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> void __user *argp = (void __user *)arg;
> long r;
>
> - switch (ioctl) {
> - case KVM_INTERRUPT: {
> + if (ioctl == KVM_INTERRUPT) {
Same here.
> struct kvm_interrupt irq;
> - r = -EFAULT;
> if (copy_from_user(&irq, argp, sizeof(irq)))
> - goto out;
> - r = kvm_vcpu_ioctl_interrupt(vcpu, &irq);
> - goto out;
> + return -EFAULT;
> + return kvm_vcpu_ioctl_interrupt(vcpu, &irq);
> }
>
> + vcpu_load(vcpu);
> +
> + switch (ioctl) {
> case KVM_ENABLE_CAP:
> {
> struct kvm_enable_cap cap;
> @@ -1666,6 +1666,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> }
>
> out:
> + vcpu_put(vcpu);
> return r;
> }
>
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 43278f334ce3..cd067b63d77f 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -3743,24 +3743,25 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> case KVM_S390_IRQ: {
> struct kvm_s390_irq s390irq;
>
> - r = -EFAULT;
> if (copy_from_user(&s390irq, argp, sizeof(s390irq)))
> - break;
> - r = kvm_s390_inject_vcpu(vcpu, &s390irq);
> - break;
> + return -EFAULT;
> + return kvm_s390_inject_vcpu(vcpu, &s390irq);
> }
> case KVM_S390_INTERRUPT: {
> struct kvm_s390_interrupt s390int;
> struct kvm_s390_irq s390irq;
>
> - r = -EFAULT;
> if (copy_from_user(&s390int, argp, sizeof(s390int)))
> - break;
> + return -EFAULT;
> if (s390int_to_s390irq(&s390int, &s390irq))
> return -EINVAL;
> - r = kvm_s390_inject_vcpu(vcpu, &s390irq);
> - break;
> + return kvm_s390_inject_vcpu(vcpu, &s390irq);
> }
> + }
I find the special casing with the immediate return a bit ugly. Maybe
introduce a helper async_vcpu_ioctl() or so that sets -ENOIOCTLCMD in
its default case and return here if ret != -ENOIOCTLCMD? Christian,
what do you think?
> +
> + vcpu_load(vcpu);
> +
> + switch (ioctl) {
> case KVM_S390_STORE_STATUS:
> idx = srcu_read_lock(&vcpu->kvm->srcu);
> r = kvm_s390_vcpu_store_status(vcpu, arg);
> @@ -3883,6 +3884,8 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> default:
> r = -ENOTTY;
> }
> +
> + vcpu_put(vcpu);
> return r;
> }
>
(...)
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 06751bbecd58..ad5f83159a15 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2693,9 +2693,7 @@ static long kvm_vcpu_ioctl(struct file *filp,
> break;
> }
> default:
> - vcpu_load(vcpu);
> r = kvm_arch_vcpu_ioctl(filp, ioctl, arg);
> - vcpu_put(vcpu);
> }
> out:
> mutex_unlock(&vcpu->mutex);
It would be nice if we could get rid of the special casing at the
beginning of this function, but as it would involve not taking the
mutex for special cases (and not releasing it for those special cases),
I don't see an elegant way to do that.
^ permalink raw reply
* [PATCH v8 00/20] ILP32 for ARM64
From: Yury Norov @ 2017-12-11 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211103230.wzg4w6eybynzh5qf@armageddon.cambridge.arm.com>
On Mon, Dec 11, 2017 at 10:32:30AM +0000, Catalin Marinas wrote:
> Hi Yury,
>
> On Thu, Nov 16, 2017 at 02:11:30PM +0300, Yury Norov wrote:
> > This is ILP32 patches on top of 4.14 kernel:
> > https://github.com/norov/linux/commits/ilp32-4.14
> >
> > I tested the series with LTP lite built by Linaro toolchain, and no
> > regressions found.
>
> Thanks. I gave it a try as well with LTP and pushed a staging/ilp32-4.14
> branch to the arm64 tree on git.kernel.org. BTW, you've added two random
> patches on top of this branch (which I removed).
Ah, it was accidentally. Removed them and force-updated the repo.
Thanks for pointing that.
> > By the way, do you have plans to upstream arch subseries?
> > https://lkml.org/lkml/2017/9/25/574
>
> I was hoping Arnd would pick them up since they are rather UAPI specific
> than arm64.
>
> BTW, I wonder whether the nds32 patches actually follow the proposed
> defaults in your patches like force_o_largefile() and get/setrlimit:
>
> https://lkml.org/lkml/2017/11/27/474
>
> (I haven't reviewed the nds32 patches in detail though)
I pulled that patches, and there's no my series.
Arnd, could you pick that? Or if you see any problems, let me know
and I'll fix them.
Yury
^ permalink raw reply
* [PATCH v2 26/36] KVM: arm64: Defer saving/restoring system registers to vcpu load/put on VHE
From: Marc Zyngier @ 2017-12-11 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207170630.592-27-christoffer.dall@linaro.org>
On 07/12/17 17:06, Christoffer Dall wrote:
> Some system registers do not affect the host kernel's execution and can
> therefore be loaded when we are about to run a VCPU and we don't have to
> restore the host state to the hardware before the time when we are
> actually about to return to userspace or schedule out the VCPU thread.
>
> The EL1 system registers and the userspace state registers, which only
> affect EL0 execution, do not affect the host kernel's execution.
>
> The 32-bit system registers are not used by a VHE host kernel and
> therefore don't need to be saved/restored on every entry/exit to/from
> the guest, but can be deferred to vcpu_load and vcpu_put, respectively.
Note that they are not used by the !VHE host kernel either, and I
believe they could be deferred too, although that would imply a round
trip to HYP to save/restore them. We already have such a hook there when
configuring ICH_VMCR_EL2, so we may not need much of a new infrastructure.
What do you think?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 11/12] cpufreq: Add module to register cpufreq on Krait CPUs
From: Sricharan R @ 2017-12-11 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211083905.GF25177@vireshk-i7>
Hi Viresh,
On 12/11/2017 2:09 PM, Viresh Kumar wrote:
> On 08-12-17, 15:12, Sricharan R wrote:
>> From: Stephen Boyd <sboyd@codeaurora.org>
>>
>> Register a cpufreq-generic device whenever we detect that a
>> "qcom,krait" compatible CPU is present in DT.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>> .../devicetree/bindings/arm/msm/qcom,pvs.txt | 38 ++++
>> drivers/cpufreq/Kconfig.arm | 9 +
>> drivers/cpufreq/Makefile | 1 +
>> drivers/cpufreq/qcom-cpufreq.c | 204 +++++++++++++++++++++
>> 4 files changed, 252 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt
>> create mode 100644 drivers/cpufreq/qcom-cpufreq.c
>
> This must be done differently as we have enhanced OPP core to support such
> hardware. Look at: dev_pm_opp_set_prop_name() and the binding around it
> (opp-microvolt-<name>). Talk to Stephen, he was part of all those discussions.
>
Thanks. Using opp-microvolt-<name> and setting the right name
extension(dev_pm_opp_set_prop_name) after reading the version
from efuse, makes it to work with proper opp-v2 bindings.
Will repost with the updates. Also with opp-v2, just not having
opp-shared property is enough to scale the cpu independently.
As you have Nacked the other patch (correctly), will drop that
patch to reintroduce the platform data. Testing this on ipq8064.
Will check with Stephen once to make sure changes hold
good for rest of the krait cores as well.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
From: Will Deacon @ 2017-12-11 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2eda3880-4542-1572-f680-9aeb820abcef@redhat.com>
On Thu, Dec 07, 2017 at 04:40:05PM -0800, Laura Abbott wrote:
> On 12/06/2017 04:35 AM, Will Deacon wrote:
> >Hi everybody,
> >
> >This is version three of the patches formerly known as KAISER (?).
> >
> > v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/542751.html
> > v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/544817.html
> >
> >Changes since v2 include:
> >
> > * Rename command-line option from "kaiser=" to "kpti=" for parity with x86
> > * Fixed Falkor erratum workaround (missing '~')
> > * Moved vectors base from literal pool into separate data page
> > * Added TTBR_ASID_MASK instead of open-coded constants
> > * Added missing newline to error message
> > * Fail to probe SPE if KPTI is enabled
> > * Addressed minor review comments
> > * Added tags
> > * Based on -rc2
> >
> >Patches are also pushed here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti
> >
> >Feedback and testing welcome. At this point, I'd like to start thinking
> >about getting this merged for 4.16.
> >
>
> You can add
>
> Tested-by: Laura Abbott <labbott@redhat.com>
Thanks, Laura!
Will
^ permalink raw reply
* [PATCH v4 12/12] cpufreq: dt: Reintroduce independent_clocks platform data
From: Sricharan R @ 2017-12-11 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211083328.GE25177@vireshk-i7>
Hi Viresh,
On 12/11/2017 2:03 PM, Viresh Kumar wrote:
> On 08-12-17, 15:12, Sricharan R wrote:
>> The Platform data was removed earlier by,
>> 'commit eb96924acddc ("cpufreq: dt: Kill platform-data")'
>> since there were no users at that time.
>> Now this is required when the each of the cpu clocks
>> can be scaled independently, which is the case
>> for krait cores. So reintroduce it.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/cpufreq/cpufreq-dt.c | 7 ++++++-
>> drivers/cpufreq/cpufreq-dt.h | 6 ++++++
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> Nack. This information should come from the OPP layer (Hint:
> dev_pm_opp_of_get_sharing_cpus()).
>
Thanks. Understand. As replied on the other patch, after using
dev_pm_opp_set_prop_name and opp-v2 bindings, this patch is no more
required.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
From: Dave Martin @ 2017-12-11 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4c6d83f1-e8f3-46d7-f3cd-af2db77e3a9c@huawei.com>
On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote:
>
> On 2017/12/11 19:59, Dave P Martin wrote:
> > On Sat, Dec 09, 2017 at 03:28:42PM +0000, Dongjiu Geng wrote:
> >> ARM v8.4 extensions include support for new floating point
> >> multiplication variant instructions to the AArch64 SIMD
> >
> > Do we have any human-readable description of what the new instructions
> > do?
> >
> > Since the v8.4 spec itself only describes these as "New Floating
> > Point Multiplication Variant", I wonder what "FHM" actually stands
> > for.
> Thanks for the point out.
> In fact, this feature only adds two instructions:
> FP16 * FP16 + FP32
> FP16 * FP16 - FP32
>
> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it
> will call "FHM", I think call it "FMLXL" may be better, which can
> stand for FMLAL/FMLSL instructions.
Although "FHM" is cryptic, I think it makes sense to keep this as "FHM"
to match the ISAR0 field name -- we've tended to follow this policy
for other extension names unless there's a much better or more obvious
name available.
For "FMLXL", new instructions might be added in the future that match
the same pattern, and then "FMLXL" could become ambiguous. So maybe
this is not the best choice.
> > Maybe something like "widening half-precision floating-point multiply
> > accumulate" is acceptable wording consistent with the existing
> > architecture, but I just made that up, so it's not official ;)
>
> how about something like "performing a multiplication of each FP16
> element of one vector with the corresponding FP16 element of a second
> vector, and to add or subtract this without an intermediate rounding
> to the corresponding FP32 element in a third vector."?
We could have that, I guess.
> >
> >> instructions set. Let the userspace know about it via a
> >> HWCAP bit and MRS emulation.
> >>
> >> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> >> ---
> >> My platform supports this feature, so I need to add it.
> >> ---
> >> Documentation/arm64/cpu-feature-registers.txt | 4 +++-
> >> arch/arm64/include/asm/sysreg.h | 1 +
> >> arch/arm64/include/uapi/asm/hwcap.h | 1 +
> >> arch/arm64/kernel/cpufeature.c | 2 ++
> >> arch/arm64/kernel/cpuinfo.c | 1 +
> >> 5 files changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt
> >> index bd9b3fa..a70090b 100644
> >> --- a/Documentation/arm64/cpu-feature-registers.txt
> >> +++ b/Documentation/arm64/cpu-feature-registers.txt
> >> @@ -110,7 +110,9 @@ infrastructure:
> >> x--------------------------------------------------x
> >> | Name | bits | visible |
> >> |--------------------------------------------------|
> >> - | RES0 | [63-48] | n |
> >> + | RES0 | [63-52] | n |
> >> + |--------------------------------------------------|
> >> + | FHM | [51-48] | y |
> >
> > You also need to update Documentation/arm64/elf_hwcaps.txt.
> I will update it, thanks for the point out
>
> >
> > Otherwise, looks OK.
> Appreciate for your review.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Masami Hiramatsu @ 2017-12-11 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211210455.170A.4A936039@socionext.com>
Hello,
2017-12-11 21:04 GMT+09:00 Kunihiko Hayashi <hayashi.kunihiko@socionext.com>:
> On Mon, 11 Dec 2017 10:19:15 +0100 Phlippe Ombredanne <pombredanne@nexb.com> wrote:
>
>> Dear Kunihiko-san,
>>
>> On Mon, Dec 11, 2017 at 8:57 AM, Kunihiko Hayashi
>> <hayashi.kunihiko@socionext.com> wrote:
>> > The UniPhier platform from Socionext provides the AVE ethernet
>> > controller that includes MAC and MDIO bus supporting RGMII/RMII
>> > modes. The controller is named AVE.
>> >
>> > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>> > Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
>> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>> [...]
>> > --- /dev/null
>> > +++ b/drivers/net/ethernet/socionext/Makefile
>> > @@ -0,0 +1,5 @@
>> > +# SPDX-License-Identifier: GPL-2.0
>>
>> You are correctly using SPDX ids here....
>>
>> > +obj-$(CONFIG_SNI_AVE) += sni_ave.o
>> > diff --git a/drivers/net/ethernet/socionext/sni_ave.c b/drivers/net/ethernet/socionext/sni_ave.c
>> > new file mode 100644
>> > index 0000000..7b293c2
>> > --- /dev/null
>> > +++ b/drivers/net/ethernet/socionext/sni_ave.c
>> > @@ -0,0 +1,1744 @@
>> > +/**
>> > + * sni_ave.c - Socionext UniPhier AVE ethernet driver
>> > + *
>> > + * Copyright 2014 Panasonic Corporation
>> > + * Copyright 2015-2017 Socionext Inc.
>> > + *
>> > + * This program is free software: you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License version 2 of
>> > + * the License as published by the Free Software Foundation.
>> > + *
>> > + * This program is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> > + * GNU General Public License for more details.
>> > + */
>>
>> ... then I guess you could also use them here, replacing at least 7
>> lines of boilerplate by a single id line?
>>
>> > +// SDPX-License-Identifier: GPL-2.0
>
> Thank you for your kindly comment.
>
> It seems there are few ethernet drivers applying SPDX-License-Identifier
> to C source, then it has been difficult for me to decide whether to replace
> boilerplate.
>
> If it's no problem to apply SPDX to sources of ethernet drivers,
> I'll replace it with the single line.
>
>> And if you go C++ style all the way, this could be even more compact:
>>
>> > +// SDPX-License-Identifier: GPL-2.0
>> > +// sni_ave.c - Socionext UniPhier AVE ethernet driver
>> > +// Copyright 2014 Panasonic Corporation
>> > +// Copyright 2015-2017 Socionext Inc.
>
> It's much simpler.
> If it's reasonable to apply this style here, I can replace it, too.
IMHO, even if we use SPDX license identifier, I recommend to use
C-style comments as many other files do, since it is C code.
If SPDX identifier requires C++ style, that is SPDX parser's issue
and should be fixed to get it from C-style comment.
https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf
Anyway, SPDX.org itself shows C-style (short header) example. See page 6.
Thank you,
>
> Thank you,
>
> ---
> Best Regards,
> Kunihiko Hayashi
>
>
--
Masami Hiramatsu
^ permalink raw reply
* [PATCH 1/6] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Arnd Bergmann @ 2017-12-11 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaKZk5N9F=_nYSzKWyXgW4xQ9Ltft7-UNM+a-nOpqq2xg@mail.gmail.com>
On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Fri, Dec 8, 2017 at 3:11 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
>
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> This patch prepares the STM32 machine for the integration of Cortex-A
>> based microprocessor (MPU), on top of the existing Cortex-M
>> microcontroller family (MCU). Since both MCUs and MPUs are sharing
>> common hardware blocks we can keep using ARCH_STM32 flag for most of
>> them. If a hardware block is specific to one family we can use either
>> ARCH_STM32_MCU or ARCH_STM32_MPU flag.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
To what degree do we need to treat them as separate families
at all then? I wonder if the MCU/MPU distinction is always that
clear along the Cortex-M/Cortex-A separation, especially if
we ever get to a chip that has both types of cores. What
exactly would we miss if we do away with the ARCH_STM32_MCU
symbol here?
> So yesterdays application processors are todays MCU processors.
>
> I said this on a lecture for control systems a while back and
> stated it as a reason I think RTOSes are not really seeing a bright
> future compared to Linux.
>
> It happened quicker than I thought though, interesting.
I think there is still lots of room for smaller RTOS in the long run,
but it's likely that the 'MPU + external DRAM' design point will
shift further to Linux, as there isn't really a benefit in squeezing
in anything smaller when the minimum is 32MB or 128MB of
RAM, depending on the interface.
For on-chip eDRAM or SRAM based MPUs, that doesn't hold
true, the memory size is what drives the cost here.
Arnd
^ permalink raw reply
* [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Russell King - ARM Linux @ 2017-12-11 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA93ih2i+G2uyL8O-4F1juR1DpUYCd1U1dBCRRM5Xdd3L-m95g@mail.gmail.com>
On Mon, Dec 11, 2017 at 10:34:17PM +0900, Masami Hiramatsu wrote:
> IMHO, even if we use SPDX license identifier, I recommend to use
> C-style comments as many other files do, since it is C code.
> If SPDX identifier requires C++ style, that is SPDX parser's issue
> and should be fixed to get it from C-style comment.
See the numerous emails on this subject already. The issue of C
vs C++ comments has come up many times by many different people, but
the result is the same. That's not going to happen. Linux kernel
C files are required to use "//" for the SPDX identifier by order
of Linus Torvalds.
Linus has also revealed in that discussion that he has a preference
for "//" style commenting for single comments, so it seems that the
kernel coding style may change - but there is no desire for patches
to "clean up" single line comments to use "//".
For further information, and to see the discussion that has already
happened, the arguments that have been made about style, see the
threads for the patch series that tglx has been posting wrt documenting
the SPDX stuff for the kernel.
Thanks (let's stop rehashing the same arguments.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Laurent Pinchart @ 2017-12-11 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208123537.18718-1-dhaval23031987@gmail.com>
Hi Dhaval,
Thank you for the patch.
On Friday, 8 December 2017 14:35:37 EET Dhaval Shah wrote:
> SPDX-License-Identifier is used for the Xilinx Video IP and
> related drivers.
>
> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> ---
> drivers/media/platform/xilinx/xilinx-dma.c | 5 +----
> drivers/media/platform/xilinx/xilinx-dma.h | 5 +----
> drivers/media/platform/xilinx/xilinx-tpg.c | 5 +----
> drivers/media/platform/xilinx/xilinx-vip.c | 5 +----
> drivers/media/platform/xilinx/xilinx-vip.h | 5 +----
> drivers/media/platform/xilinx/xilinx-vipp.c | 5 +----
> drivers/media/platform/xilinx/xilinx-vipp.h | 5 +----
> drivers/media/platform/xilinx/xilinx-vtc.c | 5 +----
> drivers/media/platform/xilinx/xilinx-vtc.h | 5 +----
How about addressing drivers/media/platform/xilinx/Makefile, drivers/media/
platform/xilinx/Kconfig and include/dt-bindings/media/xilinx-vip.h as well ?
If you're fine with that I can make the change when applying, there's no need
to resubmit the patch.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH RESEND] arm64: fault: avoid send SIGBUS two times
From: James Morse @ 2017-12-11 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2b0d31b-1831-3c76-1c57-96101abf4b6e@huawei.com>
Hi gengdongjiu,
On 08/12/17 04:43, gengdongjiu wrote:
> by the way, I think also change the info.si_code to "BUS_MCEERR_AR" is better, as shown [1].
> BUS_MCEERR_AR can tell user space "Hardware memory error consumed on a error; action required".
Today its also used as the last-resort. This signal tells user-space the page
can't be re-read from disk/swap, and its been unmapped from all affected processes.
I think using it like this (tempting as it is) changes the meaning.
> so it is better than "0". In the X86 platform, it also use the "BUS_MCEERR_AR" for si_code[2] in "arch/x86/mm/fault.c".
> what do you think about it?
This is heading into kernel-first territory, I'd prefer we do that all at once
so we know everything is covered.
> [2]:
> arch/x86/mm/fault.c:
>
> static void
> do_sigbus(struct pt_regs *regs, unsigned long error_code, unsigned long address,
> u32 *pkey, unsigned int fault)
> {
> ......
> #ifdef CONFIG_MEMORY_FAILURE
> if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
These VM_FAULT flags indicate memory_failure() has run, tried to re-read the
memory from disk/swap, failed, and unmapped the page from all affected processes.
> printk(KERN_ERR
> "MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n",
> tsk->comm, tsk->pid, address);
> code = BUS_MCEERR_AR;
> }
> #endif
> force_sig_info_fault(SIGBUS, code, address, tsk, pkey, fault);
> }
This is x86's page fault handler, not its Machine-Check-Exception handler.
arm64's page fault handler does this too, from do_page_fault():
> } else if (fault & (VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE)) {
> sig = SIGBUS;
> code = BUS_MCEERR_AR;
If you're seeing this, its likely due to the race Xie XiuQi spotted where the
recovery action has been queued, then we return to user-space before its done.
I had a go at tackling this, adding helpers to kick the assorted queues, which
we can do if we took the exception from user-space. Where I got stuck is whether
we should still force a signal, and how signals get merged. I'll try and spend
some more time on that this week.
Thanks,
James
^ permalink raw reply
* [PATCH v2 27/36] KVM: arm64: Move common VHE/non-VHE trap config in separate functions
From: Marc Zyngier @ 2017-12-11 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207170630.592-28-christoffer.dall@linaro.org>
On 07/12/17 17:06, Christoffer Dall wrote:
> As we are about to be more lazy with some of the trap configuration
> register read/writes for VHE systems, move the logic that is currently
> shared between VHE and non-VHE into a separate function which can be
> called from either the world-switch path or from vcpu_load/vcpu_put.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arch/arm64: elfcorehdr should be the first allocation
From: Will Deacon @ 2017-12-11 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512970412-5472-1-git-send-email-prabhakar.kushwaha@nxp.com>
On Mon, Dec 11, 2017 at 11:03:32AM +0530, Prabhakar Kushwaha wrote:
> From: Abhimanyu Saini <abhimanyu.saini@nxp.com>
>
> elfcorehdr_addr is assigned by kexec-utils and device tree of
> dump kernel is fixed in chosen node with parameter "linux,elfcorehdr".
> So, memory should be first reserved for elfcorehdr,
> otherwise overlaps may happen with other memory allocations
> which were done before the allocation of elcorehdr in the crash kernel
What happens in that case? Do you have a crash log we can include in
the commit message?
> Signed-off-by: Guanhua <guanhua.gao@nxp.com>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> ---
Really? How on Earth did you get three people co-developing this patch?
> arch/arm64/mm/init.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 5960bef0170d..551048cfcfff 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -453,6 +453,10 @@ void __init arm64_memblock_init(void)
> * Register the kernel text, kernel data, initrd, and initial
> * pagetables with memblock.
> */
> +
> + /* make this the first reservation so that there are no chances of
> + * overlap */
> + reserve_elfcorehdr();
> memblock_reserve(__pa_symbol(_text), _end - _text);
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> @@ -474,8 +478,6 @@ void __init arm64_memblock_init(void)
>
> reserve_crashkernel();
>
> - reserve_elfcorehdr();
Why isn't this also a problem for reserve_crashkernel() or any other
static reservations?
Will
^ permalink raw reply
* [PATCH v5 15/30] arm64/sve: Signal handling support
From: Will Deacon @ 2017-12-11 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jLO6tHm-mCPBo-csCw--+_jhLfGD_sHXCkFjmyvdame=g@mail.gmail.com>
On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrote:
> My question is mainly: why not just use copy_*() everywhere instead?
> Having these things so spread out makes it fragile, and there's very
> little performance benefit from using __copy_*() over copy_*().
I think that's more of a general question. Why not just remove the __
versions from the kernel entirely if they're not worth the perf?
Will
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox