BUG: unable to handle kernel paging request in corrupted

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
c18bb396d3d261ebbb4efbc05129c5d354c541e4 (Tue Apr 10 00:04:10 2018 +)
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=bb6ed94ce15c5cd0be00


syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6361086471176192
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5146710238035968
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-1223000601505858474

compiler: gcc (GCC) 8.0.1 20180301 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bb6ed94ce15c5cd0b...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
BUG: unable to handle kernel paging request at 5b63
PGD 1b67b2067 P4D 1b67b2067 PUD 1b67b3067 PMD 0
Oops: 0002 [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4510 Comm: syz-executor5 Not tainted 4.16.0+ #18
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

==
BUG: KASAN: out-of-bounds in vsnprintf+0x1a3b/0x1b40 lib/vsprintf.c:2315
Read of size 8 at addr -02 � ���e �6 �  a by task syz-executor5/4510

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#2] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4510 Comm: syz-executor5 Not tainted 4.16.0+ #18
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: b08e6540:die_lock+0x0/0x4
RSP: b08e6568:81b2a8f1 EFLAGS: 8801b08e61e8 ORIG_RAX:  
ed003611cc58

RAX: 110842bc RBX: 8801db021849 RCX: 874b04e3
RDX:  RSI: 874b02f9 RDI: 0001
RBP: 8801b08e6568 R08: 8801c322e040 R09: ed003b6042bc
R10: ed003b6042bc R11: 8801db0215e3 R12: 884215e0
R13: ed003611cc58 R14: 898d54ec R15: 8801b08e6540
FS:  7ff89fb7d700() GS:8801db00() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 5b63 CR3: 0001b67b1000 CR4: 001426f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 <01> 00 00 00  
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

RIP: die_lock+0x0/0x4 RSP: 81b2a8f1
---[ end trace 4c7524c29b994875 ]---


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

BUG: unable to handle kernel paging request in corrupted

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
c18bb396d3d261ebbb4efbc05129c5d354c541e4 (Tue Apr 10 00:04:10 2018 +)
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=bb6ed94ce15c5cd0be00


syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6361086471176192
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5146710238035968
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-1223000601505858474

compiler: gcc (GCC) 8.0.1 20180301 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bb6ed94ce15c5cd0b...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
BUG: unable to handle kernel paging request at 5b63
PGD 1b67b2067 P4D 1b67b2067 PUD 1b67b3067 PMD 0
Oops: 0002 [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4510 Comm: syz-executor5 Not tainted 4.16.0+ #18
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

==
BUG: KASAN: out-of-bounds in vsnprintf+0x1a3b/0x1b40 lib/vsprintf.c:2315
Read of size 8 at addr -02 � ���e �6 �  a by task syz-executor5/4510

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#2] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4510 Comm: syz-executor5 Not tainted 4.16.0+ #18
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: b08e6540:die_lock+0x0/0x4
RSP: b08e6568:81b2a8f1 EFLAGS: 8801b08e61e8 ORIG_RAX:  
ed003611cc58

RAX: 110842bc RBX: 8801db021849 RCX: 874b04e3
RDX:  RSI: 874b02f9 RDI: 0001
RBP: 8801b08e6568 R08: 8801c322e040 R09: ed003b6042bc
R10: ed003b6042bc R11: 8801db0215e3 R12: 884215e0
R13: ed003611cc58 R14: 898d54ec R15: 8801b08e6540
FS:  7ff89fb7d700() GS:8801db00() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 5b63 CR3: 0001b67b1000 CR4: 001426f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 <01> 00 00 00  
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

RIP: die_lock+0x0/0x4 RSP: 81b2a8f1
---[ end trace 4c7524c29b994875 ]---


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

instant reboot caused by 194a9749c73d650c0

[Eric Dumazet]

Hi Kirill

For some reason, my hosts instantly crash at boot time, with absolutely no log 
on console.

Bisection pointed to :

$ git bisect bad
194a9749c73d650c0b1dfdee04fb0bdf0a888ba8 is the first bad commit
commit 194a9749c73d650c0b1dfdee04fb0bdf0a888ba8
Author: Kirill A. Shutemov 
Date:   Mon Mar 12 13:02:46 2018 +0300

x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

This patch addresses a shortcoming in current boot process on machines
that supports 5-level paging.

If a bootloader enables 64-bit mode with 4-level paging, we might need to
switch over to 5-level paging. The switching requires the disabling
paging. It works fine if kernel itself is loaded below 4G.

But if the bootloader put the kernel above 4G (not sure if anybody does
this), we would lose control as soon as paging is disabled, because the
code becomes unreachable to the CPU.

This patch implements a trampoline in lower memory to handle this
situation.

We only need the memory for a very short time, until the main kernel
image sets up own page tables.

We go through the trampoline even if we don't have to: if we're already
in 5-level paging mode or if we don't need to switch to it. This way the
trampoline gets tested on every boot.

Signed-off-by: Kirill A. Shutemov 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Cyrill Gorcunov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Matthew Wilcox 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux...@kvack.org
Link: 
http://lkml.kernel.org/r/20180312100246.89175-5-kirill.shute...@linux.intel.com
Signed-off-by: Ingo Molnar 


Reverting this patch solves the problem for me.

Thanks.

instant reboot caused by 194a9749c73d650c0

[Eric Dumazet]

Hi Kirill

For some reason, my hosts instantly crash at boot time, with absolutely no log 
on console.

Bisection pointed to :

$ git bisect bad
194a9749c73d650c0b1dfdee04fb0bdf0a888ba8 is the first bad commit
commit 194a9749c73d650c0b1dfdee04fb0bdf0a888ba8
Author: Kirill A. Shutemov 
Date:   Mon Mar 12 13:02:46 2018 +0300

x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

This patch addresses a shortcoming in current boot process on machines
that supports 5-level paging.

If a bootloader enables 64-bit mode with 4-level paging, we might need to
switch over to 5-level paging. The switching requires the disabling
paging. It works fine if kernel itself is loaded below 4G.

But if the bootloader put the kernel above 4G (not sure if anybody does
this), we would lose control as soon as paging is disabled, because the
code becomes unreachable to the CPU.

This patch implements a trampoline in lower memory to handle this
situation.

We only need the memory for a very short time, until the main kernel
image sets up own page tables.

We go through the trampoline even if we don't have to: if we're already
in 5-level paging mode or if we don't need to switch to it. This way the
trampoline gets tested on every boot.

Signed-off-by: Kirill A. Shutemov 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Cyrill Gorcunov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Matthew Wilcox 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux...@kvack.org
Link: 
http://lkml.kernel.org/r/20180312100246.89175-5-kirill.shute...@linux.intel.com
Signed-off-by: Ingo Molnar 


Reverting this patch solves the problem for me.

Thanks.

[PATCH] ARM: dts: rockchip: disable arm_global_timer for rk3066a

[Yaodong Liu]

The arm_global_timer provides unstable clock to sched_clock, it will
be selected by default instead of rockchip_timer. The same issue has
been fixed in rk3188.

So we must disable arm_global_timer to get the correct clocksource.

Signed-off-by: Yaodong Liu 
---
 arch/arm/boot/dts/rk3066a.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 06523ca..1920f93 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -749,3 +749,7 @@
  {
compatible = "rockchip,rk3066-emac";
 };
+
+_timer {
+   status = "disabled";
+};
-- 
2.7.4

[PATCH] ARM: dts: rockchip: disable arm_global_timer for rk3066a

[Yaodong Liu]

The arm_global_timer provides unstable clock to sched_clock, it will
be selected by default instead of rockchip_timer. The same issue has
been fixed in rk3188.

So we must disable arm_global_timer to get the correct clocksource.

Signed-off-by: Yaodong Liu 
---
 arch/arm/boot/dts/rk3066a.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 06523ca..1920f93 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -749,3 +749,7 @@
  {
compatible = "rockchip,rk3066-emac";
 };
+
+_timer {
+   status = "disabled";
+};
-- 
2.7.4

[PATCH v2] x86/cpufeature: guard asm_volatile_goto usage with NO_BPF_WORKAROUND

[Yonghong Song]

Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always
use __always_inline function _static_cpu_has() funciton.
The static_cpu_has() uses gcc feature asm_volatile_goto construct,
which is not supported by clang.

Currently, for BPF programs written in C, the only widely-supported
compiler is clang. Because of clang lacking support
of asm_volatile_goto construct, if you try to compile
bpf programs under samples/bpf/,
   $ make -j20 && make headers_install && make samples/bpf/
you will see a lot of failures like below:

  =
  clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include \
 -I/home/yhs/work/bpf-next/arch/x86/include \
 -I./arch/x86/include/generated  -I/home/yhs/work/bpf-next/include \
 -I./include -I/home/yhs/work/bpf-next/arch/x86/include/uapi \
 -I./arch/x86/include/generated/uapi \
 -I/home/yhs/work/bpf-next/include/uapi -I./include/generated/uapi \
 -include /home/yhs/work/bpf-next/include/linux/kconfig.h
 -Isamples/bpf \
 -I/home/yhs/work/bpf-next/tools/testing/selftests/bpf/ \
 -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
 -D__TARGET_ARCH_x86 -Wno-compare-distinct-pointer-types \
 -Wno-gnu-variable-sized-type-not-at-end \
 -Wno-address-of-packed-member -Wno-tautological-compare \
 -Wno-unknown-warning-option  \
 -O2 -emit-llvm -c 
/home/yhs/work/bpf-next/samples/bpf/xdp_redirect_cpu_kern.c \
 -o -| llc -march=bpf -filetype=obj -o 
samples/bpf/xdp_redirect_cpu_kern.o
  In file included from 
/home/yhs/work/bpf-next/samples/bpf/xdp_redirect_cpu_kern.c:10:
  In file included from /home/yhs/work/bpf-next/include/uapi/linux/in.h:24:
  In file included from /home/yhs/work/bpf-next/include/linux/socket.h:8:
  In file included from /home/yhs/work/bpf-next/include/linux/uio.h:13:
  In file included from /home/yhs/work/bpf-next/include/linux/thread_info.h:38:
  In file included from 
/home/yhs/work/bpf-next/arch/x86/include/asm/thread_info.h:53:
  /home/yhs/work/bpf-next/arch/x86/include/asm/cpufeature.h:150:2: error: 'asm 
goto' constructs are not supported yet
asm_volatile_goto("1: jmp 6f\n"
^
  /home/yhs/work/bpf-next/include/linux/compiler-gcc.h:296:42: note: expanded 
from macro 'asm_volatile_goto'
  #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
   ^
  1 error generated.
  =
  ...
  In file included from /home/yhs/work/bpf-next/samples/bpf/tracex4_kern.c:7:
  In file included from /home/yhs/work/bpf-next/include/linux/ptrace.h:6:
  In file included from /home/yhs/work/bpf-next/include/linux/sched.h:14:
  In file included from /home/yhs/work/bpf-next/include/linux/pid.h:5:
  In file included from /home/yhs/work/bpf-next/include/linux/rculist.h:11:
  In file included from /home/yhs/work/bpf-next/include/linux/rcupdate.h:40:
  In file included from /home/yhs/work/bpf-next/include/linux/preempt.h:81:
  In file included from 
/home/yhs/work/bpf-next/arch/x86/include/asm/preempt.h:7:
  In file included from /home/yhs/work/bpf-next/include/linux/thread_info.h:38:
  In file included from 
/home/yhs/work/bpf-next/arch/x86/include/asm/thread_info.h:53:
  /home/yhs/work/bpf-next/arch/x86/include/asm/cpufeature.h:150:2: error: 'asm 
goto' constructs are not supported yet
  ...
  =

This patch adds a preprocessor guard NO_BPF_WORKAROUND around the
asm_volatile_goto based static_cpu_has(). NO_BPF_WORKAROUND is set
at toplevel Makefile when compiler supports asm-goto. That is,
if the compiler supports asm-goto, the kernel build will use
asm-goto version of static_cpu_has().

For clang compilation for bpf programs where only header files
are accessed, NO_BPF_WORKAROUND is not defined and asm-goto version
of static_cpu_has() will not be accessed, hence the above compilation
error will disappear.

If later clang compiler starts to support asm_volatile_goto,
the change in this patch can be reverted.

Fixes: d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
Suggested-by: Alexei Starovoitov 
Signed-off-by: Yonghong Song 
---
 Makefile  | 1 +
 arch/x86/include/asm/cpufeature.h | 5 +
 2 files changed, 6 insertions(+)

Changelog:
 v1 -> v2:
   Use NO_BPF_WORKAROUND macro instead of CC_HAVE_ASM_GOTO
   to make it explicit that this is a workaround.

diff --git a/Makefile b/Makefile
index c1a608a..7b81f1f 100644
--- a/Makefile
+++ b/Makefile
@@ -504,6 +504,7 @@ export RETPOLINE_CFLAGS
 ifeq ($(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) 
$(KBUILD_CFLAGS)), y)
   CC_HAVE_ASM_GOTO := 1
   KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
+  KBUILD_CFLAGS += -DNO_BPF_WORKAROUND
   KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
 endif
 
diff --git a/arch/x86/include/asm/cpufeature.h 

[PATCH v2] x86/cpufeature: guard asm_volatile_goto usage with NO_BPF_WORKAROUND

[Yonghong Song]

Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always
use __always_inline function _static_cpu_has() funciton.
The static_cpu_has() uses gcc feature asm_volatile_goto construct,
which is not supported by clang.

Currently, for BPF programs written in C, the only widely-supported
compiler is clang. Because of clang lacking support
of asm_volatile_goto construct, if you try to compile
bpf programs under samples/bpf/,
   $ make -j20 && make headers_install && make samples/bpf/
you will see a lot of failures like below:

  =
  clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include \
 -I/home/yhs/work/bpf-next/arch/x86/include \
 -I./arch/x86/include/generated  -I/home/yhs/work/bpf-next/include \
 -I./include -I/home/yhs/work/bpf-next/arch/x86/include/uapi \
 -I./arch/x86/include/generated/uapi \
 -I/home/yhs/work/bpf-next/include/uapi -I./include/generated/uapi \
 -include /home/yhs/work/bpf-next/include/linux/kconfig.h
 -Isamples/bpf \
 -I/home/yhs/work/bpf-next/tools/testing/selftests/bpf/ \
 -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
 -D__TARGET_ARCH_x86 -Wno-compare-distinct-pointer-types \
 -Wno-gnu-variable-sized-type-not-at-end \
 -Wno-address-of-packed-member -Wno-tautological-compare \
 -Wno-unknown-warning-option  \
 -O2 -emit-llvm -c 
/home/yhs/work/bpf-next/samples/bpf/xdp_redirect_cpu_kern.c \
 -o -| llc -march=bpf -filetype=obj -o 
samples/bpf/xdp_redirect_cpu_kern.o
  In file included from 
/home/yhs/work/bpf-next/samples/bpf/xdp_redirect_cpu_kern.c:10:
  In file included from /home/yhs/work/bpf-next/include/uapi/linux/in.h:24:
  In file included from /home/yhs/work/bpf-next/include/linux/socket.h:8:
  In file included from /home/yhs/work/bpf-next/include/linux/uio.h:13:
  In file included from /home/yhs/work/bpf-next/include/linux/thread_info.h:38:
  In file included from 
/home/yhs/work/bpf-next/arch/x86/include/asm/thread_info.h:53:
  /home/yhs/work/bpf-next/arch/x86/include/asm/cpufeature.h:150:2: error: 'asm 
goto' constructs are not supported yet
asm_volatile_goto("1: jmp 6f\n"
^
  /home/yhs/work/bpf-next/include/linux/compiler-gcc.h:296:42: note: expanded 
from macro 'asm_volatile_goto'
  #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
   ^
  1 error generated.
  =
  ...
  In file included from /home/yhs/work/bpf-next/samples/bpf/tracex4_kern.c:7:
  In file included from /home/yhs/work/bpf-next/include/linux/ptrace.h:6:
  In file included from /home/yhs/work/bpf-next/include/linux/sched.h:14:
  In file included from /home/yhs/work/bpf-next/include/linux/pid.h:5:
  In file included from /home/yhs/work/bpf-next/include/linux/rculist.h:11:
  In file included from /home/yhs/work/bpf-next/include/linux/rcupdate.h:40:
  In file included from /home/yhs/work/bpf-next/include/linux/preempt.h:81:
  In file included from 
/home/yhs/work/bpf-next/arch/x86/include/asm/preempt.h:7:
  In file included from /home/yhs/work/bpf-next/include/linux/thread_info.h:38:
  In file included from 
/home/yhs/work/bpf-next/arch/x86/include/asm/thread_info.h:53:
  /home/yhs/work/bpf-next/arch/x86/include/asm/cpufeature.h:150:2: error: 'asm 
goto' constructs are not supported yet
  ...
  =

This patch adds a preprocessor guard NO_BPF_WORKAROUND around the
asm_volatile_goto based static_cpu_has(). NO_BPF_WORKAROUND is set
at toplevel Makefile when compiler supports asm-goto. That is,
if the compiler supports asm-goto, the kernel build will use
asm-goto version of static_cpu_has().

For clang compilation for bpf programs where only header files
are accessed, NO_BPF_WORKAROUND is not defined and asm-goto version
of static_cpu_has() will not be accessed, hence the above compilation
error will disappear.

If later clang compiler starts to support asm_volatile_goto,
the change in this patch can be reverted.

Fixes: d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
Suggested-by: Alexei Starovoitov 
Signed-off-by: Yonghong Song 
---
 Makefile  | 1 +
 arch/x86/include/asm/cpufeature.h | 5 +
 2 files changed, 6 insertions(+)

Changelog:
 v1 -> v2:
   Use NO_BPF_WORKAROUND macro instead of CC_HAVE_ASM_GOTO
   to make it explicit that this is a workaround.

diff --git a/Makefile b/Makefile
index c1a608a..7b81f1f 100644
--- a/Makefile
+++ b/Makefile
@@ -504,6 +504,7 @@ export RETPOLINE_CFLAGS
 ifeq ($(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) 
$(KBUILD_CFLAGS)), y)
   CC_HAVE_ASM_GOTO := 1
   KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
+  KBUILD_CFLAGS += -DNO_BPF_WORKAROUND
   KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
 endif
 
diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index b27da96..638417b 

drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: 'values[0]' is used uninitialized in this function

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   18b7fd1c93e5204355ddbf2608a097d64df81b88
commit: 5d1ebbda0318b1ba55eaa1fae3fd867af17b0774 phy: mapphone-mdm6600: Add USB 
PHY driver for MDM6600 on Droid 4
date:   4 weeks ago
config: x86_64-randconfig-a0-04151127 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 5d1ebbda0318b1ba55eaa1fae3fd867af17b0774
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/phy/motorola/phy-mapphone-mdm6600.c: In function 
'phy_mdm6600_status':
>> drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: 'values[0]' is 
>> used uninitialized in this function [-Wuninitialized]
  val |= values[i] << i;
 ~~^~~
   drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: 'values[1]' is 
used uninitialized in this function [-Wuninitialized]
   drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: 'values[2]' is 
used uninitialized in this function [-Wuninitialized]

vim +188 drivers/phy/motorola/phy-mapphone-mdm6600.c

   166  
   167  /**
   168   * phy_mdm6600_status() - read mdm6600 status lines
   169   * @ddata: device driver data
   170   */
   171  static void phy_mdm6600_status(struct work_struct *work)
   172  {
   173  struct phy_mdm6600 *ddata;
   174  struct device *dev;
   175  int values[PHY_MDM6600_NR_STATUS_LINES];
   176  int error, i, val = 0;
   177  
   178  ddata = container_of(work, struct phy_mdm6600, 
status_work.work);
   179  dev = ddata->dev;
   180  
   181  error = gpiod_get_array_value_cansleep(PHY_MDM6600_NR_CMD_LINES,
   182 
ddata->status_gpios->desc,
   183 values);
   184  if (error)
   185  return;
   186  
   187  for (i = 0; i < PHY_MDM6600_NR_CMD_LINES; i++) {
 > 188  val |= values[i] << i;
   189  dev_dbg(ddata->dev, "XXX %s: i: %i values[i]: %i val: 
%i\n",
   190  __func__, i, values[i], val);
   191  }
   192  ddata->status = val;
   193  
   194  dev_info(dev, "modem status: %i %s\n",
   195   ddata->status,
   196   phy_mdm6600_status_name[ddata->status & 7]);
   197  complete(>ack);
   198  }
   199  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: 'values[0]' is used uninitialized in this function

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   18b7fd1c93e5204355ddbf2608a097d64df81b88
commit: 5d1ebbda0318b1ba55eaa1fae3fd867af17b0774 phy: mapphone-mdm6600: Add USB 
PHY driver for MDM6600 on Droid 4
date:   4 weeks ago
config: x86_64-randconfig-a0-04151127 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 5d1ebbda0318b1ba55eaa1fae3fd867af17b0774
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/phy/motorola/phy-mapphone-mdm6600.c: In function 
'phy_mdm6600_status':
>> drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: 'values[0]' is 
>> used uninitialized in this function [-Wuninitialized]
  val |= values[i] << i;
 ~~^~~
   drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: 'values[1]' is 
used uninitialized in this function [-Wuninitialized]
   drivers/phy/motorola/phy-mapphone-mdm6600.c:188:16: warning: 'values[2]' is 
used uninitialized in this function [-Wuninitialized]

vim +188 drivers/phy/motorola/phy-mapphone-mdm6600.c

   166  
   167  /**
   168   * phy_mdm6600_status() - read mdm6600 status lines
   169   * @ddata: device driver data
   170   */
   171  static void phy_mdm6600_status(struct work_struct *work)
   172  {
   173  struct phy_mdm6600 *ddata;
   174  struct device *dev;
   175  int values[PHY_MDM6600_NR_STATUS_LINES];
   176  int error, i, val = 0;
   177  
   178  ddata = container_of(work, struct phy_mdm6600, 
status_work.work);
   179  dev = ddata->dev;
   180  
   181  error = gpiod_get_array_value_cansleep(PHY_MDM6600_NR_CMD_LINES,
   182 
ddata->status_gpios->desc,
   183 values);
   184  if (error)
   185  return;
   186  
   187  for (i = 0; i < PHY_MDM6600_NR_CMD_LINES; i++) {
 > 188  val |= values[i] << i;
   189  dev_dbg(ddata->dev, "XXX %s: i: %i values[i]: %i val: 
%i\n",
   190  __func__, i, values[i], val);
   191  }
   192  ddata->status = val;
   193  
   194  dev_info(dev, "modem status: %i %s\n",
   195   ddata->status,
   196   phy_mdm6600_status_name[ddata->status & 7]);
   197  complete(>ack);
   198  }
   199  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH 4/4] x86/crypto: twofish: Fix function prototypes

[Joao Moreira]

Convert the use of 'struct twofish_ctx *' to 'void *' in prototypes of
functions which are referenced through 'struct common_glue_func_entry',
making their prototypes match those of this struct and, consequently,
turning them compatible with CFI requirements.

Whenever needed, cast 'void *' to 'struct twofish_ctx *'.

Signed-off-by: João Moreira 
---
 arch/x86/crypto/twofish_avx_glue.c| 30 +-
 arch/x86/crypto/twofish_glue.c|  7 +++
 arch/x86/crypto/twofish_glue_3way.c   | 10 --
 arch/x86/include/asm/crypto/twofish.h |  9 +++--
 4 files changed, 23 insertions(+), 33 deletions(-)

diff --git a/arch/x86/crypto/twofish_avx_glue.c 
b/arch/x86/crypto/twofish_avx_glue.c
index b7a3904b953c..916a4904fa25 100644
--- a/arch/x86/crypto/twofish_avx_glue.c
+++ b/arch/x86/crypto/twofish_avx_glue.c
@@ -46,25 +46,21 @@
 #define TWOFISH_PARALLEL_BLOCKS 8
 
 /* 8-way parallel cipher functions */
-asmlinkage void twofish_ecb_enc_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src);
-asmlinkage void twofish_ecb_dec_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src);
-
-asmlinkage void twofish_cbc_dec_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src);
-asmlinkage void twofish_ctr_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
-
-asmlinkage void twofish_xts_enc_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
-asmlinkage void twofish_xts_dec_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
-
-static inline void twofish_enc_blk_3way(struct twofish_ctx *ctx, u8 *dst,
+asmlinkage void twofish_ecb_enc_8way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void twofish_ecb_dec_8way(void *ctx, u8 *dst, const u8 *src);
+
+asmlinkage void twofish_cbc_dec_8way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void twofish_ctr_8way(void *ctx, u8 *dst, const u8 *src, le128 *iv);
+
+asmlinkage void twofish_xts_enc_8way(void *ctx, u8 *dst, const u8 *src,
+le128 *iv);
+asmlinkage void twofish_xts_dec_8way(void *ctx, u8 *dst, const u8 *src,
+le128 *iv);
+
+static inline void twofish_enc_blk_3way(void *ctx, u8 *dst,
const u8 *src)
 {
-   __twofish_enc_blk_3way(ctx, dst, src, false);
+   __twofish_enc_blk_3way((struct twofish_ctx *) ctx, dst, src, false);
 }
 
 static void twofish_xts_enc(void *ctx, u128 *dst, const u128 *src, le128 *iv)
diff --git a/arch/x86/crypto/twofish_glue.c b/arch/x86/crypto/twofish_glue.c
index 77e06c2da83d..3dee618c2dd2 100644
--- a/arch/x86/crypto/twofish_glue.c
+++ b/arch/x86/crypto/twofish_glue.c
@@ -44,11 +44,10 @@
 #include 
 #include 
 
-asmlinkage void twofish_enc_blk(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src);
+asmlinkage void twofish_enc_blk(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(twofish_enc_blk);
-asmlinkage void twofish_dec_blk(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src);
+
+asmlinkage void twofish_dec_blk(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(twofish_dec_blk);
 
 static void twofish_encrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
diff --git a/arch/x86/crypto/twofish_glue_3way.c 
b/arch/x86/crypto/twofish_glue_3way.c
index 243e90a4b5d9..ce25be1bc260 100644
--- a/arch/x86/crypto/twofish_glue_3way.c
+++ b/arch/x86/crypto/twofish_glue_3way.c
@@ -36,16 +36,14 @@
 EXPORT_SYMBOL_GPL(__twofish_enc_blk_3way);
 EXPORT_SYMBOL_GPL(twofish_dec_blk_3way);
 
-static inline void twofish_enc_blk_3way(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src)
+static inline void twofish_enc_blk_3way(void *ctx, u8 *dst, const u8 *src)
 {
-   __twofish_enc_blk_3way(ctx, dst, src, false);
+   __twofish_enc_blk_3way((struct twofish_ctx *) ctx, dst, src, false);
 }
 
-static inline void twofish_enc_blk_xor_3way(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src)
+static inline void twofish_enc_blk_xor_3way(void *ctx, u8 *dst, const u8 *src)
 {
-   __twofish_enc_blk_3way(ctx, dst, src, true);
+   __twofish_enc_blk_3way((struct twofish_ctx *) ctx, dst, src, true);
 }
 
 void twofish_dec_blk_cbc_3way(void *ctx, u128 *dst, const u128 *src)
diff --git a/arch/x86/include/asm/crypto/twofish.h 
b/arch/x86/include/asm/crypto/twofish.h
index 65bb80adba3e..871eaa7bacdc 100644
--- a/arch/x86/include/asm/crypto/twofish.h
+++ b/arch/x86/include/asm/crypto/twofish.h
@@ -18,16 +18,13 @@ struct twofish_xts_ctx {
 };
 
 /* regular block cipher functions from twofish_x86_64 module */
-asmlinkage void twofish_enc_blk(struct twofish_ctx *ctx, u8 *dst,
-   const u8 

[PATCH 0/4] x86/crypto: Fix function prototypes

[Joao Moreira]

It is possible to indirectly invoke functions with prototypes that do not
match those of the respectively used function pointers by using void types.
This feature is frequently used as a way of relaxing function invocation,
making it possible that different data structures are passed to different
functions through the same pointer.

Despite the benefits, this can lead to a situation where functions with a
given prototype are invoked by pointers with a different prototype, what is
undesirable as it may prevent the use of heuristics such as prototype
matching-based Control-Flow Integrity, which can be used to prevent
ROP-based attacks.

One way of fixing this situation is through converting the function
prototypes to the one used in the pointer declaration, what means converting
function arguments from a given ' *' to a 'void *', and later casting
its uses accordingly throughout the function scope.

Given the above, the current efforts to improve the Linux security, and the
upcoming kernel support to compilers with CFI features, fix prototypes in
x86/crypto algorithms: camellia, cast6, serpent, and twofish.

This patch does not introduce semantic changes to the cryptographic
algorithms, yet, if someone finds relevant, the affected algorithms were
tested with the help of tcrypt.ko without any visible harm.

Joao Moreira (4):
  x86/crypto: camellia: Fix function prototypes
  x86/crypto: cast6: Fix function prototypes
  x86/crypto: serpent: Fix function prototypes
  x86/crypto: twofish: Fix function prototypes

 arch/x86/crypto/camellia_aesni_avx2_glue.c | 25 -
 arch/x86/crypto/camellia_aesni_avx_glue.c  | 21 +++
 arch/x86/crypto/camellia_glue.c|  6 ++---
 arch/x86/crypto/cast6_avx_glue.c   | 22 ++-
 arch/x86/crypto/serpent_avx2_glue.c| 14 +-
 arch/x86/crypto/serpent_avx_glue.c | 19 ++---
 arch/x86/crypto/twofish_avx_glue.c | 30 +
 arch/x86/crypto/twofish_glue.c |  7 +++--
 arch/x86/crypto/twofish_glue_3way.c| 10 +++
 arch/x86/include/asm/crypto/camellia.h | 43 +-
 arch/x86/include/asm/crypto/serpent-avx.h  | 25 -
 arch/x86/include/asm/crypto/serpent-sse2.h | 30 +
 arch/x86/include/asm/crypto/twofish.h  |  9 +++
 13 files changed, 108 insertions(+), 153 deletions(-)

-- 
2.12.0

[PATCH 4/4] x86/crypto: twofish: Fix function prototypes

[Joao Moreira]

Convert the use of 'struct twofish_ctx *' to 'void *' in prototypes of
functions which are referenced through 'struct common_glue_func_entry',
making their prototypes match those of this struct and, consequently,
turning them compatible with CFI requirements.

Whenever needed, cast 'void *' to 'struct twofish_ctx *'.

Signed-off-by: João Moreira 
---
 arch/x86/crypto/twofish_avx_glue.c| 30 +-
 arch/x86/crypto/twofish_glue.c|  7 +++
 arch/x86/crypto/twofish_glue_3way.c   | 10 --
 arch/x86/include/asm/crypto/twofish.h |  9 +++--
 4 files changed, 23 insertions(+), 33 deletions(-)

diff --git a/arch/x86/crypto/twofish_avx_glue.c 
b/arch/x86/crypto/twofish_avx_glue.c
index b7a3904b953c..916a4904fa25 100644
--- a/arch/x86/crypto/twofish_avx_glue.c
+++ b/arch/x86/crypto/twofish_avx_glue.c
@@ -46,25 +46,21 @@
 #define TWOFISH_PARALLEL_BLOCKS 8
 
 /* 8-way parallel cipher functions */
-asmlinkage void twofish_ecb_enc_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src);
-asmlinkage void twofish_ecb_dec_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src);
-
-asmlinkage void twofish_cbc_dec_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src);
-asmlinkage void twofish_ctr_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
-
-asmlinkage void twofish_xts_enc_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
-asmlinkage void twofish_xts_dec_8way(struct twofish_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
-
-static inline void twofish_enc_blk_3way(struct twofish_ctx *ctx, u8 *dst,
+asmlinkage void twofish_ecb_enc_8way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void twofish_ecb_dec_8way(void *ctx, u8 *dst, const u8 *src);
+
+asmlinkage void twofish_cbc_dec_8way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void twofish_ctr_8way(void *ctx, u8 *dst, const u8 *src, le128 *iv);
+
+asmlinkage void twofish_xts_enc_8way(void *ctx, u8 *dst, const u8 *src,
+le128 *iv);
+asmlinkage void twofish_xts_dec_8way(void *ctx, u8 *dst, const u8 *src,
+le128 *iv);
+
+static inline void twofish_enc_blk_3way(void *ctx, u8 *dst,
const u8 *src)
 {
-   __twofish_enc_blk_3way(ctx, dst, src, false);
+   __twofish_enc_blk_3way((struct twofish_ctx *) ctx, dst, src, false);
 }
 
 static void twofish_xts_enc(void *ctx, u128 *dst, const u128 *src, le128 *iv)
diff --git a/arch/x86/crypto/twofish_glue.c b/arch/x86/crypto/twofish_glue.c
index 77e06c2da83d..3dee618c2dd2 100644
--- a/arch/x86/crypto/twofish_glue.c
+++ b/arch/x86/crypto/twofish_glue.c
@@ -44,11 +44,10 @@
 #include 
 #include 
 
-asmlinkage void twofish_enc_blk(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src);
+asmlinkage void twofish_enc_blk(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(twofish_enc_blk);
-asmlinkage void twofish_dec_blk(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src);
+
+asmlinkage void twofish_dec_blk(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(twofish_dec_blk);
 
 static void twofish_encrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
diff --git a/arch/x86/crypto/twofish_glue_3way.c 
b/arch/x86/crypto/twofish_glue_3way.c
index 243e90a4b5d9..ce25be1bc260 100644
--- a/arch/x86/crypto/twofish_glue_3way.c
+++ b/arch/x86/crypto/twofish_glue_3way.c
@@ -36,16 +36,14 @@
 EXPORT_SYMBOL_GPL(__twofish_enc_blk_3way);
 EXPORT_SYMBOL_GPL(twofish_dec_blk_3way);
 
-static inline void twofish_enc_blk_3way(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src)
+static inline void twofish_enc_blk_3way(void *ctx, u8 *dst, const u8 *src)
 {
-   __twofish_enc_blk_3way(ctx, dst, src, false);
+   __twofish_enc_blk_3way((struct twofish_ctx *) ctx, dst, src, false);
 }
 
-static inline void twofish_enc_blk_xor_3way(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src)
+static inline void twofish_enc_blk_xor_3way(void *ctx, u8 *dst, const u8 *src)
 {
-   __twofish_enc_blk_3way(ctx, dst, src, true);
+   __twofish_enc_blk_3way((struct twofish_ctx *) ctx, dst, src, true);
 }
 
 void twofish_dec_blk_cbc_3way(void *ctx, u128 *dst, const u128 *src)
diff --git a/arch/x86/include/asm/crypto/twofish.h 
b/arch/x86/include/asm/crypto/twofish.h
index 65bb80adba3e..871eaa7bacdc 100644
--- a/arch/x86/include/asm/crypto/twofish.h
+++ b/arch/x86/include/asm/crypto/twofish.h
@@ -18,16 +18,13 @@ struct twofish_xts_ctx {
 };
 
 /* regular block cipher functions from twofish_x86_64 module */
-asmlinkage void twofish_enc_blk(struct twofish_ctx *ctx, u8 *dst,
-   const u8 *src);

[PATCH 0/4] x86/crypto: Fix function prototypes

[Joao Moreira]

It is possible to indirectly invoke functions with prototypes that do not
match those of the respectively used function pointers by using void types.
This feature is frequently used as a way of relaxing function invocation,
making it possible that different data structures are passed to different
functions through the same pointer.

Despite the benefits, this can lead to a situation where functions with a
given prototype are invoked by pointers with a different prototype, what is
undesirable as it may prevent the use of heuristics such as prototype
matching-based Control-Flow Integrity, which can be used to prevent
ROP-based attacks.

One way of fixing this situation is through converting the function
prototypes to the one used in the pointer declaration, what means converting
function arguments from a given ' *' to a 'void *', and later casting
its uses accordingly throughout the function scope.

Given the above, the current efforts to improve the Linux security, and the
upcoming kernel support to compilers with CFI features, fix prototypes in
x86/crypto algorithms: camellia, cast6, serpent, and twofish.

This patch does not introduce semantic changes to the cryptographic
algorithms, yet, if someone finds relevant, the affected algorithms were
tested with the help of tcrypt.ko without any visible harm.

Joao Moreira (4):
  x86/crypto: camellia: Fix function prototypes
  x86/crypto: cast6: Fix function prototypes
  x86/crypto: serpent: Fix function prototypes
  x86/crypto: twofish: Fix function prototypes

 arch/x86/crypto/camellia_aesni_avx2_glue.c | 25 -
 arch/x86/crypto/camellia_aesni_avx_glue.c  | 21 +++
 arch/x86/crypto/camellia_glue.c|  6 ++---
 arch/x86/crypto/cast6_avx_glue.c   | 22 ++-
 arch/x86/crypto/serpent_avx2_glue.c| 14 +-
 arch/x86/crypto/serpent_avx_glue.c | 19 ++---
 arch/x86/crypto/twofish_avx_glue.c | 30 +
 arch/x86/crypto/twofish_glue.c |  7 +++--
 arch/x86/crypto/twofish_glue_3way.c| 10 +++
 arch/x86/include/asm/crypto/camellia.h | 43 +-
 arch/x86/include/asm/crypto/serpent-avx.h  | 25 -
 arch/x86/include/asm/crypto/serpent-sse2.h | 30 +
 arch/x86/include/asm/crypto/twofish.h  |  9 +++
 13 files changed, 108 insertions(+), 153 deletions(-)

-- 
2.12.0

[PATCH 3/4] x86/crypto: serpent: Fix function prototypes

[Joao Moreira]

Convert the use of 'struct serpent_ctx *' to 'void *' in prototypes of
functions which are referenced through 'struct common_glue_func_entry',
making their prototypes match those of this struct and, consequently,
turning them compatible with CFI requirements.

Whenever needed, cast 'void *' to 'struct serpent_ctx *'.

Signed-off-by: João Moreira 
---
 arch/x86/crypto/serpent_avx2_glue.c| 14 ++
 arch/x86/crypto/serpent_avx_glue.c | 19 ---
 arch/x86/include/asm/crypto/serpent-avx.h  | 25 +++--
 arch/x86/include/asm/crypto/serpent-sse2.h | 30 --
 4 files changed, 37 insertions(+), 51 deletions(-)

diff --git a/arch/x86/crypto/serpent_avx2_glue.c 
b/arch/x86/crypto/serpent_avx2_glue.c
index 870f6d812a2d..17d89b4521ac 100644
--- a/arch/x86/crypto/serpent_avx2_glue.c
+++ b/arch/x86/crypto/serpent_avx2_glue.c
@@ -27,18 +27,16 @@
 #define SERPENT_AVX2_PARALLEL_BLOCKS 16
 
 /* 16-way AVX2 parallel cipher functions */
-asmlinkage void serpent_ecb_enc_16way(struct serpent_ctx *ctx, u8 *dst,
- const u8 *src);
-asmlinkage void serpent_ecb_dec_16way(struct serpent_ctx *ctx, u8 *dst,
- const u8 *src);
+asmlinkage void serpent_ecb_enc_16way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void serpent_ecb_dec_16way(void *ctx, u8 *dst, const u8 *src);
 asmlinkage void serpent_cbc_dec_16way(void *ctx, u128 *dst, const u128 *src);
 
 asmlinkage void serpent_ctr_16way(void *ctx, u128 *dst, const u128 *src,
  le128 *iv);
-asmlinkage void serpent_xts_enc_16way(struct serpent_ctx *ctx, u8 *dst,
- const u8 *src, le128 *iv);
-asmlinkage void serpent_xts_dec_16way(struct serpent_ctx *ctx, u8 *dst,
- const u8 *src, le128 *iv);
+asmlinkage void serpent_xts_enc_16way(void *ctx, u8 *dst, const u8 *src,
+ le128 *iv);
+asmlinkage void serpent_xts_dec_16way(void *ctx, u8 *dst, const u8 *src,
+ le128 *iv);
 
 static const struct common_glue_ctx serpent_enc = {
.num_funcs = 3,
diff --git a/arch/x86/crypto/serpent_avx_glue.c 
b/arch/x86/crypto/serpent_avx_glue.c
index 6f778d3daa22..0d234458a734 100644
--- a/arch/x86/crypto/serpent_avx_glue.c
+++ b/arch/x86/crypto/serpent_avx_glue.c
@@ -41,28 +41,25 @@
 #include 
 
 /* 8-way parallel cipher functions */
-asmlinkage void serpent_ecb_enc_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
+asmlinkage void serpent_ecb_enc_8way_avx(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(serpent_ecb_enc_8way_avx);
 
-asmlinkage void serpent_ecb_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
+asmlinkage void serpent_ecb_dec_8way_avx(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(serpent_ecb_dec_8way_avx);
 
-asmlinkage void serpent_cbc_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
+asmlinkage void serpent_cbc_dec_8way_avx(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(serpent_cbc_dec_8way_avx);
 
-asmlinkage void serpent_ctr_8way_avx(struct serpent_ctx *ctx, u8 *dst,
+asmlinkage void serpent_ctr_8way_avx(void *ctx, u8 *dst,
 const u8 *src, le128 *iv);
 EXPORT_SYMBOL_GPL(serpent_ctr_8way_avx);
 
-asmlinkage void serpent_xts_enc_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
+asmlinkage void serpent_xts_enc_8way_avx(void *ctx, u8 *dst, const u8 *src,
+le128 *iv);
 EXPORT_SYMBOL_GPL(serpent_xts_enc_8way_avx);
 
-asmlinkage void serpent_xts_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
+asmlinkage void serpent_xts_dec_8way_avx(void *ctx, u8 *dst, const u8 *src,
+le128 *iv);
 EXPORT_SYMBOL_GPL(serpent_xts_dec_8way_avx);
 
 void __serpent_crypt_ctr(void *ctx, u128 *dst, const u128 *src, le128 *iv)
diff --git a/arch/x86/include/asm/crypto/serpent-avx.h 
b/arch/x86/include/asm/crypto/serpent-avx.h
index c958b7bd0fcb..c92cb0cc1f8b 100644
--- a/arch/x86/include/asm/crypto/serpent-avx.h
+++ b/arch/x86/include/asm/crypto/serpent-avx.h
@@ -17,20 +17,17 @@ struct serpent_xts_ctx {
struct serpent_ctx crypt_ctx;
 };
 
-asmlinkage void serpent_ecb_enc_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
-asmlinkage void serpent_ecb_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
-
-asmlinkage void serpent_cbc_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
-asmlinkage void 

[PATCH 1/4] x86/crypto: camellia: Fix function prototypes

[Joao Moreira]

Convert the use of 'struct camellia_ctx *' to 'void *' in prototypes of
functions which are referenced through 'struct common_glue_func_entry',
making their prototypes match those of this struct and, consequently,
turning them compatible with CFI requirements.

Whenever needed, cast 'void *' to 'struct camellia_ctx *'.

Signed-off-by: João Moreira 
---
 arch/x86/crypto/camellia_aesni_avx2_glue.c | 25 -
 arch/x86/crypto/camellia_aesni_avx_glue.c  | 21 +++
 arch/x86/crypto/camellia_glue.c|  6 ++---
 arch/x86/include/asm/crypto/camellia.h | 43 +-
 4 files changed, 40 insertions(+), 55 deletions(-)

diff --git a/arch/x86/crypto/camellia_aesni_avx2_glue.c 
b/arch/x86/crypto/camellia_aesni_avx2_glue.c
index 60907c139c4e..6fe248ee5efa 100644
--- a/arch/x86/crypto/camellia_aesni_avx2_glue.c
+++ b/arch/x86/crypto/camellia_aesni_avx2_glue.c
@@ -27,20 +27,17 @@
 #define CAMELLIA_AESNI_AVX2_PARALLEL_BLOCKS 32
 
 /* 32-way AVX2/AES-NI parallel cipher functions */
-asmlinkage void camellia_ecb_enc_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
-asmlinkage void camellia_ecb_dec_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
-
-asmlinkage void camellia_cbc_dec_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
-asmlinkage void camellia_ctr_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
-
-asmlinkage void camellia_xts_enc_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
-asmlinkage void camellia_xts_dec_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void camellia_ecb_enc_32way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void camellia_ecb_dec_32way(void *ctx, u8 *dst, const u8 *src);
+
+asmlinkage void camellia_cbc_dec_32way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void camellia_ctr_32way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
+
+asmlinkage void camellia_xts_enc_32way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
+asmlinkage void camellia_xts_dec_32way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
 
 static const struct common_glue_ctx camellia_enc = {
.num_funcs = 4,
diff --git a/arch/x86/crypto/camellia_aesni_avx_glue.c 
b/arch/x86/crypto/camellia_aesni_avx_glue.c
index d96429da88eb..3ccfd75b4af4 100644
--- a/arch/x86/crypto/camellia_aesni_avx_glue.c
+++ b/arch/x86/crypto/camellia_aesni_avx_glue.c
@@ -26,28 +26,25 @@
 #define CAMELLIA_AESNI_PARALLEL_BLOCKS 16
 
 /* 16-way parallel cipher functions (avx/aes-ni) */
-asmlinkage void camellia_ecb_enc_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
+asmlinkage void camellia_ecb_enc_16way(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(camellia_ecb_enc_16way);
 
-asmlinkage void camellia_ecb_dec_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
+asmlinkage void camellia_ecb_dec_16way(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(camellia_ecb_dec_16way);
 
-asmlinkage void camellia_cbc_dec_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
+asmlinkage void camellia_cbc_dec_16way(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(camellia_cbc_dec_16way);
 
-asmlinkage void camellia_ctr_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void camellia_ctr_16way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
 EXPORT_SYMBOL_GPL(camellia_ctr_16way);
 
-asmlinkage void camellia_xts_enc_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void camellia_xts_enc_16way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
 EXPORT_SYMBOL_GPL(camellia_xts_enc_16way);
 
-asmlinkage void camellia_xts_dec_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void camellia_xts_dec_16way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
 EXPORT_SYMBOL_GPL(camellia_xts_dec_16way);
 
 void camellia_xts_enc(void *ctx, u128 *dst, const u128 *src, le128 *iv)
diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index af4840ab2a3d..0942b3998de5 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -39,16 +39,14 @@
 asmlinkage void __camellia_enc_blk(struct camellia_ctx *ctx, u8 *dst,
   const u8 *src, bool xor);
 

[PATCH 3/4] x86/crypto: serpent: Fix function prototypes

[Joao Moreira]

Convert the use of 'struct serpent_ctx *' to 'void *' in prototypes of
functions which are referenced through 'struct common_glue_func_entry',
making their prototypes match those of this struct and, consequently,
turning them compatible with CFI requirements.

Whenever needed, cast 'void *' to 'struct serpent_ctx *'.

Signed-off-by: João Moreira 
---
 arch/x86/crypto/serpent_avx2_glue.c| 14 ++
 arch/x86/crypto/serpent_avx_glue.c | 19 ---
 arch/x86/include/asm/crypto/serpent-avx.h  | 25 +++--
 arch/x86/include/asm/crypto/serpent-sse2.h | 30 --
 4 files changed, 37 insertions(+), 51 deletions(-)

diff --git a/arch/x86/crypto/serpent_avx2_glue.c 
b/arch/x86/crypto/serpent_avx2_glue.c
index 870f6d812a2d..17d89b4521ac 100644
--- a/arch/x86/crypto/serpent_avx2_glue.c
+++ b/arch/x86/crypto/serpent_avx2_glue.c
@@ -27,18 +27,16 @@
 #define SERPENT_AVX2_PARALLEL_BLOCKS 16
 
 /* 16-way AVX2 parallel cipher functions */
-asmlinkage void serpent_ecb_enc_16way(struct serpent_ctx *ctx, u8 *dst,
- const u8 *src);
-asmlinkage void serpent_ecb_dec_16way(struct serpent_ctx *ctx, u8 *dst,
- const u8 *src);
+asmlinkage void serpent_ecb_enc_16way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void serpent_ecb_dec_16way(void *ctx, u8 *dst, const u8 *src);
 asmlinkage void serpent_cbc_dec_16way(void *ctx, u128 *dst, const u128 *src);
 
 asmlinkage void serpent_ctr_16way(void *ctx, u128 *dst, const u128 *src,
  le128 *iv);
-asmlinkage void serpent_xts_enc_16way(struct serpent_ctx *ctx, u8 *dst,
- const u8 *src, le128 *iv);
-asmlinkage void serpent_xts_dec_16way(struct serpent_ctx *ctx, u8 *dst,
- const u8 *src, le128 *iv);
+asmlinkage void serpent_xts_enc_16way(void *ctx, u8 *dst, const u8 *src,
+ le128 *iv);
+asmlinkage void serpent_xts_dec_16way(void *ctx, u8 *dst, const u8 *src,
+ le128 *iv);
 
 static const struct common_glue_ctx serpent_enc = {
.num_funcs = 3,
diff --git a/arch/x86/crypto/serpent_avx_glue.c 
b/arch/x86/crypto/serpent_avx_glue.c
index 6f778d3daa22..0d234458a734 100644
--- a/arch/x86/crypto/serpent_avx_glue.c
+++ b/arch/x86/crypto/serpent_avx_glue.c
@@ -41,28 +41,25 @@
 #include 
 
 /* 8-way parallel cipher functions */
-asmlinkage void serpent_ecb_enc_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
+asmlinkage void serpent_ecb_enc_8way_avx(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(serpent_ecb_enc_8way_avx);
 
-asmlinkage void serpent_ecb_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
+asmlinkage void serpent_ecb_dec_8way_avx(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(serpent_ecb_dec_8way_avx);
 
-asmlinkage void serpent_cbc_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
+asmlinkage void serpent_cbc_dec_8way_avx(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(serpent_cbc_dec_8way_avx);
 
-asmlinkage void serpent_ctr_8way_avx(struct serpent_ctx *ctx, u8 *dst,
+asmlinkage void serpent_ctr_8way_avx(void *ctx, u8 *dst,
 const u8 *src, le128 *iv);
 EXPORT_SYMBOL_GPL(serpent_ctr_8way_avx);
 
-asmlinkage void serpent_xts_enc_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
+asmlinkage void serpent_xts_enc_8way_avx(void *ctx, u8 *dst, const u8 *src,
+le128 *iv);
 EXPORT_SYMBOL_GPL(serpent_xts_enc_8way_avx);
 
-asmlinkage void serpent_xts_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src, le128 *iv);
+asmlinkage void serpent_xts_dec_8way_avx(void *ctx, u8 *dst, const u8 *src,
+le128 *iv);
 EXPORT_SYMBOL_GPL(serpent_xts_dec_8way_avx);
 
 void __serpent_crypt_ctr(void *ctx, u128 *dst, const u128 *src, le128 *iv)
diff --git a/arch/x86/include/asm/crypto/serpent-avx.h 
b/arch/x86/include/asm/crypto/serpent-avx.h
index c958b7bd0fcb..c92cb0cc1f8b 100644
--- a/arch/x86/include/asm/crypto/serpent-avx.h
+++ b/arch/x86/include/asm/crypto/serpent-avx.h
@@ -17,20 +17,17 @@ struct serpent_xts_ctx {
struct serpent_ctx crypt_ctx;
 };
 
-asmlinkage void serpent_ecb_enc_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
-asmlinkage void serpent_ecb_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
-
-asmlinkage void serpent_cbc_dec_8way_avx(struct serpent_ctx *ctx, u8 *dst,
-const u8 *src);
-asmlinkage void 

[PATCH 1/4] x86/crypto: camellia: Fix function prototypes

[Joao Moreira]

Convert the use of 'struct camellia_ctx *' to 'void *' in prototypes of
functions which are referenced through 'struct common_glue_func_entry',
making their prototypes match those of this struct and, consequently,
turning them compatible with CFI requirements.

Whenever needed, cast 'void *' to 'struct camellia_ctx *'.

Signed-off-by: João Moreira 
---
 arch/x86/crypto/camellia_aesni_avx2_glue.c | 25 -
 arch/x86/crypto/camellia_aesni_avx_glue.c  | 21 +++
 arch/x86/crypto/camellia_glue.c|  6 ++---
 arch/x86/include/asm/crypto/camellia.h | 43 +-
 4 files changed, 40 insertions(+), 55 deletions(-)

diff --git a/arch/x86/crypto/camellia_aesni_avx2_glue.c 
b/arch/x86/crypto/camellia_aesni_avx2_glue.c
index 60907c139c4e..6fe248ee5efa 100644
--- a/arch/x86/crypto/camellia_aesni_avx2_glue.c
+++ b/arch/x86/crypto/camellia_aesni_avx2_glue.c
@@ -27,20 +27,17 @@
 #define CAMELLIA_AESNI_AVX2_PARALLEL_BLOCKS 32
 
 /* 32-way AVX2/AES-NI parallel cipher functions */
-asmlinkage void camellia_ecb_enc_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
-asmlinkage void camellia_ecb_dec_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
-
-asmlinkage void camellia_cbc_dec_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
-asmlinkage void camellia_ctr_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
-
-asmlinkage void camellia_xts_enc_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
-asmlinkage void camellia_xts_dec_32way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void camellia_ecb_enc_32way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void camellia_ecb_dec_32way(void *ctx, u8 *dst, const u8 *src);
+
+asmlinkage void camellia_cbc_dec_32way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void camellia_ctr_32way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
+
+asmlinkage void camellia_xts_enc_32way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
+asmlinkage void camellia_xts_dec_32way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
 
 static const struct common_glue_ctx camellia_enc = {
.num_funcs = 4,
diff --git a/arch/x86/crypto/camellia_aesni_avx_glue.c 
b/arch/x86/crypto/camellia_aesni_avx_glue.c
index d96429da88eb..3ccfd75b4af4 100644
--- a/arch/x86/crypto/camellia_aesni_avx_glue.c
+++ b/arch/x86/crypto/camellia_aesni_avx_glue.c
@@ -26,28 +26,25 @@
 #define CAMELLIA_AESNI_PARALLEL_BLOCKS 16
 
 /* 16-way parallel cipher functions (avx/aes-ni) */
-asmlinkage void camellia_ecb_enc_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
+asmlinkage void camellia_ecb_enc_16way(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(camellia_ecb_enc_16way);
 
-asmlinkage void camellia_ecb_dec_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
+asmlinkage void camellia_ecb_dec_16way(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(camellia_ecb_dec_16way);
 
-asmlinkage void camellia_cbc_dec_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src);
+asmlinkage void camellia_cbc_dec_16way(void *ctx, u8 *dst, const u8 *src);
 EXPORT_SYMBOL_GPL(camellia_cbc_dec_16way);
 
-asmlinkage void camellia_ctr_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void camellia_ctr_16way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
 EXPORT_SYMBOL_GPL(camellia_ctr_16way);
 
-asmlinkage void camellia_xts_enc_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void camellia_xts_enc_16way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
 EXPORT_SYMBOL_GPL(camellia_xts_enc_16way);
 
-asmlinkage void camellia_xts_dec_16way(struct camellia_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void camellia_xts_dec_16way(void *ctx, u8 *dst, const u8 *src,
+  le128 *iv);
 EXPORT_SYMBOL_GPL(camellia_xts_dec_16way);
 
 void camellia_xts_enc(void *ctx, u128 *dst, const u128 *src, le128 *iv)
diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index af4840ab2a3d..0942b3998de5 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -39,16 +39,14 @@
 asmlinkage void __camellia_enc_blk(struct camellia_ctx *ctx, u8 *dst,
   const u8 *src, bool xor);
 

[PATCH 2/4] x86/crypto: cast6: Fix function prototypes

[Joao Moreira]

Convert the use of 'struct cast6_ctx *' to 'void *' in prototypes of
functions which are referenced through 'struct common_glue_func_entry',
making their prototypes match those of this struct and, consequently,
turning them compatible with CFI requirements.

Signed-off-by: João Moreira 
---
 arch/x86/crypto/cast6_avx_glue.c | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/arch/x86/crypto/cast6_avx_glue.c b/arch/x86/crypto/cast6_avx_glue.c
index 50e684768c55..f4e05388fbbb 100644
--- a/arch/x86/crypto/cast6_avx_glue.c
+++ b/arch/x86/crypto/cast6_avx_glue.c
@@ -41,20 +41,16 @@
 
 #define CAST6_PARALLEL_BLOCKS 8
 
-asmlinkage void cast6_ecb_enc_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src);
-asmlinkage void cast6_ecb_dec_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src);
-
-asmlinkage void cast6_cbc_dec_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src);
-asmlinkage void cast6_ctr_8way(struct cast6_ctx *ctx, u8 *dst, const u8 *src,
-  le128 *iv);
-
-asmlinkage void cast6_xts_enc_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
-asmlinkage void cast6_xts_dec_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void cast6_ecb_enc_8way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void cast6_ecb_dec_8way(void *ctx, u8 *dst, const u8 *src);
+
+asmlinkage void cast6_cbc_dec_8way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void cast6_ctr_8way(void *ctx, u8 *dst, const u8 *src, le128 *iv);
+
+asmlinkage void cast6_xts_enc_8way(void *ctx, u8 *dst, const u8 *src,
+ le128 *iv);
+asmlinkage void cast6_xts_dec_8way(void *ctx, u8 *dst, const u8 *src,
+ le128 *iv);
 
 static void cast6_xts_enc(void *ctx, u128 *dst, const u128 *src, le128 *iv)
 {
-- 
2.12.0

[PATCH 2/4] x86/crypto: cast6: Fix function prototypes

[Joao Moreira]

Convert the use of 'struct cast6_ctx *' to 'void *' in prototypes of
functions which are referenced through 'struct common_glue_func_entry',
making their prototypes match those of this struct and, consequently,
turning them compatible with CFI requirements.

Signed-off-by: João Moreira 
---
 arch/x86/crypto/cast6_avx_glue.c | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/arch/x86/crypto/cast6_avx_glue.c b/arch/x86/crypto/cast6_avx_glue.c
index 50e684768c55..f4e05388fbbb 100644
--- a/arch/x86/crypto/cast6_avx_glue.c
+++ b/arch/x86/crypto/cast6_avx_glue.c
@@ -41,20 +41,16 @@
 
 #define CAST6_PARALLEL_BLOCKS 8
 
-asmlinkage void cast6_ecb_enc_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src);
-asmlinkage void cast6_ecb_dec_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src);
-
-asmlinkage void cast6_cbc_dec_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src);
-asmlinkage void cast6_ctr_8way(struct cast6_ctx *ctx, u8 *dst, const u8 *src,
-  le128 *iv);
-
-asmlinkage void cast6_xts_enc_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
-asmlinkage void cast6_xts_dec_8way(struct cast6_ctx *ctx, u8 *dst,
-  const u8 *src, le128 *iv);
+asmlinkage void cast6_ecb_enc_8way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void cast6_ecb_dec_8way(void *ctx, u8 *dst, const u8 *src);
+
+asmlinkage void cast6_cbc_dec_8way(void *ctx, u8 *dst, const u8 *src);
+asmlinkage void cast6_ctr_8way(void *ctx, u8 *dst, const u8 *src, le128 *iv);
+
+asmlinkage void cast6_xts_enc_8way(void *ctx, u8 *dst, const u8 *src,
+ le128 *iv);
+asmlinkage void cast6_xts_dec_8way(void *ctx, u8 *dst, const u8 *src,
+ le128 *iv);
 
 static void cast6_xts_enc(void *ctx, u128 *dst, const u128 *src, le128 *iv)
 {
-- 
2.12.0

Re: [RFCv3 15/17] v4l2: document the request API interface

[Randy Dunlap]

Hi,

A few comments below...

On 02/06/2018 05:48 PM, Alexandre Courbot wrote:
> Document how the request API can be used along with the existing V4L2
> interface.
> 
> Signed-off-by: Alexandre Courbot 
> ---
>  Documentation/media/uapi/v4l/buffer.rst|  10 +-
>  Documentation/media/uapi/v4l/common.rst|   1 +
>  Documentation/media/uapi/v4l/request-api.rst   | 236 
> +
>  .../media/uapi/v4l/vidioc-g-ext-ctrls.rst  |  16 +-
>  Documentation/media/uapi/v4l/vidioc-qbuf.rst   |  21 ++
>  5 files changed, 280 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/media/uapi/v4l/request-api.rst


> diff --git a/Documentation/media/uapi/v4l/request-api.rst 
> b/Documentation/media/uapi/v4l/request-api.rst
> new file mode 100644
> index ..4c61a0dbe3a9
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/request-api.rst
> @@ -0,0 +1,236 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _media-request-api:
> +
> +Request API
> +===
> +
> +The Request API has been designed to allow V4L2 to deal with requirements of
> +modern devices (stateless codecs, MIPI cameras, ...) and APIs (Android Codec
> +v2). One such requirement is the ability for devices belonging to the same
> +pipeline to reconfigure and collaborate closely on a per-frame basis. 
> Another is
> +efficient support of stateless codecs, which need per-frame controls to be 
> set
> +asynchronously in order to be efficiently used.

   to be used efficiently.

> +
> +Supporting these features without the Request API is possible but terribly
> +inefficient: user-space would have to flush all activity on the media 
> pipeline,
> +reconfigure it for the next frame, queue the buffers to be processed with 
> that
> +configuration, and wait until they are all available for dequeing before

"dequeing" should be dequeueing or dequeuing.

> +considering the next frame. This defeats the purpose of having buffer queues
> +since in practice only one buffer would be queued at a time.
> +
> +The Request API allows a specific configuration of the pipeline (media
> +controller topology + controls for each device) to be associated with 
> specific
> +buffers. The parameters are applied by each participating device as buffers
> +associated to a request flow in. This allows user-space to schedule several
> +tasks ("requests") with different parameters in advance, knowing that the
> +parameters will be applied when needed to get the expected result. Controls
> +values at the time of request completion are also available for reading.
> +
> +Usage
> +=
> +
> +The Request API is used on top of standard media controller and V4L2 calls,
> +which are augmented with an extra ``request_fd`` parameter. All operations on
> +requests themselves are performed using the command parameter of the
> +:c:func:`MEDIA_IOC_REQUEST_CMD` ioctl.
> +
> +Request Allocation
> +--
> +
> +User-space allocates requests using the ``MEDIA_REQ_CMD_ALLOC`` command on
> +an opened media device. This returns a file descriptor representing the
> +request. Typically, several such requests will be allocated.
> +
> +Request Preparation
> +---
> +
> +Standard V4L2 ioctls can then receive a request file descriptor to express 
> the
> +fact that the ioctl is part of said request, and is not to be applied
> +immediately. V4L2 ioctls supporting this are :c:func:`VIDIOC_S_EXT_CTRLS` and
> +:c:func:`VIDIOC_QBUF`. Controls set with a request parameter are stored 
> instead
> +of being immediately applied, and queued buffers will block the buffer queue
> +until the request becomes active.
> +
> +RFC Note: currently several buffers can be queued to the same queue with the
> +same request. The request parameters will be only be applied when processing
> +the first buffer. Does it make more sense to allow at most one buffer per
> +request per queue instead?
> +
> +Request Submission
> +--
> +
> +Once the parameters and buffers of the request are specified, it can be
> +submitted with the ``MEDIA_REQ_CMD_SUBMIT`` command. This will make the 
> buffers
> +associated to the request available to their driver, which can then apply the
> +saved controls as buffers are processed. A submitted request cannot be 
> modified
> +anymore.
> +
> +If several devices are part of the request, individual drivers may 
> synchronize
> +so the requested pipeline's topology is applied before the buffers are
> +processed. This is at the discretion of the drivers and is not a requirement.
> +
> +Buffers queued without an associated request after a request-bound buffer 
> will
> +be processed using the state of the hardware at the time of the request
> +completion. All the same, controls set without a request are applied
> +immediately, regardless of whether a request is in use or not.
> +
> +User-space can ``poll()`` a request FD in order to wait until the request

Re: [RFCv3 15/17] v4l2: document the request API interface

[Randy Dunlap]

Hi,

A few comments below...

On 02/06/2018 05:48 PM, Alexandre Courbot wrote:
> Document how the request API can be used along with the existing V4L2
> interface.
> 
> Signed-off-by: Alexandre Courbot 
> ---
>  Documentation/media/uapi/v4l/buffer.rst|  10 +-
>  Documentation/media/uapi/v4l/common.rst|   1 +
>  Documentation/media/uapi/v4l/request-api.rst   | 236 
> +
>  .../media/uapi/v4l/vidioc-g-ext-ctrls.rst  |  16 +-
>  Documentation/media/uapi/v4l/vidioc-qbuf.rst   |  21 ++
>  5 files changed, 280 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/media/uapi/v4l/request-api.rst


> diff --git a/Documentation/media/uapi/v4l/request-api.rst 
> b/Documentation/media/uapi/v4l/request-api.rst
> new file mode 100644
> index ..4c61a0dbe3a9
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/request-api.rst
> @@ -0,0 +1,236 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _media-request-api:
> +
> +Request API
> +===
> +
> +The Request API has been designed to allow V4L2 to deal with requirements of
> +modern devices (stateless codecs, MIPI cameras, ...) and APIs (Android Codec
> +v2). One such requirement is the ability for devices belonging to the same
> +pipeline to reconfigure and collaborate closely on a per-frame basis. 
> Another is
> +efficient support of stateless codecs, which need per-frame controls to be 
> set
> +asynchronously in order to be efficiently used.

   to be used efficiently.

> +
> +Supporting these features without the Request API is possible but terribly
> +inefficient: user-space would have to flush all activity on the media 
> pipeline,
> +reconfigure it for the next frame, queue the buffers to be processed with 
> that
> +configuration, and wait until they are all available for dequeing before

"dequeing" should be dequeueing or dequeuing.

> +considering the next frame. This defeats the purpose of having buffer queues
> +since in practice only one buffer would be queued at a time.
> +
> +The Request API allows a specific configuration of the pipeline (media
> +controller topology + controls for each device) to be associated with 
> specific
> +buffers. The parameters are applied by each participating device as buffers
> +associated to a request flow in. This allows user-space to schedule several
> +tasks ("requests") with different parameters in advance, knowing that the
> +parameters will be applied when needed to get the expected result. Controls
> +values at the time of request completion are also available for reading.
> +
> +Usage
> +=
> +
> +The Request API is used on top of standard media controller and V4L2 calls,
> +which are augmented with an extra ``request_fd`` parameter. All operations on
> +requests themselves are performed using the command parameter of the
> +:c:func:`MEDIA_IOC_REQUEST_CMD` ioctl.
> +
> +Request Allocation
> +--
> +
> +User-space allocates requests using the ``MEDIA_REQ_CMD_ALLOC`` command on
> +an opened media device. This returns a file descriptor representing the
> +request. Typically, several such requests will be allocated.
> +
> +Request Preparation
> +---
> +
> +Standard V4L2 ioctls can then receive a request file descriptor to express 
> the
> +fact that the ioctl is part of said request, and is not to be applied
> +immediately. V4L2 ioctls supporting this are :c:func:`VIDIOC_S_EXT_CTRLS` and
> +:c:func:`VIDIOC_QBUF`. Controls set with a request parameter are stored 
> instead
> +of being immediately applied, and queued buffers will block the buffer queue
> +until the request becomes active.
> +
> +RFC Note: currently several buffers can be queued to the same queue with the
> +same request. The request parameters will be only be applied when processing
> +the first buffer. Does it make more sense to allow at most one buffer per
> +request per queue instead?
> +
> +Request Submission
> +--
> +
> +Once the parameters and buffers of the request are specified, it can be
> +submitted with the ``MEDIA_REQ_CMD_SUBMIT`` command. This will make the 
> buffers
> +associated to the request available to their driver, which can then apply the
> +saved controls as buffers are processed. A submitted request cannot be 
> modified
> +anymore.
> +
> +If several devices are part of the request, individual drivers may 
> synchronize
> +so the requested pipeline's topology is applied before the buffers are
> +processed. This is at the discretion of the drivers and is not a requirement.
> +
> +Buffers queued without an associated request after a request-bound buffer 
> will
> +be processed using the state of the hardware at the time of the request
> +completion. All the same, controls set without a request are applied
> +immediately, regardless of whether a request is in use or not.
> +
> +User-space can ``poll()`` a request FD in order to wait until the request
> +completes. A request 

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Al Viro]

On Sun, Apr 15, 2018 at 01:51:07AM +0100, Al Viro wrote:
> On Sat, Apr 14, 2018 at 02:47:21PM -0700, Linus Torvalds wrote:
> > On Sat, Apr 14, 2018 at 1:58 PM, Al Viro  wrote:
> > >
> > > That breaks d_invalidate(), unfortunately.  Look at the termination
> > > conditions in the loop there...
> > 
> > Ugh. I was going to say "but that doesn't even use select_collect()",
> > but yeah, detach_and_collect() calls it.
> > 
> > It would be easy enough to just change the
> > 
> > if (!list_empty())
> > 
> > there to
> > 
> > if (!list_empty())
> > 
> > too.
> 
> You would have to do the same in check_and_drop() as well,
> and that brings back d_invalidate()/d_invalidate() livelock
> we used to have.  See 81be24d263db...
> 
> I'm trying to put something together, but the damn thing is
> full of potential livelocks, unfortunately ;-/  Will send
> a followup once I have something resembling a sane solution...

I really wonder if we should just do the following in
d_invalidate():
* grab ->d_lock on victim, check if it's unhashed,
unlock and bugger off if it is.  Otherwise, unhash and unlock.
>From that point on any d_set_mounted() in the subtree will
fail.
* shrink_dcache_parent() to reduce the subtree size.
* go through the (hopefully shrunk) subtree, picking
mountpoints.  detach_mounts() for each of them.
* shrink_dcache_parent() if any points had been
encountered, to kick the now-unpinned stuff.

As a side benefit, we could probably be gentler on rename_lock
in d_set_mounted() after that change...

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Al Viro]

On Sun, Apr 15, 2018 at 01:51:07AM +0100, Al Viro wrote:
> On Sat, Apr 14, 2018 at 02:47:21PM -0700, Linus Torvalds wrote:
> > On Sat, Apr 14, 2018 at 1:58 PM, Al Viro  wrote:
> > >
> > > That breaks d_invalidate(), unfortunately.  Look at the termination
> > > conditions in the loop there...
> > 
> > Ugh. I was going to say "but that doesn't even use select_collect()",
> > but yeah, detach_and_collect() calls it.
> > 
> > It would be easy enough to just change the
> > 
> > if (!list_empty())
> > 
> > there to
> > 
> > if (!list_empty())
> > 
> > too.
> 
> You would have to do the same in check_and_drop() as well,
> and that brings back d_invalidate()/d_invalidate() livelock
> we used to have.  See 81be24d263db...
> 
> I'm trying to put something together, but the damn thing is
> full of potential livelocks, unfortunately ;-/  Will send
> a followup once I have something resembling a sane solution...

I really wonder if we should just do the following in
d_invalidate():
* grab ->d_lock on victim, check if it's unhashed,
unlock and bugger off if it is.  Otherwise, unhash and unlock.
>From that point on any d_set_mounted() in the subtree will
fail.
* shrink_dcache_parent() to reduce the subtree size.
* go through the (hopefully shrunk) subtree, picking
mountpoints.  detach_mounts() for each of them.
* shrink_dcache_parent() if any points had been
encountered, to kick the now-unpinned stuff.

As a side benefit, we could probably be gentler on rename_lock
in d_set_mounted() after that change...

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

[Baoquan He]

Hi Dave,

Sorry for late reply.

On 04/11/18 at 08:48am, Dave Hansen wrote:
> On 04/08/2018 01:20 AM, Baoquan He wrote:
> > On 04/06/18 at 07:50am, Dave Hansen wrote:
> >> The code looks fine to me.  It's a bit of a shame that there's no
> >> verification to ensure that idx_present never goes beyond the shiny new
> >> nr_present_sections. 
> > 
> > This is a good point. Do you think it's OK to replace (section_nr <
> > NR_MEM_SECTIONS) with (section_nr < nr_present_sections) in below
> > for_each macro? This for_each_present_section_nr() is only used
> > during sparse_init() execution.
> > 
> > #define for_each_present_section_nr(start, section_nr)  \
> > for (section_nr = next_present_section_nr(start-1); \
> >  ((section_nr >= 0) &&  \
> >   (section_nr < NR_MEM_SECTIONS) && \   
> >   
> >   (section_nr <= __highest_present_section_nr));\
> >  section_nr = next_present_section_nr(section_nr))
> 
> I was more concerned about the loops that "consume" the section maps.
> It seems like they might run over the end of the array.



> 
> >>> @@ -583,6 +592,7 @@ void __init sparse_init(void)
> >>>   unsigned long *usemap;
> >>>   unsigned long **usemap_map;
> >>>   int size;
> >>> + int idx_present = 0;
> >>
> >> I wonder whether idx_present is a good name.  Isn't it the number of
> >> consumed mem_map[]s or usemaps?
> > 
> > Yeah, in sparse_init(), it's the index of present memory sections, and
> > also the number of consumed mem_map[]s or usemaps. And I remember you
> > suggested nr_consumed_maps instead. seems nr_consumed_maps is a little
> > long to index array to make code line longer than 80 chars. How about
> > name it idx_present in sparse_init(), nr_consumed_maps in
> > alloc_usemap_and_memmap(), the maps allocation function? I am also fine
> > to use nr_consumed_maps for all of them.
> 
> Does the large array index make a bunch of lines wrap or something?  If
> not, I'd just use the long name.

I am fine with the long name, will use 'nr_consumed_maps' you suggested
earlier to replace.

> 
> >>>   if (!map) {
> >>>   ms->section_mem_map = 0;
> >>> + idx_present++;
> >>>   continue;
> >>>   }
> >>>  
> >>
> >>
> >> This hunk seems logically odd to me.  I would expect a non-used section
> >> to *not* consume an entry from the temporary array.  Why does it?  The
> >> error and success paths seem to do the same thing.
> > 
> > Yes, this place is the hardest to understand. The temorary arrays are
> > allocated beforehand with the size of 'nr_present_sections'. The error
> > paths you mentioned is caused by allocation failure of mem_map or
> > map_map, but whatever it's error or success paths, the sections must be
> > marked as present in memory_present(). Error or success paths happened
> > in alloc_usemap_and_memmap(), while checking if it's erorr or success
> > paths happened in the last for_each_present_section_nr() of
> > sparse_init(), and clear the ms->section_mem_map if it goes along error
> > paths. This is the key point of this new allocation way.
> 
> I think you owe some commenting because this is so hard to understand.

I can arrange and write a code comment above sparse_init() according to
this patch's git log, do you think it's OK?

Honestly, it took me several days to write code, while I spent more
than one week to write the patch log. Writing patch log is really a
headache to me.

Thanks
Baoquan

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

[Baoquan He]

Hi Dave,

Sorry for late reply.

On 04/11/18 at 08:48am, Dave Hansen wrote:
> On 04/08/2018 01:20 AM, Baoquan He wrote:
> > On 04/06/18 at 07:50am, Dave Hansen wrote:
> >> The code looks fine to me.  It's a bit of a shame that there's no
> >> verification to ensure that idx_present never goes beyond the shiny new
> >> nr_present_sections. 
> > 
> > This is a good point. Do you think it's OK to replace (section_nr <
> > NR_MEM_SECTIONS) with (section_nr < nr_present_sections) in below
> > for_each macro? This for_each_present_section_nr() is only used
> > during sparse_init() execution.
> > 
> > #define for_each_present_section_nr(start, section_nr)  \
> > for (section_nr = next_present_section_nr(start-1); \
> >  ((section_nr >= 0) &&  \
> >   (section_nr < NR_MEM_SECTIONS) && \   
> >   
> >   (section_nr <= __highest_present_section_nr));\
> >  section_nr = next_present_section_nr(section_nr))
> 
> I was more concerned about the loops that "consume" the section maps.
> It seems like they might run over the end of the array.



> 
> >>> @@ -583,6 +592,7 @@ void __init sparse_init(void)
> >>>   unsigned long *usemap;
> >>>   unsigned long **usemap_map;
> >>>   int size;
> >>> + int idx_present = 0;
> >>
> >> I wonder whether idx_present is a good name.  Isn't it the number of
> >> consumed mem_map[]s or usemaps?
> > 
> > Yeah, in sparse_init(), it's the index of present memory sections, and
> > also the number of consumed mem_map[]s or usemaps. And I remember you
> > suggested nr_consumed_maps instead. seems nr_consumed_maps is a little
> > long to index array to make code line longer than 80 chars. How about
> > name it idx_present in sparse_init(), nr_consumed_maps in
> > alloc_usemap_and_memmap(), the maps allocation function? I am also fine
> > to use nr_consumed_maps for all of them.
> 
> Does the large array index make a bunch of lines wrap or something?  If
> not, I'd just use the long name.

I am fine with the long name, will use 'nr_consumed_maps' you suggested
earlier to replace.

> 
> >>>   if (!map) {
> >>>   ms->section_mem_map = 0;
> >>> + idx_present++;
> >>>   continue;
> >>>   }
> >>>  
> >>
> >>
> >> This hunk seems logically odd to me.  I would expect a non-used section
> >> to *not* consume an entry from the temporary array.  Why does it?  The
> >> error and success paths seem to do the same thing.
> > 
> > Yes, this place is the hardest to understand. The temorary arrays are
> > allocated beforehand with the size of 'nr_present_sections'. The error
> > paths you mentioned is caused by allocation failure of mem_map or
> > map_map, but whatever it's error or success paths, the sections must be
> > marked as present in memory_present(). Error or success paths happened
> > in alloc_usemap_and_memmap(), while checking if it's erorr or success
> > paths happened in the last for_each_present_section_nr() of
> > sparse_init(), and clear the ms->section_mem_map if it goes along error
> > paths. This is the key point of this new allocation way.
> 
> I think you owe some commenting because this is so hard to understand.

I can arrange and write a code comment above sparse_init() according to
this patch's git log, do you think it's OK?

Honestly, it took me several days to write code, while I spent more
than one week to write the patch log. Writing patch log is really a
headache to me.

Thanks
Baoquan

drivers/infiniband/hw/mlx5/main.c:4555: undefined reference to `uverbs_default_get_objects'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   18b7fd1c93e5204355ddbf2608a097d64df81b88
commit: 8c84660bb437fe8692e6a2b4e85023ccb874a520 IB/mlx5: Initialize the 
parsing tree root without the help of uverbs
date:   10 days ago
config: x86_64-randconfig-s5-04150714 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 8c84660bb437fe8692e6a2b4e85023ccb874a520
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/infiniband/hw/mlx5/main.o: In function `populate_specs_root':
>> drivers/infiniband/hw/mlx5/main.c:4555: undefined reference to 
>> `uverbs_default_get_objects'
>> drivers/infiniband/hw/mlx5/main.c:4559: undefined reference to 
>> `uverbs_alloc_spec_tree'
   drivers/infiniband/hw/mlx5/main.o: In function `depopulate_specs_root':
>> drivers/infiniband/hw/mlx5/main.c:4566: undefined reference to 
>> `uverbs_free_spec_tree'

vim +4555 drivers/infiniband/hw/mlx5/main.c

  4550  
  4551  #define NUM_TREES   0
  4552  static int populate_specs_root(struct mlx5_ib_dev *dev)
  4553  {
  4554  const struct uverbs_object_tree_def *default_root[NUM_TREES + 
1] = {
> 4555  uverbs_default_get_objects()};
  4556  size_t num_trees = 1;
  4557  
  4558  dev->ib_dev.specs_root =
> 4559  uverbs_alloc_spec_tree(num_trees, default_root);
  4560  
  4561  return PTR_ERR_OR_ZERO(dev->ib_dev.specs_root);
  4562  }
  4563  
  4564  static void depopulate_specs_root(struct mlx5_ib_dev *dev)
  4565  {
> 4566  uverbs_free_spec_tree(dev->ib_dev.specs_root);
  4567  }
  4568  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

drivers/infiniband/hw/mlx5/main.c:4555: undefined reference to `uverbs_default_get_objects'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   18b7fd1c93e5204355ddbf2608a097d64df81b88
commit: 8c84660bb437fe8692e6a2b4e85023ccb874a520 IB/mlx5: Initialize the 
parsing tree root without the help of uverbs
date:   10 days ago
config: x86_64-randconfig-s5-04150714 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 8c84660bb437fe8692e6a2b4e85023ccb874a520
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/infiniband/hw/mlx5/main.o: In function `populate_specs_root':
>> drivers/infiniband/hw/mlx5/main.c:4555: undefined reference to 
>> `uverbs_default_get_objects'
>> drivers/infiniband/hw/mlx5/main.c:4559: undefined reference to 
>> `uverbs_alloc_spec_tree'
   drivers/infiniband/hw/mlx5/main.o: In function `depopulate_specs_root':
>> drivers/infiniband/hw/mlx5/main.c:4566: undefined reference to 
>> `uverbs_free_spec_tree'

vim +4555 drivers/infiniband/hw/mlx5/main.c

  4550  
  4551  #define NUM_TREES   0
  4552  static int populate_specs_root(struct mlx5_ib_dev *dev)
  4553  {
  4554  const struct uverbs_object_tree_def *default_root[NUM_TREES + 
1] = {
> 4555  uverbs_default_get_objects()};
  4556  size_t num_trees = 1;
  4557  
  4558  dev->ib_dev.specs_root =
> 4559  uverbs_alloc_spec_tree(num_trees, default_root);
  4560  
  4561  return PTR_ERR_OR_ZERO(dev->ib_dev.specs_root);
  4562  }
  4563  
  4564  static void depopulate_specs_root(struct mlx5_ib_dev *dev)
  4565  {
> 4566  uverbs_free_spec_tree(dev->ib_dev.specs_root);
  4567  }
  4568  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Al Viro]

On Sat, Apr 14, 2018 at 02:47:21PM -0700, Linus Torvalds wrote:
> On Sat, Apr 14, 2018 at 1:58 PM, Al Viro  wrote:
> >
> > That breaks d_invalidate(), unfortunately.  Look at the termination
> > conditions in the loop there...
> 
> Ugh. I was going to say "but that doesn't even use select_collect()",
> but yeah, detach_and_collect() calls it.
> 
> It would be easy enough to just change the
> 
> if (!list_empty())
> 
> there to
> 
> if (!list_empty())
> 
> too.

You would have to do the same in check_and_drop() as well,
and that brings back d_invalidate()/d_invalidate() livelock
we used to have.  See 81be24d263db...

I'm trying to put something together, but the damn thing is
full of potential livelocks, unfortunately ;-/  Will send
a followup once I have something resembling a sane solution...

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Al Viro]

On Sat, Apr 14, 2018 at 02:47:21PM -0700, Linus Torvalds wrote:
> On Sat, Apr 14, 2018 at 1:58 PM, Al Viro  wrote:
> >
> > That breaks d_invalidate(), unfortunately.  Look at the termination
> > conditions in the loop there...
> 
> Ugh. I was going to say "but that doesn't even use select_collect()",
> but yeah, detach_and_collect() calls it.
> 
> It would be easy enough to just change the
> 
> if (!list_empty())
> 
> there to
> 
> if (!list_empty())
> 
> too.

You would have to do the same in check_and_drop() as well,
and that brings back d_invalidate()/d_invalidate() livelock
we used to have.  See 81be24d263db...

I'm trying to put something together, but the damn thing is
full of potential livelocks, unfortunately ;-/  Will send
a followup once I have something resembling a sane solution...

Re: repeatable boot randomness inside KVM guest

[Matthew Wilcox]

On Sat, Apr 14, 2018 at 06:44:19PM -0400, Theodore Y. Ts'o wrote:
> What needs to happen is freelist should get randomized much later in
> the boot sequence.  Doing it later will require locking; I don't know
> enough about the slab/slub code to know whether the slab_mutex would
> be sufficient, or some other lock might need to be added.

Could we have the bootloader pass in some initial randomness?

Re: repeatable boot randomness inside KVM guest

[Matthew Wilcox]

On Sat, Apr 14, 2018 at 06:44:19PM -0400, Theodore Y. Ts'o wrote:
> What needs to happen is freelist should get randomized much later in
> the boot sequence.  Doing it later will require locking; I don't know
> enough about the slab/slub code to know whether the slab_mutex would
> be sufficient, or some other lock might need to be added.

Could we have the bootloader pass in some initial randomness?

Re: [RFC tip/locking/lockdep v6 01/20] lockdep/Documention: Recursive read lock detection reasoning

[Randy Dunlap]

Hi,

Just a few typos etc. below...

On 04/11/2018 06:50 AM, Boqun Feng wrote:
> Signed-off-by: Boqun Feng 
> ---
>  Documentation/locking/lockdep-design.txt | 178 
> +++
>  1 file changed, 178 insertions(+)
> 
> diff --git a/Documentation/locking/lockdep-design.txt 
> b/Documentation/locking/lockdep-design.txt
> index 9de1c158d44c..6bb9e90e2c4f 100644
> --- a/Documentation/locking/lockdep-design.txt
> +++ b/Documentation/locking/lockdep-design.txt
> @@ -284,3 +284,181 @@ Run the command and save the output, then compare 
> against the output from
>  a later run of this command to identify the leakers.  This same output
>  can also help you find situations where runtime lock initialization has
>  been omitted.
> +
> +Recursive read locks:
> +-
> +
> +Lockdep now is equipped with deadlock detection for recursive read locks.
> +
> +Recursive read locks, as their name indicates, are the locks able to be
> +acquired recursively. Unlike non-recursive read locks, recursive read locks
> +only get blocked by current write lock *holders* other than write lock
> +*waiters*, for example:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> +
> + write_lock(X);
> +
> + read_lock(X);
> +
> +is not a deadlock for recursive read locks, as while the task B is waiting 
> for
> +the lock X, the second read_lock() doesn't need to wait because it's a 
> recursive
> +read lock. However if the read_lock() is non-recursive read lock, then the 
> above
> +case is a deadlock, because even if the write_lock() in TASK B can not get 
> the
> +lock, but it can block the second read_lock() in TASK A.
> +
> +Note that a lock can be a write lock (exclusive lock), a non-recursive read
> +lock (non-recursive shared lock) or a recursive read lock (recursive shared
> +lock), depending on the lock operations used to acquire it (more 
> specifically,
> +the value of the 'read' parameter for lock_acquire()). In other words, a 
> single
> +lock instance has three types of acquisition depending on the acquisition
> +functions: exclusive, non-recursive read, and recursive read.
> +
> +To be concise, we call that write locks and non-recursive read locks as
> +"non-recursive" locks and recursive read locks as "recursive" locks.
> +
> +Recursive locks don't block each other, while non-recursive locks do (this is
> +even true for two non-recursive read locks). A non-recursive lock can block 
> the
> +corresponding recursive lock, and vice versa.
> +
> +A deadlock case with recursive locks involved is as follow:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> + read_lock(Y);
> + write_lock(Y);
> + write_lock(X);
> +
> +Task A is waiting for task B to read_unlock() Y and task B is waiting for 
> task
> +A to read_unlock() X.
> +
> +Dependency types and strong dependency paths:
> +-
> +In order to detect deadlocks as above, lockdep needs to track different 
> dependencies.
> +There are 4 categories for dependency edges in the lockdep graph:
> +
> +1) -(NN)->: non-recursive to non-recursive dependency. "X -(NN)-> Y" means
> +X -> Y and both X and Y are non-recursive locks.
> +
> +2) -(RN)->: recursive to non-recursive dependency. "X -(RN)-> Y" means
> +X -> Y and X is recursive read lock and Y is non-recursive lock.
> +
> +3) -(NR)->: non-recursive to recursive dependency, "X -(NR)-> Y" means
> +X -> Y and X is non-recursive lock and Y is recursive lock.
> +
> +4) -(RR)->: recursive to recursive dependency, "X -(RR)-> Y" means
> +X -> Y and both X and Y are recursive locks.
> +
> +Note that given two locks, they may have multiple dependencies between them, 
> for example:
> +
> + TASK A:
> +
> + read_lock(X);
> + write_lock(Y);
> + ...
> +
> + TASK B:
> +
> + write_lock(X);
> + write_lock(Y);
> +
> +, we have both X -(RN)-> Y and X -(NN)-> Y in the dependency graph.
> +
> +We use -(*N)-> for edges that is either -(RN)-> or -(NN)->, the similar for 
> -(N*)->,
> +-(*R)-> and -(R*)->
> +
> +A "path" is a series of conjunct dependency edges in the graph. And we 
> define a
> +"strong" path, which indicates the strong dependency throughout each 
> dependency
> +in the path, as the path that doesn't have two conjunct edges (dependencies) 
> as
> +-(*R)-> and -(R*)->. In other words, a "strong" path is a path from a lock
> +walking to another through the lock dependencies, and if X -> Y -> Z in the
> +path (where X, Y, Z are locks), if the walk from X to Y is through a -(NR)-> 
> or
> +-(RR)-> dependency, the walk from Y to Z must not be through a -(RN)-> or
> +-(RR)-> dependency, otherwise it's not a strong path.
> +
> +We will see why the path is called "strong" in next section.
> +
> +Recursive Read Deadlock Detection:
> 

Re: [RFC tip/locking/lockdep v6 01/20] lockdep/Documention: Recursive read lock detection reasoning

[Randy Dunlap]

Hi,

Just a few typos etc. below...

On 04/11/2018 06:50 AM, Boqun Feng wrote:
> Signed-off-by: Boqun Feng 
> ---
>  Documentation/locking/lockdep-design.txt | 178 
> +++
>  1 file changed, 178 insertions(+)
> 
> diff --git a/Documentation/locking/lockdep-design.txt 
> b/Documentation/locking/lockdep-design.txt
> index 9de1c158d44c..6bb9e90e2c4f 100644
> --- a/Documentation/locking/lockdep-design.txt
> +++ b/Documentation/locking/lockdep-design.txt
> @@ -284,3 +284,181 @@ Run the command and save the output, then compare 
> against the output from
>  a later run of this command to identify the leakers.  This same output
>  can also help you find situations where runtime lock initialization has
>  been omitted.
> +
> +Recursive read locks:
> +-
> +
> +Lockdep now is equipped with deadlock detection for recursive read locks.
> +
> +Recursive read locks, as their name indicates, are the locks able to be
> +acquired recursively. Unlike non-recursive read locks, recursive read locks
> +only get blocked by current write lock *holders* other than write lock
> +*waiters*, for example:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> +
> + write_lock(X);
> +
> + read_lock(X);
> +
> +is not a deadlock for recursive read locks, as while the task B is waiting 
> for
> +the lock X, the second read_lock() doesn't need to wait because it's a 
> recursive
> +read lock. However if the read_lock() is non-recursive read lock, then the 
> above
> +case is a deadlock, because even if the write_lock() in TASK B can not get 
> the
> +lock, but it can block the second read_lock() in TASK A.
> +
> +Note that a lock can be a write lock (exclusive lock), a non-recursive read
> +lock (non-recursive shared lock) or a recursive read lock (recursive shared
> +lock), depending on the lock operations used to acquire it (more 
> specifically,
> +the value of the 'read' parameter for lock_acquire()). In other words, a 
> single
> +lock instance has three types of acquisition depending on the acquisition
> +functions: exclusive, non-recursive read, and recursive read.
> +
> +To be concise, we call that write locks and non-recursive read locks as
> +"non-recursive" locks and recursive read locks as "recursive" locks.
> +
> +Recursive locks don't block each other, while non-recursive locks do (this is
> +even true for two non-recursive read locks). A non-recursive lock can block 
> the
> +corresponding recursive lock, and vice versa.
> +
> +A deadlock case with recursive locks involved is as follow:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> + read_lock(Y);
> + write_lock(Y);
> + write_lock(X);
> +
> +Task A is waiting for task B to read_unlock() Y and task B is waiting for 
> task
> +A to read_unlock() X.
> +
> +Dependency types and strong dependency paths:
> +-
> +In order to detect deadlocks as above, lockdep needs to track different 
> dependencies.
> +There are 4 categories for dependency edges in the lockdep graph:
> +
> +1) -(NN)->: non-recursive to non-recursive dependency. "X -(NN)-> Y" means
> +X -> Y and both X and Y are non-recursive locks.
> +
> +2) -(RN)->: recursive to non-recursive dependency. "X -(RN)-> Y" means
> +X -> Y and X is recursive read lock and Y is non-recursive lock.
> +
> +3) -(NR)->: non-recursive to recursive dependency, "X -(NR)-> Y" means
> +X -> Y and X is non-recursive lock and Y is recursive lock.
> +
> +4) -(RR)->: recursive to recursive dependency, "X -(RR)-> Y" means
> +X -> Y and both X and Y are recursive locks.
> +
> +Note that given two locks, they may have multiple dependencies between them, 
> for example:
> +
> + TASK A:
> +
> + read_lock(X);
> + write_lock(Y);
> + ...
> +
> + TASK B:
> +
> + write_lock(X);
> + write_lock(Y);
> +
> +, we have both X -(RN)-> Y and X -(NN)-> Y in the dependency graph.
> +
> +We use -(*N)-> for edges that is either -(RN)-> or -(NN)->, the similar for 
> -(N*)->,
> +-(*R)-> and -(R*)->
> +
> +A "path" is a series of conjunct dependency edges in the graph. And we 
> define a
> +"strong" path, which indicates the strong dependency throughout each 
> dependency
> +in the path, as the path that doesn't have two conjunct edges (dependencies) 
> as
> +-(*R)-> and -(R*)->. In other words, a "strong" path is a path from a lock
> +walking to another through the lock dependencies, and if X -> Y -> Z in the
> +path (where X, Y, Z are locks), if the walk from X to Y is through a -(NR)-> 
> or
> +-(RR)-> dependency, the walk from Y to Z must not be through a -(RN)-> or
> +-(RR)-> dependency, otherwise it's not a strong path.
> +
> +We will see why the path is called "strong" in next section.
> +
> +Recursive Read Deadlock Detection:
> +--
> +

[GIT PULL] OpenRISC updates for 4.17

[Stafford Horne]

Hi Linus,

Please consider for pull,


The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda:

  Linux 4.16 (2018-04-01 14:20:27 -0700)

are available in the git repository at:

  git://github.com/openrisc/linux.git tags/for-linus

for you to fetch changes up to d56f3af9e801970d21c57621de3b42bc17eac152:

  openrisc: remove unused __ARCH_HAVE_MMU define (2018-04-08 02:15:47 +0900)


OpenRISC updates for v4.17

Just one small thing here, it came in a while back but I didnt have
anything in my 4.16 queue, still its the only thing for 4.17 so sending
it alone.

Small cleanup:
 - remove unused __ARCH_HAVE_MMU define


Tobias Klauser (1):
  openrisc: remove unused __ARCH_HAVE_MMU define

 arch/openrisc/include/uapi/asm/unistd.h | 2 --
 1 file changed, 2 deletions(-)

[GIT PULL] OpenRISC updates for 4.17

[Stafford Horne]

Hi Linus,

Please consider for pull,


The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda:

  Linux 4.16 (2018-04-01 14:20:27 -0700)

are available in the git repository at:

  git://github.com/openrisc/linux.git tags/for-linus

for you to fetch changes up to d56f3af9e801970d21c57621de3b42bc17eac152:

  openrisc: remove unused __ARCH_HAVE_MMU define (2018-04-08 02:15:47 +0900)


OpenRISC updates for v4.17

Just one small thing here, it came in a while back but I didnt have
anything in my 4.16 queue, still its the only thing for 4.17 so sending
it alone.

Small cleanup:
 - remove unused __ARCH_HAVE_MMU define


Tobias Klauser (1):
  openrisc: remove unused __ARCH_HAVE_MMU define

 arch/openrisc/include/uapi/asm/unistd.h | 2 --
 1 file changed, 2 deletions(-)

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Randy Dunlap]

