[PATCH v2 2/4] Partially revert "KVM: Pass kvm_init()'s opaque param to additional arch funcs"
This partially reverts commit b99040853738 ("KVM: Pass kvm_init()'s opaque
param to additional arch funcs") remove opaque from
kvm_arch_check_processor_compat because no one uses this opaque now.
Address conflicts for ARM (due to file movement) and manually handle RISC-V
which comes after the commit.
And changes about kvm_arch_hardware_setup() in original commit are still
needed so they are not reverted.
Signed-off-by: Chao Gao
---
arch/arm64/kvm/arm.c | 2 +-
arch/mips/kvm/mips.c | 2 +-
arch/powerpc/kvm/powerpc.c | 2 +-
arch/riscv/kvm/main.c | 2 +-
arch/s390/kvm/kvm-s390.c | 2 +-
arch/x86/kvm/x86.c | 2 +-
include/linux/kvm_host.h | 2 +-
virt/kvm/kvm_main.c| 16 +++-
8 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 868109cf96b4..92ab3d5516ce 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -73,7 +73,7 @@ int kvm_arch_hardware_setup(void *opaque)
return 0;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return 0;
}
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index e59cb6246f76..c5dc4fe53bfc 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -140,7 +140,7 @@ int kvm_arch_hardware_setup(void *opaque)
return 0;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return 0;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2ad0ccd202d5..30c817f3fa0c 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -423,7 +423,7 @@ int kvm_arch_hardware_setup(void *opaque)
return 0;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return kvmppc_core_check_processor_compat();
}
diff --git a/arch/riscv/kvm/main.c b/arch/riscv/kvm/main.c
index 2e5ca43c8c49..992877e78393 100644
--- a/arch/riscv/kvm/main.c
+++ b/arch/riscv/kvm/main.c
@@ -20,7 +20,7 @@ long kvm_arch_dev_ioctl(struct file *filp,
return -EINVAL;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return 0;
}
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 9c6d45d0d345..99c70d881cb6 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -252,7 +252,7 @@ int kvm_arch_hardware_enable(void)
return 0;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return 0;
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f8bc1948a8b5..6f3bf78afb29 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11470,7 +11470,7 @@ void kvm_arch_hardware_unsetup(void)
static_call(kvm_x86_hardware_unsetup)();
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
struct cpuinfo_x86 *c = _data(smp_processor_id());
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 3c47b146851a..a51e9ab520fc 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1310,7 +1310,7 @@ int kvm_arch_hardware_enable(void);
void kvm_arch_hardware_disable(void);
int kvm_arch_hardware_setup(void *opaque);
void kvm_arch_hardware_unsetup(void);
-int kvm_arch_check_processor_compat(void *opaque);
+int kvm_arch_check_processor_compat(void);
int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu);
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu);
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 6e8e9d36f382..148f7169b431 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -5603,22 +5603,14 @@ struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void)
return _running_vcpu;
}
-struct kvm_cpu_compat_check {
- void *opaque;
- int *ret;
-};
-
-static void check_processor_compat(void *data)
+static void check_processor_compat(void *rtn)
{
- struct kvm_cpu_compat_check *c = data;
-
- *c->ret = kvm_arch_check_processor_compat(c->opaque);
+ *(int *)rtn = kvm_arch_check_processor_compat();
}
int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align,
struct module *module)
{
- struct kvm_cpu_compat_check c;
int r;
int cpu;
@@ -5646,10 +5638,8 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned
vcpu_align,
if (r < 0)
goto out_free_1;
- c.ret =
- c.opaque = opaque;
for_each_online_cpu(cpu) {
- smp_call_function_single(cpu, check_processor_compat, , 1);
+ smp_call_function_single(cpu, check_processor_compat, , 1);
if (r < 0)
goto out_free_2;
}
--
2.25.1
[PATCH 2/3] vstatus: Add user space API definitions for VSTATUS, NOKERNINFO and TIOCSTAT
Add definitions for the VSTATUS control character, and the NOKERNINFO
local control flag in the termios struct, and add an ioctl number for
the ioctl TIOCSTAT. Also add a default VSTATUS character (Ctrl-T)
default valuses in termios.c_cc. Do this for all architectures.
Signed-off-by: Walt Drummond
---
arch/alpha/include/asm/termios.h | 4 +--
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/alpha/include/uapi/asm/termbits.h | 34 +++--
arch/ia64/include/asm/termios.h | 4 +--
arch/ia64/include/uapi/asm/termbits.h| 34 +++--
arch/mips/include/asm/termios.h | 4 +--
arch/mips/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/termbits.h| 36 +++---
arch/parisc/include/asm/termios.h| 4 +--
arch/parisc/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/termbits.h | 34 +++--
arch/powerpc/include/asm/termios.h | 4 +--
arch/powerpc/include/uapi/asm/ioctls.h | 2 ++
arch/powerpc/include/uapi/asm/termbits.h | 34 +++--
arch/s390/include/asm/termios.h | 4 +--
arch/sh/include/uapi/asm/ioctls.h| 1 +
arch/sparc/include/uapi/asm/ioctls.h | 1 +
arch/sparc/include/uapi/asm/termbits.h | 38 +---
arch/xtensa/include/uapi/asm/ioctls.h| 1 +
include/asm-generic/termios.h| 4 +--
include/uapi/asm-generic/ioctls.h| 1 +
include/uapi/asm-generic/termbits.h | 34 +++--
22 files changed, 152 insertions(+), 129 deletions(-)
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termios.h
index b7c77bb1bfd2..d28ddc649286 100644
--- a/arch/alpha/include/asm/termios.h
+++ b/arch/alpha/include/asm/termios.h
@@ -8,9 +8,9 @@
werase=^W kill=^U reprint=^R sxtc=\0
intr=^C quit=^\ susp=^Z
start=^Qstop=^S lnext=^Vdiscard=^U
- vmin=\1 vtime=\0
+ vmin=\1 vtime=\0status=^T
*/
-#define INIT_C_CC
"\004\000\000\177\027\025\022\000\003\034\032\000\021\023\026\025\001\000"
+#define INIT_C_CC
"\004\000\000\177\027\025\022\000\003\034\032\000\021\023\026\025\001\000\024"
/*
* Translate a "termio" structure into a "termios". Ugh.
diff --git a/arch/alpha/include/uapi/asm/ioctls.h
b/arch/alpha/include/uapi/asm/ioctls.h
index 971311605288..4a092b917fc1 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -124,5 +124,6 @@
#define TIOCMIWAIT 0x545C /* wait for a change on serial input line(s) */
#define TIOCGICOUNT0x545D /* read serial port inline interrupt counts */
+#define TIOCSTAT 0x545E /* display process group stats on tty */
#endif /* _ASM_ALPHA_IOCTLS_H */
diff --git a/arch/alpha/include/uapi/asm/termbits.h
b/arch/alpha/include/uapi/asm/termbits.h
index 4575ba34a0ea..c429e60e0b64 100644
--- a/arch/alpha/include/uapi/asm/termbits.h
+++ b/arch/alpha/include/uapi/asm/termbits.h
@@ -70,6 +70,7 @@ struct ktermios {
#define VDISCARD 15
#define VMIN 16
#define VTIME 17
+#define VSTATUS 18
/* c_iflag bits */
#define IGNBRK 001
@@ -187,22 +188,23 @@ struct ktermios {
#define IBSHIFT16
/* c_lflag bits */
-#define ISIG 0x0080
-#define ICANON 0x0100
-#define XCASE 0x4000
-#define ECHO 0x0008
-#define ECHOE 0x0002
-#define ECHOK 0x0004
-#define ECHONL 0x0010
-#define NOFLSH 0x8000
-#define TOSTOP 0x0040
-#define ECHOCTL0x0040
-#define ECHOPRT0x0020
-#define ECHOKE 0x0001
-#define FLUSHO 0x0080
-#define PENDIN 0x2000
-#define IEXTEN 0x0400
-#define EXTPROC0x1000
+#define ISIG 0x0080
+#define ICANON0x0100
+#define XCASE 0x4000
+#define ECHO 0x0008
+#define ECHOE 0x0002
+#define ECHOK 0x0004
+#define ECHONL0x0010
+#define NOFLSH0x8000
+#define TOSTOP0x0040
+#define ECHOCTL 0x0040
+#define ECHOPRT 0x0020
+#define ECHOKE0x0001
+#define FLUSHO0x0080
+#define PENDIN0x2000
+#define IEXTEN0x0400
+#define EXTPROC 0x1000
+#define NOKERNINFO 0x4000
/* Values for the ACTION argument to `tcflow'. */
#defineTCOOFF 0
diff --git a/arch/ia64/include/asm/termios.h b/arch/ia64/include/asm/termios.h
index 589c026444cc..40e83f9b6ead 100644
--- a/arch/ia64/include/asm/termios.h
+++ b/arch/ia64/include/asm/termios.h
@@ -15,9 +15,9 @@
eof=^D vtime=\0vmin=\1 sxtc=\0
start=^Qstop=^S susp=^Z eol=\0
reprint=^R discard=^U werase=^W lnext=^V
- eol2=\0
+ eol2=\0 status=^T
*/
-#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0"
+#define INIT_C_CC
[PATCH 0/3] status: TTY status message request
This patchset adds TTY status message request feature to the n_tty line dicipline. This feature prints a brief message containing basic system and process group information to a user's TTY in response to a new control character in the line dicipline (default Ctrl-T) or the TIOCSTAT ioctl. The message contains the current system load, the name and PID of an interesting process in the forground process group, it's run time, percent CPU usage and RSS. An example of this message is: load: 0.31 cmd: sleep 3616843 [sleeping] 0.36r 0.00u 0.00s 0% 696k User API visible changes are limited to: - The addition of VSTATUS in termios.c_cc[] - The addition of NOKERNINFO bit in termios.l_cflags - The addition of the TIOCSTAT ioctl number None of these changes break the existing kernel api as the termios structure on all architectures has enough space in the control character array (.c_cc) for the new character, and the other changes are space agnostic. This feature is in many other Unix-like systems, both current and historical. In other implementations, this feature would also send SIGINFO to the process group; this implementation does not. Walt Drummond (3): vstatus: Allow the n_tty line dicipline to write to a user tty vstatus: Add user space API definitions for VSTATUS, NOKERNINFO and TIOCSTAT status: Display an informational message when the VSTATUS character is pressed or TIOCSTAT ioctl is called. arch/alpha/include/asm/termios.h | 4 +- arch/alpha/include/uapi/asm/ioctls.h | 1 + arch/alpha/include/uapi/asm/termbits.h | 34 ++--- arch/ia64/include/asm/termios.h | 4 +- arch/ia64/include/uapi/asm/termbits.h| 34 ++--- arch/mips/include/asm/termios.h | 4 +- arch/mips/include/uapi/asm/ioctls.h | 1 + arch/mips/include/uapi/asm/termbits.h| 36 ++--- arch/parisc/include/asm/termios.h| 4 +- arch/parisc/include/uapi/asm/ioctls.h| 1 + arch/parisc/include/uapi/asm/termbits.h | 34 ++--- arch/powerpc/include/asm/termios.h | 4 +- arch/powerpc/include/uapi/asm/ioctls.h | 2 + arch/powerpc/include/uapi/asm/termbits.h | 34 ++--- arch/s390/include/asm/termios.h | 4 +- arch/sh/include/uapi/asm/ioctls.h| 1 + arch/sparc/include/uapi/asm/ioctls.h | 1 + arch/sparc/include/uapi/asm/termbits.h | 38 +++--- arch/xtensa/include/uapi/asm/ioctls.h| 1 + drivers/tty/Makefile | 2 +- drivers/tty/n_tty.c | 113 +++- drivers/tty/n_tty_status.c | 162 +++ drivers/tty/tty_io.c | 2 +- include/asm-generic/termios.h| 4 +- include/linux/tty.h | 123 - include/uapi/asm-generic/ioctls.h| 1 + include/uapi/asm-generic/termbits.h | 34 ++--- 27 files changed, 461 insertions(+), 222 deletions(-) create mode 100644 drivers/tty/n_tty_status.c -- 2.30.2
[PATCH v2 0/4] Improve KVM's interaction with CPU hotplug
Changes from v1->v2: (all comments/suggestions on v1 are from Sean, thanks) - Merged v1's patch 2 into patch 1, and v1's patch 5 into patch 6. - Use static_call for check_processor_compatibility(). - Generate patch 2 with "git revert" and do manual changes based on that. - Loosen the WARN_ON() in kvm_arch_check_processor_compat() instead of removing it. - KVM always prevent incompatible CPUs from being brought up regardless of running VMs. - Use pr_warn instead of pr_info to emit logs when KVM finds offending CPUs. KVM registers its CPU hotplug callback to CPU starting section. And in the callback, KVM enables hardware virtualization on hotplugged CPUs if any VM is running on existing CPUs. There are two problems in the process: 1. KVM doesn't do compatibility checks before enabling hardware virtualization on hotplugged CPUs. This may cause #GP if VMX isn't supported or vmentry failure if some in-use VMX features are missing on hotplugged CPUs. Both break running VMs. 2. Callbacks in CPU STARTING section cannot fail. So, even if KVM finds some incompatible CPUs, its callback cannot block CPU hotplug. This series improves KVM's interaction with CPU hotplug to avoid incompatible CPUs breaking running VMs. Following changes are made: 1. move KVM's CPU hotplug callback to ONLINE section (suggested by Thomas) 2. do compatibility checks on hotplugged CPUs. 3. abort onlining incompatible CPUs This series is a follow-up to the discussion about KVM and CPU hotplug https://lore.kernel.org/lkml/3d3296f0-9245-40f9-1b5a-efffdb082...@redhat.com/T/ Note: this series is tested only on Intel systems. Chao Gao (4): KVM: x86: Move check_processor_compatibility from init ops to runtime ops Partially revert "KVM: Pass kvm_init()'s opaque param to additional arch funcs" KVM: Rename and move CPUHP_AP_KVM_STARTING to ONLINE section KVM: Do compatibility checks on hotplugged CPUs arch/arm64/kvm/arm.c | 2 +- arch/mips/kvm/mips.c | 2 +- arch/powerpc/kvm/powerpc.c | 2 +- arch/riscv/kvm/main.c | 2 +- arch/s390/kvm/kvm-s390.c | 2 +- arch/x86/include/asm/kvm-x86-ops.h | 1 + arch/x86/include/asm/kvm_host.h| 2 +- arch/x86/kvm/svm/svm.c | 4 +- arch/x86/kvm/vmx/evmcs.c | 2 +- arch/x86/kvm/vmx/evmcs.h | 2 +- arch/x86/kvm/vmx/vmx.c | 12 +++--- arch/x86/kvm/x86.c | 16 +--- include/linux/cpuhotplug.h | 2 +- include/linux/kvm_host.h | 2 +- virt/kvm/kvm_main.c| 62 -- 15 files changed, 71 insertions(+), 44 deletions(-) -- 2.25.1
[PATCH AUTOSEL 5.16 026/217] bpf: Change value of MAX_TAIL_CALL_CNT from 32 to 33
From: Tiezhu Yang
[ Upstream commit ebf7f6f0a6cdcc17a3da52b81e4b3a98c4005028 ]
In the current code, the actual max tail call count is 33 which is greater
than MAX_TAIL_CALL_CNT (defined as 32). The actual limit is not consistent
with the meaning of MAX_TAIL_CALL_CNT and thus confusing at first glance.
We can see the historical evolution from commit 04fd61ab36ec ("bpf: allow
bpf programs to tail-call other bpf programs") and commit f9dabe016b63
("bpf: Undo off-by-one in interpreter tail call count limit"). In order
to avoid changing existing behavior, the actual limit is 33 now, this is
reasonable.
After commit 874be05f525e ("bpf, tests: Add tail call test suite"), we can
see there exists failed testcase.
On all archs when CONFIG_BPF_JIT_ALWAYS_ON is not set:
# echo 0 > /proc/sys/net/core/bpf_jit_enable
# modprobe test_bpf
# dmesg | grep -w FAIL
Tail call error path, max count reached jited:0 ret 34 != 33 FAIL
On some archs:
# echo 1 > /proc/sys/net/core/bpf_jit_enable
# modprobe test_bpf
# dmesg | grep -w FAIL
Tail call error path, max count reached jited:1 ret 34 != 33 FAIL
Although the above failed testcase has been fixed in commit 18935a72eb25
("bpf/tests: Fix error in tail call limit tests"), it would still be good
to change the value of MAX_TAIL_CALL_CNT from 32 to 33 to make the code
more readable.
The 32-bit x86 JIT was using a limit of 32, just fix the wrong comments and
limit to 33 tail calls as the constant MAX_TAIL_CALL_CNT updated. For the
mips64 JIT, use "ori" instead of "addiu" as suggested by Johan Almbladh.
For the riscv JIT, use RV_REG_TCC directly to save one register move as
suggested by Björn Töpel. For the other implementations, no function changes,
it does not change the current limit 33, the new value of MAX_TAIL_CALL_CNT
can reflect the actual max tail call count, the related tail call testcases
in test_bpf module and selftests can work well for the interpreter and the
JIT.
Here are the test results on x86_64:
# uname -m
x86_64
# echo 0 > /proc/sys/net/core/bpf_jit_enable
# modprobe test_bpf test_suite=test_tail_calls
# dmesg | tail -1
test_bpf: test_tail_calls: Summary: 8 PASSED, 0 FAILED, [0/8 JIT'ed]
# rmmod test_bpf
# echo 1 > /proc/sys/net/core/bpf_jit_enable
# modprobe test_bpf test_suite=test_tail_calls
# dmesg | tail -1
test_bpf: test_tail_calls: Summary: 8 PASSED, 0 FAILED, [8/8 JIT'ed]
# rmmod test_bpf
# ./test_progs -t tailcalls
#142 tailcalls:OK
Summary: 1/11 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Tiezhu Yang
Signed-off-by: Daniel Borkmann
Tested-by: Johan Almbladh
Tested-by: Ilya Leoshkevich
Acked-by: Björn Töpel
Acked-by: Johan Almbladh
Acked-by: Ilya Leoshkevich
Link:
https://lore.kernel.org/bpf/1636075800-3264-1-git-send-email-yangtie...@loongson.cn
Signed-off-by: Sasha Levin
---
arch/arm/net/bpf_jit_32.c | 5 +++--
arch/arm64/net/bpf_jit_comp.c | 5 +++--
arch/mips/net/bpf_jit_comp32.c| 3 +--
arch/mips/net/bpf_jit_comp64.c| 2 +-
arch/powerpc/net/bpf_jit_comp32.c | 4 ++--
arch/powerpc/net/bpf_jit_comp64.c | 4 ++--
arch/riscv/net/bpf_jit_comp32.c | 6 ++
arch/riscv/net/bpf_jit_comp64.c | 7 +++
arch/s390/net/bpf_jit_comp.c | 6 +++---
arch/sparc/net/bpf_jit_comp_64.c | 2 +-
arch/x86/net/bpf_jit_comp.c | 10 +-
arch/x86/net/bpf_jit_comp32.c | 4 ++--
include/linux/bpf.h | 2 +-
include/uapi/linux/bpf.h | 2 +-
kernel/bpf/core.c | 3 ++-
lib/test_bpf.c| 4 ++--
tools/include/uapi/linux/bpf.h| 2 +-
17 files changed, 35 insertions(+), 36 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index eeb6dc0ecf463..e59b41e9ab0c1 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -1199,7 +1199,8 @@ static int emit_bpf_tail_call(struct jit_ctx *ctx)
/* tmp2[0] = array, tmp2[1] = index */
- /* if (tail_call_cnt > MAX_TAIL_CALL_CNT)
+ /*
+* if (tail_call_cnt >= MAX_TAIL_CALL_CNT)
* goto out;
* tail_call_cnt++;
*/
@@ -1208,7 +1209,7 @@ static int emit_bpf_tail_call(struct jit_ctx *ctx)
tc = arm_bpf_get_reg64(tcc, tmp, ctx);
emit(ARM_CMP_I(tc[0], hi), ctx);
_emit(ARM_COND_EQ, ARM_CMP_I(tc[1], lo), ctx);
- _emit(ARM_COND_HI, ARM_B(jmp_offset), ctx);
+ _emit(ARM_COND_CS, ARM_B(jmp_offset), ctx);
emit(ARM_ADDS_I(tc[1], tc[1], 1), ctx);
emit(ARM_ADC_I(tc[0], tc[0], 0), ctx);
arm_bpf_put_reg64(tcc, tmp, ctx);
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 3a8a7140a9bfb..356fb2116c6b2 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -287,13 +287,14 @@ static int emit_bpf_tail_call(struct jit_ctx *ctx)
emit(A64_CMP(0, r3, tmp), ctx);
emit(A64_B_(A64_COND_CS, jmp_offset), ctx);
- /* if (tail_call_cnt > MAX_TAIL_CALL_CNT)
+ /*
+*
Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
Excerpts from Dave Hansen's message of December 29, 2021 2:14 am:
> On 12/28/21 2:26 AM, Kefeng Wang wrote:
There are some disadvantages about this feature[2], one of the main
concerns is the possible memory fragmentation/waste in some scenarios,
also archs must ensure that any arch specific vmalloc allocations that
require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
>>> That just says that x86 *needs* PAGE_SIZE allocations. But, what
>>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)? Will the
>>> subsequent permission changes just fragment the 2M mapping?
>>
>> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping.
>>
>> When module alloc with STRICT_MODULE_RWX on x86, it calls
>> __change_page_attr()
>>
>> from set_memory_ro/rw/nx which will split large page, so there is no
>> need to make
>>
>> module alloc with HUGE_VMALLOC.
>
> This all sounds very fragile to me. Every time a new architecture would
> get added for huge vmalloc() support, the developer needs to know to go
> find that architecture's module_alloc() and add this flag.
This is documented in the Kconfig.
#
# Archs that select this would be capable of PMD-sized vmaps (i.e.,
# arch_vmap_pmd_supported() returns true), and they must make no assumptions
# that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
# can be used to prohibit arch-specific allocations from using hugepages to
# help with this (e.g., modules may require it).
#
config HAVE_ARCH_HUGE_VMALLOC
depends on HAVE_ARCH_HUGE_VMAP
bool
Is it really fair to say it's *very* fragile? Surely it's reasonable to
read the (not very long) documentation ad understand the consequences for
the arch code before enabling it.
> They next
> guy is going to forget, just like you did.
The miss here could just be a simple oversight or thinko, and caught by
review, as happens to a lot of things.
>
> Considering that this is not a hot path, a weak function would be a nice
> choice:
>
> /* vmalloc() flags used for all module allocations. */
> unsigned long __weak arch_module_vm_flags()
> {
> /*
>* Modules use a single, large vmalloc(). Different
>* permissions are applied later and will fragment
>* huge mappings. Avoid using huge pages for modules.
>*/
> return VM_NO_HUGE_VMAP;
> }
>
> Stick that in some the common module code, next to:
Then they have to think about it even less, so I don't know if that's an
improvement. I don't know what else an arch might be doing with these
allocations, at least modules will blow up pretty quickly, who knows
what other rare code relies on 4k vmalloc mappings?
The huge vmalloc option is not supposed to be easy to enable. This is
the same problem Andy was having with the TLB shootdown patches, he
didn't read the documentation and thought it was supposed to be a
trivial thing anybody could enable without thinking about it, and was
dutifully pointing out the the nasty "bugs" the feature has in it if
x86 were to enable it improperly.
Thanks,
Nick
>
>> void * __weak module_alloc(unsigned long size)
>> {
>> return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
> ...
>
> Then, put arch_module_vm_flags() in *all* of the module_alloc()
> implementations, including the generic one. That way (even with a new
> architecture) whoever copies-and-pastes their module_alloc()
> implementation is likely to get it right. The next guy who just does a
> "select HAVE_ARCH_HUGE_VMALLOC" will hopefully just work.
>
> VM_FLUSH_RESET_PERMS could probably be dealt with in the same way.
>
[PATCH] drivers/macintosh/ams: remove unneeded result variable
From: Minghao Chi
Return value from i2c_add_driver() directly instead
of taking this in another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
Signed-off-by: CGEL ZTE
---
drivers/macintosh/ams/ams-i2c.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/macintosh/ams/ams-i2c.c b/drivers/macintosh/ams/ams-i2c.c
index 21271b2e9259..d2f0cde6f9c7 100644
--- a/drivers/macintosh/ams/ams-i2c.c
+++ b/drivers/macintosh/ams/ams-i2c.c
@@ -256,8 +256,6 @@ static void ams_i2c_exit(void)
int __init ams_i2c_init(struct device_node *np)
{
- int result;
-
/* Set implementation stuff */
ams_info.of_node = np;
ams_info.exit = ams_i2c_exit;
@@ -266,7 +264,5 @@ int __init ams_i2c_init(struct device_node *np)
ams_info.clear_irq = ams_i2c_clear_irq;
ams_info.bustype = BUS_I2C;
- result = i2c_add_driver(_i2c_driver);
-
- return result;
+ return i2c_add_driver(_i2c_driver);
}
--
2.25.1
Re: [5.16.0] build error on unrecognized opcode: ptesync
It booted at least. I'll try your suggestions as soon as I can, I'm
progressing slower than ever, concentration is somewhat lapse still
Thanks.
Best regards
Michael
On Tue, Jan 11, 2022, 10:51 Christophe Leroy
wrote:
>
>
> Le 11/01/2022 à 10:32, Mike a écrit :
> > I managed to fix it in the end, patch attached, though i should have
> > done a $(call cc-option-, -maltivec, -mabi=altivec) in the
> > arch/powerpc/mm/Makefile
> > I wrongly assumed that the manual i had downloaded at 4.44am was for
> > 32bit ppc only and found ptesync to be ppc64 only.
> >
> > binutils-2.37.50 - GNU assembler version 2.37.50 (powerpc-linux-gnu)
> > using BFD version (GNU Binutils for Debian) 2.37.50.20220106
> > gcc version 11.2.0 (Debian 11.2.0-13)
> > ld.lld is missing but with LLVM/CLANG and LD=ld.bfd
> > arch/powerpc/kernel/vdso32/gettimeofday.S:72:8:
> > error: unsupported directive '.stabs'.stabs
> > "_restgpr_31_x:F-1",36,0,0,_restgpr_31_x; .globl _restgpr_31_x;
> > _restgpr_31_x:
> >
> > Attached the config i'm using, and the debian config 5.15.0-2. It's
> > still building.
>
> Ok, I tried with your config on my Fedora Core 35 where I have:
>
> powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1)
> GNU ld version 2.37-3.fc35
>
> From packages:
> - binutils-powerpc64-linux-gnu-2.37-3.fc35.x86_64
> - gcc-powerpc64-linux-gnu-11.2.1-1.fc35.x86_64
>
> And I don't have the problems you mention, so it must be something
> special with Debian GCC.
>
>
> Your change regarding ptesync is probably OK but is fragile I think,
> because for instance there is also a 'ptesync' in
> arch/powerpc/mm/pageattr.c and probably many other places.
>
> Also please prefer CONFIG_PPC64 to __powerpc64__
>
> Regarding the DSSALL issue, the following commit will probably help:
>
> d51f86cfd8e3 ("powerpc/mm: Switch obsolete dssall to .long")
>
> Regarding the .stabs with LLVM there is a patch at
>
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/68932ec2ba6b868d35006b96e90f0890f3da3c05.1638273868.git.christophe.le...@csgroup.eu/
>
> Thanks
> Christophe
>
>
>
> >
> > Cheers
> > Michael
> >
> > On Tue, 11 Jan 2022 at 07:20, Christophe Leroy
> > wrote:
> >>
> >>
> >>
> >> Le 10/01/2022 à 13:32, Mike a écrit :
> >>> Hey, so I originally sat down to compile the fast headers V2 patch, but
> >>> quickly discovered other things at play, and grabbed 5.16.0 a few hours
> >>> after it lifted off, arch/powerpc/mm/mmu_context.c I had to
> >>> specifically say had to include -maltivec or it barfed on a 'dssall',
> >>> I'm fine with that, I've spent years in kernel land, I can deal with
> >>> that, then came arch/powerpc/lib/step.c with the ptesync. This seems
> >>> like a totally normal instruction that shouldn't need any extra flags
> or
> >>> anything, yet the assembler throws up, and no flag I can think of fixes
> >>> it. This is a G4 7447. I reverted back to the Debian 5.15. defconfig
> >>> before dropping this mail as I had tweaked my config to be more G4.
> >>>
> >>
> >> Hi Mike,
> >>
> >> Can you provide a bit more details about your setup and config ?
> >>
> >> Are you using GCC or LLVM ?
> >> What version of GCC and BINUTILS or what version of LLVM ?
> >>
> >> What is DEBIAN defconfig ? Does it correspond to one of the standard
> >> mainline kernel defconfigs ? If not can you provide it ?
> >>
> >> Thanks
> >> Christophe
