general protection fault in qdisc_put
Hello,
syzbot found the following crash on:
HEAD commit:3b47fd5c Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10244dd660
kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4
dashboard link: https://syzkaller.appspot.com/bug?extid=d5870a903591faaca4ae
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=174743fe60
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f8c43e60
The bug was bisected to:
commit e41d58185f1444368873d4d7422f7664a68be61d
Author: Dmitry Vyukov
Date: Wed Jul 12 21:34:35 2017 +
fault-inject: support systematic fault injection
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13f66bc660
final crash:https://syzkaller.appspot.com/x/report.txt?x=100e6bc660
console output: https://syzkaller.appspot.com/x/log.txt?x=17f66bc660
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d5870a903591faaca...@syzkaller.appspotmail.com
Fixes: e41d58185f14 ("fault-inject: support systematic fault injection")
RDX: RSI: 2240 RDI: 0003
RBP: R08: 0001 R09: 01bb
R10: R11: 0246 R12:
R13: 0005 R14: R15:
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 9699 Comm: syz-executor169 Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:qdisc_put+0x25/0x90 net/sched/sch_generic.c:983
Code: 00 00 00 00 00 55 48 89 e5 41 54 49 89 fc 53 e8 c1 52 bf fb 49 8d 7c
24 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 04 3c 03 7e 54 41 8b 5c 24 10 31 ff 83 e3 01
RSP: 0018:8880944c7488 EFLAGS: 00010202
RAX: dc00 RBX: 8880945c8540 RCX: 85b49e8a
RDX: 0002 RSI: 85b3228f RDI: 0010
RBP: 8880944c7498 R08: 888099d50480 R09: ed1012898e45
R10: ed1012898e44 R11: 0003 R12:
R13: 8880945c8540 R14: 888094894500 R15: 8880945c857c
FS: 57553880() GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2610 CR3: 8c29d000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
sfb_destroy+0x61/0x80 net/sched/sch_sfb.c:468
qdisc_create+0xbc6/0x1210 net/sched/sch_api.c:1285
tc_modify_qdisc+0x524/0x1c50 net/sched/sch_api.c:1652
rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5223
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x803/0x920 net/socket.c:2311
__sys_sendmsg+0x105/0x1d0 net/socket.c:2356
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4424f9
Code: e8 9c 07 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 3b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fffed10bed8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 0003 RCX: 004424f9
RDX: RSI: 2240 RDI: 0003
RBP: R08: 0001 R09: 01bb
R10: R11: 0246 R12:
R13: 0005 R14: R15:
Modules linked in:
---[ end trace 97e52c48ae7a3cc1 ]---
RIP: 0010:qdisc_put+0x25/0x90 net/sched/sch_generic.c:983
Code: 00 00 00 00 00 55 48 89 e5 41 54 49 89 fc 53 e8 c1 52 bf fb 49 8d 7c
24 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 04 3c 03 7e 54 41 8b 5c 24 10 31 ff 83 e3 01
RSP: 0018:8880944c7488 EFLAGS: 00010202
RAX: dc00 RBX: 8880945c8540 RCX: 85b49e8a
RDX: 0002 RSI: 85b3228f RDI: 0010
RBP: 8880944c7498 R08: 888099d50480 R09: ed1012898e45
R10: ed1012898e44 R11: 0003 R12:
R13: 8880945c8540 R14: 888094894500 R15: 8880945c857c
FS:
BUG: unable to handle kernel NULL pointer dereference in tc_bind_tclass
Hello, syzbot found the following crash on: HEAD commit:0e5b36bc r8152: adjust the settings of ups flags git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=10e5ad7660 kernel config: https://syzkaller.appspot.com/x/.config?x=67b69b427c3b2dbf dashboard link: https://syzkaller.appspot.com/bug?extid=21b29db13c065852f64b compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cebbda60 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15fb9d0a60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+21b29db13c065852f...@syzkaller.appspotmail.com 8021q: adding VLAN 0 to HW filter on device batadv0 BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD a9ba0067 P4D a9ba0067 PUD a7851067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 8672 Comm: syz-executor994 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:888097fb74d8 EFLAGS: 00010246 RAX: dc00 RBX: 884a7740 RCX: 85b55676 RDX: RSI: 0001 RDI: 8880a4cd7400 RBP: 888097fb75d0 R08: 88808dc2e440 R09: 888097fb7658 R10: ed1012ff6ed9 R11: 888097fb76cf R12: 8880a4cd7400 R13: 0001 R14: 888097fb75a8 R15: 884a7740 FS: 56952880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 9c578000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: tc_bind_tclass+0x13e/0x2f0 net/sched/sch_api.c:1923 tc_ctl_tclass+0xadb/0xcd0 net/sched/sch_api.c:2059 rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5223 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:657 ___sys_sendmsg+0x803/0x920 net/socket.c:2311 __sys_sendmsg+0x105/0x1d0 net/socket.c:2356 __do_sys_sendmsg net/socket.c:2365 [inline] __se_sys_sendmsg net/socket.c:2363 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441cd9 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc9938bcf8 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 315f6576616c RCX: 00441cd9 RDX: RSI: 2240 RDI: 0005 RBP: 735f656764697262 R08: 01bb R09: 01bb R10: 01bb R11: 0246 R12: R13: 00403270 R14: R15: Modules linked in: CR2: ---[ end trace d5605e2bdb92fab7 ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:888097fb74d8 EFLAGS: 00010246 RAX: dc00 RBX: 884a7740 RCX: 85b55676 RDX: RSI: 0001 RDI: 8880a4cd7400 RBP: 888097fb75d0 R08: 88808dc2e440 R09: 888097fb7658 R10: ed1012ff6ed9 R11: 888097fb76cf R12: 8880a4cd7400 R13: 0001 R14: 888097fb75a8 R15: 884a7740 FS: 56952880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 9c578000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
WARNING in cbs_dequeue_soft
Hello,
syzbot found the following crash on:
HEAD commit:6d028043 Add linux-next specific files for 20190830
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17f1421a60
kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69
dashboard link: https://syzkaller.appspot.com/bug?extid=cdbea9b616d35e2365ae
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=147b54d160
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16c5da6e60
The bug was bisected to:
commit e0a7683d30e91e30ee6cf96314ae58a0314a095e
Author: Leandro Dorileo
Date: Mon Apr 8 17:12:18 2019 +
net/sched: cbs: fix port_rate miscalculation
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=130c614e60
final crash:https://syzkaller.appspot.com/x/report.txt?x=108c614e60
console output: https://syzkaller.appspot.com/x/log.txt?x=170c614e60
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cdbea9b616d35e236...@syzkaller.appspotmail.com
Fixes: e0a7683d30e9 ("net/sched: cbs: fix port_rate miscalculation")
[ cut here ]
cbs: dequeue() called with unknown port rate.
WARNING: CPU: 1 PID: 8572 at net/sched/sch_cbs.c:185
cbs_dequeue_soft+0x37e/0x4b0 net/sched/sch_cbs.c:185
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 8572 Comm: kworker/1:2 Not tainted 5.3.0-rc6-next-20190830 #75
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2dc/0x755 kernel/panic.c:220
__warn.cold+0x2f/0x3c kernel/panic.c:581
report_bug+0x289/0x300 lib/bug.c:195
fixup_bug arch/x86/kernel/traps.c:179 [inline]
fixup_bug arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
RIP: 0010:cbs_dequeue_soft+0x37e/0x4b0 net/sched/sch_cbs.c:185
Code: 1d 2c b3 f5 03 31 ff 89 de e8 fe 6d a6 fb 84 db 75 1a e8 b5 6c a6 fb
48 c7 c7 80 7d 4a 88 c6 05 0c b3 f5 03 01 e8 0a bb 77 fb <0f> 0b 45 31 e4
eb b1 49 bc ff ff ff ff ff ff ff 7f 48 89 55 d0 e8
RSP: 0018:8880a129f3e8 EFLAGS: 00010282
RAX: RBX: RCX:
RDX: RSI: 815bf786 RDI: ed1014253e6f
RBP: 8880a129f430 R08: 8880a63f4040 R09: fbfff14ed341
R10: fbfff14ed340 R11: 8a769a07 R12: 8880911a5800
R13: 888095de92c8 R14: 000f8f3a4493 R15:
cbs_dequeue+0x34/0x40 net/sched/sch_cbs.c:237
dequeue_skb net/sched/sch_generic.c:258 [inline]
qdisc_restart net/sched/sch_generic.c:361 [inline]
__qdisc_run+0x1e7/0x19d0 net/sched/sch_generic.c:379
__dev_xmit_skb net/core/dev.c:3533 [inline]
__dev_queue_xmit+0x16f1/0x37c0 net/core/dev.c:3838
dev_queue_xmit+0x18/0x20 net/core/dev.c:3902
neigh_resolve_output net/core/neighbour.c:1490 [inline]
neigh_resolve_output+0x5a5/0x970 net/core/neighbour.c:1470
neigh_output include/net/neighbour.h:511 [inline]
ip6_finish_output2+0x1034/0x2550 net/ipv6/ip6_output.c:116
__ip6_finish_output+0x444/0xaa0 net/ipv6/ip6_output.c:142
ip6_finish_output+0x38/0x1f0 net/ipv6/ip6_output.c:152
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip6_output+0x235/0x7f0 net/ipv6/ip6_output.c:175
dst_output include/net/dst.h:436 [inline]
NF_HOOK include/linux/netfilter.h:305 [inline]
ndisc_send_skb+0xf29/0x14a0 net/ipv6/ndisc.c:505
ndisc_send_ns+0x3a9/0x850 net/ipv6/ndisc.c:647
addrconf_dad_work+0xb88/0x1150 net/ipv6/addrconf.c:4120
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
INFO: rcu detected stall in mld_ifc_timer_expire
Hello, syzbot found the following crash on: HEAD commit:3b47fd5c Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15807dc660 kernel config: https://syzkaller.appspot.com/x/.config?x=144488c6c6c6d2b6 dashboard link: https://syzkaller.appspot.com/bug?extid=bc6297c11f19ee807dc2 compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119ee6c160 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15c4eb0a60 Bisection is inconclusive: the bug happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13b7343e60 console output: https://syzkaller.appspot.com/x/log.txt?x=17b7343e60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+bc6297c11f19ee807...@syzkaller.appspotmail.com rcu: INFO: rcu_preempt self-detected stall on CPU rcu:0-...!: (10500 ticks this GP) idle=d6e/0/0x3 softirq=9083/9083 fqs=0 (t=10501 jiffies g=6617 q=143) rcu: rcu_preempt kthread starved for 10502 jiffies! g6617 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0 rcu: RCU grace-period kthread stack dump: rcu_preempt I2908010 2 0x80004000 Call Trace: context_switch kernel/sched/core.c:3254 [inline] __schedule+0x877/0xc50 kernel/sched/core.c:3880 schedule+0x131/0x1e0 kernel/sched/core.c:3947 schedule_timeout+0x14f/0x240 kernel/time/timer.c:1807 rcu_gp_fqs_loop kernel/rcu/tree.c:1611 [inline] rcu_gp_kthread+0xef8/0x1790 kernel/rcu/tree.c:1768 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 NMI backtrace for cpu 0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113 nmi_cpu_backtrace+0xaf/0x1a0 lib/nmi_backtrace.c:101 nmi_trigger_cpumask_backtrace+0x174/0x290 lib/nmi_backtrace.c:62 arch_trigger_cpumask_backtrace+0x10/0x20 arch/x86/kernel/apic/hw_nmi.c:38 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x15a/0x220 kernel/rcu/tree_stall.h:254 print_cpu_stall kernel/rcu/tree_stall.h:455 [inline] check_cpu_stall kernel/rcu/tree_stall.h:529 [inline] rcu_pending kernel/rcu/tree.c:2736 [inline] rcu_sched_clock_irq+0xb95/0x16d0 kernel/rcu/tree.c:2183 update_process_times+0x134/0x190 kernel/time/timer.c:1639 tick_sched_handle kernel/time/tick-sched.c:167 [inline] tick_sched_timer+0x263/0x420 kernel/time/tick-sched.c:1296 __run_hrtimer kernel/time/hrtimer.c:1389 [inline] __hrtimer_run_queues+0x403/0x850 kernel/time/hrtimer.c:1451 hrtimer_interrupt+0x38c/0xda0 kernel/time/hrtimer.c:1509 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1106 [inline] smp_apic_timer_interrupt+0x109/0x280 arch/x86/kernel/apic/apic.c:1131 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 RIP: 0010:__list_add_valid+0xc/0xc0 lib/list_debug.c:22 Code: 89 e5 53 48 89 fb e8 83 d6 1f fe 48 c7 c7 56 5a 45 88 48 89 de e8 44 fd ff ff 5b 5d c3 90 55 48 89 e5 41 57 41 56 41 55 41 54 <53> 49 89 d6 49 89 f4 49 89 ff 49 bd 00 00 00 00 00 fc ff df 48 8d RSP: 0018:8880aea09730 EFLAGS: 0246 ORIG_RAX: ff13 RAX: 111012f53d0a RBX: 111012f53d0b RCX: 88875a00 RDX: 888097a9e850 RSI: 888097a9e850 RDI: 888097a9e7b8 RBP: 8880aea09750 R08: 860c4d6a R09: R10: fbfff117be8d R11: R12: dc00 R13: 888097a9e4c0 R14: 888097a9e850 R15: 888097a9e840 __list_add include/linux/list.h:60 [inline] list_add_tail include/linux/list.h:93 [inline] list_move_tail include/linux/list.h:214 [inline] hhf_dequeue+0x535/0xaa0 net/sched/sch_hhf.c:439 dequeue_skb net/sched/sch_generic.c:258 [inline] qdisc_restart net/sched/sch_generic.c:361 [inline] __qdisc_run+0x217/0x1b30 net/sched/sch_generic.c:379 __dev_xmit_skb net/core/dev.c:3533 [inline] __dev_queue_xmit+0x1161/0x3020 net/core/dev.c:3838 dev_queue_xmit+0x17/0x20 net/core/dev.c:3902 neigh_hh_output include/net/neighbour.h:500 [inline] neigh_output include/net/neighbour.h:509 [inline] ip6_finish_output2+0xff2/0x13d0 net/ipv6/ip6_output.c:116 __ip6_finish_output+0x693/0x910 net/ipv6/ip6_output.c:142 ip6_finish_output+0x52/0x1e0 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0x26f/0x390 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] NF_HOOK include/linux/netfilter.h:305 [inline] mld_sendpack+0x770/0xb90 net/ipv6/mcast.c:1682 mld_send_cr net/ipv6/mcast.c:1978 [inline] mld_ifc_timer_expire+0x820/0xb70 net/ipv6/mcast.c:2477 call_timer_fn+0x95/0x170 kernel/time/timer.c:1322 expire_timers kernel/time/timer.c:1366 [inline] __r
general protection fault in cbs_destroy
Hello, syzbot found the following crash on: HEAD commit:3b47fd5c Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14854e7160 kernel config: https://syzkaller.appspot.com/x/.config?x=144488c6c6c6d2b6 dashboard link: https://syzkaller.appspot.com/bug?extid=3a8d6a998cbb73bcf337 compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17998f9e60 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10421efa60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+3a8d6a998cbb73bcf...@syzkaller.appspotmail.com 8021q: adding VLAN 0 to HW filter on device batadv0 netlink: 24 bytes leftover after parsing attributes in process `syz-executor457'. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 9249 Comm: syz-executor457 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__list_del_entry_valid+0x6b/0x100 lib/list_debug.c:51 Code: 4c 89 f7 e8 97 d0 58 fe 48 ba 00 01 00 00 00 00 ad de 49 8b 1e 48 39 d3 74 54 48 83 c2 22 49 39 d7 74 5e 4c 89 f8 48 c1 e8 03 <42> 80 3c 20 00 74 08 4c 89 ff e8 66 d0 58 fe 49 8b 17 4c 39 f2 75 RSP: 0018:88809898f568 EFLAGS: 00010246 RAX: RBX: RCX: 0001 RDX: dead0122 RSI: 0004 RDI: 88809fb5a7e8 RBP: 88809898f588 R08: dc00 R09: ed1013131ea8 R10: ed1013131ea8 R11: R12: dc00 R13: 88809fb5a480 R14: 88809fb5a7e0 R15: FS: 568cb880() GS:8880aea0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2610 CR3: a3968000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_del_entry include/linux/list.h:131 [inline] list_del include/linux/list.h:139 [inline] cbs_destroy+0x85/0x3e0 net/sched/sch_cbs.c:435 qdisc_create+0xff8/0x13e0 net/sched/sch_api.c:1302 tc_modify_qdisc+0x989/0x1ea0 net/sched/sch_api.c:1652 rtnetlink_rcv_msg+0x889/0xd40 net/core/rtnetlink.c:5223 netlink_rcv_skb+0x19e/0x3d0 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:5241 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x787/0x900 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x993/0xc50 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg net/socket.c:657 [inline] ___sys_sendmsg+0x60d/0x910 net/socket.c:2311 __sys_sendmsg net/socket.c:2356 [inline] __do_sys_sendmsg net/socket.c:2365 [inline] __se_sys_sendmsg net/socket.c:2363 [inline] __x64_sys_sendmsg+0x17c/0x200 net/socket.c:2363 do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441b59 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffe29572cf8 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00441b59 RDX: RSI: 2240 RDI: 0003 RBP: 7ffe29572d10 R08: 01bb R09: 01bb R10: 01bb R11: 0246 R12: R13: 004030f0 R14: R15: Modules linked in: ---[ end trace 226030e488aca074 ]--- RIP: 0010:__list_del_entry_valid+0x6b/0x100 lib/list_debug.c:51 Code: 4c 89 f7 e8 97 d0 58 fe 48 ba 00 01 00 00 00 00 ad de 49 8b 1e 48 39 d3 74 54 48 83 c2 22 49 39 d7 74 5e 4c 89 f8 48 c1 e8 03 <42> 80 3c 20 00 74 08 4c 89 ff e8 66 d0 58 fe 49 8b 17 4c 39 f2 75 RSP: 0018:88809898f568 EFLAGS: 00010246 RAX: RBX: RCX: 0001 RDX: dead0122 RSI: 0004 RDI: 88809fb5a7e8 RBP: 88809898f588 R08: dc00 R09: ed1013131ea8 R10: ed1013131ea8 R11: R12: dc00 R13: 88809fb5a480 R14: 88809fb5a7e0 R15: FS: 568cb880() GS:8880aea0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2610 CR3: a3968000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers
Re: [PATCH 2/3] xen/ballon: Avoid calling dummy function __online_page_set_limits()
On 07.09.19 23:47, Souptick Joarder wrote: __online_page_set_limits() is a dummy function and an extra call to this function can be avoided. Signed-off-by: Souptick Joarder Reviewed-by: Juergen Gross Juergen
Re: [PATCH] VMCI: Release resource if the work is already queued
> On Sep 7, 2019, at 9:47 PM, Greg Kroah-Hartman > wrote: > > On Tue, Aug 20, 2019 at 01:26:38PM -0700, Nadav Amit wrote: >> Francois reported that VMware balloon gets stuck after a balloon reset, >> when the VMCI doorbell is removed. A similar error can occur when the >> balloon driver is removed with the following splat: > > > > Note, google thinks your email is spam as you are not sending this from > a valid vmware.com email server. Please fix this up if you want to make > sure your patches actually make it through... I used gmail servers since I get complaints (mainly from Linus) that our email servers use DMARC, and this causes mailing list postings to be rejected. I will check again if our open source people got to a solution, or I would just send it using my gmail identity, while keeping the vmware authorship.
[PATCH] media: vim2m: Fix BUG_ON in vim2m_device_release()
If v4l2_m2m_init() fails, m2m_dev pointer will be set ERR_PTR(-ENOMEM),
then kfree m2m_dev will triger BUG_ON, see below, fix it by setting m2m_dev
to NULL.
vim2m vim2m.0: Failed to init mem2mem device
[ cut here ]
kernel BUG at mm/slub.c:3944!
invalid opcode: [#1] SMP PTI
CPU: 11 PID: 9061 Comm: insmod Tainted: GE 5.2.0-rc2 #81
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:kfree+0x11a/0x160
Call Trace:
vim2m_device_release+0x3f/0x50 [vim2m]
device_release+0x27/0x80
kobject_release+0x68/0x190
vim2m_probe+0x20f/0x280 [vim2m]
platform_drv_probe+0x37/0x90
really_probe+0xef/0x3d0
driver_probe_device+0x110/0x120
device_driver_attach+0x4f/0x60
__driver_attach+0x9a/0x140
? device_driver_attach+0x60/0x60
bus_for_each_dev+0x76/0xc0
? klist_add_tail+0x57/0x70
bus_add_driver+0x141/0x210
driver_register+0x5b/0xe0
vim2m_init+0x29/0x1000 [vim2m]
do_one_initcall+0x46/0x1f4
? __slab_alloc+0x1c/0x30
? kmem_cache_alloc_trace+0x167/0x1b0
do_init_module+0x5b/0x21f
load_module+0x1add/0x1fb0
? __do_sys_finit_module+0xe9/0x110
__do_sys_finit_module+0xe9/0x110
do_syscall_64+0x5b/0x1c0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: ea6c7e34f3b2 ("media: vim2m: replace devm_kzalloc by kzalloc")
Reported-by: Hulk Robot
Cc: Laurent Pinchart
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Signed-off-by: Kefeng Wang
---
drivers/media/platform/vim2m.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index acd3bd48c7e2..eb8f398d41f4 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -1343,6 +1343,7 @@ static int vim2m_probe(struct platform_device *pdev)
if (IS_ERR(dev->m2m_dev)) {
v4l2_err(&dev->v4l2_dev, "Failed to init mem2mem device\n");
ret = PTR_ERR(dev->m2m_dev);
+ dev->m2m_dev = NULL;
goto error_dev;
}
--
2.20.1
[PATCH v2] regulator: lp87565: Simplify lp87565_buck_set_ramp_delay
Use rdev->regmap/&rdev->dev instead of lp87565->regmap/lp87565->dev.
In additional, the lp87565->dev actually is the parent mfd device,
so the dev_err message is misleading here with lp87565->dev.
Signed-off-by: Axel Lin
---
v2: Add lp87565 prefix in subject line
drivers/regulator/lp87565-regulator.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 0c440c5e2832..4ae12ac1f4c6 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -65,7 +65,6 @@ static int lp87565_buck_set_ramp_delay(struct regulator_dev
*rdev,
int ramp_delay)
{
int id = rdev_get_id(rdev);
- struct lp87565 *lp87565 = rdev_get_drvdata(rdev);
unsigned int reg;
int ret;
@@ -86,11 +85,11 @@ static int lp87565_buck_set_ramp_delay(struct regulator_dev
*rdev,
else
reg = 0;
- ret = regmap_update_bits(lp87565->regmap, regulators[id].ctrl2_reg,
+ ret = regmap_update_bits(rdev->regmap, regulators[id].ctrl2_reg,
LP87565_BUCK_CTRL_2_SLEW_RATE,
reg << __ffs(LP87565_BUCK_CTRL_2_SLEW_RATE));
if (ret) {
- dev_err(lp87565->dev, "SLEW RATE write failed: %d\n", ret);
+ dev_err(&rdev->dev, "SLEW RATE write failed: %d\n", ret);
return ret;
}
--
2.20.1
[PATCH] regulator: Simplify lp87565_buck_set_ramp_delay
Use rdev->regmap/&rdev->dev instead of lp87565->regmap/lp87565->dev.
In additional, the lp87565->dev actually is the parent mfd device,
so the dev_err message is misleading here with lp87565->dev.
Signed-off-by: Axel Lin
---
drivers/regulator/lp87565-regulator.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 0c440c5e2832..4ae12ac1f4c6 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -65,7 +65,6 @@ static int lp87565_buck_set_ramp_delay(struct regulator_dev
*rdev,
int ramp_delay)
{
int id = rdev_get_id(rdev);
- struct lp87565 *lp87565 = rdev_get_drvdata(rdev);
unsigned int reg;
int ret;
@@ -86,11 +85,11 @@ static int lp87565_buck_set_ramp_delay(struct regulator_dev
*rdev,
else
reg = 0;
- ret = regmap_update_bits(lp87565->regmap, regulators[id].ctrl2_reg,
+ ret = regmap_update_bits(rdev->regmap, regulators[id].ctrl2_reg,
LP87565_BUCK_CTRL_2_SLEW_RATE,
reg << __ffs(LP87565_BUCK_CTRL_2_SLEW_RATE));
if (ret) {
- dev_err(lp87565->dev, "SLEW RATE write failed: %d\n", ret);
+ dev_err(&rdev->dev, "SLEW RATE write failed: %d\n", ret);
return ret;
}
--
2.20.1
Re: general protection fault in dev_map_hash_update_elem
syzbot has found a reproducer for the following crash on: HEAD commit:a2c11b03 kcm: use BPF_PROG_RUN git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=13d46ec160 kernel config: https://syzkaller.appspot.com/x/.config?x=cf0c85d15c20ade3 dashboard link: https://syzkaller.appspot.com/bug?extid=4e7a85b1432052e8d6f8 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1220b2d160 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1360b26e60 Bisection is inconclusive: the first bad commit could be any of: 116e7dbe Merge branch 'gen-syn-cookie' 91bc3578 selftests/bpf: add test for bpf_tcp_gen_syncookie 637f71c0 selftests/bpf: bpf_tcp_gen_syncookie->bpf_helpers bf8ff0f8 selftests/bpf: fix clearing buffered output between tests/subtests 3745ee18 bpf: sync bpf.h to tools/ a98bf573 tools: bpftool: add support for reporting the effective cgroup progs 70d66244 bpf: add bpf_tcp_gen_syncookie helper 9babe825 bpf: always allocate at least 16 bytes for setsockopt hook 9349d600 tcp: add skb-less helpers to retrieve SYN cookie fd5ef31f selftests/bpf: extend sockopt_sk selftest with TCP_CONGESTION use case 02bc2b64 Merge branch 'setsockopt-extra-mem' 96511278 tcp: tcp_syn_flood_action read port from socket a78d0dbe selftests/bpf: add loop test 4 d3406913 Merge branch 'devmap_hash' 1375dc4a tools: Add definitions for devmap_hash map type 8c303960 selftests/bpf: add loop test 5 946152b3 selftests/bpf: test_progs: switch to open_memstream e4234619 tools/libbpf_probes: Add new devmap_hash type 10fbe211 tools/include/uapi: Add devmap_hash BPF map type 66bd2ec1 selftests/bpf: test_progs: test__printf -> printf 16e910d4 selftests/bpf: test_progs: drop extra trailing tab 6f9d451a xdp: Add devmap_hash map type for looking up devices by hashed index 682cdbdc Merge branch 'test_progs-stdio' fca16e51 xdp: Refactor devmap allocation code for reuse 6dbff13c include/bpf.h: Remove map_insert_ctx() stubs ef20a9b2 libbpf: add helpers for working with BTF types 475e31f8 Merge branch 'revamp-test_progs' b03bc685 libbpf: convert libbpf code to use new btf helpers 4cedc0da libbpf: add .BTF.ext offset relocation section loading b207edfe selftests/bpf: convert send_signal.c to use subtests 51436ed7 selftests/bpf: convert bpf_verif_scale.c to sub-tests API ddc7c304 libbpf: implement BPF CO-RE offset relocation algorithm 2dc26d5a selftests/bpf: add BPF_CORE_READ relocatable read macro 3a516a0a selftests/bpf: add sub-tests support for test_progs 0ff97e56 selftests/bpf: abstract away test log output df36e621 selftests/bpf: add CO-RE relocs testing setup 002d3afc selftests/bpf: add CO-RE relocs struct flavors tests 329e38f7 selftest/bpf: centralize libbpf logging management for test_progs e87fd8ba libbpf: return previous print callback from libbpf_set_print ec6438a9 selftests/bpf: add CO-RE relocs nesting tests 20a9ad2e selftests/bpf: add CO-RE relocs array tests 8160bae2 selftests/bpf: add test selectors by number and name to test_progs 766f2a59 selftests/bpf: revamp test_progs to allow more control d9db3550 selftests/bpf: add CO-RE relocs enum/ptr/func_proto tests 61098e89 selftests/bpf: prevent headers to be compiled as C code 9654e2ae selftests/bpf: add CO-RE relocs modifiers/typedef tests 943e398d Merge branch 'flow_dissector-input-flags' d698f9db selftests/bpf: add CO-RE relocs ptr-as-array tests c1f5e7dd selftests/bpf: add CO-RE relocs ints tests e853ae77 selftests/bpf: support BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP 29e1c668 selftests/bpf: add CO-RE relocs misc tests 71c99e32 bpf/flow_dissector: support ipv6 flow_label and BPF_FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL 726e333f Merge branch 'compile-once-run-everywhere' ae173a91 selftests/bpf: support BPF_FLOW_DISSECTOR_F_PARSE_1ST_FRAG 57debff2 tools/bpf: sync bpf_flow_keys flags b7076592 tools/bpf: fix core_reloc.c compilation error b2ca4e1c bpf/flow_dissector: support flags in BPF_PROG_TEST_RUN d9973cec xdp: xdp_umem: fix umem pages mapping for 32bits systems 1ac6b126 bpf/flow_dissector: document flags 3783d437 samples/bpf: xdp_fwd rename devmap name to be xdp_tx_ports 086f9568 bpf/flow_dissector: pass input flags to BPF flow dissector program a32a32cb samples/bpf: make xdp_fwd more practically usable via devmap lookup 03cd1d1a selftests/bpf: Add selftests for bpf_perf_event_output abcce733 samples/bpf: xdp_fwd explain bpf_fib_lookup return codes 7c4b90d7 bpf: Allow bpf_skb_event_output for a few prog types 9f30cd56 Merge branch 'bpf-xdp-fwd-sample-improvements' 5e31d507 Merge branch 'convert-tests-to-libbpf' a664a834 tools: bpftool: fix reading from /proc/config.gz 341dfcf8 btf: expose BTF info through sysfs 47da6e4d selftests/bpf: remove perf buffer helpers c17bec54 samples/bpf: switch trace_output sample to perf_buffer API d66fa3c7 tools: bpftool: add feature check for zlib 9840a4ff selftests/bpf: fix race in flow dissector tests f58a4d51 samples/bpf: convert xdp_sample
Re: [patch for-5.3 0/4] revert immediate fallback to remote hugepages
On Sat, 7 Sep 2019, Linus Torvalds wrote: > > Andrea acknowledges the swap storm that he reported would be fixed with > > the last two patches in this series > > The problem is that even you aren't arguing that those patches should > go into 5.3. > For three reasons: (a) we lack a test result from Andrea, (b) there's on-going discussion, particularly based on Vlastimil's feedback, and (c) the patches will be refreshed incorporating that feedback as well as Mike's suggestion to exempt __GFP_RETRY_MAYFAIL for hugetlb. > So those fixes aren't going in, so "the swap storms would be fixed" > argument isn't actually an argument at all as far as 5.3 is concerned. > It indicates that progress has been made to address the actual bug without introducing long-lived access latency regressions for others, particularly those who use MADV_HUGEPAGE. In the worst case, some systems running 5.3-rc4 and 5.3-rc5 have the same amount of memory backed by hugepages but on 5.3-rc5 the vast majority of it is allocated remotely. This incurs a signficant performance regression regardless of platform; the only thing needed to induce this is a fragmented local node that would otherwise be compacted in 5.3-rc4 rather than quickly allocate remote on 5.3-rc5. > End result: we'd have the qemu-kvm instance performance problem in 5.3 > that apparently causes distros to apply those patches that you want to > revert anyway. > > So reverting would just make distros not use 5.3 in that form. > I'm arguing to revert 5.3 back to the behavior that we have had for years and actually fix the bug that everybody else seems to be ignoring and then *backport* those fixes to 5.3 stable and every other stable tree that can use them. Introducing a new mempolicy for NUMA locality into 5.3.0 that will subsequently changed in future 5.3 stable kernels and differs from all kernels from the past few years is not in anybody's best interest if the actual problem can be fixed. It requires more feedback than a one-line "the swap storms would be fixed with this." That collaboration takes time and isn't something that should be rushed into 5.3-rc5. Yes, we can fix NUMA locality of hugepages when a workload like qemu is larger than a single socket; the vast majority of workloads in the datacenter are small than a socket and *cannot* incur the performance penalty if local memory is fragmented that 5.3-rc5 introduces. In other words, 5.3-rc5 is only fixing a highly specialized usecase where remote allocation is acceptable because the workload is larger than a socket *and* remote memory is not low on memory or fragmented. If you consider the opposite of that, workloads smaller than a socket or local compaction actually works, this has introduced a measurable regression for everybody else. I'm not sure why we are ignoring a painfully obvious bug in the page allocator because of a poor feedback loop between itself and memory compaction and rather papering over it by falling back to remote memory when NUMA actually does matter. If you release 5.3 without the first two patches in this series, I wouldn't expect any additional feedback or test results to fix this bug considering all we have gotten so far is "this would fix this swap storms" and not collaborating to fix the issue for everybody rather than only caring about their own workloads. At least my patches acknowledge and try to fix the issue the other is encountering.
Re: [PATCH 0/8] kconfig/hacking: make 'kernel hacking' menu better structured
This is a preview: │ ┌───┐ │ │ │printk and dmesg options ---> │ │ │ │Compile-time checks and compiler options ---> │ │ │ │Generic Kernel Debugging Instruments ---> │ │ │ │-*- Kernel debugging │ │ │ │[*] Miscellaneous debug code │ │ │ │Memory Debugging ---> │ │ │ │IRQ Debugging --->│ │ │ │Debug Oops, Lockups and Hangs --->│ │ │ │Scheduler Debugging ---> │ │ │ │[*] Enable extra timekeeping sanity checking │ │ │ │Lock Debugging (spinlocks, mutexes, etc...) ---> │ │ │ │-*- Stack backtrace support│ │ │ │[ ] Warn for all uses of unseeded randomness │ │ │ │[ ] kobject debugging │ │ │ │Debug kernel data structures ---> │ │ │ │[ ] Debug notifier call chains │ │ │ │[ ] Debug credential management│ │ │ │RCU Debugging --->│ │ │ │[ ] Force round-robin CPU selection for unbound work items │ │ │ │[ ] Force extended block device numbers and spread them│ │ │ │[ ] Enable CPU hotplug state control │ │ │ │[*] Latency measuring infrastructure │ │ │ │[*] Tracers ---> │ │ │ │[ ] Remote debugging over FireWire early on boot │ │ │ │[*] Sample kernel code ---> │ │ │ │[*] Filter access to /dev/mem │ │ │ │[ ] Filter I/O access to /dev/mem│ │ │ │x86 Debugging --->│ │ │ │Kernel Testing and Coverage ---> │ │ │ │ │ │ │ │ │ │ │ └───┘ │ ├───┤ │ < Exit >< Help >< Save >< Load >│ └───┘ On Sun, Sep 08, 2019 at 09:27:52AM +0800, Changbin Du wrote: > This series is a trivial improvment for the layout of 'kernel hacking' > configuration menu. Now we have many items in it which makes takes > a little time to look up them since they are not well structured yet. > > Early discussion is here: > https://lkml.org/lkml/2019/9/1/39 > > Changbin Du (8): > kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging > Instruments' > kconfig/hacking: Create submenu for arch special debugging options > kconfig/hacking: Group kernel data structures debugging together > kconfig/hacking: Move kernel testing and coverage options to same > submenu > kconfig/hacking: Move Oops into 'Lockups and Hangs' > kconfig/hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE > kconfig/hacking: Create a submenu for scheduler debugging options > kconfig/hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options' > > lib/Kconfig.debug | 627 -- > 1 file changed, 324 insertions(+), 303 deletions(-) > > -- > 2.20.1 > -- Cheers, Changbin Du
[PATCH 8/8] kconfig/hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options'
I think DEBUG_BUGVERBOSE is a dmesg option which gives more debug info to dmesg. Signed-off-by: Changbin Du --- lib/Kconfig.debug | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 740ada6744f6..bb82a02f6172 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -164,6 +164,15 @@ config DYNAMIC_DEBUG See Documentation/admin-guide/dynamic-debug-howto.rst for additional information. +config DEBUG_BUGVERBOSE + bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT + depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE) + default y + help + Say Y here to make BUG() panics output the file name and line number + of the BUG call as well as the EIP and oops trace. This aids + debugging but costs about 70-100K of memory. + endmenu # "printk and dmesg options" menu "Compile-time checks and compiler options" @@ -1322,15 +1331,6 @@ config DEBUG_KOBJECT_RELEASE config HAVE_DEBUG_BUGVERBOSE bool -config DEBUG_BUGVERBOSE - bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT - depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE) - default y - help - Say Y here to make BUG() panics output the file name and line number - of the BUG call as well as the EIP and oops trace. This aids - debugging but costs about 70-100K of memory. - menu "Debug kernel data structures" config DEBUG_LIST -- 2.20.1
[PATCH 6/8] kconfig/hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE
They are both memory debug options to debug kernel stack issues. Signed-off-by: Changbin Du --- lib/Kconfig.debug | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 99c6dbd64ce7..458d2a4435a4 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -651,6 +651,18 @@ config DEBUG_STACK_USAGE This option will slow down process creation somewhat. +config SCHED_STACK_END_CHECK + bool "Detect stack corruption on calls to schedule()" + depends on DEBUG_KERNEL + default n + help + This option checks for a stack overrun on calls to schedule(). + If the stack end location is found to be over written always panic as + the content of the corrupted region can no longer be trusted. + This is to ensure no erroneous behaviour occurs which could result in + data corruption or a sporadic crash at a later stage once the region + is examined. The runtime overhead introduced is minimal. + config DEBUG_VM bool "Debug VM" depends on DEBUG_KERNEL @@ -1004,18 +1016,6 @@ config SCHEDSTATS application, you can say N to avoid the very slight overhead this adds. -config SCHED_STACK_END_CHECK - bool "Detect stack corruption on calls to schedule()" - depends on DEBUG_KERNEL - default n - help - This option checks for a stack overrun on calls to schedule(). - If the stack end location is found to be over written always panic as - the content of the corrupted region can no longer be trusted. - This is to ensure no erroneous behaviour occurs which could result in - data corruption or a sporadic crash at a later stage once the region - is examined. The runtime overhead introduced is minimal. - config DEBUG_TIMEKEEPING bool "Enable extra timekeeping sanity checking" help -- 2.20.1
[PATCH 7/8] kconfig/hacking: Create a submenu for scheduler debugging options
Create a submenu 'Scheduler Debugging' for scheduler debugging options. Signed-off-by: Changbin Du --- lib/Kconfig.debug | 4 1 file changed, 4 insertions(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 458d2a4435a4..740ada6744f6 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -990,6 +990,8 @@ config WQ_WATCHDOG endmenu # "Debug lockups and hangs" +menu "Scheduler Debugging" + config SCHED_DEBUG bool "Collect scheduler debugging info" depends on DEBUG_KERNEL && PROC_FS @@ -1016,6 +1018,8 @@ config SCHEDSTATS application, you can say N to avoid the very slight overhead this adds. +endmenu + config DEBUG_TIMEKEEPING bool "Enable extra timekeeping sanity checking" help -- 2.20.1
[PATCH 5/8] kconfig/hacking: Move Oops into 'Lockups and Hangs'
They are similar options so place them together. Signed-off-by: Changbin Du --- lib/Kconfig.debug | 58 +++ 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index ca2083350178..99c6dbd64ce7 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -792,7 +792,35 @@ config DEBUG_SHIRQ Drivers ought to be able to handle interrupts coming in at those points; some don't and need to be caught. -menu "Debug Lockups and Hangs" +menu "Debug Oops, Lockups and Hangs" + +config PANIC_ON_OOPS + bool "Panic on Oops" + help + Say Y here to enable the kernel to panic when it oopses. This + has the same effect as setting oops=panic on the kernel command + line. + + This feature is useful to ensure that the kernel does not do + anything erroneous after an oops which could result in data + corruption or other issues. + + Say N if unsure. + +config PANIC_ON_OOPS_VALUE + int + range 0 1 + default 0 if !PANIC_ON_OOPS + default 1 if PANIC_ON_OOPS + +config PANIC_TIMEOUT + int "panic timeout" + default 0 + help + Set the timeout value (in seconds) until a reboot occurs when the + the kernel panics. If n = 0, then we wait forever. A timeout + value n > 0 will wait n seconds before rebooting, while a timeout + value n < 0 will reboot immediately. config LOCKUP_DETECTOR bool @@ -950,34 +978,6 @@ config WQ_WATCHDOG endmenu # "Debug lockups and hangs" -config PANIC_ON_OOPS - bool "Panic on Oops" - help - Say Y here to enable the kernel to panic when it oopses. This - has the same effect as setting oops=panic on the kernel command - line. - - This feature is useful to ensure that the kernel does not do - anything erroneous after an oops which could result in data - corruption or other issues. - - Say N if unsure. - -config PANIC_ON_OOPS_VALUE - int - range 0 1 - default 0 if !PANIC_ON_OOPS - default 1 if PANIC_ON_OOPS - -config PANIC_TIMEOUT - int "panic timeout" - default 0 - help - Set the timeout value (in seconds) until a reboot occurs when the - the kernel panics. If n = 0, then we wait forever. A timeout - value n > 0 will wait n seconds before rebooting, while a timeout - value n < 0 will reboot immediately. - config SCHED_DEBUG bool "Collect scheduler debugging info" depends on DEBUG_KERNEL && PROC_FS -- 2.20.1
[PATCH 3/8] kconfig/hacking: Group kernel data structures debugging together
Group these similar runtime data structures verification options together. Signed-off-by: Changbin Du --- lib/Kconfig.debug | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 96047140be93..3c9674483ec2 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1374,6 +1374,8 @@ config DEBUG_BUGVERBOSE of the BUG call as well as the EIP and oops trace. This aids debugging but costs about 70-100K of memory. +menu "Debug kernel data structures" + config DEBUG_LIST bool "Debug linked list manipulation" depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION @@ -1403,6 +1405,18 @@ config DEBUG_SG If unsure, say N. +config BUG_ON_DATA_CORRUPTION + bool "Trigger a BUG when data corruption is detected" + select DEBUG_LIST + help + Select this option if the kernel should BUG when it encounters + data corruption in kernel memory structures when they get checked + for validity. + + If unsure, say N. + +endmenu + config DEBUG_NOTIFIERS bool "Debug notifier call chains" depends on DEBUG_KERNEL @@ -2095,16 +2109,6 @@ config MEMTEST memtest=17, mean do 17 test patterns. If you are unsure how to answer this question, answer N. -config BUG_ON_DATA_CORRUPTION - bool "Trigger a BUG when data corruption is detected" - select DEBUG_LIST - help - Select this option if the kernel should BUG when it encounters - data corruption in kernel memory structures when they get checked - for validity. - - If unsure, say N. - source "samples/Kconfig" config ARCH_HAS_DEVMEM_IS_ALLOWED -- 2.20.1
[PATCH 1/8] kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments'
Group generic kernel debugging instruments sysrq/kgdb/ubsan together into a new submenu. Signed-off-by: Changbin Du --- lib/Kconfig.debug | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 5960e2980a8a..868fa64a0901 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -419,6 +419,8 @@ config DEBUG_FORCE_WEAK_PER_CPU endmenu # "Compiler options" +menu "Generic Kernel Debugging Instruments" + config MAGIC_SYSRQ bool "Magic SysRq key" depends on !UML @@ -452,6 +454,12 @@ config MAGIC_SYSRQ_SERIAL This option allows you to decide whether you want to enable the magic SysRq key. +source "lib/Kconfig.kgdb" + +source "lib/Kconfig.ubsan" + +endmenu + config DEBUG_KERNEL bool "Kernel debugging" help @@ -2099,10 +2107,6 @@ config BUG_ON_DATA_CORRUPTION source "samples/Kconfig" -source "lib/Kconfig.kgdb" - -source "lib/Kconfig.ubsan" - config ARCH_HAS_DEVMEM_IS_ALLOWED bool -- 2.20.1
[PATCH 2/8] kconfig/hacking: Create submenu for arch special debugging options
The arch special options are a little long, so create a submenu for them. Signed-off-by: Changbin Du --- lib/Kconfig.debug | 4 1 file changed, 4 insertions(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 868fa64a0901..96047140be93 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2146,6 +2146,10 @@ config IO_STRICT_DEVMEM If in doubt, say Y. +menu "$(SRCARCH) Debugging" + source "arch/$(SRCARCH)/Kconfig.debug" +endmenu + endmenu # Kernel hacking -- 2.20.1
[PATCH 4/8] kconfig/hacking: Move kernel testing and coverage options to same submenu
Move error injection, coverage, testing options to a new submenu 'Kernel Testing and Coverage'. They are all for test purpose. Signed-off-by: Changbin Du --- lib/Kconfig.debug | 485 +++--- 1 file changed, 245 insertions(+), 240 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 3c9674483ec2..ca2083350178 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -783,53 +783,6 @@ source "lib/Kconfig.kasan" endmenu # "Memory Debugging" -config ARCH_HAS_KCOV - bool - help - An architecture should select this when it can successfully - build and run with CONFIG_KCOV. This typically requires - disabling instrumentation for some early boot code. - -config CC_HAS_SANCOV_TRACE_PC - def_bool $(cc-option,-fsanitize-coverage=trace-pc) - -config KCOV - bool "Code coverage for fuzzing" - depends on ARCH_HAS_KCOV - depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS - select DEBUG_FS - select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC - help - KCOV exposes kernel code coverage information in a form suitable - for coverage-guided fuzzing (randomized testing). - - If RANDOMIZE_BASE is enabled, PC values will not be stable across - different machines and across reboots. If you need stable PC values, - disable RANDOMIZE_BASE. - - For more details, see Documentation/dev-tools/kcov.rst. - -config KCOV_ENABLE_COMPARISONS - bool "Enable comparison operands collection by KCOV" - depends on KCOV - depends on $(cc-option,-fsanitize-coverage=trace-cmp) - help - KCOV also exposes operands of every comparison in the instrumented - code along with operand sizes and PCs of the comparison instructions. - These operands can be used by fuzzing engines to improve the quality - of fuzzing coverage. - -config KCOV_INSTRUMENT_ALL - bool "Instrument all code by default" - depends on KCOV - default y - help - If you are doing generic system call fuzzing (like e.g. syzkaller), - then you will want to instrument the whole kernel and you should - say y here. If you are doing more targeted fuzzing (like e.g. - filesystem fuzzing with AFL) then you will want to enable coverage - for more specific subsets of files, and should say n here. - config DEBUG_SHIRQ bool "Debug shared IRQ handlers" depends on DEBUG_KERNEL @@ -1499,164 +1452,6 @@ config CPU_HOTPLUG_STATE_CONTROL Say N if your are unsure. -config NOTIFIER_ERROR_INJECTION - tristate "Notifier error injection" - depends on DEBUG_KERNEL - select DEBUG_FS - help - This option provides the ability to inject artificial errors to - specified notifier chain callbacks. It is useful to test the error - handling of notifier call chain failures. - - Say N if unsure. - -config PM_NOTIFIER_ERROR_INJECT - tristate "PM notifier error injection module" - depends on PM && NOTIFIER_ERROR_INJECTION - default m if PM_DEBUG - help - This option provides the ability to inject artificial errors to - PM notifier chain callbacks. It is controlled through debugfs - interface /sys/kernel/debug/notifier-error-inject/pm - - If the notifier call chain should be failed with some events - notified, write the error code to "actions//error". - - Example: Inject PM suspend error (-12 = -ENOMEM) - - # cd /sys/kernel/debug/notifier-error-inject/pm/ - # echo -12 > actions/PM_SUSPEND_PREPARE/error - # echo mem > /sys/power/state - bash: echo: write error: Cannot allocate memory - - To compile this code as a module, choose M here: the module will - be called pm-notifier-error-inject. - - If unsure, say N. - -config OF_RECONFIG_NOTIFIER_ERROR_INJECT - tristate "OF reconfig notifier error injection module" - depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION - help - This option provides the ability to inject artificial errors to - OF reconfig notifier chain callbacks. It is controlled - through debugfs interface under - /sys/kernel/debug/notifier-error-inject/OF-reconfig/ - - If the notifier call chain should be failed with some events - notified, write the error code to "actions//error". - - To compile this code as a module, choose M here: the module will - be called of-reconfig-notifier-error-inject. - - If unsure, say N. - -config NETDEV_NOTIFIER_ERROR_INJECT - tristate "Netdev notifier error injection module" - depends on NET && NOTIFIER_ERROR_INJECTION - help - This option provides the ability to inject artificial errors to - netdevice notifier chain callbacks. It is controlled through d
[PATCH 0/8] kconfig/hacking: make 'kernel hacking' menu better structured
This series is a trivial improvment for the layout of 'kernel hacking' configuration menu. Now we have many items in it which makes takes a little time to look up them since they are not well structured yet. Early discussion is here: https://lkml.org/lkml/2019/9/1/39 Changbin Du (8): kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments' kconfig/hacking: Create submenu for arch special debugging options kconfig/hacking: Group kernel data structures debugging together kconfig/hacking: Move kernel testing and coverage options to same submenu kconfig/hacking: Move Oops into 'Lockups and Hangs' kconfig/hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE kconfig/hacking: Create a submenu for scheduler debugging options kconfig/hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options' lib/Kconfig.debug | 627 -- 1 file changed, 324 insertions(+), 303 deletions(-) -- 2.20.1
drivers/power/reset/nvmem-reboot-mode.c:27:42: error: passing argument 2 of 'nvmem_cell_write' from incompatible pointer type
Hi Han,
FYI, the error/warning still remains.
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 950b07c14e8c59444e2359f15fd70ed5112e11a0
commit: 7a78a7f7695bf9ef9cef3c06fbc5fa4573fd0eef power: reset:
nvmem-reboot-mode: use NVMEM as reboot mode write interface
date: 2 months ago
config: i386-randconfig-e003-201936 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
git checkout 7a78a7f7695bf9ef9cef3c06fbc5fa4573fd0eef
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/power/reset/nvmem-reboot-mode.c: In function
'nvmem_reboot_mode_write':
>> drivers/power/reset/nvmem-reboot-mode.c:27:42: error: passing argument 2 of
>> 'nvmem_cell_write' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
ret = nvmem_cell_write(nvmem_rbm->cell, &magic, sizeof(magic));
^
In file included from drivers/power/reset/nvmem-reboot-mode.c:10:0:
include/linux/nvmem-consumer.h:120:19: note: expected 'const char *' but
argument is of type 'unsigned int *'
static inline int nvmem_cell_write(struct nvmem_cell *cell,
^~~~
cc1: some warnings being treated as errors
vim +/nvmem_cell_write +27 drivers/power/reset/nvmem-reboot-mode.c
18
19 static int nvmem_reboot_mode_write(struct reboot_mode_driver *reboot,
20 unsigned int magic)
21 {
22 int ret;
23 struct nvmem_reboot_mode *nvmem_rbm;
24
25 nvmem_rbm = container_of(reboot, struct nvmem_reboot_mode,
reboot);
26
> 27 ret = nvmem_cell_write(nvmem_rbm->cell, &magic, sizeof(magic));
28 if (ret < 0)
29 dev_err(reboot->dev, "update reboot mode bits
failed\n");
30
31 return ret;
32 }
33
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] tpm_crb: fix fTPM on AMD Zen+ CPUs
On Sun, 2019-09-08 at 00:49 +0300, Jarkko Sakkinen wrote: > On Wed, 2019-09-04 at 22:03 +0300, ivan.laz...@gmail.com wrote: > > From: Ivan Lazeev > > > > Bug link: https://bugzilla.kernel.org/show_bug.cgi?id=195657 > > > > cmd/rsp buffers are expected to be in the same ACPI region. > > For Zen+ CPUs BIOS's might report two different regions, some of > > them also report region sizes inconsistent with values from TPM > > registers. > > > > Work around the issue by storing ACPI regions declared for the > > device in a list, then using it to find entry corresponding > > to each buffer. Use information from the entry to map each resource > > at most once and make buffer size consistent with the length of the > > region. > > > > Signed-off-by: Ivan Lazeev > > Can you add the relevant pieces of /proc/iomem output to the commit > message so we can see the memory configuration? I don't have the > hardware available where this kind of situation occurs. Here in particular this is more than relevant because given that this patch fixes the issue for you, it seems that you don't have the regions marked as NVS regions. /Jarkko
[PATCH v3 0/4] cpuidle, haltpoll: governor switching on idle register
Hey, Presented herewith a series with aims to tie in together the haltpoll idle driver and governor, without sacrificing previous governor setups. In addition, there are a few fixes with respect to module loading for cpuidle-haltpoll. The series is organized as follows: Patch 1: Allows idle driver stating a preferred governor that it wants to use, based on discussion here: https://lore.kernel.org/kvm/457e8ca1-beb3-ca39-b257-e7bc6bb35...@oracle.com/ Patch 2: Decrease rating of governor, and allows previous defaults to be as before haltpoll, while using @governor to switch to haltpoll when haltpoll driver is registered; Patch 3 - 4: Module loading fixes. first is the incorrect error reporting and second is supportting module unloading. Thanks, Joao v3: * Fixed ARM build issues. v2: * Add missing Fixes tag on patches 3 and 4. Joao Martins (4): cpuidle: allow governor switch on cpuidle_register_driver() cpuidle-haltpoll: set haltpoll as preferred governor cpuidle-haltpoll: return -ENODEV on modinit failure cpuidle-haltpoll: do not set an owner to allow modunload drivers/cpuidle/cpuidle-haltpoll.c | 4 ++-- drivers/cpuidle/cpuidle.h| 2 ++ drivers/cpuidle/driver.c | 25 + drivers/cpuidle/governor.c | 7 --- drivers/cpuidle/governors/haltpoll.c | 2 +- include/linux/cpuidle.h | 3 +++ 6 files changed, 37 insertions(+), 6 deletions(-) -- 2.17.1
Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
Hi Yuehaibing, > >> Use devm_platform_ioremap_resource() to simplify the code a bit. > >> This is detected by coccinelle. > >> > >> Reported-by: Hulk Robot > > > > This tag does not look real... First of all where is the report? > > It is our internal CI robot, which is unavailable to external temporarily. Hulk Robot is not a person and not accountable for his report. If it is your internal CI, please write a sentence stating that the fix has been made using Huawei internal tools. Credit must be given to tools as well, but not accounts that will never answer an e-mail. Otherwise, the patch would look fine. Andi
[PATCH v3 4/4] cpuidle-haltpoll: do not set an owner to allow modunload
cpuidle-haltpoll can be built as a module to allow optional late load.
Given we are setting @owner to THIS_MODULE, cpuidle will attempt to grab a
module reference every time a cpuidle_device is registered -- so
essentially all online cpus get a reference.
This prevents for the module to be unloaded later, which makes the
module_exit callback entirely unused. Thus remove the @owner and allow
module to be unloaded.
Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
Signed-off-by: Joao Martins
---
v2:
* Added Fixes tag
---
drivers/cpuidle/cpuidle-haltpoll.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-haltpoll.c
b/drivers/cpuidle/cpuidle-haltpoll.c
index 7a0239ef717e..49a65c6fe91e 100644
--- a/drivers/cpuidle/cpuidle-haltpoll.c
+++ b/drivers/cpuidle/cpuidle-haltpoll.c
@@ -35,7 +35,6 @@ static int default_enter_idle(struct cpuidle_device *dev,
static struct cpuidle_driver haltpoll_driver = {
.name = "haltpoll",
.governor = "haltpoll",
- .owner = THIS_MODULE,
.states = {
{ /* entry 0 is for polling */ },
{
--
2.17.1
[PATCH v3 3/4] cpuidle-haltpoll: return -ENODEV on modinit failure
When a user loads cpuidle-haltpoll on a non KVM guest the module will
successfully load, even though idle driver registration didn't take
place.
We should instead return -ENODEV signaling the user that the driver can't
be loaded, like other error paths in haltpoll_init(). An example of such
error paths is when we return -EBUSY when attempting to register an idle
driver when it had one already (e.g. intel_idle loads at boot and then we
attempt to insert module cpuidle-haltpoll).
Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
Signed-off-by: Joao Martins
---
v2:
* Added Fixes tag
---
drivers/cpuidle/cpuidle-haltpoll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-haltpoll.c
b/drivers/cpuidle/cpuidle-haltpoll.c
index 519e90d125cf..7a0239ef717e 100644
--- a/drivers/cpuidle/cpuidle-haltpoll.c
+++ b/drivers/cpuidle/cpuidle-haltpoll.c
@@ -99,7 +99,7 @@ static int __init haltpoll_init(void)
cpuidle_poll_state_init(drv);
if (!kvm_para_available())
- return 0;
+ return -ENODEV;
ret = cpuidle_register_driver(drv);
if (ret < 0)
--
2.17.1
[PATCH v3 1/4] cpuidle: allow governor switch on cpuidle_register_driver()
The recently introduced haltpoll driver is largely only useful with
haltpoll governor. To allow drivers to associate with a particular idle
behaviour, add a @governor property to 'struct cpuidle_driver' and thus
allow a cpuidle driver to switch to a *preferred* governor on idle driver
registration. We save the previous governor, and when an idle driver is
unregistered we switch back to that.
The @governor can be overridden by cpuidle.governor= boot param or
alternatively be ignored if the governor doesn't exist.
Signed-off-by: Joao Martins
---
v3:
* Fix kbuild test robot arm issues with CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
Specifically, moved @cpuidle_prev_governor to a more generic place
as this is not really tied to !CONFIG_CPU_IDLE_MULTIPLE_DRIVERS
---
drivers/cpuidle/cpuidle.h | 2 ++
drivers/cpuidle/driver.c | 25 +
drivers/cpuidle/governor.c | 7 ---
include/linux/cpuidle.h| 3 +++
4 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
index d6613101af92..9f336af17fa6 100644
--- a/drivers/cpuidle/cpuidle.h
+++ b/drivers/cpuidle/cpuidle.h
@@ -9,6 +9,7 @@
/* For internal use only */
extern char param_governor[];
extern struct cpuidle_governor *cpuidle_curr_governor;
+extern struct cpuidle_governor *cpuidle_prev_governor;
extern struct list_head cpuidle_governors;
extern struct list_head cpuidle_detected_devices;
extern struct mutex cpuidle_lock;
@@ -22,6 +23,7 @@ extern void cpuidle_install_idle_handler(void);
extern void cpuidle_uninstall_idle_handler(void);
/* governors */
+extern struct cpuidle_governor *cpuidle_find_governor(const char *str);
extern int cpuidle_switch_governor(struct cpuidle_governor *gov);
/* sysfs */
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index dc32f34e68d9..80c1a830d991 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -254,12 +254,25 @@ static void __cpuidle_unregister_driver(struct
cpuidle_driver *drv)
*/
int cpuidle_register_driver(struct cpuidle_driver *drv)
{
+ struct cpuidle_governor *gov;
int ret;
spin_lock(&cpuidle_driver_lock);
ret = __cpuidle_register_driver(drv);
spin_unlock(&cpuidle_driver_lock);
+ if (!ret && !strlen(param_governor) && drv->governor &&
+ (cpuidle_get_driver() == drv)) {
+ mutex_lock(&cpuidle_lock);
+ gov = cpuidle_find_governor(drv->governor);
+ if (gov) {
+ cpuidle_prev_governor = cpuidle_curr_governor;
+ if (cpuidle_switch_governor(gov) < 0)
+ cpuidle_prev_governor = NULL;
+ }
+ mutex_unlock(&cpuidle_lock);
+ }
+
return ret;
}
EXPORT_SYMBOL_GPL(cpuidle_register_driver);
@@ -274,9 +287,21 @@ EXPORT_SYMBOL_GPL(cpuidle_register_driver);
*/
void cpuidle_unregister_driver(struct cpuidle_driver *drv)
{
+ bool enabled = (cpuidle_get_driver() == drv);
+
spin_lock(&cpuidle_driver_lock);
__cpuidle_unregister_driver(drv);
spin_unlock(&cpuidle_driver_lock);
+
+ if (!enabled)
+ return;
+
+ mutex_lock(&cpuidle_lock);
+ if (cpuidle_prev_governor) {
+ if (!cpuidle_switch_governor(cpuidle_prev_governor))
+ cpuidle_prev_governor = NULL;
+ }
+ mutex_unlock(&cpuidle_lock);
}
EXPORT_SYMBOL_GPL(cpuidle_unregister_driver);
diff --git a/drivers/cpuidle/governor.c b/drivers/cpuidle/governor.c
index 2e3e14192bee..e9801f26c732 100644
--- a/drivers/cpuidle/governor.c
+++ b/drivers/cpuidle/governor.c
@@ -20,14 +20,15 @@ char param_governor[CPUIDLE_NAME_LEN];
LIST_HEAD(cpuidle_governors);
struct cpuidle_governor *cpuidle_curr_governor;
+struct cpuidle_governor *cpuidle_prev_governor;
/**
- * __cpuidle_find_governor - finds a governor of the specified name
+ * cpuidle_find_governor - finds a governor of the specified name
* @str: the name
*
* Must be called with cpuidle_lock acquired.
*/
-static struct cpuidle_governor * __cpuidle_find_governor(const char *str)
+struct cpuidle_governor *cpuidle_find_governor(const char *str)
{
struct cpuidle_governor *gov;
@@ -87,7 +88,7 @@ int cpuidle_register_governor(struct cpuidle_governor *gov)
return -ENODEV;
mutex_lock(&cpuidle_lock);
- if (__cpuidle_find_governor(gov->name) == NULL) {
+ if (cpuidle_find_governor(gov->name) == NULL) {
ret = 0;
list_add_tail(&gov->governor_list, &cpuidle_governors);
if (!cpuidle_curr_governor ||
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 1a9f54eb3aa1..2dc4c6b19c25 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -121,6 +121,9 @@ struct cpuidle_driver {
/* the driver handles the cpus in cpumask */
struct cpumask *cpumask;
+
[PATCH v3 2/4] cpuidle-haltpoll: set haltpoll as preferred governor
Right now, guest current governors have the following ratings:
* ladder-> 10
* teo -> 19
* menu -> 20
* haltpoll -> 21
* ladder + nohz=off -> 25
haltpoll governor got introduced and it is now the default governor given
its highest rating -- with ladder+nohz being the exception -- regardless of
idle driver in the guest. An example of an undesirable case is x86 KVM
guests with MWAIT which have intel_idle registered first, and consequently
will have haltpoll be used as governor which would get limited to a poll
state and state 1 and the other states wouldn't get used.
To keep the previous defaults we decrease rating of governor to 9 (below
current lowest rating) and thus rely on @governor switch on
cpuidle_register_driver() to tie in haltpoll idle driver and governor
together.
Signed-off-by: Joao Martins
---
drivers/cpuidle/cpuidle-haltpoll.c | 1 +
drivers/cpuidle/governors/haltpoll.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-haltpoll.c
b/drivers/cpuidle/cpuidle-haltpoll.c
index 56d8ab814466..519e90d125cf 100644
--- a/drivers/cpuidle/cpuidle-haltpoll.c
+++ b/drivers/cpuidle/cpuidle-haltpoll.c
@@ -34,6 +34,7 @@ static int default_enter_idle(struct cpuidle_device *dev,
static struct cpuidle_driver haltpoll_driver = {
.name = "haltpoll",
+ .governor = "haltpoll",
.owner = THIS_MODULE,
.states = {
{ /* entry 0 is for polling */ },
diff --git a/drivers/cpuidle/governors/haltpoll.c
b/drivers/cpuidle/governors/haltpoll.c
index 797477bda486..7a703d2e0064 100644
--- a/drivers/cpuidle/governors/haltpoll.c
+++ b/drivers/cpuidle/governors/haltpoll.c
@@ -133,7 +133,7 @@ static int haltpoll_enable_device(struct cpuidle_driver
*drv,
static struct cpuidle_governor haltpoll_governor = {
.name = "haltpoll",
- .rating = 21,
+ .rating = 9,
.enable = haltpoll_enable_device,
.select = haltpoll_select,
.reflect = haltpoll_reflect,
--
2.17.1
Re: [PATCH v6 1/4] ftrace: Implement fs notification for tracing_max_latency
On Sat, Sep 07, 2019 at 11:12:59PM +0200, Viktor Rosendahl wrote:
> On 9/6/19 4:17 PM, Joel Fernandes wrote:
> > On Thu, Sep 05, 2019 at 03:25:45PM +0200, Viktor Rosendahl wrote:
>
> > > +
> > > +__init static int latency_fsnotify_init(void)
> > > +{
> > > + fsnotify_wq = alloc_workqueue("tr_max_lat_wq",
> > > + WQ_UNBOUND | WQ_HIGHPRI, 0);
> > > + if (!fsnotify_wq) {
> > > + pr_err("Unable to allocate tr_max_lat_wq\n");
> > > + return -ENOMEM;
> > > + }
> >
> > Why not just use the system workqueue instead of adding another workqueue?
> >
>
> For the the latency-collector to work properly in the worst case, when a
> new latency occurs immediately, the fsnotify must be received in less
> time than what the threshold is set to. If we always are slower we will
> always lose certain latencies.
>
> My intention was to minimize latency in some important cases, so that
> user space receives the notification sooner rather than later.
>
> There doesn't seem to be any system workqueue with WQ_UNBOUND and
> WQ_HIGHPRI. My thinking was that WQ_UNBOUND might help with the latency
> in some important cases.
>
> If we use:
>
> queue_work(system_highpri_wq, &tr->fsnotify_work);
>
> then the work will (almost) always execute on the same CPU but if we are
> unlucky that CPU could be too busy while there could be another CPU in
> the system that would be able to process the work soon enough.
>
> queue_work_on() could be used to queue the work on another CPU but it
> seems difficult to select the right CPU.
Ok, a separate WQ is fine with me as such since the preempt/irq events are on
a debug kernel anyway.
I'll keep reviewing your patches next few days, I am at the LPC conference so
might be a bit slow. Overall I think the series look like its maturing and
getting close.
thanks,
- Joel
Re: perf_event wakeup_events = 0
On Sep 7, 2019, at 3:45 PM, Valdis Klētnieks wrote: > So an entry is made in the buffer. It's not clear that this immediately > triggers > a signal… I think the documentation says it does when wakeup_events is 1. The code for perf backs this up: https://github.com/torvalds/linux/blob/a9815a4fa2fd297cab9fa7a12161b16657290293/tools/perf/util/evsel.c#L1051-L1054 The puzzle is what happens when wakeup_events is 0. The documentation saying "more recent kernels treat 0 the same as 1" suggests it should behave the same, but then why would perf set it to 1 after zero-initializing it? > So you need to look at what size mmap buffer is being allocated. It's > *probably* > on the order of megabytes, so that you can buffer a fairly large number of > entries > and not take several user/kernel transitions on every single entry… It’s 512 KiB. Each sample is 40 bytes (the sample_type is IP | TID | TIME | PERIOD, and each one of those 8 bytes). 40 bytes per sample * 4000 samples per second * 1.637 seconds is 261920 which is almost exactly half the buffer. So does wakeup_events = 0 means it causes a wakeup when the buffer is half full? I don't see anything in the man page about this If you'd like to try yourself, this is the strace command I've been using: strace -ttTv -eperf_event_open,mmap,poll -operf.strace perf record stress --cpu 1 --timeout 1 ~Theodore > > On Sat, 07 Sep 2019 09:14:49 -0700, Theodore Dubois said: > > Reading what it actually says rather than what I thought it said.. :) > > Events come in two flavors: counting and sampled. A counting event is > one that is used for counting the aggregate number of events that > occur. In general, counting event results are gathered with a read(2) > call. A sampling event periodically writes measurements to a buffer > that can then be accessed via mmap(2). > > For some reason, I was thinking counting events. -ENOCAFFEINE. :) > >> sample_freq is 4000 (and freq is 1). Here’s the man page on this field: >> >> sample_period, sample_freq >> A "sampling" event is one that generates an overflow notifica‐ >> tion every N events, where N is given by sample_period. A sam‐ >> pling event has sample_period > 0. > > There's this part: >> pling event has sample_period > 0. When an overflow occurs, >> requested data is recorded in the mmap buffer. The sample_type >> field controls what data is recorded on each overflow. > > So an entry is made in the buffer. It's not clear that this immediately > triggers > a signal... > > MMAP layout > When using perf_event_open() in sampled mode, asynchronous events (like > counter overflow or PROT_EXEC mmap tracking) are logged into a ring- > buffer. This ring-buffer is created and accessed through mmap(2). > > The mmap size should be 1+2^n pages, where the first page is a metadata > page (struct perf_event_mmap_page) that contains various bits of infor? > mation such as where the ring-buffer head is. > > So you need to look at what size mmap buffer is being allocated. It's > *probably* > on the order of megabytes, so that you can buffer a fairly large number of > entries > and not take several user/kernel transitions on every single entry... > >> If I’m reading this right, this is a sampling event which overflows 4000 >> times a second. > > And 4,000 entries are made in the buffer per second.. > >> But perf then does a poll call which wakes up on this FD with POLLIN after >> 1.637 seconds, instead of 0.00025 seconds > > At which point perf goes and looks at several thousand entries in the ring > buffer...
Re: [PATCH] gpio: fix build failure: gpiochip_[un]lock*() static/non-static
On Sat, Sep 7, 2019 at 2:05 AM John Hubbard wrote: > While building with !CONFIG_GPIOLIB, I experienced a build failure, > because driver.h in that configuration supplies both a static and > a non-static version of these routines: I think this is fixed in my latest version of the "devel" branch? Yours, Linus Walleij
Re: [GIT PULL] Char/Misc driver fixes for 5.3-rc8
The pull request you sent on Sat, 7 Sep 2019 19:40:33 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > tags/char-misc-5.3-rc8 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b3a9964cfa690150e49ae75ba16416ccaac3a8ba Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: perf_event wakeup_events = 0
On Sat, 07 Sep 2019 09:14:49 -0700, Theodore Dubois said: Reading what it actually says rather than what I thought it said.. :) Events come in two flavors: counting and sampled. A counting event is one that is used for counting the aggregate number of events that occur. In general, counting event results are gathered with a read(2) call. A sampling event periodically writes measurements to a buffer that can then be accessed via mmap(2). For some reason, I was thinking counting events. -ENOCAFFEINE. :) > sample_freq is 4000 (and freq is 1). Hereâs the man page on this field: > >sample_period, sample_freq > A "sampling" event is one that generates an overflow > notificaâ > tion every N events, where N is given by sample_period. A > samâ > pling event has sample_period > 0. There's this part: > pling event has sample_period > 0. When an overflow occurs, > requested data is recorded in the mmap buffer. The sample_type > field controls what data is recorded on each overflow. So an entry is made in the buffer. It's not clear that this immediately triggers a signal... MMAP layout When using perf_event_open() in sampled mode, asynchronous events (like counter overflow or PROT_EXEC mmap tracking) are logged into a ring- buffer. This ring-buffer is created and accessed through mmap(2). The mmap size should be 1+2^n pages, where the first page is a metadata page (struct perf_event_mmap_page) that contains various bits of infor? mation such as where the ring-buffer head is. So you need to look at what size mmap buffer is being allocated. It's *probably* on the order of megabytes, so that you can buffer a fairly large number of entries and not take several user/kernel transitions on every single entry... > If Iâm reading this right, this is a sampling event which overflows 4000 > times a second. And 4,000 entries are made in the buffer per second.. > But perf then does a poll call which wakes up on this FD with POLLIN after > 1.637 seconds, instead of 0.00025 seconds At which point perf goes and looks at several thousand entries in the ring buffer... pgp2wjxgbcJF2.pgp Description: PGP signature
Re: [PATCH AUTOSEL 4.19 126/167] tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations
On Sat, Sep 07, 2019 at 09:55:18PM +0300, Jarkko Sakkinen wrote:
On Tue, 2019-09-03 at 15:43 -0400, Sasha Levin wrote:
Right. I gave a go at backporting a few patches and this happens to be
one of them. It will be a while before it goes in a stable tree
(probably way after after LPC).
It *semantically* depends on
db4d8cb9c9f2 ("tpm: use tpm_try_get_ops() in tpm-sysfs.c.")
I.e. can cause crashes without the above patch. As a code change your
patch is fine but it needs the above patch backported to work in stable
manner.
So... either I can backport that one (because ultimately I have
responsibility to do that as the maintainer) but if you want to finish
this one that is what you need to backport in addition and then it
should be fine.
If you're ok with the backport of this commit, I can just add
db4d8cb9c9f2 on top.
--
Thanks,
Sasha
Re: perf_event wakeup_events = 0
On Sat, 07 Sep 2019 09:14:49 -0700, Theodore Dubois said: > If Iâm reading this right, this is a sampling event which overflows 4000 > times a second. But perf then does a poll call which wakes up on this FD with > POLLIN after 1.637 seconds, instead of 0.00025 seconds. No, it *takes a sample* 4,000 times a second. For instance, number of cache line misses since the last sample. You get an overflow when the counter wraps because there have been more than 2^32 events since you read the counter. At least that's my understanding of it. pgp4B98dVc2cw.pgp Description: PGP signature
Attention please
Dear sir/madam
My name is Mrs. Mariam Kabore. I have decided to seek a confidential
co-operation with you for the execution of the deal described
hereunder for our mutual benefit. I Hope you will keep it a secret due
to the nature of the transaction. During the course of our audit last
month, I discovered an unclaimed/abandoned fund total US$3.5 million
in a bank account that belongs to a customer who unfortunately lost
his life and entire family in a car accident.
Now our bank has been waiting for any of the relatives to come-up for
the claim but nobody has done that. I personally has been unsuccessful
in locating any of the relatives, now, I sincerely seek your consent
to present you as the next of kin / Will Beneficiary to the deceased
so that the proceeds of this account valued at {US$3.5 Million United
State Dollars} can be paid to you, which we will share in these
percentages ratio, 60% to me and 40% to you. All I request is your
utmost sincere co- operation; trust and maximum confidentiality to
achieve this project successfully. I have carefully mapped out the
moralities for execution of this transaction under a legitimate
arrangement to protect you from any breach of the law both in your
country and here in my country when the fund is being transferred to
your bank account.
I will have to provide the entire relevant document that will be
requested to indicate that you are the rightful beneficiary of this
legacy and our bank will release the fund to you without any further
delay, upon your consideration and acceptance of this offer, please
send me the following information as stated below so we can proceed
and get this fund transferred to your designated bank account
immediately. I, know much about the existence of this fund and the
secrets surrounding this money.
-Your Full Name:
-Your Contact Address:
-Your direct Mobile telephone Number:
-Your Date of Birth:
-Your occupation:
I await your swift response and re-assurance so we commence this
transaction immediately.
Best regards,
Mrs Mariam Kabore
Re: [PATCH] tpm_crb: fix fTPM on AMD Zen+ CPUs
On Wed, 2019-09-04 at 22:03 +0300, ivan.laz...@gmail.com wrote:
> From: Ivan Lazeev
>
> Bug link: https://bugzilla.kernel.org/show_bug.cgi?id=195657
>
> cmd/rsp buffers are expected to be in the same ACPI region.
> For Zen+ CPUs BIOS's might report two different regions, some of
> them also report region sizes inconsistent with values from TPM
> registers.
>
> Work around the issue by storing ACPI regions declared for the
> device in a list, then using it to find entry corresponding
> to each buffer. Use information from the entry to map each resource
> at most once and make buffer size consistent with the length of the
> region.
>
> Signed-off-by: Ivan Lazeev
Can you add the relevant pieces of /proc/iomem output to the commit
message so we can see the memory configuration? I don't have the
hardware available where this kind of situation occurs.
> ---
>
> Tested on ASRock x470 ITX motherboard with Ryzen 2600X CPU.
> However, I don't have any other hardware to test the changes on and no
> expertise to be sure that other TPMs won't break as a result.
You can still ask yourself that if the hardware describes the memory
with only one region do the code flows reduce mostly to do the same as
before this patch. It is not the same as testing with such hardware but
it is still a good mental exercise.
To summarize, I do get "not having hardware" part but completely
disqualify "not having expertise" part as the expertise needed here has
nothing specific to do with TPMs :-)
>
> drivers/char/tpm/tpm_crb.c | 137 +++--
> 1 file changed, 101 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index e59f1f91d7f3..0bcfe52db5d6 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -91,7 +91,6 @@ enum crb_status {
> struct crb_priv {
> u32 sm;
> const char *hid;
> - void __iomem *iobase;
> struct crb_regs_head __iomem *regs_h;
> struct crb_regs_tail __iomem *regs_t;
> u8 __iomem *cmd;
> @@ -108,6 +107,12 @@ struct tpm2_crb_smc {
> u32 smc_func_id;
> };
>
> +struct crb_resource {
> + struct resource io_res;
> + void __iomem *iobase;
> + struct list_head node;
> +};
Please rename 'node' as 'list' for the sake of coherency with the rest
of the kernel and io_res as iores for the sake of coherency with the
other fields.
I think it would be cleaner to do the following:
1. Start with empty resource list.
2. Everytime crb_map_res() is called it does check the existing
resources and does a ACPI walk on need basis at most adding
one new entry.
In other words, crb_map_res() gets the list and appends one entry when
necessary.
Overhead of doing multiple walks is irrelevant here. The simplicity and
clarity win.
/Jarkko
[PATCH 2/2 v2] staging: exfat: cleanup casts
Use constants and fix checkpatch.pl warnings:
CHECK: No space is necessary after a cast
Signed-off-by: Valentin Vidic
---
v2: Use constants where possible
drivers/staging/exfat/exfat_core.c | 94 ++---
drivers/staging/exfat/exfat_super.c | 66 ++--
2 files changed, 80 insertions(+), 80 deletions(-)
diff --git a/drivers/staging/exfat/exfat_core.c
b/drivers/staging/exfat/exfat_core.c
index 8fb4ce16010c..6eee2aa06bd7 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -204,7 +204,7 @@ s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
if ((--num_alloc) == 0) {
p_fs->clu_srch_ptr = new_clu;
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != UINT_MAX)
p_fs->used_clusters += num_clusters;
return num_clusters;
@@ -215,7 +215,7 @@ s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
}
p_fs->clu_srch_ptr = new_clu;
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != UINT_MAX)
p_fs->used_clusters += num_clusters;
return num_clusters;
@@ -273,7 +273,7 @@ s32 exfat_alloc_cluster(struct super_block *sb, s32
num_alloc,
if ((--num_alloc) == 0) {
p_fs->clu_srch_ptr = hint_clu;
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != UINT_MAX)
p_fs->used_clusters += num_clusters;
p_chain->size += num_clusters;
@@ -293,7 +293,7 @@ s32 exfat_alloc_cluster(struct super_block *sb, s32
num_alloc,
}
p_fs->clu_srch_ptr = hint_clu;
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != UINT_MAX)
p_fs->used_clusters += num_clusters;
p_chain->size += num_clusters;
@@ -337,7 +337,7 @@ void fat_free_cluster(struct super_block *sb, struct
chain_t *p_chain,
} while (clu != CLUSTER_32(~0));
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != UINT_MAX)
p_fs->used_clusters -= num_clusters;
}
@@ -396,7 +396,7 @@ void exfat_free_cluster(struct super_block *sb, struct
chain_t *p_chain,
} while ((clu != CLUSTER_32(0)) && (clu != CLUSTER_32(~0)));
}
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != UINT_MAX)
p_fs->used_clusters -= num_clusters;
}
@@ -473,7 +473,7 @@ s32 exfat_count_used_clusters(struct super_block *sb)
map_i = map_b = 0;
for (i = 2; i < p_fs->num_clusters; i += 8) {
- k = *(((u8 *) p_fs->vol_amap[map_i]->b_data) + map_b);
+ k = *(((u8 *)p_fs->vol_amap[map_i]->b_data) + map_b);
count += used_bit[k];
if ((++map_b) >= p_bd->sector_size) {
@@ -536,7 +536,7 @@ s32 load_alloc_bitmap(struct super_block *sb)
if (ep->flags == 0x0) {
p_fs->map_clu = GET32_A(ep->start_clu);
- map_size = (u32) GET64_A(ep->size);
+ map_size = (u32)GET64_A(ep->size);
p_fs->map_sectors = ((map_size - 1) >>
p_bd->sector_size_bits) + 1;
@@ -601,7 +601,7 @@ s32 set_alloc_bitmap(struct super_block *sb, u32 clu)
sector = START_SECTOR(p_fs->map_clu) + i;
- exfat_bitmap_set((u8 *) p_fs->vol_amap[i]->b_data, b);
+ exfat_bitmap_set((u8 *)p_fs->vol_amap[i]->b_data, b);
return sector_write(sb, sector, p_fs->vol_amap[i], 0);
}
@@ -623,7 +623,7 @@ s32 clr_alloc_bitmap(struct super_block *sb, u32 clu)
sector = START_SECTOR(p_fs->map_clu) + i;
- exfat_bitmap_clear((u8 *) p_fs->vol_amap[i]->b_data, b);
+ exfat_bitmap_clear((u8 *)p_fs->vol_amap[i]->b_data, b);
return sector_write(sb, sector, p_fs->vol_amap[i], 0);
@@ -655,7 +655,7 @@ u32 test_alloc_bitmap(struct super_block *sb, u32 clu)
map_b = (clu >> 3) & p_bd->sector_size_mask;
for (i = 2; i < p_fs->num_clusters; i += 8) {
- k = *(((u8 *) p_fs->vol_amap[map_i]->b_data) + map_b);
+ k = *(((u8 *)p_fs->vol_amap[map_i]->b_data) + map_b);
if (clu_mask > 0) {
k |= clu_mask;
clu_mask = 0;
@@ -728,7 +728,7 @@ static s32 __load_upcase_table(struct super_block *sb,
sector_t sector,
sector++;
for (i = 0; i < p_bd->sector_size && index <= 0x; i += 2) {
- uni = GET16(((u8 *) tmp_bh->b_data) + i);
+ uni = GET16(((u8 *)tmp_bh->b_data) + i);
checksum = ((checksum & 1) ? 0x8000 : 0)
Re: [GIT PULL] cpupower update for Linux 5.4-rc1
Hi Shuah, On Fri, Sep 6, 2019 at 5:36 PM Shuah Khan wrote: > > Hi Rafael, > > Please pull the following update for Linux 5.4-rc1 or 5.4-rc2 depending > on your pull request schedule for Linus. > > This cpupower update for Linux 5.4-rc1 consists of bug fixes and > German translation updates from Benjamin Weis. > > diff is attached. > > thanks, > -- Shuah > > > The following changes since commit a55aa89aab90fae7c815b0551b07be37db359d76: > >Linux 5.3-rc6 (2019-08-25 12:01:23 -0700) > > are available in the Git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux > tags/linux-cpupower-5.4-rc1 > > for you to fetch changes up to 87ce243206944a57383309dcbcdcc5750e6c905b: > >cpupower: update German translation (2019-08-29 10:18:52 -0600) Pulled, thanks!
[PATCH 1/3] hv_ballon: Avoid calling dummy function __online_page_set_limits()
__online_page_set_limits() is a dummy function and an extra call to this function can be avoided. Signed-off-by: Souptick Joarder --- drivers/hv/hv_balloon.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 6fb4ea5..9bab443 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -680,7 +680,6 @@ static void hv_page_online_one(struct hv_hotadd_state *has, struct page *pg) __ClearPageOffline(pg); /* This frame is currently backed; online the page. */ - __online_page_set_limits(pg); __online_page_increment_counters(pg); __online_page_free(pg); -- 1.9.1
[PATCH 0/3] Remove __online_page_set_limits()
__online_page_set_limits() is a dummy function and an extra call to this can be avoided. As both of the callers are now removed, __online_page_set_limits() can be removed permanently. Souptick Joarder (3): hv_ballon: Avoid calling dummy function __online_page_set_limits() xen/ballon: Avoid calling dummy function __online_page_set_limits() mm/memory_hotplug.c: Remove __online_page_set_limits() drivers/hv/hv_balloon.c| 1 - drivers/xen/balloon.c | 1 - include/linux/memory_hotplug.h | 1 - mm/memory_hotplug.c| 5 - 4 files changed, 8 deletions(-) -- 1.9.1
[PATCH 2/3] xen/ballon: Avoid calling dummy function __online_page_set_limits()
__online_page_set_limits() is a dummy function and an extra call
to this function can be avoided.
Signed-off-by: Souptick Joarder
---
drivers/xen/balloon.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 4e11de6..05b1f7e 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -376,7 +376,6 @@ static void xen_online_page(struct page *page, unsigned int
order)
mutex_lock(&balloon_mutex);
for (i = 0; i < size; i++) {
p = pfn_to_page(start_pfn + i);
- __online_page_set_limits(p);
__SetPageOffline(p);
__balloon_append(p);
}
--
1.9.1
[PATCH 3/3] mm/memory_hotplug.c: Remove __online_page_set_limits()
As both the callers of this dummy __online_page_set_limits()
is removed, this can be removed permanently.
Signed-off-by: Souptick Joarder
---
include/linux/memory_hotplug.h | 1 -
mm/memory_hotplug.c| 5 -
2 files changed, 6 deletions(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index f46ea71..8ee3a2a 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -105,7 +105,6 @@ extern unsigned long __offline_isolated_pages(unsigned long
start_pfn,
extern int set_online_page_callback(online_page_callback_t callback);
extern int restore_online_page_callback(online_page_callback_t callback);
-extern void __online_page_set_limits(struct page *page);
extern void __online_page_increment_counters(struct page *page);
extern void __online_page_free(struct page *page);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c73f099..dc0118f 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -604,11 +604,6 @@ int restore_online_page_callback(online_page_callback_t
callback)
}
EXPORT_SYMBOL_GPL(restore_online_page_callback);
-void __online_page_set_limits(struct page *page)
-{
-}
-EXPORT_SYMBOL_GPL(__online_page_set_limits);
-
void __online_page_increment_counters(struct page *page)
{
adjust_managed_page_count(page, 1);
--
1.9.1
Re: [PATCH] x86/umip: Add emulation for 64-bit processes
On Thu, Sep 05, 2019 at 04:22:21PM -0700, Brendan Shanks wrote:
> Add emulation of the sgdt, sidt, and smsw instructions for 64-bit
> processes.
>
> Wine users have encountered a number of 64-bit Windows games that use
> these instructions (particularly sgdt), and were crashing when run on
> UMIP-enabled systems.
Emulation support for 64-bit processes was not initially included
because no use cases had been identified. Brendan has found one.
Here is the relevant e-mail thread: https://lkml.org/lkml/2017/1/26/12
FWIW,
Reviewed-by: Ricardo Neri
Only one minor comment below...
>
> Originally-by: Ricardo Neri
> Signed-off-by: Brendan Shanks
> ---
> arch/x86/kernel/umip.c | 55 +-
> 1 file changed, 33 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
> index 5b345add550f..1812e95d2f55 100644
> --- a/arch/x86/kernel/umip.c
> +++ b/arch/x86/kernel/umip.c
> @@ -51,9 +51,7 @@
> * The instruction smsw is emulated to return the value that the register CR0
> * has at boot time as set in the head_32.
> *
> - * Also, emulation is provided only for 32-bit processes; 64-bit processes
> - * that attempt to use the instructions that UMIP protects will receive the
> - * SIGSEGV signal issued as a consequence of the general protection fault.
> + * Emulation is provided for both 32-bit and 64-bit processes.
> *
> * Care is taken to appropriately emulate the results when segmentation is
> * used. That is, rather than relying on USER_DS and USER_CS, the function
> @@ -63,17 +61,18 @@
> * application uses a local descriptor table.
> */
>
> -#define UMIP_DUMMY_GDT_BASE 0xfffe
> -#define UMIP_DUMMY_IDT_BASE 0x
> +#define UMIP_DUMMY_GDT_BASE 0xfffeULL
> +#define UMIP_DUMMY_IDT_BASE 0xULL
>
> /*
> * The SGDT and SIDT instructions store the contents of the global descriptor
> * table and interrupt table registers, respectively. The destination is a
> * memory operand of X+2 bytes. X bytes are used to store the base address of
> - * the table and 2 bytes are used to store the limit. In 32-bit processes,
> the
> - * only processes for which emulation is provided, X has a value of 4.
> + * the table and 2 bytes are used to store the limit. In 32-bit processes X
> + * has a value of 4, in 64-bit processes X has a value of 8.
> */
> -#define UMIP_GDT_IDT_BASE_SIZE 4
> +#define UMIP_GDT_IDT_BASE_SIZE_64BIT 8
> +#define UMIP_GDT_IDT_BASE_SIZE_32BIT 4
> #define UMIP_GDT_IDT_LIMIT_SIZE 2
>
> #define UMIP_INST_SGDT 0 /* 0F 01 /0 */
> @@ -189,6 +188,7 @@ static int identify_insn(struct insn *insn)
> * @umip_inst: A constant indicating the instruction to emulate
> * @data:Buffer into which the dummy result is stored
> * @data_size: Size of the emulated result
> + * @x86_64: true if process is 64-bit, false otherwise
> *
> * Emulate an instruction protected by UMIP and provide a dummy result. The
> * result of the emulation is saved in @data. The size of the results depends
> @@ -202,11 +202,8 @@ static int identify_insn(struct insn *insn)
> * 0 on success, -EINVAL on error while emulating.
> */
> static int emulate_umip_insn(struct insn *insn, int umip_inst,
> - unsigned char *data, int *data_size)
> + unsigned char *data, int *data_size, bool x86_64)
> {
> - unsigned long dummy_base_addr, dummy_value;
> - unsigned short dummy_limit = 0;
> -
> if (!data || !data_size || !insn)
> return -EINVAL;
> /*
> @@ -219,6 +216,9 @@ static int emulate_umip_insn(struct insn *insn, int
> umip_inst,
>* is always returned irrespective of the operand size.
>*/
> if (umip_inst == UMIP_INST_SGDT || umip_inst == UMIP_INST_SIDT) {
> + u64 dummy_base_addr;
> + u16 dummy_limit = 0;
> +
> /* SGDT and SIDT do not use registers operands. */
> if (X86_MODRM_MOD(insn->modrm.value) == 3)
> return -EINVAL;
> @@ -228,13 +228,24 @@ static int emulate_umip_insn(struct insn *insn, int
> umip_inst,
> else
> dummy_base_addr = UMIP_DUMMY_IDT_BASE;
>
> - *data_size = UMIP_GDT_IDT_LIMIT_SIZE + UMIP_GDT_IDT_BASE_SIZE;
Maybe a blank line here?
Thanks and BR,
Ricardo
Re: [PATCH] tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
On Fri, 2019-09-06 at 14:37 +0200, Jan Lübbe wrote: > This is due to the SPI accesses performed by tis_int_handler (which > will sleep). Switching to devm_request_threaded_irq fixes this and > leads to a successful IRQ probe. Aah, right through tpm_tis_read32/write32(). This is definitely a new regression. Thanks for reporting this! This was completely missed when the support for other than TCG MMIO was implemented for the TIS driver. This should have a patch of it own with your reported-by unless you care to send bug fix for it. > But: It seems that the IRQ is not acked correctly, as the interrupt > line stays low. I suspect this is because the tpm_chip_stop from > http://git.infradead.org/users/jjs/linux-tpmdd.git/commitdiff/9b558deab2c5d7dc23d5f7a4064892ede482ad32 > happens before the threaded handler runs. I'm currently unable to > verify that though, as my build machine's disk just died. :/ I cannot recall all the nyances related to interrupt probing but with a quick look I wonder why it does not utilize int_queue. Then tpm_chip_stop() could be done synchronously. > Regards, > Jan /Jarkko
Re: [PATCH 0/6] Address issues with SPDX requirements and PEP-263
On Sat, 7 Sep 2019, Markus Heiser wrote: > Am 07.09.19 um 20:04 schrieb Mauro Carvalho Chehab: > > No idea. I would actually prefer to just remove the restriction, and let > > the SPDX header to be anywhere inside the first comment block inside a > > file [2]. > > > That's basically how this thread started: other developers think > > that it is a good idea to be pedantic. So, be it, but let's then fix > > the documentation, as the way it is, it is implicitly forbidding the > > addition of encoding lines for Python scripts. > > > > [2] I *suspect* that the restriction was added in order to make > > ./scripts/spdxcheck.py to run faster and to avoid false positives. > > Right now, if the maximum limit is removed (or set to a very high > > value), there will be one false positive: Nope. The intention was to have a well define place and format instead of everyone and his dog deciding to put it somewhere. SPDX is not intended to replace the existing licensing mess with some other randomly placed and formatted licensing mess. > > > - write a shebang line if this file is called directly from the > > > command line .. but we do not need shebangs on py modules which > > > are imported from other modules or scripts > > > > > > - write a encoding line if it is need or helpful / mostly it is helpful > > > to know the encoding of a text/code file. > > > > > > - add a SPDX tag > > > > Yes, but this violates the current documentation, as it doesn't allow the > > SPDX tag after line #2. > > Thats what I mean: The documentation was written with only a small use-cases > in mind .. there is no real need for SPDX to be in line one or two ... lets > fix the documentation as I described before. If there is a requirement from the language to have 2 lines right at the top for conveying information then there is of course no reason to insist on the SPDX identifier being on line 2. So the documentation should say: The SPDX identifier must be at the first possible line at the top of the file which is not occupied by information which is required to be immediately at the top of the file by system constraints, e.g. shebang, or by the language, e.g. the encoding information for python. or something to that effect. Thanks, tglx
Re: Linux 5.3-rc7
On Sat, Sep 7, 2019 at 1:44 PM Thomas Gleixner wrote: > > That's what I just replied to Chris. Can you do it right away or should I > queue it up? Done. Thanks, Linus
Re: [PATCH v6 1/4] ftrace: Implement fs notification for tracing_max_latency
On 9/6/19 4:17 PM, Joel Fernandes wrote:
On Thu, Sep 05, 2019 at 03:25:45PM +0200, Viktor Rosendahl wrote:
+
+__init static int latency_fsnotify_init(void)
+{
+ fsnotify_wq = alloc_workqueue("tr_max_lat_wq",
+ WQ_UNBOUND | WQ_HIGHPRI, 0);
+ if (!fsnotify_wq) {
+ pr_err("Unable to allocate tr_max_lat_wq\n");
+ return -ENOMEM;
+ }
Why not just use the system workqueue instead of adding another workqueue?
For the the latency-collector to work properly in the worst case, when a
new latency occurs immediately, the fsnotify must be received in less
time than what the threshold is set to. If we always are slower we will
always lose certain latencies.
My intention was to minimize latency in some important cases, so that
user space receives the notification sooner rather than later.
There doesn't seem to be any system workqueue with WQ_UNBOUND and
WQ_HIGHPRI. My thinking was that WQ_UNBOUND might help with the latency
in some important cases.
If we use:
queue_work(system_highpri_wq, &tr->fsnotify_work);
then the work will (almost) always execute on the same CPU but if we are
unlucky that CPU could be too busy while there could be another CPU in
the system that would be able to process the work soon enough.
queue_work_on() could be used to queue the work on another CPU but it
seems difficult to select the right CPU.
best regards,
Viktor
Re: [PATCH] mostpost: don't warn about symbols from another file
On 06.09.2019 18:10, Arnd Bergmann wrote:
> On architectures such as ARM that have a list of symbols exported
> from assembler in a separate C file, we get a lot of new warnings:
>
> WARNING: "__ashrdi3" [vmlinux] is a static (unknown) WARNING:
> "__lshrdi3" [vmlinux] is a static (unknown) WARNING: "__aeabi_llsr"
> [vmlinux] is a static (unknown) WARNING: "__aeabi_lasr" [vmlinux] is
> a static (unknown) WARNING: "__aeabi_uidivmod" [vmlinux] is a static
> (unknown) WARNING: "__udivsi3" [vmlinux] is a static (unknown)
> WARNING: "_change_bit" [vmlinux] is a static (unknown) WARNING:
> "__aeabi_idiv" [vmlinux] is a static (unknown) WARNING: "__umodsi3"
> [vmlinux] is a static (unknown) WARNING: "__aeabi_uidiv" [vmlinux] is
> a static (unknown) WARNING: "__aeabi_idivmod" [vmlinux] is a static
> (unknown) WARNING: "__muldi3" [vmlinux] is a static (unknown)
> WARNING: "__aeabi_ulcmp" [vmlinux] is a static (unknown) WARNING:
> "__raw_writesb" [vmlinux] is a static (unknown) WARNING:
> "__raw_readsb" [vmlinux] is a static (unknown) ...
>
> This is not helpful, as these are clearly not static symbols at all.
> Suppress the warning in a case like this.
>
> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL*
> functions") Signed-off-by: Arnd Bergmann
Tested-by: Denis Efremov
What I could add here is that all these symbols are:
$ nm vmlinux | grep '__ashrdi3\|__lshrdi3\|__aeabi_llsr\|...'
cd63c845 A __crc___aeabi_lasr
76cf47f6 A __crc___aeabi_llsl
8a4fa83b A __crc___aeabi_llsr
44643b93 A __crc___aeabi_lmul
f564412a A __crc___aeabi_ulcmp
40f07981 A __crc___ashldi3
edd9106d A __crc___ashrdi3
389ecf9e A __crc___bswapdi2
f1ea6f1c A __crc___bswapsi2
14d4a9c5 A __crc__change_bit
ff67b37f A __crc___lshrdi3
800e4ffa A __crc___muldi3
f7163ec9 A __crc___raw_readsb
f0ed2ef4 A __crc___raw_writesb
ffb94ef0 A __crc__test_and_change_bit
7cc035a7 A __crc___ucmpdi2
There is no ksymtab, kstrtab for them and there is
no the exact symbols, only crc.
Thus they get to the symbolhash table from
handle_modversions() -> sym_update_crc().
Since there is no the exact symbols, e.g. like
nm vmlinux | grep __kmalloc
2d6fcc06 A __crc___kmalloc
c01c922d T __kmalloc <---
c0749192 r __kstrtab___kmalloc
c073c7c4 r __ksymtab___kmalloc
we can't check them in this cycle:
// check for static EXPORT_SYMBOL_* functions && global vars
for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
and they are automatically marked as static.
That's all so far, I don't know is it correct to have only
__crc* or not for a symbol.
Just a sidenote:
arch/arm/kernel/armksyms.c states that these are
/*
* libgcc functions - functions that are used internally by the
* compiler...
Thanks,
Denis
> --- scripts/mod/modpost.c | 2 +- 1 file changed, 1 insertion(+), 1
> deletion(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index
> 76c221dd9b2b..4265dd924933 100644 --- a/scripts/mod/modpost.c +++
> b/scripts/mod/modpost.c @@ -2543,7 +2543,7 @@ int main(int argc, char
> **argv) struct symbol *s = symbolhash[n];
>
> while (s) { - if (s->is_static) + if
> (s->is_static && s->export
> != export_unknown) warn("\"%s\" [%s] is a static %s\n", s->name,
> s->module->name, export_str(s->export));
>
[PATCH] Documentation: kunit: Fix verification command
kunit wrapper script ('kunit.py') receives a sub-command (only 'run' for
now) as its argument. If no sub-command is given, it prints help
message and just quit. However, an example command in the kunit
documentation for a verification of kunit is missing the sub-command.
This commit fixes the example.
Signed-off-by: SeongJae Park
---
Documentation/dev-tools/kunit/start.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kunit/start.rst
b/Documentation/dev-tools/kunit/start.rst
index 6dc229e..aeeddfa 100644
--- a/Documentation/dev-tools/kunit/start.rst
+++ b/Documentation/dev-tools/kunit/start.rst
@@ -43,7 +43,7 @@ wrapper from your kernel repo:
.. code-block:: bash
- ./tools/testing/kunit/kunit.py
+ ./tools/testing/kunit/kunit.py run
.. note::
You may want to run ``make mrproper`` first.
--
2.7.4
[PATCH] Staging: wlan-ng: parenthesis at end of line fix
Fixed open parenthesis at the end of the line on line 327. Signed-off-by: Sandro Volery --- drivers/staging/wlan-ng/cfg80211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/cfg80211.c b/drivers/staging/wlan-ng/cfg80211.c index eee1998c4b18..0a4c7415f773 100644 --- a/drivers/staging/wlan-ng/cfg80211.c +++ b/drivers/staging/wlan-ng/cfg80211.c @@ -324,7 +324,8 @@ static int prism2_scan(struct wiphy *wiphy, (i < request->n_channels) && i < ARRAY_SIZE(prism2_channels); i++) msg1.channellist.data.data[i] = - ieee80211_frequency_to_channel( + ieee80211_frequency_to_channel + ( request->channels[i]->center_freq); msg1.channellist.data.len = request->n_channels; -- 2.23.0
Re: [PATCH v3 0/6] ARM: dts: mmp2: devicetree updates
On Sat 2019-09-07 21:57:42, Arnd Bergmann wrote: > On Sat, Sep 7, 2019 at 9:40 PM Pavel Machek wrote: > > > > > > > Here's a couple of updates for the MMP2 SoC devicetree files. > > > I'm wondering if they could be applied to the armsoc tree? > > > > > > Compared to previous submission, the only change is the addition of > > > Acks from Pavel. > > > > Any news here? Having up-to-date dts is kind-of useful > > Thanks for adding me to Cc on your reply. I'm doing the merged for 5.4 > and had not noticed this series earlier (I found the mmp3 series by > accident, but that one looked like it was not meant as a submission > for inclusion yet). > > I've added the six patches to the arm/late branch in the soc tree > now, they will be in 5.4. That was quick, thank you! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: Linux 5.3-rc7
On Sat, 7 Sep 2019, Linus Torvalds wrote: > On Sat, Sep 7, 2019 at 8:00 AM Thomas Gleixner wrote: > > So why wouldn't we just revert it? That's what I just replied to Chris. Can you do it right away or should I queue it up? Thanks, tglx
Re: [PATCH -next] scsi: ufs-hisi: use devm_platform_ioremap_resource() to simplify code
YueHaibing, > Use devm_platform_ioremap_resource() to simplify the code a bit. > This is detected by coccinelle. Applied to 5.4/scsi-queue, thanks. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] scsi: ufshcd: use devm_platform_ioremap_resource() to simplify code
YueHaibing, > Use devm_platform_ioremap_resource() to simplify the code a bit. > This is detected by coccinelle. Applied to 5.4/scsi-queue, thanks. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] scsi: hisi_sas: use devm_platform_ioremap_resource() to simplify code
YueHaibing, > Use devm_platform_ioremap_resource() to simplify the code a bit. > This is detected by coccinelle. Applied to 5.4/scsi-queue, thanks. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] scsi: ufs: Use kmemdup in ufshcd_read_string_desc()
YueHaibing, > Use kmemdup rather than duplicating its implementation Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v4 0/3] Qualcomm UFS device reset support
Bjorn, > This series adds a new ufs vops to allow platform specific methods for > resetting an attached UFS device, then implements this for the > Qualcomm driver. This reset seems to be necessary for the majority of > Dragonboard845c devices. Applied to 5.4/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] Fixed most indent issues in tty_io.c
Sandro V >> On 7 Sep 2019, at 22:04, Joe Perches wrote: >> >> On Sat, 2019-09-07 at 11:09 +0200, volery wrote: >> There were a lot of styling problems using space then tab or spaces >> instead of tabs in that file. Especially the entire function at line >> 2677. >> Also added a space before the : on line 2221. > > You do not have an appropriate subject line. > > This subject should probably be something like: > > [PATCH] tty: tty_io: Use normal indentation > > Please make changes only in drivers/staging until you are > really familiar with the linux kernel patch process. Yep, noticed that I had the subject line wrong on this one too after Dan told me about that today. I'll take that drivers/staging thing into account :) Thanks again Sandro
Re: [PATCH 1/1] scsi: lpfc: Convert existing %pf users to %ps
Sakari, > Convert the remaining %pf users to %ps to prepare for the removal of > the old %pf conversion specifier support. Applied to 5.4/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]
On Sat, Sep 7, 2019 at 9:15 PM Joe Perches wrote: > > Standard integer promotion is already done and %hx and %hhx is useless > so do not encourage the use of %hh[xudi] or %h[xudi]. > > As Linus said in: > Link: > https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20...@mail.gmail.com/ > > It's a pointless warning, making for more complex code, and > making people remember esoteric printf format details that have no > reason for existing. > > The "h" and "hh" things should never be used. The only reason for them > being used if if you have an "int", but you want to print it out as a > "char" (and honestly, that is a really bad reason, you'd be better off > just using a proper cast to make the code more obvious). > > So if what you have a "char" (or unsigned char) you should always just > print it out as an "int", knowing that the compiler already did the > proper type conversion. > - char%hhd or %hhx > - short int %hd or %hx > + char%d or %x > + short int %d or %x > + s8 %d or %x > + s16 %d or %x This is incorrect. Integral promotions promotes also sign, which will produce too many f:s. -- With Best Regards, Andy Shevchenko
Re: Linux 5.3-rc7
On Sat, 7 Sep 2019, Chris Wilson wrote: > Quoting Thomas Gleixner (2019-09-07 16:00:17) > > Does this only happen with that CPU0 hotplug stuff enabled or on CPUs other > > than CPU0 as well? That hotplug CPU0 stuff is a bandaid so I wouldn't be > > surprised if we broke that somehow. > > If I ignore cpu0 in that test and so use > > [ 133.847187] smpboot: CPU 1 is now offline > [ 134.861861] x86: Booting SMP configuration: > [ 134.861875] smpboot: Booting Node 0 Processor 1 APIC 0x2 > [ 134.880218] smpboot: CPU 2 is now offline > [ 135.893806] smpboot: Booting Node 0 Processor 2 APIC 0x1 > [ 135.935115] smpboot: CPU 3 is now offline > [ 136.949760] smpboot: Booting Node 0 Processor 3 APIC 0x3 > > that has run for 10 minutes without failure, so it seems confined to > cpu0 hotplugging. All we are doing in the test to generate the hotplugs > is: Right, but you also have that config bit enabled which allows CPU0 hotplug which usually is off even in testing and that's why nobody noticed so far. So I looked at that code and I know why it's broken. I guess we'll end up reverting that commit for now as fixing it proper will be not just a one liner. Thanks for providing all the information! tglx
Re: [PATCH] Fixed most indent issues in tty_io.c
On Sat, 2019-09-07 at 11:09 +0200, volery wrote: > There were a lot of styling problems using space then tab or spaces > instead of tabs in that file. Especially the entire function at line > 2677. > Also added a space before the : on line 2221. You do not have an appropriate subject line. This subject should probably be something like: [PATCH] tty: tty_io: Use normal indentation Please make changes only in drivers/staging until you are really familiar with the linux kernel patch process.
Re: [PATCH] Fixed most indent issues in tty_io.c
On Sat, 2019-09-07 at 21:51 +0200, Sandro Volery wrote: > > On 7 Sep 2019, at 21:27, Joe Perches wrote: [] > > As long as git diff -w shows no difference and a compiled > > object comparison before and after the change shows no > > difference, I think it's fine. > > My thoughts, too. I didn't feel comfortable arguing as a newbie tho > so I'll see what I can do once I get home. If you do that, it's important to mention both elements in the commit message: 1: git diff -w shows no difference 2: pre and post compilation objects are identical It is also good to verify that allyesconfig and defconfig objects with the minimal CONFIG_ required for compilation are also identical. Whitespace only changes should only change horizontal spacing and should not have vertical line changes.
Re: [PATCH v3 0/6] ARM: dts: mmp2: devicetree updates
On Sat, Sep 7, 2019 at 9:40 PM Pavel Machek wrote: > > > > Here's a couple of updates for the MMP2 SoC devicetree files. > > I'm wondering if they could be applied to the armsoc tree? > > > > Compared to previous submission, the only change is the addition of > > Acks from Pavel. > > Any news here? Having up-to-date dts is kind-of useful Thanks for adding me to Cc on your reply. I'm doing the merged for 5.4 and had not noticed this series earlier (I found the mmp3 series by accident, but that one looked like it was not meant as a submission for inclusion yet). I've added the six patches to the arm/late branch in the soc tree now, they will be in 5.4. Lubomir, please send all future submissions to s...@kernel.org (with Cc: to the interested parties) when you want them to be included in the soc tree. That way they show up in patchwork and won't get lost. Arnd
Re: [patch for-5.3 0/4] revert immediate fallback to remote hugepages
On Sat, Sep 7, 2019 at 12:51 PM David Rientjes wrote: > > Andrea acknowledges the swap storm that he reported would be fixed with > the last two patches in this series The problem is that even you aren't arguing that those patches should go into 5.3. So those fixes aren't going in, so "the swap storms would be fixed" argument isn't actually an argument at all as far as 5.3 is concerned. End result: we'd have the qemu-kvm instance performance problem in 5.3 that apparently causes distros to apply those patches that you want to revert anyway. So reverting would just make distros not use 5.3 in that form. So I don't think we can revert those again without applying the two patches in the series. So it would be a 5.4 merge window operation. Linus
Re: [PATCH] Fixed most indent issues in tty_io.c
> On 7 Sep 2019, at 21:27, Joe Perches wrote: > > On Sat, 2019-09-07 at 18:42 +0100, Greg KH wrote: >>> On Sat, Sep 07, 2019 at 07:35:42PM +0200, Sandro Volery wrote: >>> >> On 7 Sep 2019, at 19:29, Greg KH wrote: > On Sat, Sep 07, 2019 at 07:23:59PM +0200, Sandro Volery wrote: > Dear Greg, > I am pretty sure the issue was, that I did too many things at once. > However, all the things I did are related to spaces / tabs, maybe that > still works? For some reason you sent this only to me, which is a bit rude to everyone else on the mailing list. I'll be glad to respond if you resend it to everyone. >>> >>> I'm sorry, newbie here. I thought it'd be better to not annoy everyone with >>> responses but learning things everyday I guess :) >> >> No problem, but you should also line-wrap your emails :) >> >>> I am pretty sure the issue with my patch was that there was too many >>> changes, however all of them were spaces and tabs related, so I think this >>> could be fine? >> >> As the bot said, break it out into "one patch per logical change", and >> "fix all whitespace issues" is not "one logical change". > > As long as git diff -w shows no difference and a compiled > object comparison before and after the change shows no > difference, I think it's fine. My thoughts, too. I didn't feel comfortable arguing as a newbie tho so I'll see what I can do once I get home. > > In fact, it avoid multiple commits where the only changes > are whitespace. > > >
Re: [patch for-5.3 0/4] revert immediate fallback to remote hugepages
Is there any objection from anybody to applying the first two patches, the reverts of the reverts that went into 5.3-rc5, for 5.3 and pursuing discussion and development using the last two patches in this series as a starting point for a sane allocation policy that just works by default for everybody? Andrea acknowledges the swap storm that he reported would be fixed with the last two patches in this series and there has been discussion on how they can be extended at the same time that they do not impact allocations outside the scope of the discussion here (hugetlb). On Thu, 5 Sep 2019, David Rientjes wrote: > On Wed, 4 Sep 2019, Linus Torvalds wrote: > > > > This series reverts those reverts and attempts to propose a more sane > > > default allocation strategy specifically for hugepages. Andrea > > > acknowledges this is likely to fix the swap storms that he originally > > > reported that resulted in the patches that removed __GFP_THISNODE from > > > hugepage allocations. > > > > There's no way we can try this for 5.3 even if looks ok. This is > > "let's try this during the 5.4 merge window" material, and see how it > > works. > > > > But I'd love affected people to test this all on their loads and post > > numbers, so that we have actual numbers for this series when we do try > > to merge it. > > > > I'm certainly not proposing the last two patches in the series marked as > RFC to be merged. I'm proposing the first two patches in the series, > reverts of the reverts that went into 5.3-rc5, are merged for 5.3 so that > we return to the same behavior that we have had for years and semantics > that MADV_HUGEPAGE has provided that entire libraries and userspaces have > been based on. > > It is very clear that there is a path forward here to address the *bug* > that Andrea is reporting: it has become conflated with NUMA allocation > policies which is not at all the issue. Note that if 5.3 is released with > these patches that it requires a very specialized usecase to benefit from: > workloads that are larger than one socket and *requires* remote memory not > being low on memory or fragmented. If remote memory is as low on memory > or fragmented as local memory (like in a datacenter), the reverts that > went into 5.3 will double the impact of the very bug being reported > because now it's causing swap storms for remote memory as well. I don't > anticipate we'll get numbers for that since it's not a configuration they > run in. > > The bug here is reclaim in the page allocator that does not benefit memory > compaction because we are failing per-zone watermarks already. The last > two patches in these series avoid that, which is a sane default page > allocation policy, and the allow fallback to remote memory only when we > can't easily allocate locally. > > We *need* the ability to allocate hugepages locally if compaction can > work, anything else kills performance. 5.3-rc7 won't try that, it will > simply fallback to remote memory. We need to try compaction but we do not > want to reclaim if failing watermark checks. > > I hope that I'm not being unrealistically optimistic that we can make > progress on providing a sane default allocation policy using those last > two patches as a starter for 5.4, but I'm strongly suggesting that you > take the first two patches to return us to the policy that has existed for > years and not allow MADV_HUGEPAGE to be used for immediate remote > allocation when local is possible. >
Re: [PATCH 2/2] ipc: fix sparc64 ipc() wrapper
On Thu, Sep 5, 2019 at 5:24 PM Arnd Bergmann wrote:
> diff --git a/arch/sparc/kernel/sys_sparc_64.c
> b/arch/sparc/kernel/sys_sparc_64.c
> index ccc88926bc00..5ad0494df367 100644
> --- a/arch/sparc/kernel/sys_sparc_64.c
> +++ b/arch/sparc/kernel/sys_sparc_64.c
> @@ -340,21 +340,21 @@ SYSCALL_DEFINE6(sparc_ipc, unsigned int, call, int,
> first, unsigned long, second
> if (call <= SEMTIMEDOP) {
> switch (call) {
> case SEMOP:
> - err = sys_semtimedop(first, ptr,
> -(unsigned int)second, NULL);
> + err = ksys_semtimedop(first, ptr,
> + (unsigned int)second, NULL);
> goto out;
The zero-day bot found a link error in sparc64 allnoconfig:
arch/sparc/kernel/sys_sparc_64.o: In function `__se_sys_sparc_ipc':
>> sys_sparc_64.c:(.text+0x724): undefined reference to `ksys_semtimedop'
>> sys_sparc_64.c:(.text+0x76c): undefined reference to `ksys_old_msgctl'
>> sys_sparc_64.c:(.text+0x7a8): undefined reference to `ksys_semget'
>> sys_sparc_64.c:(.text+0x7c8): undefined reference to `ksys_old_semctl'
>> sys_sparc_64.c:(.text+0x7e4): undefined reference to `ksys_msgsnd'
>> sys_sparc_64.c:(.text+0x7fc): undefined reference to `ksys_shmget'
>> sys_sparc_64.c:(.text+0x808): undefined reference to `ksys_shmdt'
sys_sparc_64.c:(.text+0x828): undefined reference to `ksys_semtimedop'
>> sys_sparc_64.c:(.text+0x844): undefined reference to `ksys_old_shmctl'
>> sys_sparc_64.c:(.text+0x858): undefined reference to `ksys_msgget'
>> sys_sparc_64.c:(.text+0x86c): undefined reference to `ksys_msgrcv'
I've added this hunk to my patch and plan to send both fixes to Linus
in the next few days, after I get a positive report from the bot as well:
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -336,6 +336,9 @@ SYSCALL_DEFINE6(sparc_ipc, unsigned int, call,
int, first, unsigned long, second
{
long err;
+ if (!IS_ENABLED(CONFIG_SYSVIPC))
+ return -ENOSYS;
+
/* No need for backward compatibility. We can start fresh... */
if (call <= SEMTIMEDOP) {
switch (call) {
Re: [PATCH v3 0/6] ARM: dts: mmp2: devicetree updates
> Here's a couple of updates for the MMP2 SoC devicetree files. > I'm wondering if they could be applied to the armsoc tree? > > Compared to previous submission, the only change is the addition of > Acks from Pavel. Any news here? Having up-to-date dts is kind-of useful Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: Linux 5.3-rc7
On Sat, Sep 7, 2019 at 12:17 PM Linus Torvalds
wrote:
>
> I'm really not clear on why it's a good idea to clear the LDR bits on
> shutdown, and commit 558682b52919 ("x86/apic: Include the LDR when
> clearing out APIC registers") just looks pointless. And now it has
> proven to break some machines.
>
> So why wouldn't we just revert it?
Side note: looking around for the discussion about this patch, at
least one version of the patch from Bandan had
+ if (!x2apic_enabled) {
rather than
+ if (!x2apic_enabled()) {
which meant that whatever Bandan tested at that point was actually a
complete no-op, since "!x2apic_enabled" is never true (it tests a
function pointer against NULL, which it won't be).
Then that was fixed by the time it hit -tip (and eventually my tree),
but it kind of shows how the patch history of this is all
questionable. Further strengthened by a quote from that discussion:
"this is really a KVM bug but it doesn't hurt to clear out the LDR in
the guest and then, it wouldn't need a hypervisor fix"
and clearly it *does* hurt to clear the LDR in the guest, making the
whole thinking behind the patch wrong and broken. The kernel clearly
_does_ depend on LDR having the right contents.
Now, I still suspect the boot problem then comes from our
cpu0_logical_apicid use mentioned in that previous email, but at this
point I think the proper fix is "revert for now, and we can look at
this as a cleanup with the cpu0_logical_apicid thing for 5.4 instead".
Hmm?
Linus
Re: [PATCH] Fixed most indent issues in tty_io.c
On Sat, 2019-09-07 at 18:42 +0100, Greg KH wrote: > On Sat, Sep 07, 2019 at 07:35:42PM +0200, Sandro Volery wrote: > > > > > > > On 7 Sep 2019, at 19:29, Greg KH wrote: > > > > On Sat, Sep 07, 2019 at 07:23:59PM +0200, Sandro Volery wrote: > > > > Dear Greg, > > > > I am pretty sure the issue was, that I did too many things at once. > > > > However, all the things I did are related to spaces / tabs, maybe that > > > > still works? > > > > > > > > > > > > For some reason you sent this only to me, which is a bit rude to > > > everyone else on the mailing list. I'll be glad to respond if you > > > resend it to everyone. > > > > I'm sorry, newbie here. I thought it'd be better to not annoy everyone with > > responses but learning things everyday I guess :) > > No problem, but you should also line-wrap your emails :) > > > I am pretty sure the issue with my patch was that there was too many > > changes, however all of them were spaces and tabs related, so I think this > > could be fine? > > As the bot said, break it out into "one patch per logical change", and > "fix all whitespace issues" is not "one logical change". As long as git diff -w shows no difference and a compiled object comparison before and after the change shows no difference, I think it's fine. In fact, it avoid multiple commits where the only changes are whitespace.
Re: [PATCH 2/2] staging: exfat: cleanup spacing for casts
On Sat, 2019-09-07 at 18:58 +, Valentin Vidic wrote:
> Fixes checkpatch.pl warnings:
>
> CHECK: No space is necessary after a cast
Please always try to improve the code rather
than shutup checkpatch warnings.
> diff --git a/drivers/staging/exfat/exfat_core.c
> b/drivers/staging/exfat/exfat_core.c
[]
> @@ -204,7 +204,7 @@ s32 fat_alloc_cluster(struct super_block *sb, s32
> num_alloc,
>
> if ((--num_alloc) == 0) {
> p_fs->clu_srch_ptr = new_clu;
> - if (p_fs->used_clusters != (u32) ~0)
> + if (p_fs->used_clusters != (u32)~0)
Probably better as UINT_MAX
etc...
> @@ -3678,7 +3678,7 @@ static int parse_options(char *options, int silent, int
> *debug,
> opts->fs_uid = current_uid();
> opts->fs_gid = current_gid();
> opts->fs_fmask = opts->fs_dmask = current->fs->umask;
> - opts->allow_utime = (unsigned short) -1;
> + opts->allow_utime = (unsigned short)-1;
and maybe U16_MAX
> @@ -3770,7 +3770,7 @@ static int parse_options(char *options, int silent, int
> *debug,
> }
>
> out:
> - if (opts->allow_utime == (unsigned short) -1)
> + if (opts->allow_utime == (unsigned short)-1)
> opts->allow_utime = ~opts->fs_dmask & 0022;
>
> return 0;
Re: Linux 5.3-rc7
On Sat, Sep 7, 2019 at 8:00 AM Thomas Gleixner wrote:
>
> Ok let me find a testbox to figure out whats wrong there.
Honestly, it looks like we should just revert that commit, since we
never used to clear the LDR bits before either, and the bug it "fixes"
doesn't really seem to be a bug (well, it's a bug in KVM, but that's a
different thing).
And I wouldn't be at all surprised if it confuses some BIOS code.
We use the LDR bits ourselves in smp_get_logical_apicid(), and so
clearing them out seems entirely bogus.
At a guess, it's wakeup_cpu_via_init_nmi() that does that
if (apic->dest_logical == APIC_DEST_LOGICAL)
id = cpu0_logical_apicid;
else
id = apicid;
and now that we've cleared the APIC LDR bits, we no longer wake the
BSP. We send the NMI to the _old_ APIC ID, but we've overwritten it
with 0 when we put it to sleep, so now nothing happens.
I'm really not clear on why it's a good idea to clear the LDR bits on
shutdown, and commit 558682b52919 ("x86/apic: Include the LDR when
clearing out APIC registers") just looks pointless. And now it has
proven to break some machines.
So why wouldn't we just revert it?
Linus
Re: [PATCH] usb: storage: Add ums-cros-aoa driver
On Fri, 6 Sep 2019, Julius Werner wrote: > FWIW, I found a suitable workaround now to get my use case working > with existing kernels: I can do the mode switch from userspace, then > after the device reenumerates I can manually disable any interfaces I > don't like by writing 0 to their 'authorized' node, and then I write > the VID/PID to usb-storage/new_id. Okay, very good. > I still think it would be nice in general to be able to force a driver > to bind a specific device (rather than a VID/PID match), but it's not > a pressing need for me anymore. You _can_ do this currently, by writing the name of the interface to /sys/bus/usb/drivers/usb-storage/bind. But as you know, this doesn't work unless the VID & PID already match one of the driver's entries. Alan Stern
Re: [PATCH v2] KEYS: trusted: correctly initialize digests and fix locking issue
On Sat, 2019-09-07 at 22:02 +0300, Jarkko Sakkinen wrote:
> On Wed, 2019-09-04 at 20:50 +0200, Roberto Sassu wrote:
> > This patch fixes two issues introduced with commit 0b6cf6b97b7e ("tpm: pass
> > an array of tpm_extend_digest structures to tpm_pcr_extend()").
> >
> > It initializes the algorithm in init_digests() for trusted keys, and moves
> > the algorithm check in tpm_pcr_extend() before locks are taken in
> > tpm_find_get_ops().
> >
> > Signed-off-by: Roberto Sassu
> > Fixes: 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to
> > tpm_pcr_extend()")
> > ---
>
> The changelog is missing. You should place it right after these three
> dashes before diffstat. So, why did you do v2?
>
> I don't see any description of the two issues. The commit messages
> goes on explaining right away what this patch does. Would be nice
> to have one paragraph describing both of the issues at first before
> striving into solutions.
>
> Also, the granularity should be one patch per one issue so this will
> require two patches in total.
Actually taking my words back as far as the last paragraph goes. Since
the fixes tag is the same I'm cool with one patch as long as the commit
message describes better what you're doing and why.
/Jarkko
Re: [PATCH v2] KEYS: trusted: correctly initialize digests and fix locking issue
On Wed, 2019-09-04 at 20:50 +0200, Roberto Sassu wrote:
> This patch fixes two issues introduced with commit 0b6cf6b97b7e ("tpm: pass
> an array of tpm_extend_digest structures to tpm_pcr_extend()").
>
> It initializes the algorithm in init_digests() for trusted keys, and moves
> the algorithm check in tpm_pcr_extend() before locks are taken in
> tpm_find_get_ops().
>
> Signed-off-by: Roberto Sassu
> Fixes: 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to
> tpm_pcr_extend()")
> ---
The changelog is missing. You should place it right after these three
dashes before diffstat. So, why did you do v2?
I don't see any description of the two issues. The commit messages
goes on explaining right away what this patch does. Would be nice
to have one paragraph describing both of the issues at first before
striving into solutions.
Also, the granularity should be one patch per one issue so this will
require two patches in total.
/Jarkko
[PATCH 2/2] staging: exfat: cleanup spacing for casts
Fixes checkpatch.pl warnings:
CHECK: No space is necessary after a cast
Signed-off-by: Valentin Vidic
---
drivers/staging/exfat/exfat_core.c | 88 ++---
drivers/staging/exfat/exfat_super.c | 66 +++---
2 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/staging/exfat/exfat_core.c
b/drivers/staging/exfat/exfat_core.c
index 8fb4ce16010c..64b89ae5af84 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -204,7 +204,7 @@ s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
if ((--num_alloc) == 0) {
p_fs->clu_srch_ptr = new_clu;
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != (u32)~0)
p_fs->used_clusters += num_clusters;
return num_clusters;
@@ -215,7 +215,7 @@ s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
}
p_fs->clu_srch_ptr = new_clu;
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != (u32)~0)
p_fs->used_clusters += num_clusters;
return num_clusters;
@@ -273,7 +273,7 @@ s32 exfat_alloc_cluster(struct super_block *sb, s32
num_alloc,
if ((--num_alloc) == 0) {
p_fs->clu_srch_ptr = hint_clu;
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != (u32)~0)
p_fs->used_clusters += num_clusters;
p_chain->size += num_clusters;
@@ -293,7 +293,7 @@ s32 exfat_alloc_cluster(struct super_block *sb, s32
num_alloc,
}
p_fs->clu_srch_ptr = hint_clu;
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != (u32)~0)
p_fs->used_clusters += num_clusters;
p_chain->size += num_clusters;
@@ -337,7 +337,7 @@ void fat_free_cluster(struct super_block *sb, struct
chain_t *p_chain,
} while (clu != CLUSTER_32(~0));
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != (u32)~0)
p_fs->used_clusters -= num_clusters;
}
@@ -396,7 +396,7 @@ void exfat_free_cluster(struct super_block *sb, struct
chain_t *p_chain,
} while ((clu != CLUSTER_32(0)) && (clu != CLUSTER_32(~0)));
}
- if (p_fs->used_clusters != (u32) ~0)
+ if (p_fs->used_clusters != (u32)~0)
p_fs->used_clusters -= num_clusters;
}
@@ -473,7 +473,7 @@ s32 exfat_count_used_clusters(struct super_block *sb)
map_i = map_b = 0;
for (i = 2; i < p_fs->num_clusters; i += 8) {
- k = *(((u8 *) p_fs->vol_amap[map_i]->b_data) + map_b);
+ k = *(((u8 *)p_fs->vol_amap[map_i]->b_data) + map_b);
count += used_bit[k];
if ((++map_b) >= p_bd->sector_size) {
@@ -536,7 +536,7 @@ s32 load_alloc_bitmap(struct super_block *sb)
if (ep->flags == 0x0) {
p_fs->map_clu = GET32_A(ep->start_clu);
- map_size = (u32) GET64_A(ep->size);
+ map_size = (u32)GET64_A(ep->size);
p_fs->map_sectors = ((map_size - 1) >>
p_bd->sector_size_bits) + 1;
@@ -601,7 +601,7 @@ s32 set_alloc_bitmap(struct super_block *sb, u32 clu)
sector = START_SECTOR(p_fs->map_clu) + i;
- exfat_bitmap_set((u8 *) p_fs->vol_amap[i]->b_data, b);
+ exfat_bitmap_set((u8 *)p_fs->vol_amap[i]->b_data, b);
return sector_write(sb, sector, p_fs->vol_amap[i], 0);
}
@@ -623,7 +623,7 @@ s32 clr_alloc_bitmap(struct super_block *sb, u32 clu)
sector = START_SECTOR(p_fs->map_clu) + i;
- exfat_bitmap_clear((u8 *) p_fs->vol_amap[i]->b_data, b);
+ exfat_bitmap_clear((u8 *)p_fs->vol_amap[i]->b_data, b);
return sector_write(sb, sector, p_fs->vol_amap[i], 0);
@@ -655,7 +655,7 @@ u32 test_alloc_bitmap(struct super_block *sb, u32 clu)
map_b = (clu >> 3) & p_bd->sector_size_mask;
for (i = 2; i < p_fs->num_clusters; i += 8) {
- k = *(((u8 *) p_fs->vol_amap[map_i]->b_data) + map_b);
+ k = *(((u8 *)p_fs->vol_amap[map_i]->b_data) + map_b);
if (clu_mask > 0) {
k |= clu_mask;
clu_mask = 0;
@@ -728,7 +728,7 @@ static s32 __load_upcase_table(struct super_block *sb,
sector_t sector,
sector++;
for (i = 0; i < p_bd->sector_size && index <= 0x; i += 2) {
- uni = GET16(((u8 *) tmp_bh->b_data) + i);
+ uni = GET16(((u8 *)tmp_bh->b_data) + i);
checksum = ((checksum & 1) ? 0x8000 : 0) +
(checksum >> 1)
[PATCH 1/2] staging: exfat: cleanup spacing for operators
Fixes checkpatch.pl warnings:
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
CHECK: spaces preferred around that '*' (ctx:VxV)
CHECK: spaces preferred around that '|' (ctx:VxV)
Signed-off-by: Valentin Vidic
---
drivers/staging/exfat/exfat.h | 2 +-
drivers/staging/exfat/exfat_core.c | 76 ++---
drivers/staging/exfat/exfat_super.c | 44 -
3 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 0aa14dea4e09..6c12f2d79f4d 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -159,7 +159,7 @@
/* Upcase table macro */
#define HIGH_INDEX_BIT (8)
#define HIGH_INDEX_MASK(0xFF00)
-#define LOW_INDEX_BIT (16-HIGH_INDEX_BIT)
+#define LOW_INDEX_BIT (16 - HIGH_INDEX_BIT)
#define UTBL_ROW_COUNT BIT(LOW_INDEX_BIT)
#define UTBL_COL_COUNT BIT(HIGH_INDEX_BIT)
diff --git a/drivers/staging/exfat/exfat_core.c
b/drivers/staging/exfat/exfat_core.c
index 995358cc7c79..8fb4ce16010c 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -230,7 +230,7 @@ s32 exfat_alloc_cluster(struct super_block *sb, s32
num_alloc,
hint_clu = p_chain->dir;
if (hint_clu == CLUSTER_32(~0)) {
- hint_clu = test_alloc_bitmap(sb, p_fs->clu_srch_ptr-2);
+ hint_clu = test_alloc_bitmap(sb, p_fs->clu_srch_ptr - 2);
if (hint_clu == CLUSTER_32(~0))
return 0;
} else if (hint_clu >= p_fs->num_clusters) {
@@ -242,7 +242,7 @@ s32 exfat_alloc_cluster(struct super_block *sb, s32
num_alloc,
p_chain->dir = CLUSTER_32(~0);
- while ((new_clu = test_alloc_bitmap(sb, hint_clu-2)) != CLUSTER_32(~0))
{
+ while ((new_clu = test_alloc_bitmap(sb, hint_clu - 2)) !=
CLUSTER_32(~0)) {
if (new_clu != hint_clu) {
if (p_chain->flags == 0x03) {
exfat_chain_cont_cluster(sb, p_chain->dir,
@@ -251,7 +251,7 @@ s32 exfat_alloc_cluster(struct super_block *sb, s32
num_alloc,
}
}
- if (set_alloc_bitmap(sb, new_clu-2) != FFS_SUCCESS)
+ if (set_alloc_bitmap(sb, new_clu - 2) != FFS_SUCCESS)
return -1;
num_clusters++;
@@ -324,7 +324,7 @@ void fat_free_cluster(struct super_block *sb, struct
chain_t *p_chain,
if (do_relse) {
sector = START_SECTOR(clu);
for (i = 0; i < p_fs->sectors_per_clu; i++)
- buf_release(sb, sector+i);
+ buf_release(sb, sector + i);
}
prev = clu;
@@ -367,10 +367,10 @@ void exfat_free_cluster(struct super_block *sb, struct
chain_t *p_chain,
if (do_relse) {
sector = START_SECTOR(clu);
for (i = 0; i < p_fs->sectors_per_clu; i++)
- buf_release(sb, sector+i);
+ buf_release(sb, sector + i);
}
- if (clr_alloc_bitmap(sb, clu-2) != FFS_SUCCESS)
+ if (clr_alloc_bitmap(sb, clu - 2) != FFS_SUCCESS)
break;
clu++;
@@ -384,10 +384,10 @@ void exfat_free_cluster(struct super_block *sb, struct
chain_t *p_chain,
if (do_relse) {
sector = START_SECTOR(clu);
for (i = 0; i < p_fs->sectors_per_clu; i++)
- buf_release(sb, sector+i);
+ buf_release(sb, sector + i);
}
- if (clr_alloc_bitmap(sb, clu-2) != FFS_SUCCESS)
+ if (clr_alloc_bitmap(sb, clu - 2) != FFS_SUCCESS)
break;
if (FAT_read(sb, clu, &clu) == -1)
@@ -491,7 +491,7 @@ void exfat_chain_cont_cluster(struct super_block *sb, u32
chain, s32 len)
return;
while (len > 1) {
- if (FAT_write(sb, chain, chain+1) < 0)
+ if (FAT_write(sb, chain, chain + 1) < 0)
break;
chain++;
len--;
@@ -538,7 +538,7 @@ s32 load_alloc_bitmap(struct super_block *sb)
p_fs->map_clu = GET32_A(ep->start_clu);
map_size = (u32) GET64_A(ep->size);
- p_fs->map_sectors = ((map_size-1) >>
p_bd->sector_size_bits) + 1;
+ p_fs->map_sectors = ((map_size - 1) >>
p_bd->sector_size_bits) + 1;
p_fs->vol_amap =
kmalloc_arra
Re: [PATCH AUTOSEL 4.19 126/167] tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations
On Tue, 2019-09-03 at 15:43 -0400, Sasha Levin wrote:
> Right. I gave a go at backporting a few patches and this happens to be
> one of them. It will be a while before it goes in a stable tree
> (probably way after after LPC).
It *semantically* depends on
db4d8cb9c9f2 ("tpm: use tpm_try_get_ops() in tpm-sysfs.c.")
I.e. can cause crashes without the above patch. As a code change your
patch is fine but it needs the above patch backported to work in stable
manner.
So... either I can backport that one (because ultimately I have
responsibility to do that as the maintainer) but if you want to finish
this one that is what you need to backport in addition and then it
should be fine.
/Jarkko
Re: [PATCH net-next] netfilter: nf_tables: avoid excessive stack usage
On Sat, Sep 07, 2019 at 08:41:22PM +0200, Arnd Bergmann wrote:
> On Sat, Sep 7, 2019 at 8:07 PM Pablo Neira Ayuso wrote:
> >
> > Hi Arnd,
> >
> > On Fri, Sep 06, 2019 at 05:12:30PM +0200, Arnd Bergmann wrote:
> > > The nft_offload_ctx structure is much too large to put on the
> > > stack:
> > >
> > > net/netfilter/nf_tables_offload.c:31:23: error: stack frame size of 1200
> > > bytes in function 'nft_flow_rule_create' [-Werror,-Wframe-larger-than=]
> > >
> > > Use dynamic allocation here, as we do elsewhere in the same
> > > function.
> > >
> > > Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
> > > Signed-off-by: Arnd Bergmann
> > > ---
> > > Since we only really care about two members of the structure, an
> > > alternative would be a larger rewrite, but that is probably too
> > > late for v5.4.
> >
> > Thanks for this patch.
> >
> > I'm attaching a patch to reduce this structure size a bit. Do you
> > think this alternative patch is ok until this alternative rewrite
> > happens?
>
> I haven't tried it yet, but it looks like that would save 8 of the
> 48 bytes in each for each of the 24 registers (12 bytes on m68k
> or i386, which only use 4 byte alignment for nft_data), so
> this wouldn't make too much difference.
I'll take your patch as is.
> > Anyway I agree we should to get this structure away from the
> > stack, even after this is still large, so your patch (or a variant of
> > it) will be useful sooner than later I think.
>
> What I was thinking for a possible smaller fix would be to not
> pass the ctx into the expr->ops->offload callback but
> only pass the 'dep' member. Since I've never seen this code
> before, I have no idea if that would be an improvement
> in the end.
We might need this more fields of this context structure, this code is
very new, still under development, let's revisit this later.
Thanks.
Re: [PATCH] VMCI: Release resource if the work is already queued
On Tue, Aug 20, 2019 at 01:26:38PM -0700, Nadav Amit wrote: > Francois reported that VMware balloon gets stuck after a balloon reset, > when the VMCI doorbell is removed. A similar error can occur when the > balloon driver is removed with the following splat: Note, google thinks your email is spam as you are not sending this from a valid vmware.com email server. Please fix this up if you want to make sure your patches actually make it through... thanks, greg k-h
Re: [PATCH] nvme: Restore device naming sanity
Apart from the some nits, this looks okay.
Reviewed-by: Chaitanya Kulkarni
May be subject line should be 's/nvme/nvme-core/' ?
On 09/04/2019 10:34 AM, Keith Busch wrote:
> The namespace names must be unique for the lifetime of the subsystem.
> This was accomplished by using their parent subsystems' instances which
> was independent of the controllers connected to that subsystem.
>
> The consequence of that naming scheme meant that name prefixes given to
> namespaces may match a controller from an unrelated subsystem. This has
> understandbly invited confusion when examining device nodes.
's/understandbly/understandably/'
>
> Ensure the namespace's subsystem instance never clashes with a
> controller instance of another subsystem by transferring the instance
> ownership to parent subsystem from the first controller discovered in
> that subsystem.
>
> Reviewed-by: Logan Gunthorpe
> Signed-off-by: Keith Busch
> ---
> drivers/nvme/host/core.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 14c0bfb55615..8a8279ece5ee 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -81,7 +81,6 @@ EXPORT_SYMBOL_GPL(nvme_reset_wq);
> struct workqueue_struct *nvme_delete_wq;
> EXPORT_SYMBOL_GPL(nvme_delete_wq);
>
> -static DEFINE_IDA(nvme_subsystems_ida);
> static LIST_HEAD(nvme_subsystems);
> static DEFINE_MUTEX(nvme_subsystems_lock);
>
> @@ -2344,7 +2343,8 @@ static void nvme_release_subsystem(struct device *dev)
> struct nvme_subsystem *subsys =
> container_of(dev, struct nvme_subsystem, dev);
>
> - ida_simple_remove(&nvme_subsystems_ida, subsys->instance);
> + if (subsys->instance >= 0)
> + ida_simple_remove(&nvme_instance_ida, subsys->instance);
> kfree(subsys);
> }
>
> @@ -2473,12 +2473,8 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl,
> struct nvme_id_ctrl *id)
> subsys = kzalloc(sizeof(*subsys), GFP_KERNEL);
> if (!subsys)
> return -ENOMEM;
> - ret = ida_simple_get(&nvme_subsystems_ida, 0, 0, GFP_KERNEL);
> - if (ret < 0) {
> - kfree(subsys);
> - return ret;
> - }
> - subsys->instance = ret;
> +
> + subsys->instance = -1;
> mutex_init(&subsys->lock);
> kref_init(&subsys->ref);
> INIT_LIST_HEAD(&subsys->ctrls);
> @@ -2497,7 +2493,7 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl,
> struct nvme_id_ctrl *id)
> subsys->dev.class = nvme_subsys_class;
> subsys->dev.release = nvme_release_subsystem;
> subsys->dev.groups = nvme_subsys_attrs_groups;
> - dev_set_name(&subsys->dev, "nvme-subsys%d", subsys->instance);
> + dev_set_name(&subsys->dev, "nvme-subsys%d", ctrl->instance);
> device_initialize(&subsys->dev);
>
> mutex_lock(&nvme_subsystems_lock);
> @@ -2528,6 +2524,8 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl,
> struct nvme_id_ctrl *id)
> goto out_put_subsystem;
> }
>
> + if (!found)
> + subsys->instance = ctrl->instance;
> ctrl->subsys = subsys;
> list_add_tail(&ctrl->subsys_entry, &subsys->ctrls);
> mutex_unlock(&nvme_subsystems_lock);
> @@ -3803,7 +3801,9 @@ static void nvme_free_ctrl(struct device *dev)
> container_of(dev, struct nvme_ctrl, ctrl_device);
> struct nvme_subsystem *subsys = ctrl->subsys;
>
> - ida_simple_remove(&nvme_instance_ida, ctrl->instance);
> + if (subsys && ctrl->instance != subsys->instance)
> + ida_simple_remove(&nvme_instance_ida, ctrl->instance);
> +
> kfree(ctrl->effects);
> nvme_mpath_uninit(ctrl);
> __free_page(ctrl->discard_page);
> @@ -4085,7 +4085,6 @@ static int __init nvme_core_init(void)
>
> static void __exit nvme_core_exit(void)
> {
> - ida_destroy(&nvme_subsystems_ida);
> class_destroy(nvme_subsys_class);
> class_destroy(nvme_class);
> unregister_chrdev_region(nvme_chr_devt, NVME_MINORS);
>
Re: [PATCH net-next] netfilter: nf_tables: avoid excessive stack usage
On Sat, Sep 7, 2019 at 8:07 PM Pablo Neira Ayuso wrote:
>
> Hi Arnd,
>
> On Fri, Sep 06, 2019 at 05:12:30PM +0200, Arnd Bergmann wrote:
> > The nft_offload_ctx structure is much too large to put on the
> > stack:
> >
> > net/netfilter/nf_tables_offload.c:31:23: error: stack frame size of 1200
> > bytes in function 'nft_flow_rule_create' [-Werror,-Wframe-larger-than=]
> >
> > Use dynamic allocation here, as we do elsewhere in the same
> > function.
> >
> > Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
> > Signed-off-by: Arnd Bergmann
> > ---
> > Since we only really care about two members of the structure, an
> > alternative would be a larger rewrite, but that is probably too
> > late for v5.4.
>
> Thanks for this patch.
>
> I'm attaching a patch to reduce this structure size a bit. Do you
> think this alternative patch is ok until this alternative rewrite
> happens?
I haven't tried it yet, but it looks like that would save 8 of the
48 bytes in each for each of the 24 registers (12 bytes on m68k
or i386, which only use 4 byte alignment for nft_data), so
this wouldn't make too much difference.
> Anyway I agree we should to get this structure away from the
> stack, even after this is still large, so your patch (or a variant of
> it) will be useful sooner than later I think.
What I was thinking for a possible smaller fix would be to not
pass the ctx into the expr->ops->offload callback but
only pass the 'dep' member. Since I've never seen this code
before, I have no idea if that would be an improvement
in the end.
Arnd
[GIT PULL] Char/Misc driver fixes for 5.3-rc8
The following changes since commit 089cf7f6ecb266b6a4164919a2e69bd2f938374a: Linux 5.3-rc7 (2019-09-02 09:57:40 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git tags/char-misc-5.3-rc8 for you to fetch changes up to a8e0abae2fe0e788fa3d92c043605d1211c13735: Documentation/process: Add Qualcomm process ambassador for hardware security issues (2019-09-07 18:30:54 +0100) Documentation update for 5.3-rc8 Here is a few small patches for the documenation file that came in through the char-misc tree in -rc7 for your tree. They fix the mistake in the .rst format that kept the table of companies from showing up in the html output, and most importantly, add people's names to the list showing support for our process. Signed-off-by: Greg Kroah-Hartman Andrew Cooper (1): Documentation/process: Volunteer as the ambassador for Xen Kees Cook (1): Documentation/process: Add Google contact for embargoed hardware issues Sasha Levin (1): Documentation/process/embargoed-hardware-issues: Microsoft ambassador Trilok Soni (1): Documentation/process: Add Qualcomm process ambassador for hardware security issues Documentation/process/embargoed-hardware-issues.rst | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)
Re: [PATCH] Fixed most indent issues in tty_io.c
Sandro V > On 7 Sep 2019, at 20:03, Greg KH wrote: > > On Sat, Sep 07, 2019 at 07:49:43PM +0200, Sandro Volery wrote: >> >> >> >> On 7 Sep 2019, at 19:42, Greg KH wrote: >>> >>> On Sat, Sep 07, 2019 at 07:35:42PM +0200, Sandro Volery wrote: On 7 Sep 2019, at 19:29, Greg KH wrote: >>> On Sat, Sep 07, 2019 at 07:23:59PM +0200, Sandro Volery wrote: >>> Dear Greg, >>> I am pretty sure the issue was, that I did too many things at once. >>> However, all the things I did are related to spaces / tabs, maybe that >>> still works? > > > > For some reason you sent this only to me, which is a bit rude to > everyone else on the mailing list. I'll be glad to respond if you > resend it to everyone. I'm sorry, newbie here. I thought it'd be better to not annoy everyone with responses but learning things everyday I guess :) >>> >>> No problem, but you should also line-wrap your emails :) >> >> I've just been told that before, I'll try to change >> those settings asap. >> >>> I am pretty sure the issue with my patch was that there was too many changes, however all of them were spaces and tabs related, so I think this could be fine? >>> >>> As the bot said, break it out into "one patch per logical change", and >>> "fix all whitespace issues" is not "one logical change". >> >> So a logical change would be if I make one patch >> to replace all spaces with tabs and a separate >> patch to add a space before the : ? > > Yes, that would be good. Make it a patch series please. Thanks! Any suggestion on how I should do the line wrapping when I want to send emails from my phone? Since I don't always have my laptop handy. Sandro V.
Re: [PATCH v2 1/3] software node: implement reference properties
On Sat, Sep 07, 2019 at 09:03:48PM +0300, Andy Shevchenko wrote:
> On Sat, Sep 07, 2019 at 10:37:24AM -0700, Dmitry Torokhov wrote:
> > On Sat, Sep 07, 2019 at 08:12:51PM +0300, Andy Shevchenko wrote:
> > > On Sat, Sep 07, 2019 at 09:32:40AM -0700, Dmitry Torokhov wrote:
> > > > On Sat, Sep 07, 2019 at 07:08:19PM +0300, Andy Shevchenko wrote:
> > > > > On Fri, Sep 06, 2019 at 03:26:09PM -0700, Dmitry Torokhov wrote:
> > >
> > > > > > + } else if (src->type == DEV_PROP_REF) {
> > > > > > + /* All reference properties must be arrays */
> > > > > > + return -EINVAL;
> > > > >
> > > > > Hmm... What about to duplicate pointer under value union and use
> > > > > is_array to
> > > > > distinguish which one to use? Because...
> > > >
> > > > Then we have to special-case copying this entry, similar to the pains we
> > > > are going with the strings.
> > >
> > > I can't see it as a pain. Simple do the same kmemdup() for the case when
> > > is_array = false and DEV_TYPE_REF?
> >
> > And then you need to make sure it is freed on error paths and when we
> > remove property entries. This requires more checks and code. In contrast
> > we already know how to handle out of line objects of arbitrary size.
>
> We can put it one level up to be a sibling to value / pointer unions.
> In that case is_array can be anything (we just don't care).
I think it would be better if you sketched out your proposed data
structure(s) so we are talking about the same things. But please note
that when you are dealing with property arrays we need to keep the easy
way of defining them, which means we should not be splitting individual
entries.
>
> Actually strings aren't inlined.
Right. Maybe I should clean it up as well.
>
> > > By the way, don't we need to update property_entry_{get,set}_pointer()?
> >
> > I do not see these, where are they?
>
> swnode.c. I meant property_{get,set}_pointer().
Yes, I think you are right about property_set_pointer() at least.
>
> > > > > > + .is_array = true,
> > > > > > \
> > > > >
> > > > > I really don't like this "cheating".
> > > >
> > > > This is not cheating. Any single value can be represented as an array of
> > > > one element. Actually, the only reason we have this "is_array" business
> > > > is because for scalar values and short strings it is much cheaper to
> > > > store single value in-line instead of out of line + pointer, especially
> > > > on 64 bit arches.
> > >
> > > Yes, and this is a lot of benefit!
> >
> > Yes, nobody argues against it. Here however we are dealing with a larger
> > structure. There is absolutely no benefit of trying to separate single
> > value vs array here.
>
> Thus, moving to upper layer makes more sense. Right?
>
> > > > If you want we can change is_array into is_inline.
> > >
> > > Nope, is_array is exactly what it tells us about the content. Its
> > > functional
> > > load is to distinguish which union (value vs. pointer) we are using.
> >
> > No, it signifies whether the value is stored within property entry or
> > outside. I can fit probably 8 bytes arrays into property entry
> > structure, in which case is_array will definitely not reflect the data
> > type.
>
> Nope, since strings are not inlined AFAICS.
But u64 values are.
Thanks.
--
Dmitry
Re: [PATCH 2/2] tools/power/x86/intel-speed-select: Display core count for bucket
On Fri, Sep 6, 2019 at 10:47 PM Srinivas Pandruvada wrote: > > On Fri, 2019-09-06 at 07:50 -0700, Srinivas Pandruvada wrote: > > On Fri, 2019-09-06 at 16:46 +0300, Andy Shevchenko wrote: > > > On Fri, Sep 06, 2019 at 05:39:54AM -0400, Prarit Bhargava wrote: > > > > On 9/5/19 7:37 PM, Srinivas Pandruvada wrote: > > > > > Read the bucket and core count relationship via MSR and display > > > > > when displaying turbo ratio limits. > > > > > + ret = isst_send_msr_command(cpu, 0x1ae, 0, > > > > > buckets_info); > > > > > > > > ^^^ you can get rid of the magic number 0x1ae by doing (sorry for > > > > the cut-and-paste) > > > > > > > > diff --git a/tools/power/x86/intel-speed-select/Makefile > > > > b/tools/power/x86/intel > > > > index 12c6939dca2a..087d802ad844 100644 > > > > --- a/tools/power/x86/intel-speed-select/Makefile > > > > +++ b/tools/power/x86/intel-speed-select/Makefile > > > > @@ -15,6 +15,8 @@ endif > > > > MAKEFLAGS += -r > > > > > > > > override CFLAGS += -O2 -Wall -g -D_GNU_SOURCE -I$(OUTPUT)include > > > > +override CFLAGS += -I../../../include > > > > +override CFLAGS += > > > > -DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"' > > > > No, we can't use msr_index. > This comment was meant for use of /dev/cpu/X/msr not msr_index. > I didn't want to bring in dependency on msr-index.h for couple of 2 > MSRs and the names in msr-index.h doesn't really reflect the actual > processing, they are doing. For example MSR_TURBO_RATIO_LIMIT1 for > 0x1ae. The definition of 0x1AE is different on cpu model 0x55 and > beyond. > > > It seems not applicable on top of tools patch series I had applied before. > > > > > > I guess it can be done in more neat way. > > > > > > > As I've been looking at this code I have been wondering why > > > > didn't > > > > you just use > > > > the standard /dev/cpu/X/msr interface that other x86 power > > > > utilities (turbostat, > > > > x86_energy_perf_policy) use? Implementing msr_read() is trivial > > > > (warning > > > > untested and uncompiled code) > > > > No. We can't. The MSR interface is disabled on several distribution > > and > > platforms with secured boot. So some special MSRs are only allowed > > via > > this IOCTL interface. > > > > Thanks, > > Srinivas > > > > > > > > > > Actually good point! > > > > -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 0/9] tools-power-x86-intel-speed-select: Fixes and updates for output
On Fri, Sep 6, 2019 at 10:58 AM Srinivas Pandruvada wrote: > > On Thu, 2019-09-05 at 08:03 -0400, Prarit Bhargava wrote: > > Some general fixes and updates for intel-speed-select. Fixes include > > some > > typos as well as an off-by-one cpu count reporting error. Updates > > for the > > output are > > > > - switching to MHz as a standard > > - reporting CPU frequencies instead of ratios as a standard > > - viewing a human-readable CPU list. > > - avoiding reporting "0|1" as success|fail as these can be confusing > > for a > > user. > > > > v2: Add additional patch to fix memory leak and remove help text in > > 8/9. > > For the series > > Acked-by: Srinivas Pandruvada > Pushed to my review and testing queue, thanks! > > > > Cc: Srinivas Pandruvada > > Cc: David Arcari > > Cc: linux-kernel@vger.kernel.org > > > > Prarit Bhargava (9): > > tools/power/x86/intel-speed-select: Fix package typo > > tools/power/x86/intel-speed-select: Fix help option typo > > tools/power/x86/intel-speed-select: Fix cpu-count output > > tools/power/x86/intel-speed-select: Simplify output for turbo-freq > > and > > base-freq > > tools/power/x86/intel-speed-select: Switch output to MHz > > tools/power/x86/intel-speed-select: Change turbo ratio output to > > maximum turbo frequency > > tools/power/x86/intel-speed-select: Output human readable CPU list > > tools/power/x86/intel-speed-select: Output success/failed for > > command > > output > > tools/power/x86/intel-speed-select: Fix memory leak > > > > .../x86/intel-speed-select/isst-config.c | 21 +-- > > .../x86/intel-speed-select/isst-display.c | 120 +--- > > -- > > 2 files changed, 98 insertions(+), 43 deletions(-) > > > -- With Best Regards, Andy Shevchenko
Re: [PATCH net-next] netfilter: nf_tables: avoid excessive stack usage
Hi Arnd,
On Fri, Sep 06, 2019 at 05:12:30PM +0200, Arnd Bergmann wrote:
> The nft_offload_ctx structure is much too large to put on the
> stack:
>
> net/netfilter/nf_tables_offload.c:31:23: error: stack frame size of 1200
> bytes in function 'nft_flow_rule_create' [-Werror,-Wframe-larger-than=]
>
> Use dynamic allocation here, as we do elsewhere in the same
> function.
>
> Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
> Signed-off-by: Arnd Bergmann
> ---
> Since we only really care about two members of the structure, an
> alternative would be a larger rewrite, but that is probably too
> late for v5.4.
Thanks for this patch.
I'm attaching a patch to reduce this structure size a bit. Do you
think this alternative patch is ok until this alternative rewrite
happens? Anyway I agree we should to get this structure away from the
stack, even after this is still large, so your patch (or a variant of
it) will be useful sooner than later I think.
diff --git a/include/net/netfilter/nf_tables_offload.h b/include/net/netfilter/nf_tables_offload.h
index db104665a9e4..cc44d29e9fd7 100644
--- a/include/net/netfilter/nf_tables_offload.h
+++ b/include/net/netfilter/nf_tables_offload.h
@@ -5,10 +5,10 @@
#include
struct nft_offload_reg {
- u32 key;
- u32 len;
- u32 base_offset;
- u32 offset;
+ u8 key;
+ u8 len;
+ u8 base_offset;
+ u8 offset;
struct nft_data data;
struct nft_data mask;
};
Re: [PATCH v2 1/3] software node: implement reference properties
On Sat, Sep 07, 2019 at 10:37:24AM -0700, Dmitry Torokhov wrote:
> On Sat, Sep 07, 2019 at 08:12:51PM +0300, Andy Shevchenko wrote:
> > On Sat, Sep 07, 2019 at 09:32:40AM -0700, Dmitry Torokhov wrote:
> > > On Sat, Sep 07, 2019 at 07:08:19PM +0300, Andy Shevchenko wrote:
> > > > On Fri, Sep 06, 2019 at 03:26:09PM -0700, Dmitry Torokhov wrote:
> >
> > > > > + } else if (src->type == DEV_PROP_REF) {
> > > > > + /* All reference properties must be arrays */
> > > > > + return -EINVAL;
> > > >
> > > > Hmm... What about to duplicate pointer under value union and use
> > > > is_array to
> > > > distinguish which one to use? Because...
> > >
> > > Then we have to special-case copying this entry, similar to the pains we
> > > are going with the strings.
> >
> > I can't see it as a pain. Simple do the same kmemdup() for the case when
> > is_array = false and DEV_TYPE_REF?
>
> And then you need to make sure it is freed on error paths and when we
> remove property entries. This requires more checks and code. In contrast
> we already know how to handle out of line objects of arbitrary size.
We can put it one level up to be a sibling to value / pointer unions.
In that case is_array can be anything (we just don't care).
Actually strings aren't inlined.
> > By the way, don't we need to update property_entry_{get,set}_pointer()?
>
> I do not see these, where are they?
swnode.c. I meant property_{get,set}_pointer().
> > > > > + .is_array = true,
> > > > > \
> > > >
> > > > I really don't like this "cheating".
> > >
> > > This is not cheating. Any single value can be represented as an array of
> > > one element. Actually, the only reason we have this "is_array" business
> > > is because for scalar values and short strings it is much cheaper to
> > > store single value in-line instead of out of line + pointer, especially
> > > on 64 bit arches.
> >
> > Yes, and this is a lot of benefit!
>
> Yes, nobody argues against it. Here however we are dealing with a larger
> structure. There is absolutely no benefit of trying to separate single
> value vs array here.
Thus, moving to upper layer makes more sense. Right?
> > > If you want we can change is_array into is_inline.
> >
> > Nope, is_array is exactly what it tells us about the content. Its functional
> > load is to distinguish which union (value vs. pointer) we are using.
>
> No, it signifies whether the value is stored within property entry or
> outside. I can fit probably 8 bytes arrays into property entry
> structure, in which case is_array will definitely not reflect the data
> type.
Nope, since strings are not inlined AFAICS.
> It is the type-specific accessors that know how to parse and fetch data
> from properties.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] Fixed most indent issues in tty_io.c
On Sat, Sep 07, 2019 at 07:49:43PM +0200, Sandro Volery wrote: > > > > > > On 7 Sep 2019, at 19:42, Greg KH wrote: > > > > On Sat, Sep 07, 2019 at 07:35:42PM +0200, Sandro Volery wrote: > >> > >> > >> On 7 Sep 2019, at 19:29, Greg KH wrote: > > On Sat, Sep 07, 2019 at 07:23:59PM +0200, Sandro Volery wrote: > > Dear Greg, > > I am pretty sure the issue was, that I did too many things at once. > > However, all the things I did are related to spaces / tabs, maybe that > > still works? > >>> > >>> > >>> > >>> For some reason you sent this only to me, which is a bit rude to > >>> everyone else on the mailing list. I'll be glad to respond if you > >>> resend it to everyone. > >> > >> I'm sorry, newbie here. I thought it'd be better to not annoy everyone > >> with responses but learning things everyday I guess :) > > > > No problem, but you should also line-wrap your emails :) > > I've just been told that before, I'll try to change > those settings asap. > > > > >> I am pretty sure the issue with my patch was that there was too many > >> changes, however all of them were spaces and tabs related, so I think this > >> could be fine? > > > > As the bot said, break it out into "one patch per logical change", and > > "fix all whitespace issues" is not "one logical change". > > So a logical change would be if I make one patch > to replace all spaces with tabs and a separate > patch to add a space before the : ? Yes, that would be good. Make it a patch series please. thanks, greg k-h
Re: [PATCH] Fixed most indent issues in tty_io.c
> On 7 Sep 2019, at 19:42, Greg KH wrote: > > On Sat, Sep 07, 2019 at 07:35:42PM +0200, Sandro Volery wrote: >> >> >> On 7 Sep 2019, at 19:29, Greg KH wrote: > On Sat, Sep 07, 2019 at 07:23:59PM +0200, Sandro Volery wrote: > Dear Greg, > I am pretty sure the issue was, that I did too many things at once. > However, all the things I did are related to spaces / tabs, maybe that > still works? >>> >>> >>> >>> For some reason you sent this only to me, which is a bit rude to >>> everyone else on the mailing list. I'll be glad to respond if you >>> resend it to everyone. >> >> I'm sorry, newbie here. I thought it'd be better to not annoy everyone with >> responses but learning things everyday I guess :) > > No problem, but you should also line-wrap your emails :) I've just been told that before, I'll try to change those settings asap. > >> I am pretty sure the issue with my patch was that there was too many >> changes, however all of them were spaces and tabs related, so I think this >> could be fine? > > As the bot said, break it out into "one patch per logical change", and > "fix all whitespace issues" is not "one logical change". So a logical change would be if I make one patch to replace all spaces with tabs and a separate patch to add a space before the : ? Thanks, Sandro V.
[PATCH] arm64: dts: rockchip: add analog audio nodes on rk3399-rockpro64
This patch adds audio codec (Everest ES8316) and I2S audio nodes for
RK3399 RockPro64.
Signed-off-by: Katsuhiro Suzuki
---
.../boot/dts/rockchip/rk3399-rockpro64.dts| 28 +++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
index 0401d4ec1f45..8b1e6382b140 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
@@ -81,6 +81,12 @@
reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
};
+ sound {
+ compatible = "audio-graph-card";
+ label = "rockchip,rk3399";
+ dais = <&i2s1_p0>;
+ };
+
vcc12v_dcin: vcc12v-dcin {
compatible = "regulator-fixed";
regulator-name = "vcc12v_dcin";
@@ -470,6 +476,20 @@
i2c-scl-rising-time-ns = <300>;
i2c-scl-falling-time-ns = <15>;
status = "okay";
+
+ es8316: codec@11 {
+ compatible = "everest,es8316";
+ reg = <0x11>;
+ clocks = <&cru SCLK_I2S_8CH_OUT>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+
+ port {
+ es8316_p0_0: endpoint {
+ remote-endpoint = <&i2s1_p0_0>;
+ };
+ };
+ };
};
&i2c3 {
@@ -505,6 +525,14 @@
rockchip,playback-channels = <2>;
rockchip,capture-channels = <2>;
status = "okay";
+
+ i2s1_p0: port {
+ i2s1_p0_0: endpoint {
+ dai-format = "i2s";
+ mclk-fs = <256>;
+ remote-endpoint = <&es8316_p0_0>;
+ };
+ };
};
&i2s2 {
--
2.23.0.rc1
[PATCH 1/4] cpufreq: ti-cpufreq: add support for omap34xx and omap36xx
This adds code and tables to read the silicon revision and
eFuse (speed binned / 720 MHz grade) bits for selecting
opp-v2 table entries.
Since these bits are not always part of the syscon register
range (like for am33xx, am43, dra7), we add code to directly
read the register values using ioremap() if syscon access fails.
The format of the opp-supported-hw entries is that it has
two 32 bit bitfields. E.g.:
opp-supported-hw = <0x 3>
The first value is matched against the bit position of the
silicon revision which is (see TRM)
omap34xx:
BIT(0) ES1.0
BIT(1) ES2.0
BIT(2) ES2.1
BIT(3) ES3.0
BIT(4) ES3.1
BIT(7) ES3.1.2
omap36xx:
BIT(0) ES1.0
BIT(1) ES1.1
BIT(2) ES1.2
The second value is matched against the speed grade eFuse:
BIT(0) no high speed OPP
BIT(1) high speed OPP
This means for the example above that it is always enabled
while e.g.
opp-supported-hw = <0x1 2>
enables the OPP only for ES1.0 BIT(0) and if the high speed
eFuse is set BIT(1).
Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Tony Lindgren
---
drivers/cpufreq/ti-cpufreq.c | 91 +++-
1 file changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 2ad1ae17932d..f2f58d689320 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -31,6 +31,11 @@
#define DRA7_EFUSE_OD_MPU_OPP BIT(1)
#define DRA7_EFUSE_HIGH_MPU_OPPBIT(2)
+#define OMAP3_CONTROL_DEVICE_STATUS0x4800244C
+#define OMAP3_CONTROL_IDCODE 0x4830A204
+#define OMAP34xx_ProdID_SKUID 0x4830A20C
+#define OMAP3_SYSCON_BASE (0x4800 + 0x2000 + 0x270)
+
#define VERSION_COUNT 2
struct ti_cpufreq_data;
@@ -84,6 +89,13 @@ static unsigned long dra7_efuse_xlate(struct ti_cpufreq_data
*opp_data,
return calculated_efuse;
}
+static unsigned long omap3_efuse_xlate(struct ti_cpufreq_data *opp_data,
+ unsigned long efuse)
+{
+ /* OPP enable bit ("Speed Binned") */
+ return BIT(efuse);
+}
+
static struct ti_cpufreq_soc_data am3x_soc_data = {
.efuse_xlate = amx3_efuse_xlate,
.efuse_fallback = AM33XX_800M_ARM_MPU_MAX_FREQ,
@@ -111,6 +123,56 @@ static struct ti_cpufreq_soc_data dra7_soc_data = {
.multi_regulator = true,
};
+/*
+ * OMAP35x TRM (SPRUF98K):
+ * CONTROL_IDCODE (0x4830 A204) describes Silicon revisions.
+ * Control OMAP Status Register 15:0 (Address 0x4800 244C)
+ *to separate between omap3503, omap3515, omap3525, omap3530
+ *and feature presence.
+ *There are encodings for versions limited to 400/266MHz
+ *but we ignore.
+ *Not clear if this also holds for omap34xx.
+ * some eFuse values e.g. CONTROL_FUSE_OPP1_VDD1
+ *are stored in the SYSCON register range
+ * Register 0x4830A20C [ProdID.SKUID] [0:3]
+ *0x0 for normal 600/430MHz device.
+ *0x8 for 720/520MHz device.
+ *Not clear what omap34xx value is.
+ */
+
+static struct ti_cpufreq_soc_data omap34xx_soc_data = {
+ .efuse_xlate = omap3_efuse_xlate,
+ .efuse_offset = OMAP34xx_ProdID_SKUID - OMAP3_SYSCON_BASE,
+ .efuse_shift = 3,
+ .efuse_mask = BIT(3),
+ .rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
+ .multi_regulator = false,
+};
+
+/*
+ * AM/DM37x TRM (SPRUGN4M)
+ * CONTROL_IDCODE (0x4830 A204) describes Silicon revisions.
+ * Control Device Status Register 15:0 (Address 0x4800 244C)
+ *to separate between am3703, am3715, dm3725, dm3730
+ *and feature presence.
+ * Speed Binned = Bit 9
+ * 0 800/600 MHz
+ * 1 1000/800 MHz
+ * some eFuse values e.g. CONTROL_FUSE_OPP 1G_VDD1
+ *are stored in the SYSCON register range.
+ * There is no 0x4830A20C [ProdID.SKUID] register (exists but
+ *seems to always read as 0).
+ */
+
+static struct ti_cpufreq_soc_data omap36xx_soc_data = {
+ .efuse_xlate = omap3_efuse_xlate,
+ .efuse_offset = OMAP3_CONTROL_DEVICE_STATUS - OMAP3_SYSCON_BASE,
+ .efuse_shift = 9,
+ .efuse_mask = BIT(9),
+ .rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
+ .multi_regulator = false,
+};
+
/**
* ti_cpufreq_get_efuse() - Parse and return efuse value present on SoC
* @opp_data: pointer to ti_cpufreq_data context
@@ -127,7 +189,17 @@ static int ti_cpufreq_get_efuse(struct ti_cpufreq_data
*opp_data,
ret = regmap_read(opp_data->syscon, opp_data->soc_data->efuse_offset,
&efuse);
- if (ret) {
+ if (ret == -EIO) {
+ /* not a syscon register! */
+ void __iomem *regs = ioremap(OMAP3_SYSCON_BASE +
+ opp_data->soc_data->efuse_offset, 4);
+
+ if (!regs)
+ return -ENOMEM;
+ efuse = readl(regs);
+ iounmap(regs);
+ }
+ else if
[PATCH 4/4] DTS: bindings: omap: update bindings documentation
* clarify that we now need either "ti,omap3430" or "ti,omap3630" or "ti,am3517" for omap3 chips * clarify that "ti,omap3" has no default * clarify that AM33x is not an "ti,omap3" * clarify that the list of boards is incomplete * remove some "ti,am33xx", "ti,omap3" * add some missing "ti,omap4" Signed-off-by: H. Nikolaus Schaller Acked-by: Tony Lindgren --- .../devicetree/bindings/arm/omap/omap.txt | 30 +++ 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index b301f753ed2c..e77635c5422c 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -43,7 +43,7 @@ SoC Families: - OMAP2 generic - defaults to OMAP2420 compatible = "ti,omap2" -- OMAP3 generic - defaults to OMAP3430 +- OMAP3 generic compatible = "ti,omap3" - OMAP4 generic - defaults to OMAP4430 compatible = "ti,omap4" @@ -51,6 +51,8 @@ SoC Families: compatible = "ti,omap5" - DRA7 generic - defaults to DRA742 compatible = "ti,dra7" +- AM33x generic + compatible = "ti,am33xx" - AM43x generic - defaults to AM4372 compatible = "ti,am43" @@ -63,12 +65,14 @@ SoCs: - OMAP3430 compatible = "ti,omap3430", "ti,omap3" + legacy: "ti,omap34xx" - please do not use any more - AM3517 compatible = "ti,am3517", "ti,omap3" - OMAP3630 - compatible = "ti,omap36xx", "ti,omap3" -- AM33xx - compatible = "ti,am33xx", "ti,omap3" + compatible = "ti,omap3630", "ti,omap3" + legacy: "ti,omap36xx" - please do not use any more +- AM335x + compatible = "ti,am33xx" - OMAP4430 compatible = "ti,omap4430", "ti,omap4" @@ -110,19 +114,19 @@ SoCs: - AM4372 compatible = "ti,am4372", "ti,am43" -Boards: +Boards (incomplete list of examples): - OMAP3 BeagleBoard : Low cost community board - compatible = "ti,omap3-beagle", "ti,omap3" + compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3" - OMAP3 Tobi with Overo : Commercial expansion board with daughter board - compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3" + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3" - OMAP4 SDP : Software Development Board - compatible = "ti,omap4-sdp", "ti,omap4430" + compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4" - OMAP4 PandaBoard : Low cost community board - compatible = "ti,omap4-panda", "ti,omap4430" + compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4" - OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4"; @@ -134,16 +138,16 @@ Boards: compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4"; - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x - compatible = "ti,omap3-evm", "ti,omap3" + compatible = "ti,omap3-evm", "ti,omap3630", "ti,omap3" - AM335X EVM : Software Development Board for AM335x - compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3" + compatible = "ti,am335x-evm", "ti,am33xx" - AM335X Bone : Low cost community board - compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3" + compatible = "ti,am335x-bone", "ti,am33xx" - AM3359 ICEv2 : Low cost Industrial Communication Engine EVM. - compatible = "ti,am3359-icev2", "ti,am33xx", "ti,omap3" + compatible = "ti,am3359-icev2", "ti,am33xx" - AM335X OrionLXm : Substation Automation Platform compatible = "novatech,am335x-lxm", "ti,am33xx" -- 2.19.1
[PATCH 2/4] ARM: dts: replace opp-v1 tables by opp-v2 for omap34xx and omap36xx
In addition, move omap3 from whitelist to blacklist in cpufreq-dt-platdev
in the same patch, because doing either first breaks operation and
may make trouble in bisect.
We also can remove opp-v1 table for omap3-n950-n9 since it is now
automatically detected.
We also fix a wrong OPP4 voltage for omap3430 which must be
0.6V + 54*12.5mV = 1275mV. Otherwise the twl4030 driver will reject
this OPP.
Signed-off-by: H. Nikolaus Schaller
Acked-by: Tony Lindgren
---
arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 ---
arch/arm/boot/dts/omap34xx.dtsi | 65
arch/arm/boot/dts/omap36xx.dtsi | 53 +++
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +-
4 files changed, 102 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 5441e9ffdbb4..e98b0c615f19 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -11,13 +11,6 @@
cpus {
cpu@0 {
cpu0-supply = <&vcc>;
- operating-points = <
- /* kHzuV */
- 30 1012500
- 60 120
- 80 1325000
- 100 1375000
- >;
};
};
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index f572a477f74c..91154829f86a 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -16,19 +16,66 @@
/ {
cpus {
cpu: cpu@0 {
- /* OMAP343x/OMAP35xx variants OPP1-5 */
- operating-points = <
- /* kHzuV */
- 125000 975000
- 25 1075000
- 50 120
- 55 127
- 60 135
- >;
+ /* OMAP343x/OMAP35xx variants OPP1-6 */
+ operating-points-v2 = <&cpu0_opp_table>;
+
clock-latency = <30>; /* From legacy driver */
};
};
+ /* see Documentation/devicetree/bindings/opp/opp.txt */
+ cpu0_opp_table: opp-table {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ opp1-12500 {
+ opp-hz = /bits/ 64 <12500>;
+ /*
+* we currently only select the max voltage from table
+* Table 3-3 of the omap3530 Data sheet (SPRS507F).
+* Format is:
+*/
+ opp-microvolt = <975000 975000 975000>;
+ /*
+* first value is silicon revision bit mask
+* second one 720MHz Device Identification bit mask
+*/
+ opp-supported-hw = <0x 3>;
+ };
+
+ opp2-25000 {
+ opp-hz = /bits/ 64 <25000>;
+ opp-microvolt = <1075000 1075000 1075000>;
+ opp-supported-hw = <0x 3>;
+ opp-suspend;
+ };
+
+ opp3-5 {
+ opp-hz = /bits/ 64 <5>;
+ opp-microvolt = <120 120 120>;
+ opp-supported-hw = <0x 3>;
+ };
+
+ opp4-55000 {
+ opp-hz = /bits/ 64 <55000>;
+ opp-microvolt = <1275000 1275000 1275000>;
+ opp-supported-hw = <0x 3>;
+ };
+
+ opp5-6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <135 135 135>;
+ opp-supported-hw = <0x 3>;
+ };
+
+ opp6-72000 {
+ opp-hz = /bits/ 64 <72000>;
+ opp-microvolt = <135 135 135>;
+ /* only high-speed grade omap3530 devices */
+ opp-supported-hw = <0x 2>;
+ };
+ };
+
ocp@6800 {
omap3_pmx_core2: pinmux@480025d8 {
compatible = "ti,omap3-padconf", "pinctrl-single";
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 6fb23ada1f64..44f25b0eb45b 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -19,15 +19,52 @@
};
cpus {
- /* OMAP3630/OMAP37xx 'standard device' variants OPP50 to OPP130
*/
+
[PATCH 3/4] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap3630 or ti,am3517
For the ti-cpufreq driver we need a clear separation between omap34 and omap36
families
since they have different silicon revisions and efuses.
So far ti,omap3630/ti,omap36xx is just an additional flag to ti,omap3 while
omap34 has no
required entry.
Therefore we can not match omap34 boards properly.
This needs to add ti,omap3430 and ti,omap3630 where it is missing.
We also clean up some instances of missing ti,am3517 so that we can rely on
seeing either one of:
ti,am3517
ti,omap3430
ti,omap3630
in addition to ti,omap3.
We leave ti,omap34xx and ti,omap36xx untouched for compatibility.
The script to do the conversion is:
manually fix am3517_mt_ventoux.dts
find arch/arm/boot/dts -name '*.dts*' -exec fgrep -q '"ti,omap34xx"' {} \; !
-exec fgrep -q '"ti,omap3430"' {} \; -exec sed -i ''
's/"ti,omap34xx"/"ti,omap3430", "ti,omap34xx"/' {} \;
find arch/arm/boot/dts -name '*.dts*' -exec fgrep -q '"ti,omap36xx"' {} \; !
-exec fgrep -q '"ti,omap3630"' {} \; -exec sed -i ''
's/"ti,omap36xx"/"ti,omap3630", "ti,omap36xx"/' {} \;
find arch/arm/boot/dts \( -name 'omap*.dts*' -o -name 'logic*.dts*' \) -exec
fgrep -q '"ti,omap3"' {} \; ! -exec fgrep -q '"ti,omap3630"' {} \; ! -exec
fgrep -q '"ti,omap36xx"' {} \; ! -exec fgrep -q '"ti,am3517"' {} \; ! -exec
fgrep -q '"ti,omap34xx"' {} \; ! -exec fgrep -q '"ti,omap3430"' {} \; -exec sed
-i '' 's/"ti,omap3"/"ti,omap3430", "ti,omap3"/' {} \;
So if your out-of-tree omap3 board does not show any OPPs, please check
the compatibility entry and update if needed.
Signed-off-by: H. Nikolaus Schaller
Acked-by: Tony Lindgren
---
arch/arm/boot/dts/am3517_mt_ventoux.dts| 2 +-
arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts | 2 +-
arch/arm/boot/dts/logicpd-torpedo-35xx-devkit.dts | 2 +-
arch/arm/boot/dts/omap3-beagle-xm.dts | 2 +-
arch/arm/boot/dts/omap3-beagle.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3530.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3730.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000-lcd43.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000-lcd70.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000.dts | 2 +-
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
arch/arm/boot/dts/omap3-ha-lcd.dts | 2 +-
arch/arm/boot/dts/omap3-ha.dts | 2 +-
arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 2 +-
arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 2 +-
arch/arm/boot/dts/omap3-igep0030.dts | 2 +-
arch/arm/boot/dts/omap3-ldp.dts| 2 +-
arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 2 +-
arch/arm/boot/dts/omap3-lilly-dbb056.dts | 2 +-
arch/arm/boot/dts/omap3-n9.dts | 2 +-
arch/arm/boot/dts/omap3-n950.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-alto35.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-gallop43.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-palo35.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-palo43.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-summit.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-tobiduo.dts| 2 +-
arch/arm/boot/dts/omap3-pandora-1ghz.dts | 2 +-
arch/arm/boot/dts/omap3-sbc-t3530.dts | 2 +-
arch/arm/boot/dts/omap3-sbc-t3730.dts | 2 +-
arch/arm/boot/dts/omap3-sniper.dts | 2 +-
arch/arm/boot/dts/omap3-thunder.dts| 2 +-
arch/arm/boot/dts/omap3-zoom3.dts | 2 +-
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
37 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/arch/arm/boot/dts/am3517_mt_ventoux.dts
b/arch/arm/boot/dts/am3517_mt_ventoux.dts
index e507e4ae0d88..e7d7124a34ba 100644
--- a/arch/arm/boot/dts/am3517_mt_ventoux.dts
+++ b/arch/arm/boot/dts/am3517_mt_ventoux.dts
@@ -8,7 +8,7 @@
/ {
model = "TeeJet Mt.Ventoux";
- compatible = "teejet,mt_ventoux", "ti,omap3";
+ compatible = "teejet,mt_ventoux", "ti,am3517", "ti,omap3";
memory@8000 {
device_type = "memory";
diff --git a/arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts
b/arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts
index f7a841a28865..2a0a98fe67f0 100644
--- a/arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts
@@ -9,5 +9,5 @@
/ {
model = "LogicPD Zoom OMAP35xx SOM-LV Development Kit";
- compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3";
+ compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3430", "ti,omap3";
};
diff --git a/arch/arm/boot/dts/logicpd-torpedo-35xx-devkit.dts
b/arch/arm/boot/dts/logicpd-torpedo-35xx-devkit.dts
index 7675bc3fa868..57bae2aa910e 100644
--- a/arch/arm/boot/dts/logicpd-