On 04/12/18 22:06, Masahiro Yamada wrote:
> Add a document for the macro language introduced to Kconfig.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/kbuild/kconfig-macro-language.txt | 179 
> 
>  MAINTAINERS |   2 +-
>  2 files changed, 180 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
> 
> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
> b/Documentation/kbuild/kconfig-macro-language.txt
> new file mode 100644
> index 000..1f6281b
> --- /dev/null
> +++ b/Documentation/kbuild/kconfig-macro-language.txt
> @@ -0,0 +1,179 @@
> +Concept
> +---
> +
> +The basic idea was inspired by Make. When we look at Make, we notice sort of
> +two languages in one. One language describes dependency graphs consisting of
> +targets and prerequisites. The other is a macro language for performing 
> textual
> +substitution.
> +
> +There is clear distinction between the two language stages. For example, you
> +can write a makefile like follows:
> +
> +APP := foo
> +SRC := foo.c
> +CC := gcc
> +
> +$(APP): $(SRC)
> +$(CC) -o $(APP) $(SRC)
> +
> +The macro language replaces the variable references with their expanded form,
> +and handles as if the source file were input like follows:
> +
> +foo: foo.c
> +gcc -o foo foo.c
> +
> +Then, Make analyzes the dependency graph and determines the targets to be
> +updated.
> +
> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
> +file like this:
> +
> +CC := gcc
> +
> +config CC_HAS_FOO
> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
> +
> +The macro language in Kconfig processes the source file into the following
> +intermediate:
> +
> +config CC_HAS_FOO
> +def_bool y
> +
> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> +dependency, which is explained in kconfig-language.txt.
> +
> +
> +Variables
> +-
> +
> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
> +variable is expanded "in place" to yield a text string that may then expanded

   may then be 
expanded

> +further. To get the value of a variable, enclose the variable name in $( ).
> +As a special case, single-letter variable names can omit the parentheses and 
> is

and 
are

> +simply referenced like $X. Unlike Make, Kconfig does not support curly braces
> +as in ${CC}.
> +
> +There are two types of variables: simply expanded variables and recursively
> +expanded variables.
> +
> +A simply expanded variable is defined using the := assignment operator. Its
> +righthand side is expanded immediately upon reading the line from the Kconfig
> +file.
> +
> +A recursively expanded variable is defined using the = assignment operator.
> +Its righthand side is simply stored as the value of the variable without
> +expanding it in any way. Instead, the expansion is performed when the 
> variable
> +is used.
> +
> +There is another type of assignment operator; += is used to append text to a
> +variable. The righthand side of += is expanded immediately if the lefthand
> +side was originally defined as a simple variable. Otherwise, its evaluation 
> is
> +deferred.
> +
> +
> +Functions
> +-
> +
> +Like Make, Kconfig supports both built-in and user-defined functions. A
> +function invocation looks much like a variable reference, but includes one or
> +more parameters separated by commas:
> +
> +  $(function-name arg1, arg2, arg3)
> +
> +Some functions are implemented as a built-in function. Currently, Kconfig
> +supports the following:
> +
> + - $(shell command)
> +
> +  The 'shell' function accepts a single argument that is expanded and passed
> +  to a subshell for execution. The standard output of the command is then 
> read
> +  and returned as the value of the function. Every newline in the output is
> +  replaced with a space. Any trailing newlines are deleted. The standard 
> error
> +  is not returned, nor is any program exit status.
> +
> + - $(warning text)
> +
> +  The 'warning' function prints its arguments to stderr. The output is 
> prefixed
> +  with the name of the current Kconfig file, the current line number. It

  file and the current line number. It

> +  evaluates to an empty string.
> +
> + - $(info text)
> +
> +  The 'info' function is similar to 'warning' except that it sends its 
> argument
> +  to stdout without any Kconfig name or line number.

Are current Kconfig file name and line number available so that someone can
construct their own $(info message) messages?

> +
> +A user-defined function is defined by using the = operator. The 

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Randy Dunlap]

On 04/12/18 22:06, Masahiro Yamada wrote:
> Add a document for the macro language introduced to Kconfig.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/kbuild/kconfig-macro-language.txt | 179 
> 
>  MAINTAINERS |   2 +-
>  2 files changed, 180 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
> 
> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
> b/Documentation/kbuild/kconfig-macro-language.txt
> new file mode 100644
> index 000..1f6281b
> --- /dev/null
> +++ b/Documentation/kbuild/kconfig-macro-language.txt
> @@ -0,0 +1,179 @@
> +Concept
> +---
> +
> +The basic idea was inspired by Make. When we look at Make, we notice sort of
> +two languages in one. One language describes dependency graphs consisting of
> +targets and prerequisites. The other is a macro language for performing 
> textual
> +substitution.
> +
> +There is clear distinction between the two language stages. For example, you
> +can write a makefile like follows:
> +
> +APP := foo
> +SRC := foo.c
> +CC := gcc
> +
> +$(APP): $(SRC)
> +$(CC) -o $(APP) $(SRC)
> +
> +The macro language replaces the variable references with their expanded form,
> +and handles as if the source file were input like follows:
> +
> +foo: foo.c
> +gcc -o foo foo.c
> +
> +Then, Make analyzes the dependency graph and determines the targets to be
> +updated.
> +
> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
> +file like this:
> +
> +CC := gcc
> +
> +config CC_HAS_FOO
> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
> +
> +The macro language in Kconfig processes the source file into the following
> +intermediate:
> +
> +config CC_HAS_FOO
> +def_bool y
> +
> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> +dependency, which is explained in kconfig-language.txt.
> +
> +
> +Variables
> +-
> +
> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
> +variable is expanded "in place" to yield a text string that may then expanded

   may then be 
expanded

> +further. To get the value of a variable, enclose the variable name in $( ).
> +As a special case, single-letter variable names can omit the parentheses and 
> is

and 
are

> +simply referenced like $X. Unlike Make, Kconfig does not support curly braces
> +as in ${CC}.
> +
> +There are two types of variables: simply expanded variables and recursively
> +expanded variables.
> +
> +A simply expanded variable is defined using the := assignment operator. Its
> +righthand side is expanded immediately upon reading the line from the Kconfig
> +file.
> +
> +A recursively expanded variable is defined using the = assignment operator.
> +Its righthand side is simply stored as the value of the variable without
> +expanding it in any way. Instead, the expansion is performed when the 
> variable
> +is used.
> +
> +There is another type of assignment operator; += is used to append text to a
> +variable. The righthand side of += is expanded immediately if the lefthand
> +side was originally defined as a simple variable. Otherwise, its evaluation 
> is
> +deferred.
> +
> +
> +Functions
> +-
> +
> +Like Make, Kconfig supports both built-in and user-defined functions. A
> +function invocation looks much like a variable reference, but includes one or
> +more parameters separated by commas:
> +
> +  $(function-name arg1, arg2, arg3)
> +
> +Some functions are implemented as a built-in function. Currently, Kconfig
> +supports the following:
> +
> + - $(shell command)
> +
> +  The 'shell' function accepts a single argument that is expanded and passed
> +  to a subshell for execution. The standard output of the command is then 
> read
> +  and returned as the value of the function. Every newline in the output is
> +  replaced with a space. Any trailing newlines are deleted. The standard 
> error
> +  is not returned, nor is any program exit status.
> +
> + - $(warning text)
> +
> +  The 'warning' function prints its arguments to stderr. The output is 
> prefixed
> +  with the name of the current Kconfig file, the current line number. It

  file and the current line number. It

> +  evaluates to an empty string.
> +
> + - $(info text)
> +
> +  The 'info' function is similar to 'warning' except that it sends its 
> argument
> +  to stdout without any Kconfig name or line number.

Are current Kconfig file name and line number available so that someone can
construct their own $(info message) messages?

> +
> +A user-defined function is defined by using the = operator. The parameters 
> are
> +referenced 

Re: repeatable boot randomness inside KVM guest

[Alexey Dobriyan]

On Sat, Apr 14, 2018 at 03:41:42PM -0700, Andy Lutomirski wrote:
> On Sat, Apr 14, 2018 at 12:59 PM, Alexey Dobriyan  wrote:
> > SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
> > allocation pattern inside a slab:
> >
> >
> > #ifdef CONFIG_SLAB_FREELIST_RANDOM
> > /* Pre-initialize the random sequence cache */
> > static int init_cache_random_seq(struct kmem_cache *s)
> > {
> > ...
> >
> > Then I printed actual random sequences for each kmem cache.
> > Turned out they were all the same for most of the caches and
> > they didn't vary across guest reboots.
> >
> > int cache_random_seq_create(struct kmem_cache *cachep, unsigned int 
> > count, gfp_t gfp)
> > {
> > ...
> > /* Get best entropy at this stage of boot */
> > prandom_seed_state(, get_random_long());
> >
> > Then I searched internet and turned out KVM can pass randomness via
> > virtio-rng or something. So I linked /dev/urandom.
> >
> > And it didn't help!
> >
> > The only way to get randomness for SLAB is to enable RDRAND inside guest.
> >
> > Is it KVM bug?
> >
> > For the record I'm using qemu 2.11.1-r2 and whatever F27 ships now.
> 
> virtio-rng doesn't really do that.  I have an ancient patch set to do
> exactly what you want, and I should dust it off.

Please, do. Here is a list of caches which aren't exactly randomly
randomized with my setup. Many important ones are there :-(

XXX name 'dma-kmalloc-96', r b1e6718e2e7147d4
XXX name 'dma-kmalloc-192', r a7664a0d69968019
XXX name 'dma-kmalloc-8', r 662c2e986443235c
XXX name 'dma-kmalloc-16', r 770a9b620ae4cd62
XXX name 'dma-kmalloc-32', r 2e200073d5fa9f46
XXX name 'dma-kmalloc-64', r d8538fda83c74168
XXX name 'dma-kmalloc-128', r 9e4b956d09dd7d44
XXX name 'dma-kmalloc-256', r 8b14bcb58f9e18f5
XXX name 'dma-kmalloc-512', r 2bbace4b7120624a
XXX name 'dma-kmalloc-1024', r 7cdf44406db52f5b
XXX name 'dma-kmalloc-2048', r 18fe0ebf6bcfdf43
XXX name 'dma-kmalloc-4096', r 9f1a5eee118facf7
XXX name 'dma-kmalloc-8192', r f514d72a1cc441a2
XXX name 'kmalloc-8192', r 14843df817b556cc
XXX name 'kmalloc-4096', r 52ed85fa9c691bbe
XXX name 'kmalloc-2048', r fa81aa9222ff65a7
XXX name 'kmalloc-1024', r ae355c02d31f21d3
XXX name 'kmalloc-512', r 5fe0d22aaf2ef8d9
XXX name 'kmalloc-256', r 336d07a06917b95
XXX name 'kmalloc-192', r 6b6cd5399dd06d95
XXX name 'kmalloc-128', r 893b9e85369964ab
XXX name 'kmalloc-96', r 179e185395d2612
XXX name 'kmalloc-64', r 29cf688b37eccea7
XXX name 'kmalloc-32', r fb7b4e7dca6de00a
XXX name 'kmalloc-16', r a2a441fdc499d0c7
XXX name 'kmalloc-8', r e5454c7095ddd2be
XXX name 'kmem_cache_node', r 500dc6126a47b229
XXX name 'kmem_cache', r 816c8c7bcde08372
XXX name 'task_group', r c09c4d1c1436ce97
XXX name 'radix_tree_node', r 4dd9540b830a4ea8
XXX name 'pool_workqueue', r 88b1e9d9a1f0b570
XXX name 'Acpi-Namespace', r 3e34d55f8f1cb140
XXX name 'Acpi-State', r b94e04635e77b48a
XXX name 'Acpi-Parse', r d5374863b90f2a4c
XXX name 'Acpi-ParseExt', r eefb2fff892f64a9
XXX name 'Acpi-Operand', r ce51949bcc80af13
XXX name 'pid', r cd6d8ee9e5209156
XXX name 'anon_vma', r c3a9273a68127ac7
XXX name 'anon_vma_chain', r a7cec15033c31a9b
XXX name 'cred_jar', r fe4cc38c6d99cf63
XXX name 'task_struct', r eecb8895c6b7dbdb
XXX name 'sighand_cache', r e5243c5eb2ce3a63
XXX name 'signal_cache', r 88b2e108d8ef81c7
XXX name 'files_cache', r ee29814e58dc909c
XXX name 'fs_cache', r bc700a5f8fc28ff8
XXX name 'mm_struct', r f5230f99c7447359
XXX name 'vm_area_struct', r e30f3f8e648a9f88
XXX name 'nsproxy', r ae7c08b524a0f4d4
XXX name 'uts_namespace', r 6b1266178968ed99
XXX name 'buffer_head', r b24c10679dc55a11
XXX name 'names_cache', r 2e023b54e3ca5b8f
XXX name 'dentry', r 83cc18634fbd74e8
XXX name 'inode_cache', r ff9a0ff3b4665cf5
XXX name 'filp', r 4fdad214b7ca7fc1
XXX name 'mnt_cache', r 8e726d32470b23e0
XXX name 'kernfs_node_cache', r 929c5f56778d365d
XXX name 'bdev_cache', r 8a5520036bd0a464
XXX name 'sigqueue', r 2cf75c4d16191efb
XXX name 'seq_file', r ec3ba1fe514524d5
XXX name 'proc_inode_cache', r b0c76cbbda5bb41f
XXX name 'pde_opener', r 5f82f8e7100a517c
XXX name 'proc_dir_entry', r ebabc4e93b52d7b8
XXX name 'shmem_inode_cache', r 2b25a3eb9aa32973
XXX name 'net_namespace', r 95793a7eae08a33f

Re: repeatable boot randomness inside KVM guest

[Alexey Dobriyan]

On Sat, Apr 14, 2018 at 03:41:42PM -0700, Andy Lutomirski wrote:
> On Sat, Apr 14, 2018 at 12:59 PM, Alexey Dobriyan  wrote:
> > SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
> > allocation pattern inside a slab:
> >
> >
> > #ifdef CONFIG_SLAB_FREELIST_RANDOM
> > /* Pre-initialize the random sequence cache */
> > static int init_cache_random_seq(struct kmem_cache *s)
> > {
> > ...
> >
> > Then I printed actual random sequences for each kmem cache.
> > Turned out they were all the same for most of the caches and
> > they didn't vary across guest reboots.
> >
> > int cache_random_seq_create(struct kmem_cache *cachep, unsigned int 
> > count, gfp_t gfp)
> > {
> > ...
> > /* Get best entropy at this stage of boot */
> > prandom_seed_state(, get_random_long());
> >
> > Then I searched internet and turned out KVM can pass randomness via
> > virtio-rng or something. So I linked /dev/urandom.
> >
> > And it didn't help!
> >
> > The only way to get randomness for SLAB is to enable RDRAND inside guest.
> >
> > Is it KVM bug?
> >
> > For the record I'm using qemu 2.11.1-r2 and whatever F27 ships now.
> 
> virtio-rng doesn't really do that.  I have an ancient patch set to do
> exactly what you want, and I should dust it off.

Please, do. Here is a list of caches which aren't exactly randomly
randomized with my setup. Many important ones are there :-(

XXX name 'dma-kmalloc-96', r b1e6718e2e7147d4
XXX name 'dma-kmalloc-192', r a7664a0d69968019
XXX name 'dma-kmalloc-8', r 662c2e986443235c
XXX name 'dma-kmalloc-16', r 770a9b620ae4cd62
XXX name 'dma-kmalloc-32', r 2e200073d5fa9f46
XXX name 'dma-kmalloc-64', r d8538fda83c74168
XXX name 'dma-kmalloc-128', r 9e4b956d09dd7d44
XXX name 'dma-kmalloc-256', r 8b14bcb58f9e18f5
XXX name 'dma-kmalloc-512', r 2bbace4b7120624a
XXX name 'dma-kmalloc-1024', r 7cdf44406db52f5b
XXX name 'dma-kmalloc-2048', r 18fe0ebf6bcfdf43
XXX name 'dma-kmalloc-4096', r 9f1a5eee118facf7
XXX name 'dma-kmalloc-8192', r f514d72a1cc441a2
XXX name 'kmalloc-8192', r 14843df817b556cc
XXX name 'kmalloc-4096', r 52ed85fa9c691bbe
XXX name 'kmalloc-2048', r fa81aa9222ff65a7
XXX name 'kmalloc-1024', r ae355c02d31f21d3
XXX name 'kmalloc-512', r 5fe0d22aaf2ef8d9
XXX name 'kmalloc-256', r 336d07a06917b95
XXX name 'kmalloc-192', r 6b6cd5399dd06d95
XXX name 'kmalloc-128', r 893b9e85369964ab
XXX name 'kmalloc-96', r 179e185395d2612
XXX name 'kmalloc-64', r 29cf688b37eccea7
XXX name 'kmalloc-32', r fb7b4e7dca6de00a
XXX name 'kmalloc-16', r a2a441fdc499d0c7
XXX name 'kmalloc-8', r e5454c7095ddd2be
XXX name 'kmem_cache_node', r 500dc6126a47b229
XXX name 'kmem_cache', r 816c8c7bcde08372
XXX name 'task_group', r c09c4d1c1436ce97
XXX name 'radix_tree_node', r 4dd9540b830a4ea8
XXX name 'pool_workqueue', r 88b1e9d9a1f0b570
XXX name 'Acpi-Namespace', r 3e34d55f8f1cb140
XXX name 'Acpi-State', r b94e04635e77b48a
XXX name 'Acpi-Parse', r d5374863b90f2a4c
XXX name 'Acpi-ParseExt', r eefb2fff892f64a9
XXX name 'Acpi-Operand', r ce51949bcc80af13
XXX name 'pid', r cd6d8ee9e5209156
XXX name 'anon_vma', r c3a9273a68127ac7
XXX name 'anon_vma_chain', r a7cec15033c31a9b
XXX name 'cred_jar', r fe4cc38c6d99cf63
XXX name 'task_struct', r eecb8895c6b7dbdb
XXX name 'sighand_cache', r e5243c5eb2ce3a63
XXX name 'signal_cache', r 88b2e108d8ef81c7
XXX name 'files_cache', r ee29814e58dc909c
XXX name 'fs_cache', r bc700a5f8fc28ff8
XXX name 'mm_struct', r f5230f99c7447359
XXX name 'vm_area_struct', r e30f3f8e648a9f88
XXX name 'nsproxy', r ae7c08b524a0f4d4
XXX name 'uts_namespace', r 6b1266178968ed99
XXX name 'buffer_head', r b24c10679dc55a11
XXX name 'names_cache', r 2e023b54e3ca5b8f
XXX name 'dentry', r 83cc18634fbd74e8
XXX name 'inode_cache', r ff9a0ff3b4665cf5
XXX name 'filp', r 4fdad214b7ca7fc1
XXX name 'mnt_cache', r 8e726d32470b23e0
XXX name 'kernfs_node_cache', r 929c5f56778d365d
XXX name 'bdev_cache', r 8a5520036bd0a464
XXX name 'sigqueue', r 2cf75c4d16191efb
XXX name 'seq_file', r ec3ba1fe514524d5
XXX name 'proc_inode_cache', r b0c76cbbda5bb41f
XXX name 'pde_opener', r 5f82f8e7100a517c
XXX name 'proc_dir_entry', r ebabc4e93b52d7b8
XXX name 'shmem_inode_cache', r 2b25a3eb9aa32973
XXX name 'net_namespace', r 95793a7eae08a33f

[GIT PULL] Please pull powerpc/linux.git powerpc-4.17-2 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull some powerpc fixes for 4.17-rc1 if you can:

The following changes since commit 49a695ba723224875df50e327bd7b0b65dd9a56b:

  Merge tag 'powerpc-4.17-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2018-04-07 
12:08:19 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.17-2

for you to fetch changes up to 81b654c273914704a4bdf580f28d67aaba1094e4:

  powerpc/64s: Fix CPU_FTRS_ALWAYS vs DT CPU features (2018-04-13 23:51:44 
+1000)

- 
powerpc fixes for 4.17 #2

 - Fix crashes when loading modules built with a different CONFIG_RELOCATABLE
   value by adding CONFIG_RELOCATABLE to vermagic.

 - Fix busy loops in the OPAL NVRAM driver if we get certain error conditions
   from firmware.

 - Remove tlbie trace points from KVM code that's called in real mode, because
   it causes crashes.

 - Fix checkstops caused by invalid tlbiel on Power9 Radix.

 - Ensure the set of CPU features we "know" are always enabled is actually the
   minimal set when we build with support for firmware supplied CPU features.

Thanks to:
  Aneesh Kumar K.V, Anshuman Khandual, Nicholas Piggin.

- 
Aneesh Kumar K.V (1):
  powerpc/8xx: Fix build with hugetlbfs enabled

Anshuman Khandual (1):
  powerpc/fscr: Enable interrupts earlier before calling get_user()

Michael Ellerman (4):
  powerpc/modules: Fix crashes by adding CONFIG_RELOCATABLE to vermagic
  powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
  powerpc/mm/radix: Fix checkstops caused by invalid tlbiel
  powerpc/64s: Fix CPU_FTRS_ALWAYS vs DT CPU features

Nicholas Piggin (3):
  powerpc/powernv: define a standard delay for OPAL_BUSY type retry loops
  powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops
  KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode

 arch/powerpc/include/asm/cputable.h | 23 +++--
 arch/powerpc/include/asm/module.h   | 12 ++-
 arch/powerpc/include/asm/opal.h |  3 +++
 arch/powerpc/kernel/dt_cpu_ftrs.c   | 14 +
 arch/powerpc/kernel/setup_64.c  |  2 +-
 arch/powerpc/kernel/traps.c | 32 +++--
 arch/powerpc/kvm/book3s_hv_rm_mmu.c |  4 
 arch/powerpc/mm/slice.c |  1 +
 arch/powerpc/mm/tlb-radix.c |  5 ++---
 arch/powerpc/platforms/powernv/opal-nvram.c |  7 ++-
 10 files changed, 63 insertions(+), 40 deletions(-)
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJa0oerAAoJEFHr6jzI4aWAvCIP/iG5Fv1b3MoslwQkCsAcMtTy
zO/Ga7H54Kpiopr9F5T4JTKVOMVBb4urs8mP9RXGUzqf9iuNy3ZWGJfbHn1VXw4r
wKFx5MfZYKNkoi8tGZHmbxhcSzFKsGHdCAEfC/SiNZCZZnbnt4NjWlUV4/QRts4a
/LEyvrWPGzGCZF1y+LpFREAJakhJ1uklJNbqwMvRtlXmoJoqODNCRPk1Tmy8fQ8E
eYLtAYGcN0x9w0YRo/1cTkJM/cksLPzJjZZn/6GR1vWRS544+iTSs6xT81RC7/yB
2QVsKD+V7D3iJ3iQ4DhCNkpMHNZjLqDNymMLjcYM1H/mPobvsegwZuGDm1jr7++D
3XBZa9wO6/dAOflu+nMlVNd323BMsdhGcI2WiZzsdkBh+aWU6hkQrgEG1uY3XV90
8zlOk6Cmiq+aYkcemEzMCvV1gYSpiauZx2q8Y/GKww2BVekRUKpsBTgcZvvKbBUX
XBJtAkRo5hR2o2qLAUwSXiJuGcfrlZBuZT0qCb1SYd9XRxIevvb1iQz2Yngxr6PI
n9reO01c6a25CJQqNLH07iy+eZcsWUNcrzEjaeHaHWPl+zcl0AWEuGj3Q80/SM6Y
rqOBMn3YSANpFjmat90c6CSWC/Bdf2nORMEtIHQ5mKsnL4rBv6X+pvMf3/TSwDNa
QzAeCp1gwX940ngqW3H7
=VzIU
-END PGP SIGNATURE-

[GIT PULL] Please pull powerpc/linux.git powerpc-4.17-2 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull some powerpc fixes for 4.17-rc1 if you can:

The following changes since commit 49a695ba723224875df50e327bd7b0b65dd9a56b:

  Merge tag 'powerpc-4.17-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2018-04-07 
12:08:19 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.17-2

for you to fetch changes up to 81b654c273914704a4bdf580f28d67aaba1094e4:

  powerpc/64s: Fix CPU_FTRS_ALWAYS vs DT CPU features (2018-04-13 23:51:44 
+1000)

- 
powerpc fixes for 4.17 #2

 - Fix crashes when loading modules built with a different CONFIG_RELOCATABLE
   value by adding CONFIG_RELOCATABLE to vermagic.

 - Fix busy loops in the OPAL NVRAM driver if we get certain error conditions
   from firmware.

 - Remove tlbie trace points from KVM code that's called in real mode, because
   it causes crashes.

 - Fix checkstops caused by invalid tlbiel on Power9 Radix.

 - Ensure the set of CPU features we "know" are always enabled is actually the
   minimal set when we build with support for firmware supplied CPU features.

Thanks to:
  Aneesh Kumar K.V, Anshuman Khandual, Nicholas Piggin.

- 
Aneesh Kumar K.V (1):
  powerpc/8xx: Fix build with hugetlbfs enabled

Anshuman Khandual (1):
  powerpc/fscr: Enable interrupts earlier before calling get_user()

Michael Ellerman (4):
  powerpc/modules: Fix crashes by adding CONFIG_RELOCATABLE to vermagic
  powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
  powerpc/mm/radix: Fix checkstops caused by invalid tlbiel
  powerpc/64s: Fix CPU_FTRS_ALWAYS vs DT CPU features

Nicholas Piggin (3):
  powerpc/powernv: define a standard delay for OPAL_BUSY type retry loops
  powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops
  KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode

 arch/powerpc/include/asm/cputable.h | 23 +++--
 arch/powerpc/include/asm/module.h   | 12 ++-
 arch/powerpc/include/asm/opal.h |  3 +++
 arch/powerpc/kernel/dt_cpu_ftrs.c   | 14 +
 arch/powerpc/kernel/setup_64.c  |  2 +-
 arch/powerpc/kernel/traps.c | 32 +++--
 arch/powerpc/kvm/book3s_hv_rm_mmu.c |  4 
 arch/powerpc/mm/slice.c |  1 +
 arch/powerpc/mm/tlb-radix.c |  5 ++---
 arch/powerpc/platforms/powernv/opal-nvram.c |  7 ++-
 10 files changed, 63 insertions(+), 40 deletions(-)
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJa0oerAAoJEFHr6jzI4aWAvCIP/iG5Fv1b3MoslwQkCsAcMtTy
zO/Ga7H54Kpiopr9F5T4JTKVOMVBb4urs8mP9RXGUzqf9iuNy3ZWGJfbHn1VXw4r
wKFx5MfZYKNkoi8tGZHmbxhcSzFKsGHdCAEfC/SiNZCZZnbnt4NjWlUV4/QRts4a
/LEyvrWPGzGCZF1y+LpFREAJakhJ1uklJNbqwMvRtlXmoJoqODNCRPk1Tmy8fQ8E
eYLtAYGcN0x9w0YRo/1cTkJM/cksLPzJjZZn/6GR1vWRS544+iTSs6xT81RC7/yB
2QVsKD+V7D3iJ3iQ4DhCNkpMHNZjLqDNymMLjcYM1H/mPobvsegwZuGDm1jr7++D
3XBZa9wO6/dAOflu+nMlVNd323BMsdhGcI2WiZzsdkBh+aWU6hkQrgEG1uY3XV90
8zlOk6Cmiq+aYkcemEzMCvV1gYSpiauZx2q8Y/GKww2BVekRUKpsBTgcZvvKbBUX
XBJtAkRo5hR2o2qLAUwSXiJuGcfrlZBuZT0qCb1SYd9XRxIevvb1iQz2Yngxr6PI
n9reO01c6a25CJQqNLH07iy+eZcsWUNcrzEjaeHaHWPl+zcl0AWEuGj3Q80/SM6Y
rqOBMn3YSANpFjmat90c6CSWC/Bdf2nORMEtIHQ5mKsnL4rBv6X+pvMf3/TSwDNa
QzAeCp1gwX940ngqW3H7
=VzIU
-END PGP SIGNATURE-

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

[Andy Lutomirski]

On Thu, Apr 12, 2018 at 12:43 PM, Linus Torvalds
 wrote:
> On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers
>  wrote:
>> The cpu_opv system call executes a vector of operations on behalf of
>> user-space on a specific CPU with preemption disabled. It is inspired
>> by readv() and writev() system calls which take a "struct iovec"
>> array as argument.
>
> Do we really want the page pinning?
>
> This whole cpu_opv thing is the most questionable part of the series,
> and the page pinning is the most questionable part of cpu_opv for me.
>
> Can we plan on merging just the plain rseq parts *without* this all
> first, and then see the cpu_opv thing as a "maybe future expansion"
> part.
>
> I think that would make Andy happier too.
>

It only makes me happier if the userspace code involved is actually
going to work when single-stepped, which might actually be the case
(fingers crossed).  That being said, I'm not really convinced that
cpu_opv() makes much difference here, since I'm not entirely convinced
that user code will actually use it or that user code will actually be
that well tested.  C'est la vie.

Re: repeatable boot randomness inside KVM guest

[Theodore Y. Ts'o]

+linux...@kvack.org
k...@vger.kernel.org, secur...@kernel.org moved to bcc

On Sat, Apr 14, 2018 at 10:59:21PM +0300, Alexey Dobriyan wrote:
> SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
> allocation pattern inside a slab:
> 
>   int cache_random_seq_create(struct kmem_cache *cachep, unsigned int 
> count, gfp_t gfp)
>   {
>   ...
>   /* Get best entropy at this stage of boot */
>   prandom_seed_state(, get_random_long());
>
> Then I printed actual random sequences for each kmem cache.
> Turned out they were all the same for most of the caches and
> they didn't vary across guest reboots.

The problem is at the super-early state of the boot path, kernel code
can't allocate memory.  This is something most device drivers kinda
assume they can do.  :-)

So it means we haven't yet initialized the virtio-rng driver, and it's
before interrupts have been enabled, so we can't harvest any entropy
from interrupt timing.  So that's why trying to use virtio-rng didn't
help.

> The only way to get randomness for SLAB is to enable RDRAND inside guest.
> 
> Is it KVM bug?

No, it's not a KVM bug.  The fundamental issue is in how the
CONFIG_SLAB_FREELIST_RANDOM is currently implemented.

What needs to happen is freelist should get randomized much later in
the boot sequence.  Doing it later will require locking; I don't know
enough about the slab/slub code to know whether the slab_mutex would
be sufficient, or some other lock might need to be added.

The other thing I would note that is that using prandom_u32_state() doesn't
really provide much security.  In fact, if the the goal is to protect
against a malicious attacker trying to guess what addresses will be
returned by the slab allocator, I suspect it's much like the security
patdowns done at airports.  It might protect against a really stupid
attacker, but it's mostly security theater.

The freelist randomization is only being done once; so it's not like
performance is really an issue.  It would be much better to just use
get_random_u32() and be done with it.  I'd drop using prandom_*
functions in slab.c and slubct and slab_common.c, and just use a
really random number generator, if the goal is real security as
opposed to security for show

(Not that there's necessarily any thing wrong with security theater;
the US spends over 3 billion dollars a year on security theater.  As
politicians know, symbolism can be important.  :-)

Cheers,

- Ted

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

[Andy Lutomirski]

On Thu, Apr 12, 2018 at 12:43 PM, Linus Torvalds
 wrote:
> On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers
>  wrote:
>> The cpu_opv system call executes a vector of operations on behalf of
>> user-space on a specific CPU with preemption disabled. It is inspired
>> by readv() and writev() system calls which take a "struct iovec"
>> array as argument.
>
> Do we really want the page pinning?
>
> This whole cpu_opv thing is the most questionable part of the series,
> and the page pinning is the most questionable part of cpu_opv for me.
>
> Can we plan on merging just the plain rseq parts *without* this all
> first, and then see the cpu_opv thing as a "maybe future expansion"
> part.
>
> I think that would make Andy happier too.
>

It only makes me happier if the userspace code involved is actually
going to work when single-stepped, which might actually be the case
(fingers crossed).  That being said, I'm not really convinced that
cpu_opv() makes much difference here, since I'm not entirely convinced
that user code will actually use it or that user code will actually be
that well tested.  C'est la vie.

Re: repeatable boot randomness inside KVM guest

[Theodore Y. Ts'o]

+linux...@kvack.org
k...@vger.kernel.org, secur...@kernel.org moved to bcc

On Sat, Apr 14, 2018 at 10:59:21PM +0300, Alexey Dobriyan wrote:
> SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
> allocation pattern inside a slab:
> 
>   int cache_random_seq_create(struct kmem_cache *cachep, unsigned int 
> count, gfp_t gfp)
>   {
>   ...
>   /* Get best entropy at this stage of boot */
>   prandom_seed_state(, get_random_long());
>
> Then I printed actual random sequences for each kmem cache.
> Turned out they were all the same for most of the caches and
> they didn't vary across guest reboots.

The problem is at the super-early state of the boot path, kernel code
can't allocate memory.  This is something most device drivers kinda
assume they can do.  :-)

So it means we haven't yet initialized the virtio-rng driver, and it's
before interrupts have been enabled, so we can't harvest any entropy
from interrupt timing.  So that's why trying to use virtio-rng didn't
help.

> The only way to get randomness for SLAB is to enable RDRAND inside guest.
> 
> Is it KVM bug?

No, it's not a KVM bug.  The fundamental issue is in how the
CONFIG_SLAB_FREELIST_RANDOM is currently implemented.

What needs to happen is freelist should get randomized much later in
the boot sequence.  Doing it later will require locking; I don't know
enough about the slab/slub code to know whether the slab_mutex would
be sufficient, or some other lock might need to be added.

The other thing I would note that is that using prandom_u32_state() doesn't
really provide much security.  In fact, if the the goal is to protect
against a malicious attacker trying to guess what addresses will be
returned by the slab allocator, I suspect it's much like the security
patdowns done at airports.  It might protect against a really stupid
attacker, but it's mostly security theater.

The freelist randomization is only being done once; so it's not like
performance is really an issue.  It would be much better to just use
get_random_u32() and be done with it.  I'd drop using prandom_*
functions in slab.c and slubct and slab_common.c, and just use a
really random number generator, if the goal is real security as
opposed to security for show

(Not that there's necessarily any thing wrong with security theater;
the US spends over 3 billion dollars a year on security theater.  As
politicians know, symbolism can be important.  :-)

Cheers,

- Ted

Re: repeatable boot randomness inside KVM guest

[Andy Lutomirski]

On Sat, Apr 14, 2018 at 12:59 PM, Alexey Dobriyan  wrote:
> SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
> allocation pattern inside a slab:
>
>
> #ifdef CONFIG_SLAB_FREELIST_RANDOM
> /* Pre-initialize the random sequence cache */
> static int init_cache_random_seq(struct kmem_cache *s)
> {
> ...
>
> Then I printed actual random sequences for each kmem cache.
> Turned out they were all the same for most of the caches and
> they didn't vary across guest reboots.
>
> int cache_random_seq_create(struct kmem_cache *cachep, unsigned int 
> count, gfp_t gfp)
> {
> ...
> /* Get best entropy at this stage of boot */
> prandom_seed_state(, get_random_long());
>
> Then I searched internet and turned out KVM can pass randomness via
> virtio-rng or something. So I linked /dev/urandom.
>
> And it didn't help!
>
> The only way to get randomness for SLAB is to enable RDRAND inside guest.
>
> Is it KVM bug?
>
> For the record I'm using qemu 2.11.1-r2 and whatever F27 ships now.

virtio-rng doesn't really do that.  I have an ancient patch set to do
exactly what you want, and I should dust it off.

Re: repeatable boot randomness inside KVM guest

[Andy Lutomirski]

On Sat, Apr 14, 2018 at 12:59 PM, Alexey Dobriyan  wrote:
> SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
> allocation pattern inside a slab:
>
>
> #ifdef CONFIG_SLAB_FREELIST_RANDOM
> /* Pre-initialize the random sequence cache */
> static int init_cache_random_seq(struct kmem_cache *s)
> {
> ...
>
> Then I printed actual random sequences for each kmem cache.
> Turned out they were all the same for most of the caches and
> they didn't vary across guest reboots.
>
> int cache_random_seq_create(struct kmem_cache *cachep, unsigned int 
> count, gfp_t gfp)
> {
> ...
> /* Get best entropy at this stage of boot */
> prandom_seed_state(, get_random_long());
>
> Then I searched internet and turned out KVM can pass randomness via
> virtio-rng or something. So I linked /dev/urandom.
>
> And it didn't help!
>
> The only way to get randomness for SLAB is to enable RDRAND inside guest.
>
> Is it KVM bug?
>
> For the record I'm using qemu 2.11.1-r2 and whatever F27 ships now.

virtio-rng doesn't really do that.  I have an ancient patch set to do
exactly what you want, and I should dust it off.

Re: [PATCH 2/2] kvm: nVMX: Introduce KVM_CAP_STATE

[Raslan, KarimAllah]

On Sat, 2018-04-14 at 15:56 +, Raslan, KarimAllah wrote:
> On Thu, 2018-04-12 at 17:12 +0200, KarimAllah Ahmed wrote:
> > 
> > From: Jim Mattson 
> > 
> > For nested virtualization L0 KVM is managing a bit of state for L2 guests,
> > this state can not be captured through the currently available IOCTLs. In
> > fact the state captured through all of these IOCTLs is usually a mix of L1
> > and L2 state. It is also dependent on whether the L2 guest was running at
> > the moment when the process was interrupted to save its state.
> > 
> > With this capability, there are two new vcpu ioctls: KVM_GET_VMX_STATE and
> > KVM_SET_VMX_STATE. These can be used for saving and restoring a VM that is
> > in VMX operation.
> > 
> > Cc: Paolo Bonzini 
> > Cc: Radim Krčmář 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: H. Peter Anvin 
> > Cc: x...@kernel.org
> > Cc: k...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Jim Mattson 
> > [karahmed@ - rename structs and functions and make them ready for AMD and
> >  address previous comments.
> >- rebase & a bit of refactoring.
> >- Merge 7/8 and 8/8 into one patch.
> >- Force a VMExit from L2 after reading the kvm_state to avoid
> >  mixed state between L1 and L2 on resurrecting the instance. ]
> > Signed-off-by: KarimAllah Ahmed 
> > ---
> > v2 -> v3:
> > - Remove the forced VMExit from L2 after reading the kvm_state. The actual
> >   problem is solved.
> > - Rebase again!
> > - Set nested_run_pending during restore (not sure if it makes sense yet or
> >   not).
> > - Reduce KVM_REQUEST_ARCH_BASE to 7 instead of 8 (the other alternative is
> >   to switch everything to u64)
> > 
> > v1 -> v2:
> > - Rename structs and functions and make them ready for AMD and address
> >   previous comments.
> > - Rebase & a bit of refactoring.
> > - Merge 7/8 and 8/8 into one patch.
> > - Force a VMExit from L2 after reading the kvm_state to avoid mixed state
> >   between L1 and L2 on resurrecting the instance.
> > ---
> >  Documentation/virtual/kvm/api.txt |  47 ++
> >  arch/x86/include/asm/kvm_host.h   |   7 ++
> >  arch/x86/include/uapi/asm/kvm.h   |  38 
> >  arch/x86/kvm/vmx.c| 177 
> > +-
> >  arch/x86/kvm/x86.c|  21 +
> >  include/linux/kvm_host.h  |   2 +-
> >  include/uapi/linux/kvm.h  |   5 ++
> >  7 files changed, 292 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/virtual/kvm/api.txt 
> > b/Documentation/virtual/kvm/api.txt
> > index 1c7958b..c51d5d3 100644
> > --- a/Documentation/virtual/kvm/api.txt
> > +++ b/Documentation/virtual/kvm/api.txt
> > @@ -3548,6 +3548,53 @@ Returns: 0 on success,
> > -ENOENT on deassign if the conn_id isn't registered
> > -EEXIST on assign if the conn_id is already registered
> >  
> > +4.114 KVM_GET_STATE
> > +
> > +Capability: KVM_CAP_STATE
> > +Architectures: x86
> > +Type: vcpu ioctl
> > +Parameters: struct kvm_state (in/out)
> > +Returns: 0 on success, -1 on error
> > +Errors:
> > +  E2BIG: the data size exceeds the value of 'size' specified by
> > + the user (the size required will be written into size).
> > +
> > +struct kvm_state {
> > +   __u16 flags;
> > +   __u16 format;
> > +   __u32 size;
> > +   union {
> > +   struct kvm_vmx_state vmx;
> > +   struct kvm_svm_state svm;
> > +   __u8 pad[120];
> > +   };
> > +   __u8 data[0];
> > +};
> > +
> > +This ioctl copies the vcpu's kvm_state struct from the kernel to userspace.
> > +
> > +4.115 KVM_SET_STATE
> > +
> > +Capability: KVM_CAP_STATE
> > +Architectures: x86
> > +Type: vcpu ioctl
> > +Parameters: struct kvm_state (in)
> > +Returns: 0 on success, -1 on error
> > +
> > +struct kvm_state {
> > +   __u16 flags;
> > +   __u16 format;
> > +   __u32 size;
> > +   union {
> > +   struct kvm_vmx_state vmx;
> > +   struct kvm_svm_state svm;
> > +   __u8 pad[120];
> > +   };
> > +   __u8 data[0];
> > +};
> > +
> > +This copies the vcpu's kvm_state struct from userspace to the kernel.
> > +>>> 13a7c9e... kvm: nVMX: Introduce KVM_CAP_STATE
> >  
> >  5. The kvm_run structure
> >  
> > diff --git a/arch/x86/include/asm/kvm_host.h 
> > b/arch/x86/include/asm/kvm_host.h
> > index 9fa4f57..ad2116a 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -75,6 +75,7 @@
> >  #define KVM_REQ_HV_EXITKVM_ARCH_REQ(21)
> >  #define KVM_REQ_HV_STIMER  KVM_ARCH_REQ(22)
> >  #define KVM_REQ_LOAD_EOI_EXITMAP   KVM_ARCH_REQ(23)
> > +#define KVM_REQ_GET_VMCS12_PAGES   KVM_ARCH_REQ(24)
> >  
> >  #define CR0_RESERVED_BITS   \
> > 

Re: [PATCH 2/2] kvm: nVMX: Introduce KVM_CAP_STATE

[Raslan, KarimAllah]

On Sat, 2018-04-14 at 15:56 +, Raslan, KarimAllah wrote:
> On Thu, 2018-04-12 at 17:12 +0200, KarimAllah Ahmed wrote:
> > 
> > From: Jim Mattson 
> > 
> > For nested virtualization L0 KVM is managing a bit of state for L2 guests,
> > this state can not be captured through the currently available IOCTLs. In
> > fact the state captured through all of these IOCTLs is usually a mix of L1
> > and L2 state. It is also dependent on whether the L2 guest was running at
> > the moment when the process was interrupted to save its state.
> > 
> > With this capability, there are two new vcpu ioctls: KVM_GET_VMX_STATE and
> > KVM_SET_VMX_STATE. These can be used for saving and restoring a VM that is
> > in VMX operation.
> > 
> > Cc: Paolo Bonzini 
> > Cc: Radim Krčmář 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: H. Peter Anvin 
> > Cc: x...@kernel.org
> > Cc: k...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Jim Mattson 
> > [karahmed@ - rename structs and functions and make them ready for AMD and
> >  address previous comments.
> >- rebase & a bit of refactoring.
> >- Merge 7/8 and 8/8 into one patch.
> >- Force a VMExit from L2 after reading the kvm_state to avoid
> >  mixed state between L1 and L2 on resurrecting the instance. ]
> > Signed-off-by: KarimAllah Ahmed 
> > ---
> > v2 -> v3:
> > - Remove the forced VMExit from L2 after reading the kvm_state. The actual
> >   problem is solved.
> > - Rebase again!
> > - Set nested_run_pending during restore (not sure if it makes sense yet or
> >   not).
> > - Reduce KVM_REQUEST_ARCH_BASE to 7 instead of 8 (the other alternative is
> >   to switch everything to u64)
> > 
> > v1 -> v2:
> > - Rename structs and functions and make them ready for AMD and address
> >   previous comments.
> > - Rebase & a bit of refactoring.
> > - Merge 7/8 and 8/8 into one patch.
> > - Force a VMExit from L2 after reading the kvm_state to avoid mixed state
> >   between L1 and L2 on resurrecting the instance.
> > ---
> >  Documentation/virtual/kvm/api.txt |  47 ++
> >  arch/x86/include/asm/kvm_host.h   |   7 ++
> >  arch/x86/include/uapi/asm/kvm.h   |  38 
> >  arch/x86/kvm/vmx.c| 177 
> > +-
> >  arch/x86/kvm/x86.c|  21 +
> >  include/linux/kvm_host.h  |   2 +-
> >  include/uapi/linux/kvm.h  |   5 ++
> >  7 files changed, 292 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/virtual/kvm/api.txt 
> > b/Documentation/virtual/kvm/api.txt
> > index 1c7958b..c51d5d3 100644
> > --- a/Documentation/virtual/kvm/api.txt
> > +++ b/Documentation/virtual/kvm/api.txt
> > @@ -3548,6 +3548,53 @@ Returns: 0 on success,
> > -ENOENT on deassign if the conn_id isn't registered
> > -EEXIST on assign if the conn_id is already registered
> >  
> > +4.114 KVM_GET_STATE
> > +
> > +Capability: KVM_CAP_STATE
> > +Architectures: x86
> > +Type: vcpu ioctl
> > +Parameters: struct kvm_state (in/out)
> > +Returns: 0 on success, -1 on error
> > +Errors:
> > +  E2BIG: the data size exceeds the value of 'size' specified by
> > + the user (the size required will be written into size).
> > +
> > +struct kvm_state {
> > +   __u16 flags;
> > +   __u16 format;
> > +   __u32 size;
> > +   union {
> > +   struct kvm_vmx_state vmx;
> > +   struct kvm_svm_state svm;
> > +   __u8 pad[120];
> > +   };
> > +   __u8 data[0];
> > +};
> > +
> > +This ioctl copies the vcpu's kvm_state struct from the kernel to userspace.
> > +
> > +4.115 KVM_SET_STATE
> > +
> > +Capability: KVM_CAP_STATE
> > +Architectures: x86
> > +Type: vcpu ioctl
> > +Parameters: struct kvm_state (in)
> > +Returns: 0 on success, -1 on error
> > +
> > +struct kvm_state {
> > +   __u16 flags;
> > +   __u16 format;
> > +   __u32 size;
> > +   union {
> > +   struct kvm_vmx_state vmx;
> > +   struct kvm_svm_state svm;
> > +   __u8 pad[120];
> > +   };
> > +   __u8 data[0];
> > +};
> > +
> > +This copies the vcpu's kvm_state struct from userspace to the kernel.
> > +>>> 13a7c9e... kvm: nVMX: Introduce KVM_CAP_STATE
> >  
> >  5. The kvm_run structure
> >  
> > diff --git a/arch/x86/include/asm/kvm_host.h 
> > b/arch/x86/include/asm/kvm_host.h
> > index 9fa4f57..ad2116a 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -75,6 +75,7 @@
> >  #define KVM_REQ_HV_EXITKVM_ARCH_REQ(21)
> >  #define KVM_REQ_HV_STIMER  KVM_ARCH_REQ(22)
> >  #define KVM_REQ_LOAD_EOI_EXITMAP   KVM_ARCH_REQ(23)
> > +#define KVM_REQ_GET_VMCS12_PAGES   KVM_ARCH_REQ(24)
> >  
> >  #define CR0_RESERVED_BITS   \
> > (~(unsigned long)(X86_CR0_PE | X86_CR0_MP | X86_CR0_EM | X86_CR0_TS \
> > @@ -1084,6 +1085,12 @@ struct kvm_x86_ops {
> >  
> > void (*setup_mce)(struct 

Re: Regression with 5dcd8400884c ("macsec: missing dev_put() on error in macsec_newlink()")

[Sabrina Dubroca]

Hello Laura,

2018-04-14, 10:56:55 -0700, Laura Abbott wrote:
> Hi,
> 
> Fedora got a bug report of a regression when trying to remove the
> the macsec module (https://bugzilla.redhat.com/show_bug.cgi?id=1566410).
> I did a bisect and found
> 
> commit 5dcd8400884cc4a043a6d4617e042489e5d566a9
> Author: Dan Carpenter 
> Date:   Wed Mar 21 11:09:01 2018 +0300
> 
> macsec: missing dev_put() on error in macsec_newlink()
> We moved the dev_hold(real_dev); call earlier in the function but forgot
> to update the error paths.
> Fixes: 0759e552bce7 ("macsec: fix negative refcnt on parent link")
> Signed-off-by: Dan Carpenter 
> Signed-off-by: David S. Miller 
> 
> The script I used for testing based on the reporter is attached. It
> looks like modprobe is stuck in the D state. Any idea?

I don't think that reference was actually leaked. It gets released in
macsec_free_netdev() when the device is deleted.

modprobe getting stuck is just a side-effect of the refcount going
negative on the parent device, since removing the module needs to take
the lock that is held by device deletion.

I'll send a revert tomorrow.

Thanks for the report,

-- 
Sabrina

Re: Regression with 5dcd8400884c ("macsec: missing dev_put() on error in macsec_newlink()")

[Sabrina Dubroca]

Hello Laura,

2018-04-14, 10:56:55 -0700, Laura Abbott wrote:
> Hi,
> 
> Fedora got a bug report of a regression when trying to remove the
> the macsec module (https://bugzilla.redhat.com/show_bug.cgi?id=1566410).
> I did a bisect and found
> 
> commit 5dcd8400884cc4a043a6d4617e042489e5d566a9
> Author: Dan Carpenter 
> Date:   Wed Mar 21 11:09:01 2018 +0300
> 
> macsec: missing dev_put() on error in macsec_newlink()
> We moved the dev_hold(real_dev); call earlier in the function but forgot
> to update the error paths.
> Fixes: 0759e552bce7 ("macsec: fix negative refcnt on parent link")
> Signed-off-by: Dan Carpenter 
> Signed-off-by: David S. Miller 
> 
> The script I used for testing based on the reporter is attached. It
> looks like modprobe is stuck in the D state. Any idea?

I don't think that reference was actually leaked. It gets released in
macsec_free_netdev() when the device is deleted.

modprobe getting stuck is just a side-effect of the refcount going
negative on the parent device, since removing the module needs to take
the lock that is held by device deletion.

I'll send a revert tomorrow.

Thanks for the report,

-- 
Sabrina

[PATCH] KVM: Switch 'requests' to be 64-bit (explicitly)

[KarimAllah Ahmed]

Switch 'requests' to be explicitly 64-bit and update BUILD_BUG_ON check to
use the size of "requests" instead of the hard-coded '32'.

That gives us a bit more room again for arch-specific requests as we
already ran out of space for x86 due to the hard-coded check.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: KarimAllah Ahmed 
---
 include/linux/kvm_host.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6930c63..fe4f46b 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -129,7 +129,7 @@ static inline bool is_error_page(struct page *page)
 #define KVM_REQUEST_ARCH_BASE 8
 
 #define KVM_ARCH_REQ_FLAGS(nr, flags) ({ \
-   BUILD_BUG_ON((unsigned)(nr) >= 32 - KVM_REQUEST_ARCH_BASE); \
+   BUILD_BUG_ON((unsigned)(nr) >= (sizeof(((struct kvm_vcpu 
*)0)->requests) * 8) - KVM_REQUEST_ARCH_BASE); \
(unsigned)(((nr) + KVM_REQUEST_ARCH_BASE) | (flags)); \
 })
 #define KVM_ARCH_REQ(nr)   KVM_ARCH_REQ_FLAGS(nr, 0)
@@ -223,7 +223,7 @@ struct kvm_vcpu {
int vcpu_id;
int srcu_idx;
int mode;
-   unsigned long requests;
+   u64 requests;
unsigned long guest_debug;
 
int pre_pcpu;
@@ -1122,7 +1122,7 @@ static inline void kvm_make_request(int req, struct 
kvm_vcpu *vcpu)
 * caller.  Paired with the smp_mb__after_atomic in kvm_check_request.
 */
smp_wmb();
-   set_bit(req & KVM_REQUEST_MASK, >requests);
+   set_bit(req & KVM_REQUEST_MASK, (void *)>requests);
 }
 
 static inline bool kvm_request_pending(struct kvm_vcpu *vcpu)
@@ -1132,12 +1132,12 @@ static inline bool kvm_request_pending(struct kvm_vcpu 
*vcpu)
 
 static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
 {
-   return test_bit(req & KVM_REQUEST_MASK, >requests);
+   return test_bit(req & KVM_REQUEST_MASK, (void *)>requests);
 }
 
 static inline void kvm_clear_request(int req, struct kvm_vcpu *vcpu)
 {
-   clear_bit(req & KVM_REQUEST_MASK, >requests);
+   clear_bit(req & KVM_REQUEST_MASK, (void *)>requests);
 }
 
 static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
-- 
2.7.4

[PATCH] KVM: Switch 'requests' to be 64-bit (explicitly)

[KarimAllah Ahmed]

Switch 'requests' to be explicitly 64-bit and update BUILD_BUG_ON check to
use the size of "requests" instead of the hard-coded '32'.

That gives us a bit more room again for arch-specific requests as we
already ran out of space for x86 due to the hard-coded check.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: KarimAllah Ahmed 
---
 include/linux/kvm_host.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6930c63..fe4f46b 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -129,7 +129,7 @@ static inline bool is_error_page(struct page *page)
 #define KVM_REQUEST_ARCH_BASE 8
 
 #define KVM_ARCH_REQ_FLAGS(nr, flags) ({ \
-   BUILD_BUG_ON((unsigned)(nr) >= 32 - KVM_REQUEST_ARCH_BASE); \
+   BUILD_BUG_ON((unsigned)(nr) >= (sizeof(((struct kvm_vcpu 
*)0)->requests) * 8) - KVM_REQUEST_ARCH_BASE); \
(unsigned)(((nr) + KVM_REQUEST_ARCH_BASE) | (flags)); \
 })
 #define KVM_ARCH_REQ(nr)   KVM_ARCH_REQ_FLAGS(nr, 0)
@@ -223,7 +223,7 @@ struct kvm_vcpu {
int vcpu_id;
int srcu_idx;
int mode;
-   unsigned long requests;
+   u64 requests;
unsigned long guest_debug;
 
int pre_pcpu;
@@ -1122,7 +1122,7 @@ static inline void kvm_make_request(int req, struct 
kvm_vcpu *vcpu)
 * caller.  Paired with the smp_mb__after_atomic in kvm_check_request.
 */
smp_wmb();
-   set_bit(req & KVM_REQUEST_MASK, >requests);
+   set_bit(req & KVM_REQUEST_MASK, (void *)>requests);
 }
 
 static inline bool kvm_request_pending(struct kvm_vcpu *vcpu)
@@ -1132,12 +1132,12 @@ static inline bool kvm_request_pending(struct kvm_vcpu 
*vcpu)
 
 static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
 {
-   return test_bit(req & KVM_REQUEST_MASK, >requests);
+   return test_bit(req & KVM_REQUEST_MASK, (void *)>requests);
 }
 
 static inline void kvm_clear_request(int req, struct kvm_vcpu *vcpu)
 {
-   clear_bit(req & KVM_REQUEST_MASK, >requests);
+   clear_bit(req & KVM_REQUEST_MASK, (void *)>requests);
 }
 
 static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
-- 
2.7.4

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Linus Torvalds]

On Sat, Apr 14, 2018 at 1:58 PM, Al Viro  wrote:
>
> That breaks d_invalidate(), unfortunately.  Look at the termination
> conditions in the loop there...

Ugh. I was going to say "but that doesn't even use select_collect()",
but yeah, detach_and_collect() calls it.

It would be easy enough to just change the

if (!list_empty())

there to

if (!list_empty())

too.

In fact, it probably *should* do that, exactly to get the whole
"cond_resched()" call in that whole call chain too. Because as-is, it
looks like it has the same issue as shrink_dcache_parent() does..

But yeah, the fact that I didn't notice that makes me a bit nervous.
But now I triple-checked, there are no other indirect callers.

Linus

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Linus Torvalds]

On Sat, Apr 14, 2018 at 1:58 PM, Al Viro  wrote:
>
> That breaks d_invalidate(), unfortunately.  Look at the termination
> conditions in the loop there...

Ugh. I was going to say "but that doesn't even use select_collect()",
but yeah, detach_and_collect() calls it.

It would be easy enough to just change the

if (!list_empty())

there to

if (!list_empty())

too.

In fact, it probably *should* do that, exactly to get the whole
"cond_resched()" call in that whole call chain too. Because as-is, it
looks like it has the same issue as shrink_dcache_parent() does..

But yeah, the fact that I didn't notice that makes me a bit nervous.
But now I triple-checked, there are no other indirect callers.

Linus

Re: 4.15.14 crash with iscsi target and dvd

[Wakko Warner]

Ming Lei wrote:
> On Thu, Apr 12, 2018 at 09:43:02PM -0400, Wakko Warner wrote:
> > Ming Lei wrote:
> > > On Tue, Apr 10, 2018 at 08:45:25PM -0400, Wakko Warner wrote:
> > > > Sorry for the delay.  I reverted my change, added this one.  I didn't
> > > > reboot, I just unloaded and loaded this one.
> > > > Note: /dev/sr1 as seen from the initiator is /dev/sr0 (physical disc) 
> > > > on the
> > > > target.
> > > > 
> > > > Doesn't crash, however on the initiator I see this:
> > > > [9273849.70] ISO 9660 Extensions: RRIP_1991A
> > > > [9273863.359718] scsi_io_completion: 13 callbacks suppressed
> > > > [9273863.359788] sr 26:0:0:0: [sr1] tag#1 UNKNOWN(0x2003) Result: 
> > > > hostbyte=0x00 driverbyte=0x08
> > > > [9273863.359909] sr 26:0:0:0: [sr1] tag#1 Sense Key : 0x2 [current] 
> > > > [9273863.359974] sr 26:0:0:0: [sr1] tag#1 ASC=0x8 ASCQ=0x0 
> > > > [9273863.360036] sr 26:0:0:0: [sr1] tag#1 CDB: opcode=0x28 28 00 00 22 
> > > > f6 96 00 00 80 00
> > > > [9273863.360116] blk_update_request: 13 callbacks suppressed
> > > > [9273863.360177] blk_update_request: I/O error, dev sr1, sector 9165400
> > > > [9273875.864648] sr 26:0:0:0: [sr1] tag#1 UNKNOWN(0x2003) Result: 
> > > > hostbyte=0x00 driverbyte=0x08
> > > > [9273875.864738] sr 26:0:0:0: [sr1] tag#1 Sense Key : 0x2 [current] 
> > > > [9273875.864801] sr 26:0:0:0: [sr1] tag#1 ASC=0x8 ASCQ=0x0 
> > > > [9273875.864890] sr 26:0:0:0: [sr1] tag#1 CDB: opcode=0x28 28 00 00 22 
> > > > f7 16 00 00 80 00
> > > > [9273875.864971] blk_update_request: I/O error, dev sr1, sector 9165912
> > > > 
> > > > To cause this, I mounted the dvd as seen in the first line and ran this
> > > > command: find /cdrom2 -type f | xargs -tn1 cat > /dev/null
> > > > I did some various tests.  Each test was done after umount and mount to
> > > > clear the cache.
> > > > cat  > /dev/null causes the message.
> > > > dd if= of=/dev/null bs=2048 doesn't
> > > > using bs=4096 doesn't
> > > > using bs=64k doesn't
> > > > using bs=128k does
> > > > cat uses a blocksize of 128k.
> > > > 
> > > > The following was done without being mounted.
> > > > ddrescue -f -f /dev/sr1 /dev/null 
> > > > doesn't cause the message
> > > > dd if=/dev/sr1 of=/dev/null bs=128k
> > > > doesn't cause the message
> > > > using bs=256k causes the message once:
> > > > [9275916.857409] sr 27:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result: 
> > > > hostbyte=0x00 driverbyte=0x08
> > > > [9275916.857482] sr 27:0:0:0: [sr1] tag#0 Sense Key : 0x2 [current] 
> > > > [9275916.857520] sr 27:0:0:0: [sr1] tag#0 ASC=0x8 ASCQ=0x0 
> > > > [9275916.857556] sr 27:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 
> > > > 00 00 00 00 80 00
> > > > [9275916.857614] blk_update_request: I/O error, dev sr1, sector 0
> > > > 
> > > > If I access the disc from the target natively either by mounting and
> > > > accessing files or working with the device directly (ie dd) no errors 
> > > > are
> > > > logged on the target.
> > > 
> > > OK, thanks for your test.
> > > 
> > > Could you test the following patch and see if there is still the failure
> > > message?
> > > 
> > > diff --git a/drivers/target/target_core_pscsi.c 
> > > b/drivers/target/target_core_pscsi.c
> > > index 0d99b242e82e..6137287b52fb 100644
> > > --- a/drivers/target/target_core_pscsi.c
> > > +++ b/drivers/target/target_core_pscsi.c
> > > @@ -913,9 +913,11 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist 
> > > *sgl, u32 sgl_nents,
> > >  
> > >   rc = bio_add_pc_page(pdv->pdv_sd->request_queue,
> > >   bio, page, bytes, off);
> > > + if (rc != bytes)
> > > + goto fail;
> > >   pr_debug("PSCSI: bio->bi_vcnt: %d nr_vecs: %d\n",
> > >   bio_segments(bio), nr_vecs);
> > > - if (rc != bytes) {
> > > + if (/*rc != bytes*/0) {
> > >   pr_debug("PSCSI: Reached bio->bi_vcnt max:"
> > >   " %d i: %d bio: %p, allocating another"
> > >   " bio\n", bio->bi_vcnt, i, bio);
> > 
> > Target doesn't crash but the errors on the initiator are still there.
> 
> OK, then this error log isn't related with my commit, because the patch
> I sent to you in last email is to revert my commit simply.
> 
> But the following patch is one correct fix for your crash.
> 
> https://marc.info/?l=linux-kernel=152331690727052=2

Ok, that'll be the one I used.  Do you know when it'll go upstream?

-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

Re: 4.15.14 crash with iscsi target and dvd

[Wakko Warner]

Ming Lei wrote:
> On Thu, Apr 12, 2018 at 09:43:02PM -0400, Wakko Warner wrote:
> > Ming Lei wrote:
> > > On Tue, Apr 10, 2018 at 08:45:25PM -0400, Wakko Warner wrote:
> > > > Sorry for the delay.  I reverted my change, added this one.  I didn't
> > > > reboot, I just unloaded and loaded this one.
> > > > Note: /dev/sr1 as seen from the initiator is /dev/sr0 (physical disc) 
> > > > on the
> > > > target.
> > > > 
> > > > Doesn't crash, however on the initiator I see this:
> > > > [9273849.70] ISO 9660 Extensions: RRIP_1991A
> > > > [9273863.359718] scsi_io_completion: 13 callbacks suppressed
> > > > [9273863.359788] sr 26:0:0:0: [sr1] tag#1 UNKNOWN(0x2003) Result: 
> > > > hostbyte=0x00 driverbyte=0x08
> > > > [9273863.359909] sr 26:0:0:0: [sr1] tag#1 Sense Key : 0x2 [current] 
> > > > [9273863.359974] sr 26:0:0:0: [sr1] tag#1 ASC=0x8 ASCQ=0x0 
> > > > [9273863.360036] sr 26:0:0:0: [sr1] tag#1 CDB: opcode=0x28 28 00 00 22 
> > > > f6 96 00 00 80 00
> > > > [9273863.360116] blk_update_request: 13 callbacks suppressed
> > > > [9273863.360177] blk_update_request: I/O error, dev sr1, sector 9165400
> > > > [9273875.864648] sr 26:0:0:0: [sr1] tag#1 UNKNOWN(0x2003) Result: 
> > > > hostbyte=0x00 driverbyte=0x08
> > > > [9273875.864738] sr 26:0:0:0: [sr1] tag#1 Sense Key : 0x2 [current] 
> > > > [9273875.864801] sr 26:0:0:0: [sr1] tag#1 ASC=0x8 ASCQ=0x0 
> > > > [9273875.864890] sr 26:0:0:0: [sr1] tag#1 CDB: opcode=0x28 28 00 00 22 
> > > > f7 16 00 00 80 00
> > > > [9273875.864971] blk_update_request: I/O error, dev sr1, sector 9165912
> > > > 
> > > > To cause this, I mounted the dvd as seen in the first line and ran this
> > > > command: find /cdrom2 -type f | xargs -tn1 cat > /dev/null
> > > > I did some various tests.  Each test was done after umount and mount to
> > > > clear the cache.
> > > > cat  > /dev/null causes the message.
> > > > dd if= of=/dev/null bs=2048 doesn't
> > > > using bs=4096 doesn't
> > > > using bs=64k doesn't
> > > > using bs=128k does
> > > > cat uses a blocksize of 128k.
> > > > 
> > > > The following was done without being mounted.
> > > > ddrescue -f -f /dev/sr1 /dev/null 
> > > > doesn't cause the message
> > > > dd if=/dev/sr1 of=/dev/null bs=128k
> > > > doesn't cause the message
> > > > using bs=256k causes the message once:
> > > > [9275916.857409] sr 27:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result: 
> > > > hostbyte=0x00 driverbyte=0x08
> > > > [9275916.857482] sr 27:0:0:0: [sr1] tag#0 Sense Key : 0x2 [current] 
> > > > [9275916.857520] sr 27:0:0:0: [sr1] tag#0 ASC=0x8 ASCQ=0x0 
> > > > [9275916.857556] sr 27:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 
> > > > 00 00 00 00 80 00
> > > > [9275916.857614] blk_update_request: I/O error, dev sr1, sector 0
> > > > 
> > > > If I access the disc from the target natively either by mounting and
> > > > accessing files or working with the device directly (ie dd) no errors 
> > > > are
> > > > logged on the target.
> > > 
> > > OK, thanks for your test.
> > > 
> > > Could you test the following patch and see if there is still the failure
> > > message?
> > > 
> > > diff --git a/drivers/target/target_core_pscsi.c 
> > > b/drivers/target/target_core_pscsi.c
> > > index 0d99b242e82e..6137287b52fb 100644
> > > --- a/drivers/target/target_core_pscsi.c
> > > +++ b/drivers/target/target_core_pscsi.c
> > > @@ -913,9 +913,11 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist 
> > > *sgl, u32 sgl_nents,
> > >  
> > >   rc = bio_add_pc_page(pdv->pdv_sd->request_queue,
> > >   bio, page, bytes, off);
> > > + if (rc != bytes)
> > > + goto fail;
> > >   pr_debug("PSCSI: bio->bi_vcnt: %d nr_vecs: %d\n",
> > >   bio_segments(bio), nr_vecs);
> > > - if (rc != bytes) {
> > > + if (/*rc != bytes*/0) {
> > >   pr_debug("PSCSI: Reached bio->bi_vcnt max:"
> > >   " %d i: %d bio: %p, allocating another"
> > >   " bio\n", bio->bi_vcnt, i, bio);
> > 
> > Target doesn't crash but the errors on the initiator are still there.
> 
> OK, then this error log isn't related with my commit, because the patch
> I sent to you in last email is to revert my commit simply.
> 
> But the following patch is one correct fix for your crash.
> 
> https://marc.info/?l=linux-kernel=152331690727052=2

Ok, that'll be the one I used.  Do you know when it'll go upstream?

-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions

[Julia Lawall]

On Wed, 11 Apr 2018, Joe Perches wrote:

> On Thu, 2018-04-12 at 08:22 +0200, Julia Lawall wrote:
> > On Wed, 11 Apr 2018, Joe Perches wrote:
> > > On Wed, 2018-04-11 at 09:29 -0700, Andrew Morton wrote:
> > > > We already have some 500 bools-in-structs
> > >
> > > I got at least triple that only in include/
> > > so I expect there are at probably an order
> > > of magnitude more than 500 in the kernel.
> > >
> > > I suppose some cocci script could count the
> > > actual number of instances.  A regex can not.
> >
> > I got 12667.
>
> Could you please post the cocci script?
>
> > I'm not sure to understand the issue.  Will using a bitfield help if there
> > are no other bitfields in the structure?
>
> IMO, not really.
>
> The primary issue is described by Linus here:
> https://lkml.org/lkml/2017/11/21/384
>
> I personally do not find a significant issue with
> uncontrolled sizes of bool in kernel structs as
> all of the kernel structs are transitory and not
> written out to storage.
>
> I suppose bool bitfields are also OK, but for the
> RMW required.
>
> Using unsigned int :1 bitfield instead of bool :1
> has the negative of truncation so that the uint
> has to be set with !! instead of a simple assign.

At least with gcc 5.4.0, a number of structures become larger with
unsigned int :1. bool:1 seems to mostly solve this problem.  The structure
ichx_desc, defined in drivers/gpio/gpio-ich.c seems to become larger with
both approaches.

julia

Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions

[Julia Lawall]

On Wed, 11 Apr 2018, Joe Perches wrote:

> On Thu, 2018-04-12 at 08:22 +0200, Julia Lawall wrote:
> > On Wed, 11 Apr 2018, Joe Perches wrote:
> > > On Wed, 2018-04-11 at 09:29 -0700, Andrew Morton wrote:
> > > > We already have some 500 bools-in-structs
> > >
> > > I got at least triple that only in include/
> > > so I expect there are at probably an order
> > > of magnitude more than 500 in the kernel.
> > >
> > > I suppose some cocci script could count the
> > > actual number of instances.  A regex can not.
> >
> > I got 12667.
>
> Could you please post the cocci script?
>
> > I'm not sure to understand the issue.  Will using a bitfield help if there
> > are no other bitfields in the structure?
>
> IMO, not really.
>
> The primary issue is described by Linus here:
> https://lkml.org/lkml/2017/11/21/384
>
> I personally do not find a significant issue with
> uncontrolled sizes of bool in kernel structs as
> all of the kernel structs are transitory and not
> written out to storage.
>
> I suppose bool bitfields are also OK, but for the
> RMW required.
>
> Using unsigned int :1 bitfield instead of bool :1
> has the negative of truncation so that the uint
> has to be set with !! instead of a simple assign.

At least with gcc 5.4.0, a number of structures become larger with
unsigned int :1. bool:1 seems to mostly solve this problem.  The structure
ichx_desc, defined in drivers/gpio/gpio-ich.c seems to become larger with
both approaches.

julia

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Al Viro]

On Sat, Apr 14, 2018 at 09:36:23AM -0700, Linus Torvalds wrote:
> But it does *not* make sense for the case where we've hit a dentry
> that is already on the shrink list. Sure, we'll continue to gather all
> the other dentries, but if there is concurrent shrinking, shouldn't we
> give up the CPU more eagerly - *particularly* if somebody else is
> waiting (it might be the other process that actually gets rid of the
> shrinking dentries!)?
> 
> So my gut feel is that we should at least try doing something like
> this in select_collect():
> 
> -   if (!list_empty(>dispose))
> +   if (data->found)
> ret = need_resched() ? D_WALK_QUIT : D_WALK_NORETRY;
> 
> because even if we haven't actually been able to shrink something, if
> we hit an already shrinking entry we should probably at least not do
> the "retry for rename". And if we actually are going to reschedule, we
> might as well start from the beginning.
> 
> I realize that *this* thread might not be making any actual progress
> (because it didn't find any dentries to shrink), but since it did find
> _a_ dentry that is being shrunk, we know the operation itself - on a
> bigger scale - is making progress.
> 
> Hmm?

That breaks d_invalidate(), unfortunately.  Look at the termination
conditions in the loop there...

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Al Viro]

On Sat, Apr 14, 2018 at 09:36:23AM -0700, Linus Torvalds wrote:
> But it does *not* make sense for the case where we've hit a dentry
> that is already on the shrink list. Sure, we'll continue to gather all
> the other dentries, but if there is concurrent shrinking, shouldn't we
> give up the CPU more eagerly - *particularly* if somebody else is
> waiting (it might be the other process that actually gets rid of the
> shrinking dentries!)?
> 
> So my gut feel is that we should at least try doing something like
> this in select_collect():
> 
> -   if (!list_empty(>dispose))
> +   if (data->found)
> ret = need_resched() ? D_WALK_QUIT : D_WALK_NORETRY;
> 
> because even if we haven't actually been able to shrink something, if
> we hit an already shrinking entry we should probably at least not do
> the "retry for rename". And if we actually are going to reschedule, we
> might as well start from the beginning.
> 
> I realize that *this* thread might not be making any actual progress
> (because it didn't find any dentries to shrink), but since it did find
> _a_ dentry that is being shrunk, we know the operation itself - on a
> bigger scale - is making progress.
> 
> Hmm?

That breaks d_invalidate(), unfortunately.  Look at the termination
conditions in the loop there...

[PATCH 3/3] net: macb: Receive Side Coalescing (RSC) feature added.

[Rafal Ozieblo]

This is basically the same as Large Receive Offload (LRO)
in Linux framework.

Signed-off-by: Rafal Ozieblo 
---
 drivers/net/ethernet/cadence/macb.h  |  6 +++
 drivers/net/ethernet/cadence/macb_main.c | 70 +++-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index a2cb805..9ebdde7 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -83,6 +83,7 @@
 #define GEM_USRIO  0x000c /* User IO */
 #define GEM_DMACFG 0x0010 /* DMA Configuration */
 #define GEM_JML0x0048 /* Jumbo Max Length */
+#define GEM_RSC0x0058 /* RSC Control */
 #define GEM_HRB0x0080 /* Hash Bottom */
 #define GEM_HRT0x0084 /* Hash Top */
 #define GEM_SA1B   0x0088 /* Specific1 Bottom */
@@ -318,6 +319,11 @@
 #define GEM_ADDR64_OFFSET  30 /* Address bus width - 64b or 32b */
 #define GEM_ADDR64_SIZE1
 
+/* Bitfields in RSC control */
+#define GEM_RSCCTRL_OFFSET 1 /* RSC control */
+#define GEM_RSCCTRL_SIZE   15
+#define GEM_CLRMSK_OFFSET  16 /* RSC clear mask */
+#define GEM_CLRMSK_SIZE1
 
 /* Bitfields in NSR */
 #define MACB_NSR_LINK_OFFSET   0 /* pcs_link_state */
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 27c406c..92bdcf1 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2377,6 +2377,8 @@ static int macb_open(struct net_device *dev)
 
if (!(bp->dev->hw_features & NETIF_F_LRO))
bufsz += NET_IP_ALIGN;
+   else
+   bufsz = 0xFF * 64; // For RSC Buffer Sizes must be set to 16K.
 
/* RX buffers initialization */
macb_init_rx_buffer_size(bp, bufsz);
@@ -2801,6 +2803,62 @@ static int macb_get_ts_info(struct net_device *netdev,
return ethtool_op_get_ts_info(netdev, info);
 }
 
+static void gem_enable_hdr_data_split(struct macb *bp, bool enable)
+{
+   u32 dmacfg;
+
+   dmacfg = gem_readl(bp, DMACFG);
+   if (enable)
+   dmacfg |= GEM_BIT(HDRS);
+   else
+   dmacfg &= ~GEM_BIT(HDRS);
+   gem_writel(bp, DMACFG, dmacfg);
+}
+
+static void gem_update_rsc_state(struct macb *bp, netdev_features_t feature)
+{
+   u32 rsc_control, rsc_control_new, queue, rsc;
+   bool enable, jumbo, any_enabled = false;
+   struct ethtool_rx_fs_item *item;
+   unsigned long flags;
+   u32 ncfgr;
+
+   enable = (!!(feature & NETIF_F_NTUPLE) && !!(feature & NETIF_F_LRO));
+   rsc = gem_readl(bp, RSC);
+   rsc_control = GEM_BFEXT(RSCCTRL, rsc);
+   rsc_control_new = 0;
+   if (enable) {
+   list_for_each_entry(item, >rx_fs_list.list, list) {
+   queue = item->fs.ring_cookie;
+   rsc_control_new |= (1 << (queue - 1));
+   any_enabled = true;
+   netdev_dbg(bp->dev, "RSC %sabled for queue %u\n",
+  enable ? "en" : "dis", queue);
+   }
+   }
+   if (rsc_control_new != rsc_control) {
+   rsc = GEM_BFINS(RSCCTRL, rsc_control_new, rsc);
+   gem_writel(bp, RSC, rsc);
+   }
+   if (bp->caps & MACB_CAPS_JUMBO) {
+   /* Don't enable jumbo mode for RSC:
+* disable unless not RSC and large MTU
+*/
+   ncfgr = gem_readl(bp, NCFGR);
+   enable = !any_enabled;
+   jumbo = !!MACB_BFEXT(JFRAME, ncfgr);
+   /* and don't touch if already in the state we want */
+   if ((jumbo && !enable) || (!jumbo && enable)) {
+   ncfgr = MACB_BFINS(JFRAME, enable, ncfgr);
+   spin_lock_irqsave(>lock, flags);
+   gem_writel(bp, NCFGR, ncfgr);
+   spin_unlock_irqrestore(>lock, flags);
+   }
+   }
+   /* Need to enable header-data splitting also */
+   gem_enable_hdr_data_split(bp, any_enabled);
+}
+
 static void gem_enable_flow_filters(struct macb *bp, bool enable)
 {
struct ethtool_rx_fs_item *item;
@@ -2969,6 +3027,8 @@ static int gem_add_flow_filter(struct net_device *netdev,
if (netdev->features & NETIF_F_NTUPLE)
gem_enable_flow_filters(bp, 1);
 
+   /* enable RSC if LRO & NTUPLE on */
+   gem_update_rsc_state(bp, netdev->features);
spin_unlock_irqrestore(>rx_fs_lock, flags);
return 0;
 
@@ -3009,6 +3069,7 @@ static int gem_del_flow_filter(struct net_device *netdev,
return 0;
}
}
+   gem_update_rsc_state(bp, netdev->features);
 
spin_unlock_irqrestore(>rx_fs_lock, flags);
return -EINVAL;
@@ 

[PATCH 3/3] net: macb: Receive Side Coalescing (RSC) feature added.

[Rafal Ozieblo]

This is basically the same as Large Receive Offload (LRO)
in Linux framework.

Signed-off-by: Rafal Ozieblo 
---
 drivers/net/ethernet/cadence/macb.h  |  6 +++
 drivers/net/ethernet/cadence/macb_main.c | 70 +++-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index a2cb805..9ebdde7 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -83,6 +83,7 @@
 #define GEM_USRIO  0x000c /* User IO */
 #define GEM_DMACFG 0x0010 /* DMA Configuration */
 #define GEM_JML0x0048 /* Jumbo Max Length */
+#define GEM_RSC0x0058 /* RSC Control */
 #define GEM_HRB0x0080 /* Hash Bottom */
 #define GEM_HRT0x0084 /* Hash Top */
 #define GEM_SA1B   0x0088 /* Specific1 Bottom */
@@ -318,6 +319,11 @@
 #define GEM_ADDR64_OFFSET  30 /* Address bus width - 64b or 32b */
 #define GEM_ADDR64_SIZE1
 
+/* Bitfields in RSC control */
+#define GEM_RSCCTRL_OFFSET 1 /* RSC control */
+#define GEM_RSCCTRL_SIZE   15
+#define GEM_CLRMSK_OFFSET  16 /* RSC clear mask */
+#define GEM_CLRMSK_SIZE1
 
 /* Bitfields in NSR */
 #define MACB_NSR_LINK_OFFSET   0 /* pcs_link_state */
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 27c406c..92bdcf1 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2377,6 +2377,8 @@ static int macb_open(struct net_device *dev)
 
if (!(bp->dev->hw_features & NETIF_F_LRO))
bufsz += NET_IP_ALIGN;
+   else
+   bufsz = 0xFF * 64; // For RSC Buffer Sizes must be set to 16K.
 
/* RX buffers initialization */
macb_init_rx_buffer_size(bp, bufsz);
@@ -2801,6 +2803,62 @@ static int macb_get_ts_info(struct net_device *netdev,
return ethtool_op_get_ts_info(netdev, info);
 }
 
+static void gem_enable_hdr_data_split(struct macb *bp, bool enable)
+{
+   u32 dmacfg;
+
+   dmacfg = gem_readl(bp, DMACFG);
+   if (enable)
+   dmacfg |= GEM_BIT(HDRS);
+   else
+   dmacfg &= ~GEM_BIT(HDRS);
+   gem_writel(bp, DMACFG, dmacfg);
+}
+
+static void gem_update_rsc_state(struct macb *bp, netdev_features_t feature)
+{
+   u32 rsc_control, rsc_control_new, queue, rsc;
+   bool enable, jumbo, any_enabled = false;
+   struct ethtool_rx_fs_item *item;
+   unsigned long flags;
+   u32 ncfgr;
+
+   enable = (!!(feature & NETIF_F_NTUPLE) && !!(feature & NETIF_F_LRO));
+   rsc = gem_readl(bp, RSC);
+   rsc_control = GEM_BFEXT(RSCCTRL, rsc);
+   rsc_control_new = 0;
+   if (enable) {
+   list_for_each_entry(item, >rx_fs_list.list, list) {
+   queue = item->fs.ring_cookie;
+   rsc_control_new |= (1 << (queue - 1));
+   any_enabled = true;
+   netdev_dbg(bp->dev, "RSC %sabled for queue %u\n",
+  enable ? "en" : "dis", queue);
+   }
+   }
+   if (rsc_control_new != rsc_control) {
+   rsc = GEM_BFINS(RSCCTRL, rsc_control_new, rsc);
+   gem_writel(bp, RSC, rsc);
+   }
+   if (bp->caps & MACB_CAPS_JUMBO) {
+   /* Don't enable jumbo mode for RSC:
+* disable unless not RSC and large MTU
+*/
+   ncfgr = gem_readl(bp, NCFGR);
+   enable = !any_enabled;
+   jumbo = !!MACB_BFEXT(JFRAME, ncfgr);
+   /* and don't touch if already in the state we want */
+   if ((jumbo && !enable) || (!jumbo && enable)) {
+   ncfgr = MACB_BFINS(JFRAME, enable, ncfgr);
+   spin_lock_irqsave(>lock, flags);
+   gem_writel(bp, NCFGR, ncfgr);
+   spin_unlock_irqrestore(>lock, flags);
+   }
+   }
+   /* Need to enable header-data splitting also */
+   gem_enable_hdr_data_split(bp, any_enabled);
+}
+
 static void gem_enable_flow_filters(struct macb *bp, bool enable)
 {
struct ethtool_rx_fs_item *item;
@@ -2969,6 +3027,8 @@ static int gem_add_flow_filter(struct net_device *netdev,
if (netdev->features & NETIF_F_NTUPLE)
gem_enable_flow_filters(bp, 1);
 
+   /* enable RSC if LRO & NTUPLE on */
+   gem_update_rsc_state(bp, netdev->features);
spin_unlock_irqrestore(>rx_fs_lock, flags);
return 0;
 
@@ -3009,6 +3069,7 @@ static int gem_del_flow_filter(struct net_device *netdev,
return 0;
}
}
+   gem_update_rsc_state(bp, netdev->features);
 
spin_unlock_irqrestore(>rx_fs_lock, flags);
return -EINVAL;
@@ -3191,7 +3252,12 @@ 

Inbox SMTP, Inbox Webmail, I Sell Sure Spamming Toolz

[Mr Spamming]

I Sell Sure Spamming Toolz 
What we have on Stock Daily 

Inbox Webmail
Inbox SMTP
Fresh USA email leads
Fresh Canada email leads
Fresh Loan email leads
Fresh Business emails leads
Real Eastate email leads
Conference delegates email leads
Fresh Job Seaker emails
cPanel HTTP and HTTPs
Shell Zip/Unzipp
Mailer
RDP
All ScamPages
Bank ScamPage

Add me on whatsapp or call me

Watsapp: +2348107268246

Only Real buyers

Inbox SMTP, Inbox Webmail, I Sell Sure Spamming Toolz

[Mr Spamming]

I Sell Sure Spamming Toolz 
What we have on Stock Daily 

Inbox Webmail
Inbox SMTP
Fresh USA email leads
Fresh Canada email leads
Fresh Loan email leads
Fresh Business emails leads
Real Eastate email leads
Conference delegates email leads
Fresh Job Seaker emails
cPanel HTTP and HTTPs
Shell Zip/Unzipp
Mailer
RDP
All ScamPages
Bank ScamPage

Add me on whatsapp or call me

Watsapp: +2348107268246

Only Real buyers

[PATCH 2/3] net: macb: Add support for header data spliting

[Rafal Ozieblo]

This patch adds support for frames splited between
many rx buffers. Header data spliting can be used
but also buffers shorter than max frame length.
The only limitation is that frame header can't
be splited.

Signed-off-by: Rafal Ozieblo 
---
 drivers/net/ethernet/cadence/macb.h  |  13 +++
 drivers/net/ethernet/cadence/macb_main.c | 137 +++
 2 files changed, 118 insertions(+), 32 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 33c9a48..a2cb805 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -295,6 +295,8 @@
 /* Bitfields in DMACFG. */
 #define GEM_FBLDO_OFFSET   0 /* fixed burst length for DMA */
 #define GEM_FBLDO_SIZE 5
+#define GEM_HDRS_OFFSET5 /* Header Data Splitting */
+#define GEM_HDRS_SIZE  1
 #define GEM_ENDIA_DESC_OFFSET  6 /* endian swap mode for management descriptor 
access */
 #define GEM_ENDIA_DESC_SIZE1
 #define GEM_ENDIA_PKT_OFFSET   7 /* endian swap mode for packet data access */
@@ -755,8 +757,12 @@ struct gem_tx_ts {
 #define MACB_RX_SOF_SIZE   1
 #define MACB_RX_EOF_OFFSET 15
 #define MACB_RX_EOF_SIZE   1
+#define MACB_RX_HDR_OFFSET 16
+#define MACB_RX_HDR_SIZE   1
 #define MACB_RX_CFI_OFFSET 16
 #define MACB_RX_CFI_SIZE   1
+#define MACB_RX_EOH_OFFSET 17
+#define MACB_RX_EOH_SIZE   1
 #define MACB_RX_VLAN_PRI_OFFSET17
 #define MACB_RX_VLAN_PRI_SIZE  3
 #define MACB_RX_PRI_TAG_OFFSET 20
@@ -1086,6 +1092,11 @@ struct tsu_incr {
u32 ns;
 };
 
+struct rx_frag_list {
+   struct sk_buff  *skb_head;
+   struct sk_buff  *skb_tail;
+};
+
 struct macb_queue {
struct macb *bp;
int irq;
@@ -1121,6 +1132,8 @@ struct macb_queue {
unsigned inttx_ts_head, tx_ts_tail;
struct gem_tx_tstx_timestamps[PTP_TS_BUFFER_SIZE];
 #endif
+   struct rx_frag_list rx_frag;
+   u32 rx_frag_len;
 };
 
 struct ethtool_rx_fs_item {
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 43201a8..27c406c 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -967,6 +967,13 @@ static void discard_partial_frame(struct macb_queue 
*queue, unsigned int begin,
 */
 }
 
+void gem_reset_rx_state(struct macb_queue *queue)
+{
+   queue->rx_frag.skb_head = NULL;
+   queue->rx_frag.skb_tail = NULL;
+   queue->rx_frag_len = 0;
+}
+
 static int gem_rx(struct macb_queue *queue, int budget)
 {
struct macb *bp = queue->bp;
@@ -977,6 +984,9 @@ static int gem_rx(struct macb_queue *queue, int budget)
int count = 0;
 
while (count < budget) {
+   struct sk_buff *skb_head, *skb_tail;
+   bool eoh = false, header = false;
+   bool sof, eof;
u32 ctrl;
dma_addr_t addr;
bool rxused;
@@ -995,57 +1005,118 @@ static int gem_rx(struct macb_queue *queue, int budget)
break;
 
queue->rx_tail++;
-   count++;
-
-   if (!(ctrl & MACB_BIT(RX_SOF) && ctrl & MACB_BIT(RX_EOF))) {
+   skb = queue->rx_skbuff[entry];
+   if (unlikely(!skb)) {
netdev_err(bp->dev,
-  "not whole frame pointed by descriptor\n");
+  "inconsistent Rx descriptor chain\n");
bp->dev->stats.rx_dropped++;
queue->stats.rx_dropped++;
break;
}
-   skb = queue->rx_skbuff[entry];
-   if (unlikely(!skb)) {
+   skb_head = queue->rx_frag.skb_head;
+   skb_tail = queue->rx_frag.skb_tail;
+   sof = !!(ctrl & MACB_BIT(RX_SOF));
+   eof = !!(ctrl & MACB_BIT(RX_EOF));
+   if (GEM_BFEXT(HDRS, gem_readl(bp, DMACFG))) {
+   eoh = !!(ctrl & MACB_BIT(RX_EOH));
+   if (!eof)
+   header = !!(ctrl & MACB_BIT(RX_HDR));
+   }
+
+   queue->rx_skbuff[entry] = NULL;
+   /* Discard if out-of-sequence or header split across buffers */
+   if ((!skb_head /* first frame buffer */
+   && (!sof /* without start of frame */
+   || (header && !eoh))) /* or without whole header */
+   || (skb_head && sof)) { /* or new start before EOF */
+   struct sk_buff *tmp_skb;
+

[PATCH 2/3] net: macb: Add support for header data spliting

[Rafal Ozieblo]

This patch adds support for frames splited between
many rx buffers. Header data spliting can be used
but also buffers shorter than max frame length.
The only limitation is that frame header can't
be splited.

Signed-off-by: Rafal Ozieblo 
---
 drivers/net/ethernet/cadence/macb.h  |  13 +++
 drivers/net/ethernet/cadence/macb_main.c | 137 +++
 2 files changed, 118 insertions(+), 32 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 33c9a48..a2cb805 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -295,6 +295,8 @@
 /* Bitfields in DMACFG. */
 #define GEM_FBLDO_OFFSET   0 /* fixed burst length for DMA */
 #define GEM_FBLDO_SIZE 5
+#define GEM_HDRS_OFFSET5 /* Header Data Splitting */
+#define GEM_HDRS_SIZE  1
 #define GEM_ENDIA_DESC_OFFSET  6 /* endian swap mode for management descriptor 
access */
 #define GEM_ENDIA_DESC_SIZE1
 #define GEM_ENDIA_PKT_OFFSET   7 /* endian swap mode for packet data access */
@@ -755,8 +757,12 @@ struct gem_tx_ts {
 #define MACB_RX_SOF_SIZE   1
 #define MACB_RX_EOF_OFFSET 15
 #define MACB_RX_EOF_SIZE   1
+#define MACB_RX_HDR_OFFSET 16
+#define MACB_RX_HDR_SIZE   1
 #define MACB_RX_CFI_OFFSET 16
 #define MACB_RX_CFI_SIZE   1
+#define MACB_RX_EOH_OFFSET 17
+#define MACB_RX_EOH_SIZE   1
 #define MACB_RX_VLAN_PRI_OFFSET17
 #define MACB_RX_VLAN_PRI_SIZE  3
 #define MACB_RX_PRI_TAG_OFFSET 20
@@ -1086,6 +1092,11 @@ struct tsu_incr {
u32 ns;
 };
 
+struct rx_frag_list {
+   struct sk_buff  *skb_head;
+   struct sk_buff  *skb_tail;
+};
+
 struct macb_queue {
struct macb *bp;
int irq;
@@ -1121,6 +1132,8 @@ struct macb_queue {
unsigned inttx_ts_head, tx_ts_tail;
struct gem_tx_tstx_timestamps[PTP_TS_BUFFER_SIZE];
 #endif
+   struct rx_frag_list rx_frag;
+   u32 rx_frag_len;
 };
 
 struct ethtool_rx_fs_item {
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 43201a8..27c406c 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -967,6 +967,13 @@ static void discard_partial_frame(struct macb_queue 
*queue, unsigned int begin,
 */
 }
 
+void gem_reset_rx_state(struct macb_queue *queue)
+{
+   queue->rx_frag.skb_head = NULL;
+   queue->rx_frag.skb_tail = NULL;
+   queue->rx_frag_len = 0;
+}
+
 static int gem_rx(struct macb_queue *queue, int budget)
 {
struct macb *bp = queue->bp;
@@ -977,6 +984,9 @@ static int gem_rx(struct macb_queue *queue, int budget)
int count = 0;
 
while (count < budget) {
+   struct sk_buff *skb_head, *skb_tail;
+   bool eoh = false, header = false;
+   bool sof, eof;
u32 ctrl;
dma_addr_t addr;
bool rxused;
@@ -995,57 +1005,118 @@ static int gem_rx(struct macb_queue *queue, int budget)
break;
 
queue->rx_tail++;
-   count++;
-
-   if (!(ctrl & MACB_BIT(RX_SOF) && ctrl & MACB_BIT(RX_EOF))) {
+   skb = queue->rx_skbuff[entry];
+   if (unlikely(!skb)) {
netdev_err(bp->dev,
-  "not whole frame pointed by descriptor\n");
+  "inconsistent Rx descriptor chain\n");
bp->dev->stats.rx_dropped++;
queue->stats.rx_dropped++;
break;
}
-   skb = queue->rx_skbuff[entry];
-   if (unlikely(!skb)) {
+   skb_head = queue->rx_frag.skb_head;
+   skb_tail = queue->rx_frag.skb_tail;
+   sof = !!(ctrl & MACB_BIT(RX_SOF));
+   eof = !!(ctrl & MACB_BIT(RX_EOF));
+   if (GEM_BFEXT(HDRS, gem_readl(bp, DMACFG))) {
+   eoh = !!(ctrl & MACB_BIT(RX_EOH));
+   if (!eof)
+   header = !!(ctrl & MACB_BIT(RX_HDR));
+   }
+
+   queue->rx_skbuff[entry] = NULL;
+   /* Discard if out-of-sequence or header split across buffers */
+   if ((!skb_head /* first frame buffer */
+   && (!sof /* without start of frame */
+   || (header && !eoh))) /* or without whole header */
+   || (skb_head && sof)) { /* or new start before EOF */
+   struct sk_buff *tmp_skb;
+
netdev_err(bp->dev,
-  

[PATCH 1/3] net: macb: Add support for rsc capable hardware

[Rafal Ozieblo]

When the pbuf_rsc has been enabled in hardware
the receive buffer offset for incoming packets
cannot be changed in the network configuration register
(even when rsc is not use at all).

Signed-off-by: Rafal Ozieblo 
---
 drivers/net/ethernet/cadence/macb.h  |  2 ++
 drivers/net/ethernet/cadence/macb_main.c | 22 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 8665982..33c9a48 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -477,6 +477,8 @@
 /* Bitfields in DCFG6. */
 #define GEM_PBUF_LSO_OFFSET27
 #define GEM_PBUF_LSO_SIZE  1
+#define GEM_PBUF_RSC_OFFSET26
+#define GEM_PBUF_RSC_SIZE  1
 #define GEM_DAW64_OFFSET   23
 #define GEM_DAW64_SIZE 1
 
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index b4c9268..43201a8 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -930,8 +930,9 @@ static void gem_rx_refill(struct macb_queue *queue)
macb_set_addr(bp, desc, paddr);
desc->ctrl = 0;
 
-   /* properly align Ethernet header */
-   skb_reserve(skb, NET_IP_ALIGN);
+   if (!(bp->dev->hw_features & NETIF_F_LRO))
+   /* properly align Ethernet header */
+   skb_reserve(skb, NET_IP_ALIGN);
} else {
desc->addr &= ~MACB_BIT(RX_USED);
desc->ctrl = 0;
@@ -2110,7 +2111,13 @@ static void macb_init_hw(struct macb *bp)
config = macb_mdc_clk_div(bp);
if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII)
config |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
-   config |= MACB_BF(RBOF, NET_IP_ALIGN);  /* Make eth data aligned */
+   /* When the pbuf_rsc has been enabled in hardware the receive buffer
+* offset cannot be changed in the network configuration register.
+*/
+   if (!(bp->dev->hw_features &  NETIF_F_LRO))
+   /* Make eth data aligned */
+   config |= MACB_BF(RBOF, NET_IP_ALIGN);
+
config |= MACB_BIT(PAE);/* PAuse Enable */
config |= MACB_BIT(DRFCS);  /* Discard Rx FCS */
if (bp->caps & MACB_CAPS_JUMBO)
@@ -2281,7 +2288,7 @@ static void macb_set_rx_mode(struct net_device *dev)
 static int macb_open(struct net_device *dev)
 {
struct macb *bp = netdev_priv(dev);
-   size_t bufsz = dev->mtu + ETH_HLEN + ETH_FCS_LEN + NET_IP_ALIGN;
+   size_t bufsz = dev->mtu + ETH_HLEN + ETH_FCS_LEN;
struct macb_queue *queue;
unsigned int q;
int err;
@@ -2295,6 +2302,9 @@ static int macb_open(struct net_device *dev)
if (!dev->phydev)
return -EAGAIN;
 
+   if (!(bp->dev->hw_features & NETIF_F_LRO))
+   bufsz += NET_IP_ALIGN;
+
/* RX buffers initialization */
macb_init_rx_buffer_size(bp, bufsz);
 
@@ -3365,6 +3375,10 @@ static int macb_init(struct platform_device *pdev)
if (GEM_BFEXT(PBUF_LSO, gem_readl(bp, DCFG6)))
dev->hw_features |= MACB_NETIF_LSO;
 
+   /* Check RSC capability */
+   if (GEM_BFEXT(PBUF_RSC, gem_readl(bp, DCFG6)))
+   dev->hw_features |= NETIF_F_LRO;
+
/* Checksum offload is only available on gem with packet buffer */
if (macb_is_gem(bp) && !(bp->caps & MACB_CAPS_FIFO_MODE))
dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
-- 
2.4.5

[PATCH 1/3] net: macb: Add support for rsc capable hardware

[Rafal Ozieblo]

When the pbuf_rsc has been enabled in hardware
the receive buffer offset for incoming packets
cannot be changed in the network configuration register
(even when rsc is not use at all).

Signed-off-by: Rafal Ozieblo 
---
 drivers/net/ethernet/cadence/macb.h  |  2 ++
 drivers/net/ethernet/cadence/macb_main.c | 22 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 8665982..33c9a48 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -477,6 +477,8 @@
 /* Bitfields in DCFG6. */
 #define GEM_PBUF_LSO_OFFSET27
 #define GEM_PBUF_LSO_SIZE  1
+#define GEM_PBUF_RSC_OFFSET26
+#define GEM_PBUF_RSC_SIZE  1
 #define GEM_DAW64_OFFSET   23
 #define GEM_DAW64_SIZE 1
 
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index b4c9268..43201a8 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -930,8 +930,9 @@ static void gem_rx_refill(struct macb_queue *queue)
macb_set_addr(bp, desc, paddr);
desc->ctrl = 0;
 
-   /* properly align Ethernet header */
-   skb_reserve(skb, NET_IP_ALIGN);
+   if (!(bp->dev->hw_features & NETIF_F_LRO))
+   /* properly align Ethernet header */
+   skb_reserve(skb, NET_IP_ALIGN);
} else {
desc->addr &= ~MACB_BIT(RX_USED);
desc->ctrl = 0;
@@ -2110,7 +2111,13 @@ static void macb_init_hw(struct macb *bp)
config = macb_mdc_clk_div(bp);
if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII)
config |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
-   config |= MACB_BF(RBOF, NET_IP_ALIGN);  /* Make eth data aligned */
+   /* When the pbuf_rsc has been enabled in hardware the receive buffer
+* offset cannot be changed in the network configuration register.
+*/
+   if (!(bp->dev->hw_features &  NETIF_F_LRO))
+   /* Make eth data aligned */
+   config |= MACB_BF(RBOF, NET_IP_ALIGN);
+
config |= MACB_BIT(PAE);/* PAuse Enable */
config |= MACB_BIT(DRFCS);  /* Discard Rx FCS */
if (bp->caps & MACB_CAPS_JUMBO)
@@ -2281,7 +2288,7 @@ static void macb_set_rx_mode(struct net_device *dev)
 static int macb_open(struct net_device *dev)
 {
struct macb *bp = netdev_priv(dev);
-   size_t bufsz = dev->mtu + ETH_HLEN + ETH_FCS_LEN + NET_IP_ALIGN;
+   size_t bufsz = dev->mtu + ETH_HLEN + ETH_FCS_LEN;
struct macb_queue *queue;
unsigned int q;
int err;
@@ -2295,6 +2302,9 @@ static int macb_open(struct net_device *dev)
if (!dev->phydev)
return -EAGAIN;
 
+   if (!(bp->dev->hw_features & NETIF_F_LRO))
+   bufsz += NET_IP_ALIGN;
+
/* RX buffers initialization */
macb_init_rx_buffer_size(bp, bufsz);
 
@@ -3365,6 +3375,10 @@ static int macb_init(struct platform_device *pdev)
if (GEM_BFEXT(PBUF_LSO, gem_readl(bp, DCFG6)))
dev->hw_features |= MACB_NETIF_LSO;
 
+   /* Check RSC capability */
+   if (GEM_BFEXT(PBUF_RSC, gem_readl(bp, DCFG6)))
+   dev->hw_features |= NETIF_F_LRO;
+
/* Checksum offload is only available on gem with packet buffer */
if (macb_is_gem(bp) && !(bp->caps & MACB_CAPS_FIFO_MODE))
dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
-- 
2.4.5

[PATCH 0/3] Receive Side Coalescing for macb driver

[Rafal Ozieblo]

This patch series adds support for receive side coalescing
for Cadence GEM driver. Receive segmentation coalescing
is a mechanism to reduce CPU overhead. This is done by
coalescing received TCP message segments together into
a single large message. This means that when the message
is complete the CPU only has to process the single header
and act upon the one data payload.

Rafal Ozieblo (3):
  net: macb: Add support for rsc capable hardware
  net: macb: Add support for header data spliting
  net: macb: Receive Side Coalescing (RSC) feature added.

 drivers/net/ethernet/cadence/macb.h  |  21 +++
 drivers/net/ethernet/cadence/macb_main.c | 227 ++-
 2 files changed, 212 insertions(+), 36 deletions(-)

-- 
2.4.5

[PATCH 0/3] Receive Side Coalescing for macb driver

[Rafal Ozieblo]

This patch series adds support for receive side coalescing
for Cadence GEM driver. Receive segmentation coalescing
is a mechanism to reduce CPU overhead. This is done by
coalescing received TCP message segments together into
a single large message. This means that when the message
is complete the CPU only has to process the single header
and act upon the one data payload.

Rafal Ozieblo (3):
  net: macb: Add support for rsc capable hardware
  net: macb: Add support for header data spliting
  net: macb: Receive Side Coalescing (RSC) feature added.

 drivers/net/ethernet/cadence/macb.h  |  21 +++
 drivers/net/ethernet/cadence/macb_main.c | 227 ++-
 2 files changed, 212 insertions(+), 36 deletions(-)

-- 
2.4.5

Re: [PATCH] x86/cpufeature: guard asm_volatile_goto usage with CC_HAVE_ASM_GOTO

[Yonghong Song]

On 4/14/18 3:11 AM, Peter Zijlstra wrote:

On Fri, Apr 13, 2018 at 01:42:14PM -0700, Alexei Starovoitov wrote:

On 4/13/18 11:19 AM, Peter Zijlstra wrote:

On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote:

Instead of
#ifdef CC_HAVE_ASM_GOTO
we can replace it with
#ifndef __BPF__
or some other name,


I would prefer the BPF specific hack; otherwise we might be encouraging
people to build the kernel proper without asm-goto.



I don't understand this concern.


The thing is; this will be a (temporary) BPF specific hack. Hiding it
behind something that looks 'normal' (CC_HAVE_ASM_GOTO) is just not
right.


This is a fair concern. I will use a different macro and send v2 soon.
Thanks.

Re: [PATCH] x86/cpufeature: guard asm_volatile_goto usage with CC_HAVE_ASM_GOTO

[Yonghong Song]

On 4/14/18 3:11 AM, Peter Zijlstra wrote:

On Fri, Apr 13, 2018 at 01:42:14PM -0700, Alexei Starovoitov wrote:

On 4/13/18 11:19 AM, Peter Zijlstra wrote:

On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote:

Instead of
#ifdef CC_HAVE_ASM_GOTO
we can replace it with
#ifndef __BPF__
or some other name,


I would prefer the BPF specific hack; otherwise we might be encouraging
people to build the kernel proper without asm-goto.



I don't understand this concern.


The thing is; this will be a (temporary) BPF specific hack. Hiding it
behind something that looks 'normal' (CC_HAVE_ASM_GOTO) is just not
right.


This is a fair concern. I will use a different macro and send v2 soon.
Thanks.

[PATCH] kernel: relay: Change return type to vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler
in struct vm_operations_struct.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 kernel/relay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/relay.c b/kernel/relay.c
index c302940..a8cdbf7 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -39,7 +39,7 @@ static void relay_file_mmap_close(struct vm_area_struct *vma)
 /*
  * fault() vm_op implementation for relay file mapping.
  */
-static int relay_buf_fault(struct vm_fault *vmf)
+static vm_fault_t relay_buf_fault(struct vm_fault *vmf)
 {
struct page *page;
struct rchan_buf *buf = vmf->vma->vm_private_data;
--
1.9.1

[PATCH] kernel: relay: Change return type to vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler
in struct vm_operations_struct.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 kernel/relay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/relay.c b/kernel/relay.c
index c302940..a8cdbf7 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -39,7 +39,7 @@ static void relay_file_mmap_close(struct vm_area_struct *vma)
 /*
  * fault() vm_op implementation for relay file mapping.
  */
-static int relay_buf_fault(struct vm_fault *vmf)
+static vm_fault_t relay_buf_fault(struct vm_fault *vmf)
 {
struct page *page;
struct rchan_buf *buf = vmf->vma->vm_private_data;
--
1.9.1

[PATCH] kernel: event: core: Change return type to vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler and
page_mkwrite handler in struct vm_operations_struct.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 kernel/events/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 96db9ae..d09f1c4 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4918,11 +4918,11 @@ void perf_event_update_userpage(struct perf_event 
*event)
 }
 EXPORT_SYMBOL_GPL(perf_event_update_userpage);

-static int perf_mmap_fault(struct vm_fault *vmf)
+static vm_fault_t perf_mmap_fault(struct vm_fault *vmf)
 {
struct perf_event *event = vmf->vma->vm_file->private_data;
struct ring_buffer *rb;
-   int ret = VM_FAULT_SIGBUS;
+   vm_fault_t ret = VM_FAULT_SIGBUS;

if (vmf->flags & FAULT_FLAG_MKWRITE) {
if (vmf->pgoff == 0)
--
1.9.1

[PATCH] kernel: event: core: Change return type to vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler and
page_mkwrite handler in struct vm_operations_struct.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 kernel/events/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 96db9ae..d09f1c4 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4918,11 +4918,11 @@ void perf_event_update_userpage(struct perf_event 
*event)
 }
 EXPORT_SYMBOL_GPL(perf_event_update_userpage);

-static int perf_mmap_fault(struct vm_fault *vmf)
+static vm_fault_t perf_mmap_fault(struct vm_fault *vmf)
 {
struct perf_event *event = vmf->vma->vm_file->private_data;
struct ring_buffer *rb;
-   int ret = VM_FAULT_SIGBUS;
+   vm_fault_t ret = VM_FAULT_SIGBUS;

if (vmf->flags & FAULT_FLAG_MKWRITE) {
if (vmf->pgoff == 0)
--
1.9.1

[PATCH] ipc: Adding new return type vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 ipc/shm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipc/shm.c b/ipc/shm.c
index 4643865..2ba0cfc 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -378,7 +378,7 @@ void exit_shm(struct task_struct *task)
up_write(_ids(ns).rwsem);
 }
 
-static int shm_fault(struct vm_fault *vmf)
+static vm_fault_t shm_fault(struct vm_fault *vmf)
 {
struct file *file = vmf->vma->vm_file;
struct shm_file_data *sfd = shm_file_data(file);
-- 
1.9.1

[PATCH] ipc: Adding new return type vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 ipc/shm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipc/shm.c b/ipc/shm.c
index 4643865..2ba0cfc 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -378,7 +378,7 @@ void exit_shm(struct task_struct *task)
up_write(_ids(ns).rwsem);
 }
 
-static int shm_fault(struct vm_fault *vmf)
+static vm_fault_t shm_fault(struct vm_fault *vmf)
 {
struct file *file = vmf->vma->vm_file;
struct shm_file_data *sfd = shm_file_data(file);
-- 
1.9.1

Request for Quotation

[Mohammed]

Hello,
 
Good day,
 
I am  Mohammed, Our company is interested in your product.
We have gone through your product site online and wish to make order of your
product.
Please do send us details of your products and company to our {email} Also
provide with the recent price
 
We await your response with quotation and specification.
[1] Payment terms
[2] And your products Warranty
(3] Minimum Order Quantity
 
 
Mohammed /Purchasing Manager
Telephone: +966 3 867 1902
Fax: +966 3 867 3435
tr.export.imp...@outlook.com
 
PAN TRADING  EQUIPMENT'S WORLDWIDE
 
Address: Dallah street, Al Rehab
Saudi Arabia

Request for Quotation

[Mohammed]

Hello,
 
Good day,
 
I am  Mohammed, Our company is interested in your product.
We have gone through your product site online and wish to make order of your
product.
Please do send us details of your products and company to our {email} Also
provide with the recent price
 
We await your response with quotation and specification.
[1] Payment terms
[2] And your products Warranty
(3] Minimum Order Quantity
 
 
Mohammed /Purchasing Manager
Telephone: +966 3 867 1902
Fax: +966 3 867 3435
tr.export.imp...@outlook.com
 
PAN TRADING  EQUIPMENT'S WORLDWIDE
 
Address: Dallah street, Al Rehab
Saudi Arabia

repeatable boot randomness inside KVM guest

[Alexey Dobriyan]

SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
allocation pattern inside a slab:


#ifdef CONFIG_SLAB_FREELIST_RANDOM
/* Pre-initialize the random sequence cache */
static int init_cache_random_seq(struct kmem_cache *s)
{
...

Then I printed actual random sequences for each kmem cache.
Turned out they were all the same for most of the caches and
they didn't vary across guest reboots.

int cache_random_seq_create(struct kmem_cache *cachep, unsigned int 
count, gfp_t gfp)
{
...
/* Get best entropy at this stage of boot */
prandom_seed_state(, get_random_long());

Then I searched internet and turned out KVM can pass randomness via
virtio-rng or something. So I linked /dev/urandom.

And it didn't help!

The only way to get randomness for SLAB is to enable RDRAND inside guest.

Is it KVM bug?

For the record I'm using qemu 2.11.1-r2 and whatever F27 ships now.

repeatable boot randomness inside KVM guest

[Alexey Dobriyan]

SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
allocation pattern inside a slab:


#ifdef CONFIG_SLAB_FREELIST_RANDOM
/* Pre-initialize the random sequence cache */
static int init_cache_random_seq(struct kmem_cache *s)
{
...

Then I printed actual random sequences for each kmem cache.
Turned out they were all the same for most of the caches and
they didn't vary across guest reboots.

int cache_random_seq_create(struct kmem_cache *cachep, unsigned int 
count, gfp_t gfp)
{
...
/* Get best entropy at this stage of boot */
prandom_seed_state(, get_random_long());

Then I searched internet and turned out KVM can pass randomness via
virtio-rng or something. So I linked /dev/urandom.

And it didn't help!

The only way to get randomness for SLAB is to enable RDRAND inside guest.

Is it KVM bug?

For the record I'm using qemu 2.11.1-r2 and whatever F27 ships now.

Yes Yes Yes Yes

[Mr. Gersave Emmanuel]

Hello Dear,

I am Mr. Gervase Emmanuel, executive office holder, general operation
and regional accountant of Royal Bank of Scotland Plc, London United
Kingdom. I believe it is the wish of God for me to come across you
today. Also, I hope that you will not expose or betray this trust and
confident that I am about to impose on you. I have been in search of
someone with this same last name, so when I saw your name, I was
pushed to contact you for our mutual benefit.

One of our customer from your country had a fixed deposit account with
our bank in 2004 that valued the Sum of £7,100,000.00 (Seven million,
one hundred thousand British pounds). The maturity date for this
deposit was on 2007; unfortunately he was among the death victims of
the May 26, 2006 earthquake disaster in Jawa, Indonesia that killed
about 5,782 people.

He was on a business trip in Indonesia during this disaster that end
up his life. Being single, he did not state any next of kin
Heir-apparent when the account was opened, although as his account
officer, he told me that he will later forward one of his relative’s
names as his next of kin Heir to the account which he did not
fulfilled before he met his death.

Since then, I am searching for someone from your country with similar
name. I was happy when I saw your name and I am now seeking for your
co-operation to present you as the next of kin Heir to this account
hence you have similar last name with the deceased. Do not be afraid,
there is no risk involved and every legitimate arrangement to perfect
this deal has been put in place.

For your involvement in this deal, you will receive 45% of the total
amount after the money is transfer to your bank account. Also for
confidentiality in this transaction i will like us to keep via email
for now. Should you consider this offer interesting, kindly send me
the below information of yours completely.

Your complete name:
Your full contact address:
Your direct mobile phone number:
Your major occupation:
Your Age:


I look forward to hear from you to enable me give you more details
about this fund, and please reply me through private email:
gervaseemma...@myself.com

Thanks in anticipation of your urgent response.

Best Regards
Mr. Gervase Emmanuel

Yes Yes Yes Yes

[Mr. Gersave Emmanuel]

Hello Dear,

I am Mr. Gervase Emmanuel, executive office holder, general operation
and regional accountant of Royal Bank of Scotland Plc, London United
Kingdom. I believe it is the wish of God for me to come across you
today. Also, I hope that you will not expose or betray this trust and
confident that I am about to impose on you. I have been in search of
someone with this same last name, so when I saw your name, I was
pushed to contact you for our mutual benefit.

One of our customer from your country had a fixed deposit account with
our bank in 2004 that valued the Sum of £7,100,000.00 (Seven million,
one hundred thousand British pounds). The maturity date for this
deposit was on 2007; unfortunately he was among the death victims of
the May 26, 2006 earthquake disaster in Jawa, Indonesia that killed
about 5,782 people.

He was on a business trip in Indonesia during this disaster that end
up his life. Being single, he did not state any next of kin
Heir-apparent when the account was opened, although as his account
officer, he told me that he will later forward one of his relative’s
names as his next of kin Heir to the account which he did not
fulfilled before he met his death.

Since then, I am searching for someone from your country with similar
name. I was happy when I saw your name and I am now seeking for your
co-operation to present you as the next of kin Heir to this account
hence you have similar last name with the deceased. Do not be afraid,
there is no risk involved and every legitimate arrangement to perfect
this deal has been put in place.

For your involvement in this deal, you will receive 45% of the total
amount after the money is transfer to your bank account. Also for
confidentiality in this transaction i will like us to keep via email
for now. Should you consider this offer interesting, kindly send me
the below information of yours completely.

Your complete name:
Your full contact address:
Your direct mobile phone number:
Your major occupation:
Your Age:


I look forward to hear from you to enable me give you more details
about this fund, and please reply me through private email:
gervaseemma...@myself.com

Thanks in anticipation of your urgent response.

Best Regards
Mr. Gervase Emmanuel

Re: [PATCH v2] block: do not use interruptible wait anywhere

[Jens Axboe]

On 4/12/18 12:11 PM, Alan Jenkins wrote:
> When blk_queue_enter() waits for a queue to unfreeze, or unset the
> PREEMPT_ONLY flag, do not allow it to be interrupted by a signal.
> 
> The PREEMPT_ONLY flag was introduced later in commit 3a0a529971ec
> ("block, scsi: Make SCSI quiesce and resume work reliably").  Note the SCSI
> device is resumed asynchronously, i.e. after un-freezing userspace tasks.
> 
> So that commit exposed the bug as a regression in v4.15.  A mysterious
> SIGBUS (or -EIO) sometimes happened during the time the device was being
> resumed.  Most frequently, there was no kernel log message, and we saw Xorg
> or Xwayland killed by SIGBUS.[1]
> 
> [1] E.g. https://bugzilla.redhat.com/show_bug.cgi?id=1553979
> 
> Without this fix, I get an IO error in this test:
> 
> # dd if=/dev/sda of=/dev/null iflag=direct & \
>   while killall -SIGUSR1 dd; do sleep 0.1; done & \
>   echo mem > /sys/power/state ; \
>   sleep 5; killall dd  # stop after 5 seconds
> 
> The interruptible wait was added to blk_queue_enter in
> commit 3ef28e83ab15 ("block: generic request_queue reference counting").
> Before then, the interruptible wait was only in blk-mq, but I don't think
> it could ever have been correct.

Applied, thanks.

Still want that test in blktests, though!

-- 
Jens Axboe

Re: [PATCH v2] block: do not use interruptible wait anywhere

[Jens Axboe]

On 4/12/18 12:11 PM, Alan Jenkins wrote:
> When blk_queue_enter() waits for a queue to unfreeze, or unset the
> PREEMPT_ONLY flag, do not allow it to be interrupted by a signal.
> 
> The PREEMPT_ONLY flag was introduced later in commit 3a0a529971ec
> ("block, scsi: Make SCSI quiesce and resume work reliably").  Note the SCSI
> device is resumed asynchronously, i.e. after un-freezing userspace tasks.
> 
> So that commit exposed the bug as a regression in v4.15.  A mysterious
> SIGBUS (or -EIO) sometimes happened during the time the device was being
> resumed.  Most frequently, there was no kernel log message, and we saw Xorg
> or Xwayland killed by SIGBUS.[1]
> 
> [1] E.g. https://bugzilla.redhat.com/show_bug.cgi?id=1553979
> 
> Without this fix, I get an IO error in this test:
> 
> # dd if=/dev/sda of=/dev/null iflag=direct & \
>   while killall -SIGUSR1 dd; do sleep 0.1; done & \
>   echo mem > /sys/power/state ; \
>   sleep 5; killall dd  # stop after 5 seconds
> 
> The interruptible wait was added to blk_queue_enter in
> commit 3ef28e83ab15 ("block: generic request_queue reference counting").
> Before then, the interruptible wait was only in blk-mq, but I don't think
> it could ever have been correct.

Applied, thanks.

Still want that test in blktests, though!

-- 
Jens Axboe

Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere

[Jens Axboe]

On 4/14/18 1:46 PM, Alan Jenkins wrote:
> On 13/04/18 09:31, Johannes Thumshirn wrote:
>> Hi Alan,
>>
>> On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:
>>> # dd if=/dev/sda of=/dev/null iflag=direct & \
>>>while killall -SIGUSR1 dd; do sleep 0.1; done & \
>>>echo mem > /sys/power/state ; \
>>>sleep 5; killall dd  # stop after 5 seconds
>> Can you please also add a regression test to blktests[1] for this?
>>
>> [1] https://github.com/osandov/blktests
>>
>> Thanks,
>>  Johannes
> 
> Good question. It would be nice to promote this test.
> 
> Template looks like I need the commit (sha1) first.
> 
> I had some ideas about automating it, so I wrote a standalone (see 
> end).  I can automate the wakeup by using pm_test, but this is still a 
> system suspend test.  Unfortunately I don't think there's any 
> alternative. To give the most dire example
> 
>  # This test is non-destructive, but it exercises suspend in all drivers.
>  # If your system has a problem with suspend, it might not wake up again.
> 
> 
> So I'm not sure if it would be acceptable for the default set?
> 
> How useful is this going to be? Is there an expanded/full set of tests 
> that gets run somewhere?
> 
> If you can't guarantee it's going to be run somewhere, I'd worry the 
> cost/benefit  feels a little narrow :-(. There were one or two further 
> "interesting" details, and it might theoretically bitrot if it's not run 
> periodically.

I run it, just last week we found two new bugs with it. I'm requiring
anyone that submits block patches to run the test suite, and also
working towards having it be part of the 0-day runs so it gets run
on posted patches automatically.

So yes, it's useful and it won't bitrot. Please do turn it into a blktests
test.

-- 
Jens Axboe

Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere

[Jens Axboe]

On 4/14/18 1:46 PM, Alan Jenkins wrote:
> On 13/04/18 09:31, Johannes Thumshirn wrote:
>> Hi Alan,
>>
>> On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:
>>> # dd if=/dev/sda of=/dev/null iflag=direct & \
>>>while killall -SIGUSR1 dd; do sleep 0.1; done & \
>>>echo mem > /sys/power/state ; \
>>>sleep 5; killall dd  # stop after 5 seconds
>> Can you please also add a regression test to blktests[1] for this?
>>
>> [1] https://github.com/osandov/blktests
>>
>> Thanks,
>>  Johannes
> 
> Good question. It would be nice to promote this test.
> 
> Template looks like I need the commit (sha1) first.
> 
> I had some ideas about automating it, so I wrote a standalone (see 
> end).  I can automate the wakeup by using pm_test, but this is still a 
> system suspend test.  Unfortunately I don't think there's any 
> alternative. To give the most dire example
> 
>  # This test is non-destructive, but it exercises suspend in all drivers.
>  # If your system has a problem with suspend, it might not wake up again.
> 
> 
> So I'm not sure if it would be acceptable for the default set?
> 
> How useful is this going to be? Is there an expanded/full set of tests 
> that gets run somewhere?
> 
> If you can't guarantee it's going to be run somewhere, I'd worry the 
> cost/benefit  feels a little narrow :-(. There were one or two further 
> "interesting" details, and it might theoretically bitrot if it's not run 
> periodically.

I run it, just last week we found two new bugs with it. I'm requiring
anyone that submits block patches to run the test suite, and also
working towards having it be part of the 0-day runs so it gets run
on posted patches automatically.

So yes, it's useful and it won't bitrot. Please do turn it into a blktests
test.

-- 
Jens Axboe

Re: [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

[David Miller]

The net-next tree is closed, please resubmit this when the merge window
ends and the net-next tree opens back up.

Thank you.

Re: [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

[David Miller]

The net-next tree is closed, please resubmit this when the merge window
ends and the net-next tree opens back up.

Thank you.

Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere

[Alan Jenkins]

On 13/04/18 09:31, Johannes Thumshirn wrote:

Hi Alan,

On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:

# dd if=/dev/sda of=/dev/null iflag=direct & \
   while killall -SIGUSR1 dd; do sleep 0.1; done & \
   echo mem > /sys/power/state ; \
   sleep 5; killall dd  # stop after 5 seconds

Can you please also add a regression test to blktests[1] for this?

[1] https://github.com/osandov/blktests

Thanks,
Johannes


Good question. It would be nice to promote this test.

Template looks like I need the commit (sha1) first.

I had some ideas about automating it, so I wrote a standalone (see 
end).  I can automate the wakeup by using pm_test, but this is still a 
system suspend test.  Unfortunately I don't think there's any 
alternative. To give the most dire example


# This test is non-destructive, but it exercises suspend in all drivers.
# If your system has a problem with suspend, it might not wake up again.


So I'm not sure if it would be acceptable for the default set?

How useful is this going to be? Is there an expanded/full set of tests 
that gets run somewhere?


If you can't guarantee it's going to be run somewhere, I'd worry the 
cost/benefit  feels a little narrow :-(. There were one or two further 
"interesting" details, and it might theoretically bitrot if it's not run 
periodically.


If you look at the diff and title for the fix, I don't think it's at 
high risk of being reversed unintentionally.


And I think you can trust users will notice if the fix gets merged away 
accidentally, before it hits -stable releases :-). The issue kills the 
entire GUI session on resume from suspend, say once every three days, on 
gnome-shell (due to Xwayland). One unfortunate user switched to Xorg 
only to find that was also affected.  I honestly assume the issue 
applies generally to laptop systems.  The only mitigating factor is if 
you have RAM to spare, so you don't hit the major pagefaults during resume.


#!/bin/bash

# This test is non-destructive, but it exercises suspend in all drivers.
# If your system has a problem with suspend, it might not wake up again.

# TEST_DEV must be SCSI (inc. libata).
#
# Additionally, this test will abort if $TEST_DEV is too tiny
# and we finish reading it within 3 seconds.  Sorry.
TEST_DEV=sda

# RATIONALE
#
# The original root cause issue was the behaviour around blk_queue_freeze().
# It put tasks into an interruptible wait, which is wrong for block devices.
#
# XXX Insert reference to fix commit XXX
#
# The freeze feature is not directly exposed to userspace, so I can not test
# it directly :(.  (It's used to "guarantee no request is in use, so we can
# change any data structure of the queue afterward".  I.e. freeze, modify the
# queue structure, unfreeze).
#
# However, this lead to a regression with a decent reproducer.  In v4.15 the
# same interruptible wait was also used for SCSI suspend/resume.  SCSI resume
# can take a second or so... hence we like to do it asynchronously.  This
# means we can observe the wait at resume time, and we can test if it is
# interruptible.
#
# Note `echo quiesce > /sys/class/scsi_device/*/device/state` can *not*
# trigger the specific wait in the block layer.  That code path only
# sets the SCSI device state; it does not set any block device state.
# (It does not call into blk_queue_freeze() or blk_set_preempt_only();
#  it literally just sets sdev->sdev_state to SDEV_QUIESCE).

set -o nounset

abort() {
echo "$*"
echo "=== Test ERROR ==="
exit 2
}

SYSFS_PM_TEST_DELAY=/sys/module/suspend/parameters/pm_test_delay
SAVED_PM_TEST_DELAY=

# Child process IDs
DD=
SUBSHELL=

cleanup() {
# In many cases the subshell will already have exited...
# and semantics for `wait` are crappy in shell.
# Failure will be harmless in most cases.
# Just try to provide enough context for the user to guess.

echo "Cleaning up"

if [ -n "$SUBSHELL" ]; then

echo "Killing sub-shell PID $SUBSHELL..."
kill $SUBSHELL
wait $SUBSHELL
fi
if [ -n "$DD" ]; then
echo "Killing 'dd' PID $DD..."
kill $DD
wait $DD
fi

echo "Resetting pm_test"
echo none > /sys/power/pm_test

echo "Resetting pm_test_delay"

if [ -n "$SAVED_PM_TEST_DELAY" ]; then
echo "$SAVED_PM_TEST_DELAY" > "$SYSFS_PM_TEST_DELAY"
fi
}
trap cleanup EXIT

# "If a user has disabled async probing a likely reason
#  is due to a storage enclosure that does not inject
#  staggered spin-ups. For safety, make resume
#  synchronous as well in that case."
if ! SCAN="$(cat /sys/module/scsi_mod/parameters/scan)"; then
abort "error reading '/sys/module/scsi_mod/parameters/scan' ?"
fi
if [ "$SCAN" != "async" ]; then
abort "This test does not work if you have set 'scsi_mod.scan=sync'"
fi

# Ignore USR1, in the hope that this applies to child processes.
# This allows us to safely `kill -USR1 $DD`, when we don't know
# whether the child process has fully started yet.

Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere

[Alan Jenkins]

On 13/04/18 09:31, Johannes Thumshirn wrote:

Hi Alan,

On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:

# dd if=/dev/sda of=/dev/null iflag=direct & \
   while killall -SIGUSR1 dd; do sleep 0.1; done & \
   echo mem > /sys/power/state ; \
   sleep 5; killall dd  # stop after 5 seconds

Can you please also add a regression test to blktests[1] for this?

[1] https://github.com/osandov/blktests

Thanks,
Johannes


Good question. It would be nice to promote this test.

Template looks like I need the commit (sha1) first.

I had some ideas about automating it, so I wrote a standalone (see 
end).  I can automate the wakeup by using pm_test, but this is still a 
system suspend test.  Unfortunately I don't think there's any 
alternative. To give the most dire example


# This test is non-destructive, but it exercises suspend in all drivers.
# If your system has a problem with suspend, it might not wake up again.


So I'm not sure if it would be acceptable for the default set?

How useful is this going to be? Is there an expanded/full set of tests 
that gets run somewhere?


If you can't guarantee it's going to be run somewhere, I'd worry the 
cost/benefit  feels a little narrow :-(. There were one or two further 
"interesting" details, and it might theoretically bitrot if it's not run 
periodically.


If you look at the diff and title for the fix, I don't think it's at 
high risk of being reversed unintentionally.


And I think you can trust users will notice if the fix gets merged away 
accidentally, before it hits -stable releases :-). The issue kills the 
entire GUI session on resume from suspend, say once every three days, on 
gnome-shell (due to Xwayland). One unfortunate user switched to Xorg 
only to find that was also affected.  I honestly assume the issue 
applies generally to laptop systems.  The only mitigating factor is if 
you have RAM to spare, so you don't hit the major pagefaults during resume.


#!/bin/bash

# This test is non-destructive, but it exercises suspend in all drivers.
# If your system has a problem with suspend, it might not wake up again.

# TEST_DEV must be SCSI (inc. libata).
#
# Additionally, this test will abort if $TEST_DEV is too tiny
# and we finish reading it within 3 seconds.  Sorry.
TEST_DEV=sda

# RATIONALE
#
# The original root cause issue was the behaviour around blk_queue_freeze().
# It put tasks into an interruptible wait, which is wrong for block devices.
#
# XXX Insert reference to fix commit XXX
#
# The freeze feature is not directly exposed to userspace, so I can not test
# it directly :(.  (It's used to "guarantee no request is in use, so we can
# change any data structure of the queue afterward".  I.e. freeze, modify the
# queue structure, unfreeze).
#
# However, this lead to a regression with a decent reproducer.  In v4.15 the
# same interruptible wait was also used for SCSI suspend/resume.  SCSI resume
# can take a second or so... hence we like to do it asynchronously.  This
# means we can observe the wait at resume time, and we can test if it is
# interruptible.
#
# Note `echo quiesce > /sys/class/scsi_device/*/device/state` can *not*
# trigger the specific wait in the block layer.  That code path only
# sets the SCSI device state; it does not set any block device state.
# (It does not call into blk_queue_freeze() or blk_set_preempt_only();
#  it literally just sets sdev->sdev_state to SDEV_QUIESCE).

set -o nounset

abort() {
echo "$*"
echo "=== Test ERROR ==="
exit 2
}

SYSFS_PM_TEST_DELAY=/sys/module/suspend/parameters/pm_test_delay
SAVED_PM_TEST_DELAY=

# Child process IDs
DD=
SUBSHELL=

cleanup() {
# In many cases the subshell will already have exited...
# and semantics for `wait` are crappy in shell.
# Failure will be harmless in most cases.
# Just try to provide enough context for the user to guess.

echo "Cleaning up"

if [ -n "$SUBSHELL" ]; then

echo "Killing sub-shell PID $SUBSHELL..."
kill $SUBSHELL
wait $SUBSHELL
fi
if [ -n "$DD" ]; then
echo "Killing 'dd' PID $DD..."
kill $DD
wait $DD
fi

echo "Resetting pm_test"
echo none > /sys/power/pm_test

echo "Resetting pm_test_delay"

if [ -n "$SAVED_PM_TEST_DELAY" ]; then
echo "$SAVED_PM_TEST_DELAY" > "$SYSFS_PM_TEST_DELAY"
fi
}
trap cleanup EXIT

# "If a user has disabled async probing a likely reason
#  is due to a storage enclosure that does not inject
#  staggered spin-ups. For safety, make resume
#  synchronous as well in that case."
if ! SCAN="$(cat /sys/module/scsi_mod/parameters/scan)"; then
abort "error reading '/sys/module/scsi_mod/parameters/scan' ?"
fi
if [ "$SCAN" != "async" ]; then
abort "This test does not work if you have set 'scsi_mod.scan=sync'"
fi

# Ignore USR1, in the hope that this applies to child processes.
# This allows us to safely `kill -USR1 $DD`, when we don't know
# whether the child process has fully started yet.

Re: [PATCH v3] IB: make INFINIBAND_ADDR_TRANS configurable

[kbuild test robot]

Hi Greg,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16 next-20180413]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Greg-Thelen/IB-make-INFINIBAND_ADDR_TRANS-configurable/20180414-234042
config: i386-randconfig-x005-201815 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/nvme/host/rdma.o: In function `nvme_rdma_stop_queue':
   drivers/nvme/host/rdma.c:554: undefined reference to `rdma_disconnect'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_free_queue':
   drivers/nvme/host/rdma.c:570: undefined reference to `rdma_destroy_id'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_alloc_queue':
   drivers/nvme/host/rdma.c:511: undefined reference to `__rdma_create_id'
   drivers/nvme/host/rdma.c:523: undefined reference to `rdma_resolve_addr'
   drivers/nvme/host/rdma.c:544: undefined reference to `rdma_destroy_id'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_create_qp':
   drivers/nvme/host/rdma.c:258: undefined reference to `rdma_create_qp'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_create_queue_ib':
   drivers/nvme/host/rdma.c:485: undefined reference to `rdma_destroy_qp'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_addr_resolved':
   drivers/nvme/host/rdma.c:1461: undefined reference to `rdma_resolve_route'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_route_resolved':
   drivers/nvme/host/rdma.c:1512: undefined reference to `rdma_connect'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_conn_rejected':
   drivers/nvme/host/rdma.c:1436: undefined reference to `rdma_reject_msg'
   drivers/nvme/host/rdma.c:1437: undefined reference to 
`rdma_consumer_reject_data'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_create_ch_ib':
>> drivers/infiniband/ulp/srp/ib_srp.c:585: undefined reference to 
>> `rdma_create_qp'
>> drivers/infiniband/ulp/srp/ib_srp.c:647: undefined reference to 
>> `rdma_destroy_qp'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_disconnect_target':
>> drivers/infiniband/ulp/srp/ib_srp.c:977: undefined reference to 
>> `rdma_disconnect'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_new_rdma_cm_id':
>> drivers/infiniband/ulp/srp/ib_srp.c:336: undefined reference to 
>> `__rdma_create_id'
>> drivers/infiniband/ulp/srp/ib_srp.c:345: undefined reference to 
>> `rdma_resolve_addr'
>> drivers/infiniband/ulp/srp/ib_srp.c:369: undefined reference to 
>> `rdma_destroy_id'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_rdma_lookup_path':
>> drivers/infiniband/ulp/srp/ib_srp.c:790: undefined reference to 
>> `rdma_resolve_route'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_send_req':
>> drivers/infiniband/ulp/srp/ib_srp.c:938: undefined reference to 
>> `rdma_connect'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_free_ch_ib':
   drivers/infiniband/ulp/srp/ib_srp.c:677: undefined reference to 
`rdma_destroy_id'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_rdma_cm_handler':
   drivers/infiniband/ulp/srp/ib_srp.c:2808: undefined reference to 
`rdma_disconnect'

vim +585 drivers/infiniband/ulp/srp/ib_srp.c

7dad6b2e Bart Van Assche   2014-10-21  542  
509c07bc Bart Van Assche   2014-10-30  543  static int srp_create_ch_ib(struct 
srp_rdma_ch *ch)
aef9ec39 Roland Dreier 2005-11-02  544  {
509c07bc Bart Van Assche   2014-10-30  545  struct srp_target_port *target 
= ch->target;
62154b2e Bart Van Assche   2014-05-20  546  struct srp_device *dev = 
target->srp_host->srp_dev;
aef9ec39 Roland Dreier 2005-11-02  547  struct ib_qp_init_attr 
*init_attr;
73aa89ed Ishai Rabinovitz  2012-11-26  548  struct ib_cq *recv_cq, *send_cq;
73aa89ed Ishai Rabinovitz  2012-11-26  549  struct ib_qp *qp;
d1b4289e Bart Van Assche   2014-05-20  550  struct ib_fmr_pool *fmr_pool = 
NULL;
5cfb1782 Bart Van Assche   2014-05-20  551  struct srp_fr_pool *fr_pool = 
NULL;
509c5f33 Bart Van Assche   2016-05-12  552  const int m = 1 + 
dev->use_fast_reg * target->mr_per_cmd * 2;
aef9ec39 Roland Dreier 2005-11-02  553  int ret;
aef9ec39 Roland Dreier 2005-11-02  554  
aef9ec39 Roland Dreier 2005-11-02  555  init_attr = kzalloc(sizeof 
*init_attr, GFP_KERNEL);
aef9ec39 Roland Dreier 2005-11-02  556  if (!init_attr)
aef9ec39 Roland Dreier 2005-11-02  557  return -ENOMEM;
aef9ec39 Roland Dreier 2005-11-02  558  
561392d4 Steve Wise2016-02-17  559  /* queue_size + 1 for 
ib_drain_rq() */
1dc7b1f1 Christoph Hellwig 2015-11-13  560  recv_cq = ib_alloc_cq(dev->dev, 
ch, target-&g

Re: [PATCH v3] IB: make INFINIBAND_ADDR_TRANS configurable

[kbuild test robot]

Hi Greg,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16 next-20180413]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Greg-Thelen/IB-make-INFINIBAND_ADDR_TRANS-configurable/20180414-234042
config: i386-randconfig-x005-201815 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/nvme/host/rdma.o: In function `nvme_rdma_stop_queue':
   drivers/nvme/host/rdma.c:554: undefined reference to `rdma_disconnect'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_free_queue':
   drivers/nvme/host/rdma.c:570: undefined reference to `rdma_destroy_id'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_alloc_queue':
   drivers/nvme/host/rdma.c:511: undefined reference to `__rdma_create_id'
   drivers/nvme/host/rdma.c:523: undefined reference to `rdma_resolve_addr'
   drivers/nvme/host/rdma.c:544: undefined reference to `rdma_destroy_id'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_create_qp':
   drivers/nvme/host/rdma.c:258: undefined reference to `rdma_create_qp'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_create_queue_ib':
   drivers/nvme/host/rdma.c:485: undefined reference to `rdma_destroy_qp'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_addr_resolved':
   drivers/nvme/host/rdma.c:1461: undefined reference to `rdma_resolve_route'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_route_resolved':
   drivers/nvme/host/rdma.c:1512: undefined reference to `rdma_connect'
   drivers/nvme/host/rdma.o: In function `nvme_rdma_conn_rejected':
   drivers/nvme/host/rdma.c:1436: undefined reference to `rdma_reject_msg'
   drivers/nvme/host/rdma.c:1437: undefined reference to 
`rdma_consumer_reject_data'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_create_ch_ib':
>> drivers/infiniband/ulp/srp/ib_srp.c:585: undefined reference to 
>> `rdma_create_qp'
>> drivers/infiniband/ulp/srp/ib_srp.c:647: undefined reference to 
>> `rdma_destroy_qp'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_disconnect_target':
>> drivers/infiniband/ulp/srp/ib_srp.c:977: undefined reference to 
>> `rdma_disconnect'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_new_rdma_cm_id':
>> drivers/infiniband/ulp/srp/ib_srp.c:336: undefined reference to 
>> `__rdma_create_id'
>> drivers/infiniband/ulp/srp/ib_srp.c:345: undefined reference to 
>> `rdma_resolve_addr'
>> drivers/infiniband/ulp/srp/ib_srp.c:369: undefined reference to 
>> `rdma_destroy_id'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_rdma_lookup_path':
>> drivers/infiniband/ulp/srp/ib_srp.c:790: undefined reference to 
>> `rdma_resolve_route'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_send_req':
>> drivers/infiniband/ulp/srp/ib_srp.c:938: undefined reference to 
>> `rdma_connect'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_free_ch_ib':
   drivers/infiniband/ulp/srp/ib_srp.c:677: undefined reference to 
`rdma_destroy_id'
   drivers/infiniband/ulp/srp/ib_srp.o: In function `srp_rdma_cm_handler':
   drivers/infiniband/ulp/srp/ib_srp.c:2808: undefined reference to 
`rdma_disconnect'

vim +585 drivers/infiniband/ulp/srp/ib_srp.c

7dad6b2e Bart Van Assche   2014-10-21  542  
509c07bc Bart Van Assche   2014-10-30  543  static int srp_create_ch_ib(struct 
srp_rdma_ch *ch)
aef9ec39 Roland Dreier 2005-11-02  544  {
509c07bc Bart Van Assche   2014-10-30  545  struct srp_target_port *target 
= ch->target;
62154b2e Bart Van Assche   2014-05-20  546  struct srp_device *dev = 
target->srp_host->srp_dev;
aef9ec39 Roland Dreier 2005-11-02  547  struct ib_qp_init_attr 
*init_attr;
73aa89ed Ishai Rabinovitz  2012-11-26  548  struct ib_cq *recv_cq, *send_cq;
73aa89ed Ishai Rabinovitz  2012-11-26  549  struct ib_qp *qp;
d1b4289e Bart Van Assche   2014-05-20  550  struct ib_fmr_pool *fmr_pool = 
NULL;
5cfb1782 Bart Van Assche   2014-05-20  551  struct srp_fr_pool *fr_pool = 
NULL;
509c5f33 Bart Van Assche   2016-05-12  552  const int m = 1 + 
dev->use_fast_reg * target->mr_per_cmd * 2;
aef9ec39 Roland Dreier 2005-11-02  553  int ret;
aef9ec39 Roland Dreier 2005-11-02  554  
aef9ec39 Roland Dreier 2005-11-02  555  init_attr = kzalloc(sizeof 
*init_attr, GFP_KERNEL);
aef9ec39 Roland Dreier 2005-11-02  556  if (!init_attr)
aef9ec39 Roland Dreier 2005-11-02  557  return -ENOMEM;
aef9ec39 Roland Dreier 2005-11-02  558  
561392d4 Steve Wise2016-02-17  559  /* queue_size + 1 for 
ib_drain_rq() */
1dc7b1f1 Christoph Hellwig 2015-11-13  560  recv_cq = ib_alloc_cq(dev->dev, 
ch, target-&g

[GIT PULL] Kbuild updates for 4.17 (2nd round)

[Masahiro Yamada]

Hi Linus,

Please pull more Kbuild updates for v4.17-rc1.
Thanks!


The following changes since commit f605ba97fb80522656c7dce9825a908f1e765b57:

  Merge tag 'vfio-v4.17-rc1' of git://github.com/awilliam/linux-vfio
(2018-04-06 19:44:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v4.17-2

for you to fetch changes up to 17baab68d337a0bf4654091e2b4cd67c3fdb44d8:

  kconfig: extend output of 'listnewconfig' (2018-04-13 23:23:11 +0900)


Kbuild updates for v4.17 (2nd)

- pass HOSTLDFLAGS when compiling single .c host programs

- build genksyms lexer and parser files instead of using shipped
  versions

- rename *-asn1.[ch] to *.asn1.[ch] for suffix consistency

- let the top .gitignore globally ignore artifacts generated by
  flex, bison, and asn1_compiler

- let the top Makefile globally clean artifacts generated by
  flex, bison, and asn1_compiler

- use safer .SECONDARY marker instead of .PRECIOUS to prevent
  intermediate files from being removed

- support -fmacro-prefix-map option to make __FILE__ a relative path

- fix # escaping to prepare for the future GNU Make release

- clean up deb-pkg by using debian tools instead of handrolled
  source/changes generation

- improve rpm-pkg portability by supporting kernel-install as a
  fallback of new-kernel-pkg

- extend Kconfig listnewconfig target to provide more information


Don Zickus (1):
  kconfig: extend output of 'listnewconfig'

Javier Martinez Canillas (1):
  kbuild: rpm-pkg: use kernel-install as a fallback for new-kernel-pkg

Masahiro Yamada (10):
  .gitignore: move *.lex.c *.tab.[ch] patterns to the top-level .gitignore
  kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level Makefile
  genksyms: generate lexer and parser during build instead of shipping
  kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically
  kbuild: add %.dtb.S and %.dtb to 'targets' automatically
  .gitignore: move *-asn1.[ch] patterns to the top-level .gitignore
  kbuild: clean up *-asn1.[ch] patterns from top-level Makefile
  kbuild: rename *-asn1.[ch] to *.asn1.[ch]
  kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS markers
  kbuild: use -fmacro-prefix-map to make __FILE__ a relative path

Rasmus Villemoes (1):
  Kbuild: fix # escaping in .cmd files for future Make

Riku Voipio (1):
  kbuild: deb-pkg: split generating packaging and build

Robin Jarry (1):
  kbuild: use HOSTLDFLAGS for single .c executables

 .gitignore  |7 +-
 Makefile|5 +
 arch/arc/boot/dts/Makefile  |2 -
 arch/arm/crypto/Makefile|2 +-
 arch/arm64/crypto/Makefile  |2 +-
 arch/sparc/vdso/Makefile|4 +-
 arch/x86/entry/vdso/Makefile|4 +-
 crypto/.gitignore   |1 -
 crypto/Makefile |   14 +-
 crypto/asymmetric_keys/.gitignore   |1 -
 crypto/asymmetric_keys/Makefile |   31 +-
 crypto/asymmetric_keys/mscode_parser.c  |2 +-
 crypto/asymmetric_keys/pkcs7_parser.c   |2 +-
 crypto/asymmetric_keys/x509_cert_parser.c   |4 +-
 crypto/rsa_helper.c |4 +-
 drivers/crypto/qat/qat_common/.gitignore|1 -
 drivers/of/unittest-data/Makefile   |6 -
 net/ipv4/netfilter/Makefile |5 +-
 net/ipv4/netfilter/nf_nat_snmp_basic_main.c |2 +-
 scripts/Kbuild.include  |5 +-
 scripts/Makefile.build  |   23 +-
 scripts/Makefile.host   |2 +-
 scripts/Makefile.lib|   31 +-
 scripts/asn1_compiler.c |2 +-
 scripts/dtc/.gitignore  |3 -
 scripts/dtc/Makefile|5 -
 scripts/genksyms/.gitignore |3 -
 scripts/genksyms/Makefile   |   27 +-
 scripts/genksyms/lex.lex.c_shipped  | 2291 
 scripts/genksyms/parse.tab.c_shipped| 2394
--
 scripts/genksyms/parse.tab.h_shipped|  119 --
 scripts/kconfig/.gitignore  |3 -
 scripts/kconfig/Makefile|4 +-
 scripts/kconfig/conf.c  |   14 +-
 scripts/package/Makefile|   34 +-
 scripts/package/builddeb|  221 +--
 scripts/package/mkdebian|  189 +++
 scripts/package/mkspec  |2 +
 tools/build/Build.include   |5 +-
 tools/objtool/Makefile  |2 +-
 tools/scripts/Makefile.include  |2 +
 41 files 

[GIT PULL] Kbuild updates for 4.17 (2nd round)

[Masahiro Yamada]

Hi Linus,

Please pull more Kbuild updates for v4.17-rc1.
Thanks!


The following changes since commit f605ba97fb80522656c7dce9825a908f1e765b57:

  Merge tag 'vfio-v4.17-rc1' of git://github.com/awilliam/linux-vfio
(2018-04-06 19:44:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v4.17-2

for you to fetch changes up to 17baab68d337a0bf4654091e2b4cd67c3fdb44d8:

  kconfig: extend output of 'listnewconfig' (2018-04-13 23:23:11 +0900)


Kbuild updates for v4.17 (2nd)

- pass HOSTLDFLAGS when compiling single .c host programs

- build genksyms lexer and parser files instead of using shipped
  versions

- rename *-asn1.[ch] to *.asn1.[ch] for suffix consistency

- let the top .gitignore globally ignore artifacts generated by
  flex, bison, and asn1_compiler

- let the top Makefile globally clean artifacts generated by
  flex, bison, and asn1_compiler

- use safer .SECONDARY marker instead of .PRECIOUS to prevent
  intermediate files from being removed

- support -fmacro-prefix-map option to make __FILE__ a relative path

- fix # escaping to prepare for the future GNU Make release

- clean up deb-pkg by using debian tools instead of handrolled
  source/changes generation

- improve rpm-pkg portability by supporting kernel-install as a
  fallback of new-kernel-pkg

- extend Kconfig listnewconfig target to provide more information


Don Zickus (1):
  kconfig: extend output of 'listnewconfig'

Javier Martinez Canillas (1):
  kbuild: rpm-pkg: use kernel-install as a fallback for new-kernel-pkg

Masahiro Yamada (10):
  .gitignore: move *.lex.c *.tab.[ch] patterns to the top-level .gitignore
  kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level Makefile
  genksyms: generate lexer and parser during build instead of shipping
  kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically
  kbuild: add %.dtb.S and %.dtb to 'targets' automatically
  .gitignore: move *-asn1.[ch] patterns to the top-level .gitignore
  kbuild: clean up *-asn1.[ch] patterns from top-level Makefile
  kbuild: rename *-asn1.[ch] to *.asn1.[ch]
  kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS markers
  kbuild: use -fmacro-prefix-map to make __FILE__ a relative path

Rasmus Villemoes (1):
  Kbuild: fix # escaping in .cmd files for future Make

Riku Voipio (1):
  kbuild: deb-pkg: split generating packaging and build

Robin Jarry (1):
  kbuild: use HOSTLDFLAGS for single .c executables

 .gitignore  |7 +-
 Makefile|5 +
 arch/arc/boot/dts/Makefile  |2 -
 arch/arm/crypto/Makefile|2 +-
 arch/arm64/crypto/Makefile  |2 +-
 arch/sparc/vdso/Makefile|4 +-
 arch/x86/entry/vdso/Makefile|4 +-
 crypto/.gitignore   |1 -
 crypto/Makefile |   14 +-
 crypto/asymmetric_keys/.gitignore   |1 -
 crypto/asymmetric_keys/Makefile |   31 +-
 crypto/asymmetric_keys/mscode_parser.c  |2 +-
 crypto/asymmetric_keys/pkcs7_parser.c   |2 +-
 crypto/asymmetric_keys/x509_cert_parser.c   |4 +-
 crypto/rsa_helper.c |4 +-
 drivers/crypto/qat/qat_common/.gitignore|1 -
 drivers/of/unittest-data/Makefile   |6 -
 net/ipv4/netfilter/Makefile |5 +-
 net/ipv4/netfilter/nf_nat_snmp_basic_main.c |2 +-
 scripts/Kbuild.include  |5 +-
 scripts/Makefile.build  |   23 +-
 scripts/Makefile.host   |2 +-
 scripts/Makefile.lib|   31 +-
 scripts/asn1_compiler.c |2 +-
 scripts/dtc/.gitignore  |3 -
 scripts/dtc/Makefile|5 -
 scripts/genksyms/.gitignore |3 -
 scripts/genksyms/Makefile   |   27 +-
 scripts/genksyms/lex.lex.c_shipped  | 2291 
 scripts/genksyms/parse.tab.c_shipped| 2394
--
 scripts/genksyms/parse.tab.h_shipped|  119 --
 scripts/kconfig/.gitignore  |3 -
 scripts/kconfig/Makefile|4 +-
 scripts/kconfig/conf.c  |   14 +-
 scripts/package/Makefile|   34 +-
 scripts/package/builddeb|  221 +--
 scripts/package/mkdebian|  189 +++
 scripts/package/mkspec  |2 +
 tools/build/Build.include   |5 +-
 tools/objtool/Makefile  |2 +-
 tools/scripts/Makefile.include  |2 +
 41 files 

[GIT PULL V3] Thermal SoC management updates for v4.17-rc1

[Eduardo Valentin]

Hello Linus,

Please find thermal-soc changes for v4.17-rc1.
Rui asked me to send the pull request directly to you
as we are close to the end of the merge window.
Essentially this pull removes the series that caused
warning regression. I will work with the developer
to get that fixed later on, but I am still sending
the other few patches that are unrelated to that.
Let me know if this causes any issues and can still
be pulled.

Changelog:
- New i.MX7 thermal sensor
- Mediatek driver now supports MT7622 SoC
- Removal of min max cpu cooling DT property

Differences in V3:
- Rebased on top current linus/master, to avoid and merge issues
from previous pulled thermal code.

Differences in V2:
- Reordered the patches to drop exynos changes for now until we get
agreement on the fix on that driver for the compilation warns
caused by the confusing conversion functions.


The following changes since commit 48023102b7078a6674516b1fe0d639669336049d:

  Merge branch 'overlayfs-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2018-04-13 16:55:41 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus

for you to fetch changes up to 15a32df1918259be6c23fc36014fc26ee66c836c:

  dt-bindings: thermal: Remove "cooling-{min|max}-level" properties (2018-04-14 
09:37:55 -0700)


Anson Huang (1):
  thermal: imx: add i.MX7 thermal sensor support

Bartlomiej Zolnierkiewicz (1):
  dt-bindings: thermal: remove no longer needed samsung thermal properties

Sean Wang (2):
  dt-bindings: thermal: add binding for MT7622 SoC
  thermal: mediatek: add support for MT7622 SoC

Viresh Kumar (1):
  dt-bindings: thermal: Remove "cooling-{min|max}-level" properties

 .../devicetree/bindings/thermal/exynos-thermal.txt |  23 +-
 .../devicetree/bindings/thermal/imx-thermal.txt|   9 +-
 .../bindings/thermal/mediatek-thermal.txt  |   1 +
 .../devicetree/bindings/thermal/thermal.txt|  16 +-
 drivers/thermal/imx_thermal.c  | 295 -
 drivers/thermal/mtk_thermal.c  |  35 +++
 6 files changed, 281 insertions(+), 98 deletions(-)

[GIT PULL V3] Thermal SoC management updates for v4.17-rc1

[Eduardo Valentin]

Hello Linus,

Please find thermal-soc changes for v4.17-rc1.
Rui asked me to send the pull request directly to you
as we are close to the end of the merge window.
Essentially this pull removes the series that caused
warning regression. I will work with the developer
to get that fixed later on, but I am still sending
the other few patches that are unrelated to that.
Let me know if this causes any issues and can still
be pulled.

Changelog:
- New i.MX7 thermal sensor
- Mediatek driver now supports MT7622 SoC
- Removal of min max cpu cooling DT property

Differences in V3:
- Rebased on top current linus/master, to avoid and merge issues
from previous pulled thermal code.

Differences in V2:
- Reordered the patches to drop exynos changes for now until we get
agreement on the fix on that driver for the compilation warns
caused by the confusing conversion functions.


The following changes since commit 48023102b7078a6674516b1fe0d639669336049d:

  Merge branch 'overlayfs-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2018-04-13 16:55:41 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus

for you to fetch changes up to 15a32df1918259be6c23fc36014fc26ee66c836c:

  dt-bindings: thermal: Remove "cooling-{min|max}-level" properties (2018-04-14 
09:37:55 -0700)


Anson Huang (1):
  thermal: imx: add i.MX7 thermal sensor support

Bartlomiej Zolnierkiewicz (1):
  dt-bindings: thermal: remove no longer needed samsung thermal properties

Sean Wang (2):
  dt-bindings: thermal: add binding for MT7622 SoC
  thermal: mediatek: add support for MT7622 SoC

Viresh Kumar (1):
  dt-bindings: thermal: Remove "cooling-{min|max}-level" properties

 .../devicetree/bindings/thermal/exynos-thermal.txt |  23 +-
 .../devicetree/bindings/thermal/imx-thermal.txt|   9 +-
 .../bindings/thermal/mediatek-thermal.txt  |   1 +
 .../devicetree/bindings/thermal/thermal.txt|  16 +-
 drivers/thermal/imx_thermal.c  | 295 -
 drivers/thermal/mtk_thermal.c  |  35 +++
 6 files changed, 281 insertions(+), 98 deletions(-)