Re: possible deadlock in console_unlock
On (02/16/19 16:21), Sergey Senozhatsky wrote: > On (02/16/19 14:36), Yao HongBo wrote: > > hi, sergey: > > > > As shown in that link, https://lkml.org/lkml/2018/6/6/397 > > > > On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in > > console_unlock' > > bug for several times in my environment. > > > > This solution fixes things for me. Do you have a plan to submit patches to > > solve this problem. > > > > diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c > > __printk_safe_enter(); > > kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC); > > __printk_safe_exit(); > > I would probably try the following: Yao HongBo, could you please post the lockdep splat? GFP_NOWARN is probably the best option for now. Yes, it, maybe, will not work for fault-injection cases; but printk_safe approach is harder to push for, especially given that printk_safe maybe will not even exist in the future. -ss
Re: [PATCH] ata: fix a race condition when internal cmd time out
Hello! On 16.02.2019 6:42, Jason Yan wrote: For internal cmds, we will unmap DMA memory associated with the cmd before we abort the cmd. If DMA transfering data before the aborting, Transferring. bus error will occured. Occur. ata_exec_internal_sg ->ata_port_freeze if timeout ->ata_qc_complete ->ata_sg_clean dma transfering data = bus error ->ap->ops->post_internal_cmd ->sas_ata_post_internal ->sas_ata_internal_abort ->abort the cmd Fix this by move post_internal_cmd() before unmapping the DMA memory Moving. when time out. Notice that we have to set ATA_QCFLAG_FAILED flag before calling post_internal_cmd() so that the aborting will work. Reported-by: luojian Signed-off-by: Jason Yan [...] MBR, Sergei
linux-next: Fixes tag needs some work in the kvm tree
Hi all,
In commit
aa8359972cfc ("KVM: x86/mmu: Differentiate between nr zapped and list
unstable")
Fixes tag
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return
has these problem(s):
- Subject has leading but no trailing quotes
Please do not split Fixes tags over more than one line
In commit
4d3f8e4ff75e ("kvm: vmx: Fix typos in vmentry/vmexit control setting")
Fixes tag
Fixes: 'commit f99e3daf94ff ("KVM: x86: Add Intel PT virtualization work
mode")'
has these problem(s):
- No SHA1 recognised
The leading word 'commit' is unexpected and the surrounding single
quotes likewise.
Please just use
git log -1 --format='Fixes: %h ("%s")'
--
Cheers,
Stephen Rothwell
pgp_Gkh89_nDl.pgp
Description: OpenPGP digital signature
Re: possible deadlock in console_unlock
On (02/16/19 14:36), Yao HongBo wrote: > hi, sergey: > > As shown in that link, https://lkml.org/lkml/2018/6/6/397 > > On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in > console_unlock' > bug for several times in my environment. > > This solution fixes things for me. Do you have a plan to submit patches to > solve this problem. > > diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c > __printk_safe_enter(); > kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC); > __printk_safe_exit(); I would probably try the following: --- diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c index ec145a59f199..058d004dcbaa 100644 --- a/drivers/tty/tty_buffer.c +++ b/drivers/tty/tty_buffer.c @@ -172,7 +172,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size) have queued and recycle that ? */ if (atomic_read(>buf.mem_used) > port->buf.mem_limit) return NULL; - p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC); + p = kmalloc(sizeof(struct tty_buffer) + 2 * size, + GFP_ATOMIC | __GFP_NOWARN); if (p == NULL) return NULL;
[PATCH -next] drm/bridge: cdns: Remove set but not used variable 'bpp'
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/bridge/cdns-dsi.c: In function 'cdns_dsi_bridge_enable': drivers/gpu/drm/bridge/cdns-dsi.c:986:6: warning: variable 'bpp' set but not used [-Wunused-but-set-variable] It never used since introduction. Signed-off-by: YueHaibing --- drivers/gpu/drm/bridge/cdns-dsi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c b/drivers/gpu/drm/bridge/cdns-dsi.c index 6166dca6be81..07ee1685fdfe 100644 --- a/drivers/gpu/drm/bridge/cdns-dsi.c +++ b/drivers/gpu/drm/bridge/cdns-dsi.c @@ -785,13 +785,12 @@ static void cdns_dsi_bridge_enable(struct drm_bridge *bridge) unsigned long tx_byte_period; struct cdns_dsi_cfg dsi_cfg; u32 tmp, reg_wakeup, div; - int bpp, nlanes; + int nlanes; if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0)) return; mode = >encoder->crtc->state->adjusted_mode; - bpp = mipi_dsi_pixel_format_to_bpp(output->dev->format); nlanes = output->dev->lanes; WARN_ON_ONCE(cdns_dsi_check_conf(dsi, mode, _cfg, false));
WARNING in __vunmap
Hello, syzbot found the following crash on: HEAD commit:a048a07d7f45 powerpc/64s: Add support for a store forwardi.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1418d5a780 kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02 dashboard link: https://syzkaller.appspot.com/bug?extid=5ec9bb042ddfe9644773 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5ec9bb042ddfe9644...@syzkaller.appspotmail.com [ cut here ] Trying to vfree() nonexistent vm area (94b55709) WARNING: CPU: 1 PID: 8605 at mm/vmalloc.c:1525 __vunmap+0x324/0x3c0 mm/vmalloc.c:1524 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 8605 Comm: syz-executor7 Not tainted 4.17.0-rc6+ #63 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+0x1b9/0x294 lib/dump_stack.c:113 panic+0x22f/0x4de kernel/panic.c:184 __warn.cold.8+0x163/0x1b3 kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992 RIP: 0010:__vunmap+0x324/0x3c0 mm/vmalloc.c:1524 RSP: 0018:88018273f2b0 EFLAGS: 00010286 RAX: 0038 RBX: RCX: c90003ed8000 RDX: 3b55 RSI: 81610961 RDI: 88018273ee10 RBP: 88018273f2f0 R08: 8801ab1a0340 R09: 0006 R10: 8801ab1a0340 R11: R12: c90014122000 R13: 0001 R14: fbfff12f7f76 R15: 60fe24e7fae8 vfree+0x68/0x100 mm/vmalloc.c:1606 ipcomp_free_scratches+0xbb/0x150 net/xfrm/xfrm_ipcomp.c:216 ipcomp_free_data net/xfrm/xfrm_ipcomp.c:325 [inline] ipcomp_init_state+0x8cf/0xc00 net/xfrm/xfrm_ipcomp.c:377 ipcomp4_init_state+0x110/0xb30 net/ipv4/ipcomp.c:137 __xfrm_init_state+0x60e/0x1030 net/xfrm/xfrm_state.c:2277 xfrm_init_state+0x1e/0x80 net/xfrm/xfrm_state.c:2303 pfkey_msg2xfrm_state net/key/af_key.c:1307 [inline] pfkey_add+0x1c86/0x2eb0 net/key/af_key.c:1524 pfkey_process+0x83d/0x980 net/key/af_key.c:2844 pfkey_sendmsg+0x5f4/0x1050 net/key/af_key.c:3683 sock_sendmsg_nosec net/socket.c:629 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:639 ___sys_sendmsg+0x805/0x940 net/socket.c:2117 __sys_sendmsg+0x115/0x270 net/socket.c:2155 __do_sys_sendmsg net/socket.c:2164 [inline] __se_sys_sendmsg net/socket.c:2162 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x455a09 RSP: 002b:7fe6fd709c68 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 7fe6fd70a6d4 RCX: 00455a09 RDX: RSI: 20f56000 RDI: 0014 RBP: 0072bea0 R08: R09: R10: R11: 0246 R12: R13: 059d R14: 006fc758 R15: Dumping ftrace buffer: (ftrace buffer empty) 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#bug-status-tracking for how to communicate with syzbot.
INFO: task hung in __flush_work
Hello,
syzbot found the following crash on:
HEAD commit:90cadbbf341d Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10a565c740
kernel config: https://syzkaller.appspot.com/x/.config?x=9d41c8529d7e7362
dashboard link: https://syzkaller.appspot.com/bug?extid=aa0b64a57e300a1c6bcc
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a6629b40
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1222d29b40
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+aa0b64a57e300a1c6...@syzkaller.appspotmail.com
TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
cookies. Check SNMP counters.
INFO: task syz-executor925:7871 blocked for more than 140 seconds.
Not tainted 4.20.0-rc7+ #360
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor925 D19912 7871 7870 0x0004
Call Trace:
context_switch kernel/sched/core.c:2831 [inline]
__schedule+0x86c/0x1ed0 kernel/sched/core.c:3472
schedule+0xfe/0x460 kernel/sched/core.c:3516
schedule_timeout+0x1cc/0x260 kernel/time/timer.c:1780
do_wait_for_common kernel/sched/completion.c:83 [inline]
__wait_for_common kernel/sched/completion.c:104 [inline]
wait_for_common kernel/sched/completion.c:115 [inline]
wait_for_completion+0x427/0x8a0 kernel/sched/completion.c:136
__flush_work+0x59c/0x9b0 kernel/workqueue.c:2917
__cancel_work_timer+0x4ba/0x820 kernel/workqueue.c:3004
cancel_delayed_work_sync+0x1a/0x20 kernel/workqueue.c:3136
tls_sw_free_resources_tx+0x1df/0xcf0 net/tls/tls_sw.c:1795
tls_sk_proto_close+0x602/0x750 net/tls/tls_main.c:280
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:458
__sock_release+0xd7/0x250 net/socket.c:579
sock_close+0x19/0x20 net/socket.c:1141
__fput+0x385/0xa30 fs/file_table.c:278
fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x401010
Code: 01 f0 ff ff 0f 83 b0 0a 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 83 3d bd 16 2d 00 00 75 14 b8 03 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 84 0a 00 00 c3 48 83 ec 08 e8 3a 01 00 00
RSP: 002b:7ffec7856f48 EFLAGS: 0246 ORIG_RAX: 0003
RAX: RBX: 0004 RCX: 00401010
RDX: e0ff RSI: 25c0 RDI: 0004
RBP: R08: R09:
R10: R11: 0246 R12: 00401f20
R13: 00401fb0 R14: R15:
Showing all locks held in the system:
2 locks held by kworker/0:0/5:
#0: 6d11dec0 ((wq_completion)"events"){+.+.}, at:
__write_once_size include/linux/compiler.h:218 [inline]
#0: 6d11dec0 ((wq_completion)"events"){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 6d11dec0 ((wq_completion)"events"){+.+.}, at: atomic64_set
include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 6d11dec0 ((wq_completion)"events"){+.+.}, at: atomic_long_set
include/asm-generic/atomic-long.h:59 [inline]
#0: 6d11dec0 ((wq_completion)"events"){+.+.}, at: set_work_data
kernel/workqueue.c:617 [inline]
#0: 6d11dec0 ((wq_completion)"events"){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 6d11dec0 ((wq_completion)"events"){+.+.}, at:
process_one_work+0xb43/0x1c40 kernel/workqueue.c:2124
#1: ccfe6c9a
((work_completion)(&(_ctx_tx->tx_work.work)->work)){+.+.}, at:
process_one_work+0xb9a/0x1c40 kernel/workqueue.c:2128
1 lock held by khungtaskd/1014:
#0: 153ed952 (rcu_read_lock){}, at:
debug_show_all_locks+0xd0/0x424 kernel/locking/lockdep.c:4379
1 lock held by rsyslogd/7757:
#0: 34b64696 (>f_pos_lock){+.+.}, at: __fdget_pos+0x1bb/0x200
fs/file.c:766
2 locks held by getty/7847:
#0: d063ffb7 (>ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 45d4d183 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/7848:
#0: dda11696 (>ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: a02eb135 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/7849:
#0: 13f4e4e1 (>ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1:
general protection fault in rt_cache_valid
Hello, syzbot found the following crash on: HEAD commit:b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1582bc30c0 kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76 dashboard link: https://syzkaller.appspot.com/bug?extid=0290d2290a607e035ba1 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+0290d2290a607e035...@syzkaller.appspotmail.com 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: 2230 Comm: syz-executor0 Not tainted 4.20.0+ #3 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:rt_cache_valid+0x85/0x250 net/ipv4/route.c:1510 Code: 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 34 92 f1 fa 48 85 db 74 4a e8 2a 92 f1 fa 48 8d 7b 3a 4c 8d 75 d8 48 89 f8 48 c1 e8 03 <42> 0f b6 14 28 48 89 f8 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 kobject: 'loop3' (2d125388): kobject_uevent_env RSP: 0018:88809b24e0a8 EFLAGS: 00010207 RAX: 0024 RBX: 00eb RCX: c90005df9000 RDX: 16a8 RSI: 869013e6 RDI: 0125 RBP: 88809b24e130 R08: 88806586e0c0 R09: ed1015ce5b90 R10: ed1015ce5b8f R11: 8880ae72dc7b R12: 111013649c15 R13: dc00 R14: 88809b24e108 R15: FS: 7f9fa034d700() GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b33722000 CR3: 8512a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __mkroute_output net/ipv4/route.c:2260 [inline] ip_route_output_key_hash_rcu+0x952/0x3470 net/ipv4/route.c:2492 kobject: 'loop3' (2d125388): fill_kobj_path: path = '/devices/virtual/block/loop3' kobject: 'loop5' (a20c7830): kobject_uevent_env ip_route_output_key_hash+0x25d/0x400 net/ipv4/route.c:2321 kobject: 'loop5' (a20c7830): fill_kobj_path: path = '/devices/virtual/block/loop5' icmp_route_lookup.constprop.0+0x458/0x18e0 net/ipv4/icmp.c:489 kobject: 'loop2' (9de45ca1): kobject_uevent_env icmp_send+0x12eb/0x1bc0 net/ipv4/icmp.c:714 kobject: 'loop2' (9de45ca1): fill_kobj_path: path = '/devices/virtual/block/loop2' ipv4_link_failure+0x2c/0x210 net/ipv4/route.c:1187 dst_link_failure include/net/dst.h:427 [inline] vti_xmit net/ipv4/ip_vti.c:229 [inline] vti_tunnel_xmit+0x85a/0x1730 net/ipv4/ip_vti.c:264 __netdev_start_xmit include/linux/netdevice.h:4382 [inline] netdev_start_xmit include/linux/netdevice.h:4391 [inline] xmit_one net/core/dev.c:3278 [inline] dev_hard_start_xmit+0x261/0xc70 net/core/dev.c:3294 kobject: 'loop2' (9de45ca1): kobject_uevent_env kobject: 'loop2' (9de45ca1): fill_kobj_path: path = '/devices/virtual/block/loop2' __dev_queue_xmit+0x2f8a/0x3a60 net/core/dev.c:3864 kobject: 'loop1' (f4ea9cf1): kobject_uevent_env kobject: 'loop1' (f4ea9cf1): fill_kobj_path: path = '/devices/virtual/block/loop1' dev_queue_xmit+0x18/0x20 net/core/dev.c:3897 neigh_direct_output+0x16/0x20 net/core/neighbour.c:1511 kobject: 'loop1' (f4ea9cf1): kobject_uevent_env neigh_output include/net/neighbour.h:508 [inline] ip_finish_output2+0xa35/0x1a00 net/ipv4/ip_output.c:229 kobject: 'loop1' (f4ea9cf1): fill_kobj_path: path = '/devices/virtual/block/loop1' ip_finish_output+0x7e4/0xf60 net/ipv4/ip_output.c:317 NF_HOOK_COND include/linux/netfilter.h:278 [inline] ip_output+0x226/0x880 net/ipv4/ip_output.c:405 dst_output include/net/dst.h:444 [inline] ip_local_out+0xc4/0x1b0 net/ipv4/ip_output.c:124 ip_send_skb+0x42/0xf0 net/ipv4/ip_output.c:1465 udp_send_skb.isra.0+0x6b2/0x1160 net/ipv4/udp.c:891 udp_sendmsg+0x2902/0x3a40 net/ipv4/udp.c:1178 udpv6_sendmsg+0x1843/0x3550 net/ipv6/udp.c:1279 kobject: 'loop4' (7ece3fce): kobject_uevent_env kobject: 'loop4' (7ece3fce): fill_kobj_path: path = '/devices/virtual/block/loop4' inet_sendmsg+0x1af/0x740 net/ipv4/af_inet.c:798 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:631 ___sys_sendmsg+0x409/0x910 net/socket.c:2116 __sys_sendmmsg+0x246/0x6f0 net/socket.c:2211 __do_sys_sendmmsg net/socket.c:2240 [inline] __se_sys_sendmmsg net/socket.c:2237 [inline] __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2237 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457ec9 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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
general protection fault in __vunmap
Hello, syzbot found the following crash on: HEAD commit:cb5b020a8d38 Revert "exec: load_script: don't blindly trun.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13c2886cc0 kernel config: https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1 dashboard link: https://syzkaller.appspot.com/bug?extid=39d3a56f2f717d237007 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+39d3a56f2f717d237...@syzkaller.appspotmail.com 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: 23956 Comm: syz-executor.3 Not tainted 5.0.0-rc6+ #72 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__vunmap+0x68/0x400 mm/vmalloc.c:1508 Code: 85 e4 0f 85 de 02 00 00 e8 45 c7 d0 ff 4c 89 ef e8 9d 82 ff ff 48 ba 00 00 00 00 00 fc ff df 48 8d 78 48 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 50 03 00 00 4c 8b 60 48 4d 85 e4 0f 84 bd 02 00 RSP: 0018:88809613f4b0 EFLAGS: 00010206 RAX: RBX: 0001 RCX: 0009 RDX: dc00 RSI: 0004 RDI: 0048 RBP: 88809613f4f0 R08: 11146d18 R09: fbfff1146d19 R10: fbfff1146d18 R11: 88a368c3 R12: R13: 004e R14: e8c71948 R15: 607f51471948 FS: 7fa9e49b6700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fc7182d2000 CR3: 4b7bb000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: vfree+0x8d/0x140 mm/vmalloc.c:1597 ipcomp_free_scratches+0xc0/0x150 net/xfrm/xfrm_ipcomp.c:216 ipcomp_free_data net/xfrm/xfrm_ipcomp.c:325 [inline] ipcomp_init_state+0x76d/0xa10 net/xfrm/xfrm_ipcomp.c:377 ipcomp6_init_state+0xc9/0x880 net/ipv6/ipcomp6.c:165 __xfrm_init_state+0x557/0xef0 net/xfrm/xfrm_state.c:2302 xfrm_init_state+0x1e/0x80 net/xfrm/xfrm_state.c:2328 pfkey_msg2xfrm_state net/key/af_key.c:1307 [inline] pfkey_add+0x1da7/0x2fd0 net/key/af_key.c:1524 pfkey_process+0x6d2/0x810 net/key/af_key.c:2844 pfkey_sendmsg+0x40b/0xbe0 net/key/af_key.c:3683 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:631 ___sys_sendmsg+0x3e2/0x930 net/socket.c:2114 __sys_sendmmsg+0x1c3/0x4e0 net/socket.c:2209 __do_sys_sendmmsg net/socket.c:2238 [inline] __se_sys_sendmmsg net/socket.c:2235 [inline] __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2235 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457e29 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fa9e49b5c78 EFLAGS: 0246 ORIG_RAX: 0133 RAX: ffda RBX: 0004 RCX: 00457e29 RDX: 04000142 RSI: 2180 RDI: 0004 RBP: 0073c040 R08: R09: R10: R11: 0246 R12: 7fa9e49b66d4 R13: 004c4dd8 R14: 004d8a70 R15: Modules linked in: kobject: 'loop4' (647dbe39): kobject_uevent_env kobject: 'loop4' (647dbe39): fill_kobj_path: path = '/devices/virtual/block/loop4' kobject: 'kvm' (78525e49): kobject_uevent_env kobject: 'kvm' (78525e49): fill_kobj_path: path = '/devices/virtual/misc/kvm' ---[ end trace 25e2186da6a07104 ]--- RIP: 0010:__vunmap+0x68/0x400 mm/vmalloc.c:1508 IPVS: ftp: loaded support on port[0] = 21 Code: 85 e4 0f 85 de 02 00 00 e8 45 c7 d0 ff 4c 89 ef e8 9d 82 ff ff 48 ba 00 00 00 00 00 fc ff df 48 8d 78 48 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 50 03 00 00 4c 8b 60 48 4d 85 e4 0f 84 bd 02 00 kobject: 'kvm' (78525e49): kobject_uevent_env kobject: 'lo' (532a5fa3): kobject_add_internal: parent: 'net', set: 'devices' kobject: 'kvm' (78525e49): fill_kobj_path: path = '/devices/virtual/misc/kvm' RSP: 0018:88809613f4b0 EFLAGS: 00010206 RAX: RBX: 0001 RCX: 0009 kobject: 'kvm' (78525e49): kobject_uevent_env kobject: 'lo' (532a5fa3): kobject_uevent_env RDX: dc00 RSI: 0004 RDI: 0048 kobject: 'kvm' (78525e49): fill_kobj_path: path = '/devices/virtual/misc/kvm' RBP: 88809613f4f0 R08: 11146d18 R09: fbfff1146d19 kobject: 'lo' (532a5fa3): fill_kobj_path: path = '/devices/virtual/net/lo' R10: fbfff1146d18 R11: 88a368c3 R12:
general protection fault in reuseport_add_sock
Hello, syzbot found the following crash on: HEAD commit:f9bcc9f3ee4f net: ethernet: freescale: set FEC ethtool reg.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=158a10f340 kernel config: https://syzkaller.appspot.com/x/.config?x=8f00801d7b7c4fe6 dashboard link: https://syzkaller.appspot.com/bug?extid=675ee297acac988852c1 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+675ee297acac98885...@syzkaller.appspotmail.com 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 kobject: 'loop2' (5809b865): kobject_uevent_env CPU: 1 PID: 14725 Comm: syz-executor.3 Not tainted 5.0.0-rc5+ #78 kobject: 'loop2' (5809b865): fill_kobj_path: path = '/devices/virtual/block/loop2' Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:reuseport_add_sock+0x187/0x8f0 net/core/sock_reuseport.c:170 Code: e8 ce 4e f2 fb 66 83 fb 01 0f 85 54 06 00 00 e8 5f 4d f2 fb 4d 8d 74 24 12 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 14 02 4c 89 f0 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 fc RSP: 0018:888066abfca0 EFLAGS: 00010202 RAX: dc00 RBX: 0001 RCX: c9000c432000 RDX: 0002 RSI: 857d8dc1 RDI: 0005 kobject: 'loop4' (b88abefc): kobject_uevent_env RBP: 888066abfd08 R08: 888064ff43c0 R09: fbfff1264fcd R10: fbfff1264fcc R11: 89327e63 R12: R13: 888098d9c800 R14: 0012 R15: kobject: 'loop4' (b88abefc): fill_kobj_path: path = '/devices/virtual/block/loop4' FS: 7f02a40cf700() GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004563fa CR3: 9ae04000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __sctp_hash_endpoint net/sctp/input.c:758 [inline] sctp_hash_endpoint+0x523/0x5d0 net/sctp/input.c:786 sctp_listen_start net/sctp/socket.c:7967 [inline] sctp_inet_listen+0x5b2/0x880 net/sctp/socket.c:8022 kobject: 'loop5' (99e34deb): kobject_uevent_env __sys_listen+0x19b/0x270 net/socket.c:1515 kobject: 'loop5' (99e34deb): fill_kobj_path: path = '/devices/virtual/block/loop5' __do_sys_listen net/socket.c:1524 [inline] __se_sys_listen net/socket.c:1522 [inline] __x64_sys_listen+0x54/0x80 net/socket.c:1522 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457e29 kobject: 'loop1' (259faa1c): kobject_uevent_env Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f02a40cec78 EFLAGS: 0246 ORIG_RAX: 0032 kobject: 'loop1' (259faa1c): fill_kobj_path: path = '/devices/virtual/block/loop1' RAX: ffda RBX: 0002 RCX: 00457e29 RDX: RSI: 00010001 RDI: 0005 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7f02a40cf6d4 R13: 004c3a2d R14: 004d6940 R15: Modules linked in: ---[ end trace 3ce5847aad8cc1f0 ]--- RIP: 0010:reuseport_add_sock+0x187/0x8f0 net/core/sock_reuseport.c:170 Code: e8 ce 4e f2 fb 66 83 fb 01 0f 85 54 06 00 00 e8 5f 4d f2 fb 4d 8d 74 24 12 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 14 02 4c 89 f0 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 fc RSP: 0018:888066abfca0 EFLAGS: 00010202 RAX: dc00 RBX: 0001 RCX: c9000c432000 RDX: 0002 RSI: 857d8dc1 RDI: 0005 RBP: 888066abfd08 R08: 888064ff43c0 R09: fbfff1264fcd R10: fbfff1264fcc R11: 89327e63 R12: R13: 888098d9c800 R14: 0012 R15: FS: 7f02a40cf700() GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004563fa CR3: 9ae04000 CR4: 001406e0 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#bug-status-tracking for how to communicate with syzbot.
possible deadlock in console_unlock
hi, sergey: As shown in that link, https://lkml.org/lkml/2018/6/6/397 On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in console_unlock' bug for several times in my environment. This solution fixes things for me. Do you have a plan to submit patches to solve this problem. diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c __printk_safe_enter(); kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC); __printk_safe_exit(); Best regards, Hongbo
Re: WARNING: refcount bug in kvm_vm_ioctl
On Fri, Feb 15, 2019 at 6:22 PM Jann Horn wrote:
>
> On Fri, Feb 15, 2019 at 6:13 PM Dmitry Vyukov wrote:
> > On Fri, Feb 15, 2019 at 6:10 PM Jann Horn wrote:
> > > On Fri, Feb 15, 2019 at 5:45 PM Dmitry Vyukov wrote:
> > > > On Fri, Feb 15, 2019 at 5:03 PM Jann Horn wrote:
> > > > > On Fri, Feb 15, 2019 at 4:40 PM Dmitry Vyukov
> > > > > wrote:
> > > > > > On Thu, Oct 11, 2018 at 4:18 PM Paolo Bonzini
> > > > > > wrote:
> > > > > > > On 10/10/2018 09:58, syzbot wrote:
> > > > > > > > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
> > > > > > > > invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
> > > > > > > > RIP: 0010:refcount_inc_checked+0x5d/0x70 lib/refcount.c:153
> > > > > > > > kvm_get_kvm arch/x86/kvm/../../../virt/kvm/kvm_main.c:766
> > > > > > > > [inline]
> > > > > > > > kvm_ioctl_create_device
> > > > > > > > arch/x86/kvm/../../../virt/kvm/kvm_main.c:2924
> > > > > > > > kvm_vm_ioctl+0xed7/0x1d40
> > > > > > > > arch/x86/kvm/../../../virt/kvm/kvm_main.c:3114
> > > > > > > > vfs_ioctl fs/ioctl.c:46 [inline]
> > > > > > > > file_ioctl fs/ioctl.c:501 [inline]
> > > > > > > > do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
> > > > > > > > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
> > > > > > > > __do_sys_ioctl fs/ioctl.c:709 [inline]
> > > > > > > > __se_sys_ioctl fs/ioctl.c:707 [inline]
> > > > > > > > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
> > > > > > > > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > > > > > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > > > > >
> > > > > > > The trace here is fairly simple, but I don't understand how this
> > > > > > > could
> > > > > > > happen.
> > > > > > >
> > > > > > > The kvm_get_kvm is done within kvm_ioctl_create_device, which is
> > > > > > > called
> > > > > > > from ioctl; the last reference cannot disappear inside a ioctl,
> > > > > > > because:
> > > > > > >
> > > > > > > 1) kvm_ioctl is called from vfs_ioctl, which does fdget and holds
> > > > > > > the fd
> > > > > > > reference until after kvm_vm_ioctl returns
> > > > > > >
> > > > > > > 2) the file descriptor holds one reference to the struct kvm*,
> > > > > > > and this
> > > > > > > reference is not released until kvm_vm_release is called by the
> > > > > > > last
> > > > > > > fput (which could be fdput's call to fput if the process has
> > > > > > > exited in
> > > > > > > the meanwhile)
> > > > > > >
> > > > > > > 3) for completeness, in case anon_inode_getfd fails,
> > > > > > > put_unused_fd will
> > > > > > > not invoke the file descriptor's ->release callback (in this case
> > > > > > > kvm_device_release).
> > > > > > >
> > > > > > > CCing some random people to get their opinion...
> > > > > > >
> > > > > > > Paolo
> > > > > >
> > > > > >
> > > > > > Jann, is it what you fixed in "kvm: fix kvm_ioctl_create_device()
> > > > > > reference counting (CVE-2019-6974)"?
> > > > > > If so, we need to close the syzbot bug.
> > > > > >
> > > > > >
> > > > > > > > # See https://goo.gl/kgGztJ for information about syzkaller
> > > > > > > > reproducers.
> > > > > > > > #{"threaded":true,"collide":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"tun":true,"tmpdir":true,"cgroups":true,"netdev":true,"resetnet":true,"segv":true}
> > > > > > > > r0 = openat$kvm(0xff9c,
> > > > > > > > &(0x7f000380)='/dev/kvm\x00', 0x0, 0x0)
> > > > > > > > r1 = syz_open_dev$dspn(&(0x7f000100)='/dev/dsp#\x00',
> > > > > > > > 0x3fe, 0x400)
> > > > > > > > r2 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
> > > > >
> > > > > Here we create a VM fd...
> > > > >
> > > > > > > > perf_event_open(&(0x7f40)={0x1, 0x70, 0x0, 0x0, 0x0,
> > > > > > > > 0x0, 0x0, 0x50d}, 0x0, 0x, 0x,
> > > > > > > > 0x0)
> > > > > > > > mincore(&(0x7fffc000/0x1000)=nil, 0x1000,
> > > > > > > > &(0x7f0003c0)=""/4096)
> > > > > > > > setrlimit(0x0, &(0x7f00))
> > > > > > > > readahead(r1, 0x3, 0x9a6)
> > > > > > > > ioctl$KVM_CREATE_DEVICE(r2, 0xc00caee0, &(0x7f0002c0)={0x4})
> > > > >
> > > > > ... and here we do the KVM_CREATE_DEVICE ioctl with
> > > > > type==KVM_DEV_TYPE_VFIO.
> > > > >
> > > > > So that far it looks exactly like CVE-2019-6974. But CVE-2019-6974
> > > > > also requires that someone calls close() on the file descriptor of the
> > > > > newly created device very quickly, before the ioctl is able to
> > > > > increment the refcount further, and I don't see anything like that
> > > > > here. Is there a chance that syzkaller called close() on a file
> > > > > descriptor while the ioctl() was still running without saying so here
> > > > > (potentially through dup2() or something like that)?
> > > >
> > > > Yes, all fd's are closed at the end of the test:
> > > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L2561-L2568
> > >
> > > Can that happen before the ioctl() has finished?
> >
> > Yes, ioctl runs in a separate thread.
>
> Alright, then yes, it looks like the same
Re: next/master boot bisection: next-20190215 on beaglebone-black
Hi Andrew, On Fri, 15 Feb 2019 11:00:24 -0800 Andrew Morton wrote: > > On Fri, 15 Feb 2019 18:51:51 + Mark Brown wrote: > > > On Fri, Feb 15, 2019 at 10:43:25AM -0800, Andrew Morton wrote: > > > On Fri, 15 Feb 2019 10:20:10 -0800 (PST) "kernelci.org bot" > > > wrote: > > > > > > Details:https://kernelci.org/boot/id/5c666ea959b514b017fe6017 > > > > Plain log: > > > > https://storage.kernelci.org//next/master/next-20190215/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-7/lab-collabora/boot-am335x-boneblack.txt > > > > HTML log: > > > > https://storage.kernelci.org//next/master/next-20190215/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-7/lab-collabora/boot-am335x-boneblack.html > > > > > > > > > Thanks. > > > > > But what actually went wrong? Kernel doesn't boot? > > > > The linked logs show the kernel dying early in boot before the console > > comes up so yeah. There should be kernel output at the bottom of the > > logs. > > OK, thanks. > > Well, we have a result. Stephen, can we please drop > mm-shuffle-default-enable-all-shuffling.patch for now? Dropped. -- Cheers, Stephen Rothwell pgpHqYHxvuEsT.pgp Description: OpenPGP digital signature
Re: [PATCH] gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime
On Fri, Feb 15, 2019 at 11:01:04AM -0500, Alex Deucher wrote:
> On Fri, Feb 15, 2019 at 10:39 AM Rafael J. Wysocki wrote:
> > On HP ProBook 4540s, if PM-runtime is enabled in the radeon driver
> > and the direct-complete optimization is used for the radeon device
> > during system-wide suspend, the system doesn't resume.
> >
> > Preventing direct-complete from being used with the radeon device by
> > setting the DPM_FLAG_NEVER_SKIP driver flag for it makes the problem
> > go away, which indicates that direct-complete is not safe for the
> > radeon driver in general and should not be used with it (at least
> > for now).
> >
> > This fixes a regression introduced by commit c62ec4610c40
> > ("PM / core: Fix direct_complete handling for devices with no
> > callbacks") which allowed direct-complete to be applied to
> > devices without PM callbacks (again) which in turn unlocked
> > direct-complete for radeon on HP ProBook 4540s.
>
> Do other similar drivers like amdgpu and nouveau need the same fix?
> I'm not too familiar with the direct_complete feature in general.
direct_complete means that a discrete GPU which is in D3cold upon
entering system sleep is left as is, i.e. it is not woken. It is
also expected to still be in D3cold when resuming from system sleep
from the PM core's point of view. (If it is in D0uninitialized, the
GPU's driver needs to ensure it is transitioned to D3cold again.)
I know for a fact that resuming the discrete GPU is not necessary
on my MacBook Pro with Nvidia GPU. I'd expect those with AMD GPUs
to behave the same. The apple-gmux driver takes care of putting
the GPU into D3cold on resume from system sleep if it was in D3cold
when entering system sleep (see drivers/platform/x86/apple-gmux.c,
gmux_resume()).
I think it is desirable to use direct_complete because it saves power
(no need to gratuitously wake the GPU upon entering system sleep,
only to immediately cut its power) and it also speeds up the suspend
process by about half a second.
The root cause on the HP ProBook 4540s needs to be debugged, I'd
suspect a BIOS issue which could be adressed by a quirk, either for
this particular machine or for a certain class of devices (e.g. all
machines which use PR3 to transition to D3cold) if that is necessary
to behave identically to Windows. Or maybe the atpx vga_switcheroo
handler needs to be amended to put the GPU into D3cold on resume from
system sleep if it was runtime suspended before.
Is this machine using s2idle or does it suspend to S3?
Thanks,
Lukas
> > Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices
> > with no callbacks")
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=201519
> > Reported-by: ??
> > Tested-by: ??
> > Signed-off-by: Rafael J. Wysocki
> > ---
> > drivers/gpu/drm/radeon/radeon_kms.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > Index: linux-pm/drivers/gpu/drm/radeon/radeon_kms.c
> > ===
> > --- linux-pm.orig/drivers/gpu/drm/radeon/radeon_kms.c
> > +++ linux-pm/drivers/gpu/drm/radeon/radeon_kms.c
> > @@ -172,6 +172,7 @@ int radeon_driver_load_kms(struct drm_de
> > }
> >
> > if (radeon_is_px(dev)) {
> > + dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NEVER_SKIP);
> > pm_runtime_use_autosuspend(dev->dev);
> > pm_runtime_set_autosuspend_delay(dev->dev, 5000);
> > pm_runtime_set_active(dev->dev);
[PATCH -next] platform/chrome: Make function wilco_ec_transfer() static
Fixes the following sparse warning:
drivers/platform/chrome/wilco_ec/mailbox.c:126:5: warning:
symbol 'wilco_ec_transfer' was not declared. Should it be static?
Fixes: 436dad4fda10 ("platform/chrome: Add new driver for Wilco EC")
Signed-off-by: Wei Yongjun
---
drivers/platform/chrome/wilco_ec/mailbox.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/chrome/wilco_ec/mailbox.c
b/drivers/platform/chrome/wilco_ec/mailbox.c
index c7028488e575..f6ff29a11f1a 100644
--- a/drivers/platform/chrome/wilco_ec/mailbox.c
+++ b/drivers/platform/chrome/wilco_ec/mailbox.c
@@ -123,8 +123,9 @@ static void wilco_ec_prepare(struct wilco_ec_message *msg,
* Context: ec->mailbox_lock should be held while using this function.
* Return: number of bytes received or negative error code on failure.
*/
-int wilco_ec_transfer(struct wilco_ec_device *ec, struct wilco_ec_message *msg,
- struct wilco_ec_request *rq)
+static int wilco_ec_transfer(struct wilco_ec_device *ec,
+struct wilco_ec_message *msg,
+struct wilco_ec_request *rq)
{
struct wilco_ec_response *rs;
u8 checksum;
Re: [Lsf-pc] [LSF/MM TOPIC] The end of the DAX experiment
On Thu, Feb 14, 2019 at 12:20:11PM -0800, Dan Williams wrote: > On Thu, Feb 14, 2019 at 12:09 PM Matthew Wilcox wrote: > > > > On Thu, Feb 14, 2019 at 11:31:24AM -0800, Dan Williams wrote: > > > On Thu, Feb 14, 2019 at 11:10 AM Jerome Glisse wrote: > > > > I am just again working on my struct page mapping patchset as well as > > > > the generic page write protection that sits on top. I hope to be able > > > > to post the v2 in couple weeks. You can always look at my posting last > > > > year to see more details. > > > > > > Yes, I have that in mind as one of the contenders. However, it's not > > > clear to me that its a suitable fit for filesystem-reflink. Others > > > have floated the 'page proxy' idea, so it would be good to discuss the > > > merits of the general approaches. > > > > ... and my preferred option of putting pfn entries in the page cache. > > Another option to include the discussion. > > > Or is that what you meant by "page proxy"? > > Page proxy would be an object that a filesystem could allocate to > point back to a single physical 'struct page *'. The proxy would > contain an override for page->index. Needs to override page->mapping, potentially the page flags, what happens when someone takes a gup reference to the proxy structure, etc? Besides, didn't we discuss all this last year? how about we start with a summary of all the options considered last year, the pros and cons, etc, and then go from there? Regurgitating everything we've already talked about last year doesn't seem particularly useful to me... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH net-next v3 0/9] net: Get rid of switchdev_port_attr_get()
On 2/15/2019 8:55 PM, Florian Fainelli wrote: > Hi all, > > This patch series splits the removal of the switchdev_ops that was > proposed a few times before and first tackles the easy part which is the > removal of the single call to switchdev_port_attr_get() within the > bridge code. > > As suggestd by Ido, this patch series adds a > SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS which is used in the same > context as the caller of switchdev_port_attr_set(), so not deferred, and > then the operation is carried out in deferred context with setting a > support bridge port flag. > > Follow-up patches will do the switchdev_ops removal after introducing > the proper helpers for the switchdev blocking notifier to work across > stacked devices (unlike the previous submissions). OK, I really need to use the long weekend break here and stop sending stale patches series apologies everyone, work will resume when I have put my head, hands and keyboard back together. -- Florian
[PATCH net-next v3 4/9] mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_GET/SET
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare mlxsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
mlxsw_sp_port_attr_{set,get} calls.
Signed-off-by: Florian Fainelli
---
.../mellanox/mlxsw/spectrum_switchdev.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 95e37de3e48f..c6d7bb70e8f2 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -3443,6 +3443,26 @@ mlxsw_sp_switchdev_handle_vxlan_obj_del(struct
net_device *vxlan_dev,
}
}
+static int
+mlxsw_sp_switchdev_port_attr_event(unsigned long event, struct net_device *dev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err = -EOPNOTSUPP;
+
+ switch (event) {
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = mlxsw_sp_port_attr_set(dev, port_attr_info->attr,
+port_attr_info->trans);
+ break;
+ case SWITCHDEV_PORT_ATTR_GET:
+ err = mlxsw_sp_port_attr_get(dev, port_attr_info->attr);
+ break;
+ }
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
static int mlxsw_sp_switchdev_blocking_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -3466,6 +3486,9 @@ static int mlxsw_sp_switchdev_blocking_event(struct
notifier_block *unused,
mlxsw_sp_port_dev_check,
mlxsw_sp_port_obj_del);
return notifier_from_errno(err);
+ case SWITCHDEV_PORT_ATTR_SET:
+ case SWITCHDEV_PORT_ATTR_GET:
+ return mlxsw_sp_switchdev_port_attr_event(event, dev, ptr);
}
return NOTIFY_DONE;
--
2.19.1
[PATCH net-next v3 2/9] switchdev: Add SWITCHDEV_PORT_ATTR_SET, SWITCHDEV_PORT_ATTR_GET
In preparation for allowing switchdev enabled drivers to veto specific
attribute settings from within the context of the caller, introduce a
new switchdev notifier type for port attributes.
Suggested-by: Ido Schimmel
Signed-off-by: Florian Fainelli
---
include/net/switchdev.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 5e87b54c5dc5..b8becabbef38 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -143,6 +143,9 @@ enum switchdev_notifier_type {
SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE,
SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE,
SWITCHDEV_VXLAN_FDB_OFFLOADED,
+
+ SWITCHDEV_PORT_ATTR_SET, /* Blocking. */
+ SWITCHDEV_PORT_ATTR_GET, /* Blocking. */
};
struct switchdev_notifier_info {
@@ -165,6 +168,13 @@ struct switchdev_notifier_port_obj_info {
bool handled;
};
+struct switchdev_notifier_port_attr_info {
+ struct switchdev_notifier_info info; /* must be first */
+ struct switchdev_attr *attr;
+ struct switchdev_trans *trans;
+ bool handled;
+};
+
static inline struct net_device *
switchdev_notifier_info_to_dev(const struct switchdev_notifier_info *info)
{
--
2.19.1
[PATCH net-next v3 9/9] net: Remove switchdev_ops
Now that we have converted all possible callers to using a switchdev
notifier for attributes we do not have a need for implementing
switchdev_ops anymore, and this can be removed from all drivers the
net_device structure.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 12
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 --
.../mellanox/mlxsw/spectrum_switchdev.c| 13 -
drivers/net/ethernet/mscc/ocelot.c | 5 -
drivers/net/ethernet/rocker/rocker_main.c | 6 --
drivers/staging/fsl-dpaa2/ethsw/ethsw.c| 6 --
include/linux/netdevice.h | 3 ---
include/net/switchdev.h| 18 --
net/dsa/slave.c| 6 --
9 files changed, 71 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 7c9745cecbbd..619965abab43 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -3220,7 +3220,6 @@ static int mlxsw_sp_port_create(struct mlxsw_sp
*mlxsw_sp, u8 local_port,
}
mlxsw_sp_port->default_vlan = mlxsw_sp_port_vlan;
- mlxsw_sp_port_switchdev_init(mlxsw_sp_port);
mlxsw_sp->ports[local_port] = mlxsw_sp_port;
err = register_netdev(dev);
if (err) {
@@ -3237,7 +3236,6 @@ static int mlxsw_sp_port_create(struct mlxsw_sp
*mlxsw_sp, u8 local_port,
err_register_netdev:
mlxsw_sp->ports[local_port] = NULL;
- mlxsw_sp_port_switchdev_fini(mlxsw_sp_port);
mlxsw_sp_port_vlan_destroy(mlxsw_sp_port_vlan);
err_port_vlan_create:
err_port_pvid_set:
@@ -3280,7 +3278,6 @@ static void mlxsw_sp_port_remove(struct mlxsw_sp
*mlxsw_sp, u8 local_port)
mlxsw_core_port_clear(mlxsw_sp->core, local_port, mlxsw_sp);
unregister_netdev(mlxsw_sp_port->dev); /* This calls ndo_stop */
mlxsw_sp->ports[local_port] = NULL;
- mlxsw_sp_port_switchdev_fini(mlxsw_sp_port);
mlxsw_sp_port_vlan_flush(mlxsw_sp_port, true);
mlxsw_sp_port_nve_fini(mlxsw_sp_port);
mlxsw_sp_tc_qdisc_fini(mlxsw_sp_port);
@@ -4001,12 +3998,6 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
goto err_span_init;
}
- err = mlxsw_sp_switchdev_init(mlxsw_sp);
- if (err) {
- dev_err(mlxsw_sp->bus_info->dev, "Failed to initialize
switchdev\n");
- goto err_switchdev_init;
- }
-
err = mlxsw_sp_counter_pool_init(mlxsw_sp);
if (err) {
dev_err(mlxsw_sp->bus_info->dev, "Failed to init counter
pool\n");
@@ -4077,8 +4068,6 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
err_afa_init:
mlxsw_sp_counter_pool_fini(mlxsw_sp);
err_counter_pool_init:
- mlxsw_sp_switchdev_fini(mlxsw_sp);
-err_switchdev_init:
mlxsw_sp_span_fini(mlxsw_sp);
err_span_init:
mlxsw_sp_lag_fini(mlxsw_sp);
@@ -4141,7 +4130,6 @@ static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
mlxsw_sp_nve_fini(mlxsw_sp);
mlxsw_sp_afa_fini(mlxsw_sp);
mlxsw_sp_counter_pool_fini(mlxsw_sp);
- mlxsw_sp_switchdev_fini(mlxsw_sp);
mlxsw_sp_span_fini(mlxsw_sp);
mlxsw_sp_lag_fini(mlxsw_sp);
mlxsw_sp_buffers_fini(mlxsw_sp);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index ceebc91f4f1d..82e3e6dc81a1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -375,8 +375,6 @@ u32 mlxsw_sp_bytes_cells(const struct mlxsw_sp *mlxsw_sp,
u32 bytes);
/* spectrum_switchdev.c */
int mlxsw_sp_switchdev_init(struct mlxsw_sp *mlxsw_sp);
void mlxsw_sp_switchdev_fini(struct mlxsw_sp *mlxsw_sp);
-void mlxsw_sp_port_switchdev_init(struct mlxsw_sp_port *mlxsw_sp_port);
-void mlxsw_sp_port_switchdev_fini(struct mlxsw_sp_port *mlxsw_sp_port);
int mlxsw_sp_rif_fdb_op(struct mlxsw_sp *mlxsw_sp, const char *mac, u16 fid,
bool adding);
void
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index c6d7bb70e8f2..fafd582c2fdc 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -1957,11 +1957,6 @@ static struct mlxsw_sp_port
*mlxsw_sp_lag_rep_port(struct mlxsw_sp *mlxsw_sp,
return NULL;
}
-static const struct switchdev_ops mlxsw_sp_port_switchdev_ops = {
- .switchdev_port_attr_get= mlxsw_sp_port_attr_get,
- .switchdev_port_attr_set= mlxsw_sp_port_attr_set,
-};
-
static int
mlxsw_sp_bridge_8021q_port_join(struct mlxsw_sp_bridge_device *bridge_device,
struct mlxsw_sp_bridge_port *bridge_port,
@@ -3576,11 +3571,3 @@ void
[PATCH net-next v3 7/9] net: dsa: Handle SWITCHDEV_PORT_ATTR_GET/SET
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare DSA to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
dsa_slave_port_attr_{set,get} calls.
Signed-off-by: Florian Fainelli
---
net/dsa/slave.c | 24
1 file changed, 24 insertions(+)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 2e5e7c04821b..2a14a38f5f93 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1558,6 +1558,27 @@ dsa_slave_switchdev_port_obj_event(unsigned long event,
return notifier_from_errno(err);
}
+static int
+dsa_slave_switchdev_port_attr_event(unsigned long event,
+ struct net_device *netdev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err = -EOPNOTSUPP;
+
+ switch (event) {
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = dsa_slave_port_attr_set(netdev, port_attr_info->attr,
+ port_attr_info->trans);
+ break;
+ case SWITCHDEV_PORT_ATTR_GET:
+ err = dsa_slave_port_attr_get(netdev, port_attr_info->attr);
+ break;
+ }
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
static int dsa_slave_switchdev_blocking_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -1570,6 +1591,9 @@ static int dsa_slave_switchdev_blocking_event(struct
notifier_block *unused,
case SWITCHDEV_PORT_OBJ_ADD: /* fall through */
case SWITCHDEV_PORT_OBJ_DEL:
return dsa_slave_switchdev_port_obj_event(event, dev, ptr);
+ case SWITCHDEV_PORT_ATTR_SET: /* fallthrough */
+ case SWITCHDEV_PORT_ATTR_GET:
+ return dsa_slave_switchdev_port_attr_event(event, dev, ptr);
}
return NOTIFY_DONE;
--
2.19.1
[PATCH net-next v3 8/9] net: switchdev: Replace port attr get/set SDO with a notification
Drop switchdev_ops.switchdev_port_attr_get and _set. Drop the uses of
this field from all clients, which were migrated to use switchdev
notification in the previous patches.
Add a new function switchdev_port_attr_notify() that sends the switchdev
notifications SWITCHDEV_PORT_ATTR_GET and _SET.
Update switchdev_port_attr_get() to dispatch to this new function. Drop
__switchdev_port_attr_set() and update switchdev_port_attr_set()
likewise.
Signed-off-by: Florian Fainelli
---
net/switchdev/switchdev.c | 107 +-
1 file changed, 37 insertions(+), 70 deletions(-)
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index 7e1357db33d7..8fc3db2179f5 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -174,81 +174,31 @@ static int switchdev_deferred_enqueue(struct net_device
*dev,
return 0;
}
-/**
- * switchdev_port_attr_get - Get port attribute
- *
- * @dev: port device
- * @attr: attribute to get
- */
-int switchdev_port_attr_get(struct net_device *dev, struct switchdev_attr
*attr)
+static int switchdev_port_attr_notify(enum switchdev_notifier_type nt,
+ struct net_device *dev,
+ struct switchdev_attr *attr,
+ struct switchdev_trans *trans)
{
- const struct switchdev_ops *ops = dev->switchdev_ops;
- struct net_device *lower_dev;
- struct list_head *iter;
- struct switchdev_attr first = {
- .id = SWITCHDEV_ATTR_ID_UNDEFINED
- };
- int err = -EOPNOTSUPP;
+ int err;
+ int rc;
- if (ops && ops->switchdev_port_attr_get)
- return ops->switchdev_port_attr_get(dev, attr);
+ struct switchdev_notifier_port_attr_info attr_info = {
+ .attr = attr,
+ .trans = trans,
+ .handled = false,
+ };
- if (attr->flags & SWITCHDEV_F_NO_RECURSE)
+ rc = call_switchdev_blocking_notifiers(nt, dev, _info.info, NULL);
+ err = notifier_to_errno(rc);
+ if (err) {
+ WARN_ON(!attr_info.handled);
return err;
-
- /* Switch device port(s) may be stacked under
-* bond/team/vlan dev, so recurse down to get attr on
-* each port. Return -ENODATA if attr values don't
-* compare across ports.
-*/
-
- netdev_for_each_lower_dev(dev, lower_dev, iter) {
- err = switchdev_port_attr_get(lower_dev, attr);
- if (err)
- break;
- if (first.id == SWITCHDEV_ATTR_ID_UNDEFINED)
- first = *attr;
- else if (memcmp(, attr, sizeof(*attr)))
- return -ENODATA;
- }
-
- return err;
-}
-EXPORT_SYMBOL_GPL(switchdev_port_attr_get);
-
-static int __switchdev_port_attr_set(struct net_device *dev,
-const struct switchdev_attr *attr,
-struct switchdev_trans *trans)
-{
- const struct switchdev_ops *ops = dev->switchdev_ops;
- struct net_device *lower_dev;
- struct list_head *iter;
- int err = -EOPNOTSUPP;
-
- if (ops && ops->switchdev_port_attr_set) {
- err = ops->switchdev_port_attr_set(dev, attr, trans);
- goto done;
- }
-
- if (attr->flags & SWITCHDEV_F_NO_RECURSE)
- goto done;
-
- /* Switch device port(s) may be stacked under
-* bond/team/vlan dev, so recurse down to set attr on
-* each port.
-*/
-
- netdev_for_each_lower_dev(dev, lower_dev, iter) {
- err = __switchdev_port_attr_set(lower_dev, attr, trans);
- if (err)
- break;
}
-done:
- if (err == -EOPNOTSUPP && attr->flags & SWITCHDEV_F_SKIP_EOPNOTSUPP)
- err = 0;
+ if (!attr_info.handled)
+ return -EOPNOTSUPP;
- return err;
+ return 0;
}
static int switchdev_port_attr_set_now(struct net_device *dev,
@@ -267,7 +217,9 @@ static int switchdev_port_attr_set_now(struct net_device
*dev,
*/
trans.ph_prepare = true;
- err = __switchdev_port_attr_set(dev, attr, );
+ err = switchdev_port_attr_notify(SWITCHDEV_PORT_ATTR_SET,
+dev, (struct switchdev_attr *)attr,
+);
if (err) {
/* Prepare phase failed: abort the transaction. Any
* resources reserved in the prepare phase are
@@ -286,7 +238,9 @@ static int switchdev_port_attr_set_now(struct net_device
*dev,
*/
trans.ph_prepare = false;
- err = __switchdev_port_attr_set(dev, attr, );
+ err = switchdev_port_attr_notify(SWITCHDEV_PORT_ATTR_SET,
+dev, (struct switchdev_attr *)attr,
+
[PATCH net-next v3 5/9] net: mscc: ocelot: Handle SWITCHDEV_PORT_ATTR_GET/SET
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare ocelot to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
ocelot_port_attr_{set,get} calls.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/mscc/ocelot.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/mscc/ocelot.c
b/drivers/net/ethernet/mscc/ocelot.c
index 195306d05bcd..850a49033a30 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1582,6 +1582,24 @@ struct notifier_block ocelot_netdevice_nb __read_mostly
= {
};
EXPORT_SYMBOL(ocelot_netdevice_nb);
+static int
+ocelot_switchdev_port_attr_event(unsigned long event,
+ struct net_device *netdev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err = -EOPNOTSUPP;
+
+ switch (event) {
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = ocelot_port_attr_set(netdev, port_attr_info->attr,
+ port_attr_info->trans);
+ break;
+ }
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
static int ocelot_switchdev_blocking_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -1600,6 +1618,9 @@ static int ocelot_switchdev_blocking_event(struct
notifier_block *unused,
ocelot_netdevice_dev_check,
ocelot_port_obj_del);
return notifier_from_errno(err);
+ case SWITCHDEV_PORT_ATTR_SET:
+ case SWITCHDEV_PORT_ATTR_GET: /* fallthrough */
+ return ocelot_switchdev_port_attr_event(event, dev, ptr);
}
return NOTIFY_DONE;
--
2.19.1
[PATCH net-next v3 6/9] staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_ATTR_GET/SET
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare ethsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
swdev_port_attr_{set,get} calls.
Signed-off-by: Florian Fainelli
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index e559f4c25cf7..bc9e7de07200 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -,6 +,27 @@ ethsw_switchdev_port_obj_event(unsigned long event,
struct net_device *netdev,
return notifier_from_errno(err);
}
+static int
+ethsw_switchdev_port_attr_event(unsigned long event,
+ struct net_device *netdev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err = -EOPNOTSUPP;
+
+ switch (event) {
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = swdev_port_attr_set(netdev, port_attr_info->attr,
+ port_attr_info->trans);
+ break;
+ case SWITCHDEV_PORT_ATTR_GET:
+ err = swdev_port_attr_get(netdev, port_attr_info->attr);
+ break;
+ }
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
static int port_switchdev_blocking_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -1123,6 +1144,9 @@ static int port_switchdev_blocking_event(struct
notifier_block *unused,
case SWITCHDEV_PORT_OBJ_ADD: /* fall through */
case SWITCHDEV_PORT_OBJ_DEL:
return ethsw_switchdev_port_obj_event(event, dev, ptr);
+ case SWITCHDEV_PORT_ATTR_SET:
+ case SWITCHDEV_PORT_ATTR_GET:
+ return ethsw_switchdev_port_attr_event(event, dev, ptr);
}
return NOTIFY_DONE;
--
2.19.1
[PATCH net-next v3 3/9] rocker: Handle SWITCHDEV_PORT_ATTR_GET/SET
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare rocker to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
rocker_port_attr_{set,get} calls.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/rocker/rocker_main.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c
b/drivers/net/ethernet/rocker/rocker_main.c
index 66f72f8c46e5..591008c8fa74 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2835,6 +2835,27 @@ rocker_switchdev_port_obj_event(unsigned long event,
struct net_device *netdev,
return notifier_from_errno(err);
}
+static int
+rocker_switchdev_port_attr_event(unsigned long event, struct net_device
*netdev,
+struct switchdev_notifier_port_attr_info
+*port_attr_info)
+{
+ int err = -EOPNOTSUPP;
+
+ switch (event) {
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = rocker_port_attr_set(netdev, port_attr_info->attr,
+ port_attr_info->trans);
+ break;
+ case SWITCHDEV_PORT_ATTR_GET:
+ err = rocker_port_attr_get(netdev, port_attr_info->attr);
+ break;
+ }
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
static int rocker_switchdev_blocking_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -2847,6 +2868,9 @@ static int rocker_switchdev_blocking_event(struct
notifier_block *unused,
case SWITCHDEV_PORT_OBJ_ADD:
case SWITCHDEV_PORT_OBJ_DEL:
return rocker_switchdev_port_obj_event(event, dev, ptr);
+ case SWITCHDEV_PORT_ATTR_SET:
+ case SWITCHDEV_PORT_ATTR_GET:
+ return rocker_switchdev_port_attr_event(event, dev, ptr);
}
return NOTIFY_DONE;
--
2.19.1
Re: [f2fs-dev] [PATCH] f2fs: don't clear CP_QUOTA_NEED_FSCK_FLAG
On 02/13, Chao Yu wrote: > On 2019/2/12 10:33, Jaegeuk Kim wrote: > > If we met this once, let fsck.f2fs clear this only. > > Note that, this addresses all the subtle fault injection test. > > > > Signed-off-by: Jaegeuk Kim > > --- > > fs/f2fs/checkpoint.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > > index 03fea4efd64b..10a3ada28715 100644 > > --- a/fs/f2fs/checkpoint.c > > +++ b/fs/f2fs/checkpoint.c > > @@ -1267,8 +1267,6 @@ static void update_ckpt_flags(struct f2fs_sb_info > > *sbi, struct cp_control *cpc) > > > > if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) > > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > > - else > > - __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > > I didn't get it, previously, if we didn't persist all quota file's data in > checkpoint, then we will tag CP_QUOTA_NEED_FSCK_FLAG in CP area, but in > current > checkpoint, we have persisted all quota file's data, quota files are > consistent > with all other files in filesystem, why we can't remove this NEED_FSCK flag..? I said it's subtle. So, I guessed 1) set CP_QUOTA_NEED_FSCK_FLAG, 2) clear SBI_QUOTA_SKIP_FLUSH by checkpoint, 3) clear CP_QUOTA_NEED_FSCK_FLAG by another checkpoint? > > Thanks, > > > > > if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) > > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > >
[PATCH net-next v3 1/9] Documentation: networking: switchdev: Update port parent ID section
Update the section about switchdev drivers having to implement a
switchdev_port_attr_get() function to return
SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
commit bccb30254a4a ("net: Get rid of
SWITCHDEV_ATTR_ID_PORT_PARENT_ID").
Fixes: bccb30254a4a ("net: Get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID")
Signed-off-by: Florian Fainelli
---
Documentation/networking/switchdev.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/switchdev.txt
b/Documentation/networking/switchdev.txt
index f3244d87512a..2842f63ad47b 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -92,11 +92,11 @@ device.
Switch ID
^
-The switchdev driver must implement the switchdev op switchdev_port_attr_get
-for SWITCHDEV_ATTR_ID_PORT_PARENT_ID for each port netdev, returning the same
-physical ID for each port of a switch. The ID must be unique between switches
-on the same system. The ID does not need to be unique between switches on
-different systems.
+The switchdev driver must implement the net_device operation
+ndo_get_port_parent_id for each port netdev, returning the same physical ID
+for each port of a switch. The ID must be unique between switches on the same
+system. The ID does not need to be unique between switches on different
+systems.
The switch ID is used to locate ports on a switch and to know if aggregated
ports belong to the same switch.
--
2.19.1
[PATCH net-next v3 0/9] net: Get rid of switchdev_port_attr_get()
Hi all, This patch series splits the removal of the switchdev_ops that was proposed a few times before and first tackles the easy part which is the removal of the single call to switchdev_port_attr_get() within the bridge code. As suggestd by Ido, this patch series adds a SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS which is used in the same context as the caller of switchdev_port_attr_set(), so not deferred, and then the operation is carried out in deferred context with setting a support bridge port flag. Follow-up patches will do the switchdev_ops removal after introducing the proper helpers for the switchdev blocking notifier to work across stacked devices (unlike the previous submissions). Changes in v3: - fixed build failure in mlxsw/spectrum_switchdev.c due to left over argument - fixed unused variable in rocker Changes in v2: - differentiate callers not supporting switchdev_port_attr_set() from the driver not being able to support specific bridge flags - pass "mask" instead of "flags" for the PRE_BRIDGE_FLAGS check - skip prepare phase for PRE_BRIDGE_FLAGS - corrected documentation a bit more - tested bridge_vlan_aware.sh with veth/VRF Florian Fainelli (9): Documentation: networking: switchdev: Update port parent ID section switchdev: Add SWITCHDEV_PORT_ATTR_SET, SWITCHDEV_PORT_ATTR_GET rocker: Handle SWITCHDEV_PORT_ATTR_GET/SET mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_GET/SET net: mscc: ocelot: Handle SWITCHDEV_PORT_ATTR_GET/SET staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_ATTR_GET/SET net: dsa: Handle SWITCHDEV_PORT_ATTR_GET/SET net: switchdev: Replace port attr get/set SDO with a notification net: Remove switchdev_ops Documentation/networking/switchdev.txt| 10 +- .../net/ethernet/mellanox/mlxsw/spectrum.c| 12 -- .../net/ethernet/mellanox/mlxsw/spectrum.h| 2 - .../mellanox/mlxsw/spectrum_switchdev.c | 36 +++--- drivers/net/ethernet/mscc/ocelot.c| 26 - drivers/net/ethernet/rocker/rocker_main.c | 30 - drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 30 - include/linux/netdevice.h | 3 - include/net/switchdev.h | 28 ++--- net/dsa/slave.c | 30 - net/switchdev/switchdev.c | 107 ++ 11 files changed, 168 insertions(+), 146 deletions(-) -- 2.19.1
Re: [PATCH net-next v2 0/9] net: Get rid of switchdev_port_attr_get()
From: Florian Fainelli Date: Fri, 15 Feb 2019 16:37:38 -0800 > David, please ignore this version, I will repost one that actually > builds, need to keep mangling with my kernel configuration and keep > those drivers enabled... Ok.
[PATCH] arm64/mm: skip hwasan callbacks for pgtable walker
Page table walkers trigger soft lockups below with KASAN_SW_TAGS outline mode on a large ThunderX2 system, because there is too much overhead to call check_memory_region() for every memory access where it needs to dereference every byte of the corresponding KASAN shadow address for the correct tag. [ 76.531328] watchdog: BUG: soft lockup - CPU#65 stuck for 23s! [swapper/0:1] [ 76.538372] Modules linked in: [ 76.541433] CPU: 65 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc6+ #62 [ 76.557697] pstate: 6049 (nZCv daif +PAN -UAO) [ 76.562491] pc : check_memory_region+0x64/0x94 [ 76.566934] lr : __hwasan_load8_noabort+0x20/0x2c [ 76.571633] sp : 7eff808ba0247ca0 [ 76.574943] x29: 7eff808ba0247cc0 x28: 068cef72 [ 76.580256] x27: 0800 x26: 00600793 [ 76.585568] x25: 068d x24: 83537b98 [ 76.590880] x23: 7eff808ba0247e08 x22: [ 76.596192] x21: 7eff808ba0247e08 x20: 0008 [ 76.601503] x19: 1000100a8d64 x18: [ 76.606814] x17: 01000100 x16: [ 76.612125] x15: 100013805578 x14: 100014085000 [ 76.617437] x13: 30373a2e x12: 00f00793 [ 76.622749] x11: 808ba0247e0f x10: 0808ba0247e0 [ 76.628060] x9 : 0808ba0247e0 x8 : 007e [ 76.633371] x7 : x6 : 0002 [ 76.638682] x5 : x4 : 00e00793 [ 76.643994] x3 : 1000100a8d64 x2 : [ 76.649305] x1 : 0008 x0 : 7eff808ba0247e08 [ 76.654617] Call trace: [ 76.657066] check_memory_region+0x64/0x94 [ 76.661162] __hwasan_load8_noabort+0x20/0x2c [ 76.665519] note_page+0x84/0x708 [ 76.668833] walk_pgd+0x174/0x258 [ 76.672147] ptdump_check_wx+0x90/0xfc [ 76.675894] mark_rodata_ro+0x38/0x44 [ 76.679557] kernel_init+0x48/0x180 [ 76.683045] ret_from_fork+0x10/0x18 Signed-off-by: Qian Cai --- arch/arm64/mm/Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile index 849c1df3d214..4b9a7a50faaf 100644 --- a/arch/arm64/mm/Makefile +++ b/arch/arm64/mm/Makefile @@ -12,3 +12,9 @@ KASAN_SANITIZE_physaddr.o += n obj-$(CONFIG_KASAN)+= kasan_init.o KASAN_SANITIZE_kasan_init.o:= n + +ifdef CONFIG_KASAN_SW_TAGS +ifdef CONFIG_KASAN_OUTLINE +KASAN_SANITIZE_dump.o := n +endif +endif -- 2.17.2 (Apple Git-113)
Re: [PATCH net-next] selftests: forwarding: Add some missing configuration symbols
From: Florian Fainelli Date: Fri, 15 Feb 2019 10:14:52 -0800 > For the forwarding selftests to work, we need network namespaces when > using veth/vrf otherwise ping/ping6 commands like these: > > ip vrf exec vveth0 /bin/ping 192.0.2.2 -c 10 -i 0.1 -w 5 > > will fail because network namespaces may not be enabled. > > Signed-off-by: Florian Fainelli Applied.
Re: [PATCH] x86: uaccess: fix regression in unsafe_get_user
+Andy Lutomirski
On Sat, Feb 16, 2019 at 12:59 AM wrote:
>
> From: Arthur Gautier
>
> When extracting an initramfs, a filename may be near an allocation boundary.
> Should that happen, strncopy_from_user will invoke unsafe_get_user which
> may cross the allocation boundary. Should that happen, unsafe_get_user will
> trigger a page fault, and strncopy_from_user would then bailout to
> byte_at_a_time behavior.
>
> unsafe_get_user is unsafe by nature, and rely on pagefault to detect
> boundaries.
> After 9da3f2b74054 ("x86/fault: BUG() when uaccess helpers fault on kernel
> addresses")
> it may no longer rely on pagefault as the new page fault handler would
> trigger a BUG().
>
> This commit allows unsafe_get_user to explicitly trigger pagefaults and
> handle them directly with the error target label.
Oof. So basically the init code is full of things that just call
syscalls instead of using VFS functions (which don't actually exist
for everything), and the VFS syscalls use getname_flags(), which uses
strncpy_from_user(), which can access out-of-bounds pages on
architectures that set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, and
that in summary means that all the init code is potentially prone to
tripping over this?
I don't particularly like this approach to fixing it, but I also don't
have any better ideas, so I guess unless someone else has a bright
idea, this patch might have to go in.
> Kernel bug:
> [0.965251] Unpacking initramfs...
> [1.797025] BUG: pagefault on kernel address 0xae80c0c7e000 in
> non-whitelisted uaccess
> [1.798992] BUG: unable to handle kernel paging request at ae80c0c7e000
> [1.798992] #PF error: [normal kernel read fault]
> [1.798992] PGD 68526067 P4D 68526067 PUD 68527067 PMD 67f0d067 PTE 0
> [1.798992] Oops: [#1] SMP PTI
> [1.798992] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc6+ #14
> [1.798992] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [1.798992] RIP: 0010:strncpy_from_user+0x67/0xe0
> [1.798992] Code: fe fe 48 39 ca 49 ba 80 80 80 80 80 80 80 80 48 0f 46 ca
> 31 c0 45 31 db 49 89 c8 4c 89 c1 48 29 c1 48 83 f9 07 76 49 44 89 d9 <4c> 8b
> 0c 06 85 c9 75 3e 49 8d 0c 19 4c 89 0c 07 49 f7 d1 4c 21 c9
> [1.798992] RSP: :ae80c031fc40 EFLAGS: 00050216
> [1.798992] RAX: 0040 RBX: fefefefefefefeff RCX:
>
> [1.798992] RDX: 0fe0 RSI: ae80c0c7dfba RDI:
> 8b3d27cce020
> [1.798992] RBP: ff9c R08: 0fe0 R09:
> caccd29190978b86
> [1.798992] R10: 8080808080808080 R11: R12:
> ae80c0c7dfba
> [1.798992] R13: ae80c031fd00 R14: R15:
>
> [1.798992] FS: () GS:8b3d28a0()
> knlGS:
> [1.798992] CS: 0010 DS: ES: CR0: 80050033
> [1.798992] CR2: ae80c0c7e000 CR3: 3a60e001 CR4:
> 00360eb0
> [1.798992] Call Trace:
> [1.798992] getname_flags+0x69/0x187
> [1.798992] user_path_at_empty+0x1e/0x41
> [1.798992] vfs_statx+0x70/0xcc
> [1.798992] clean_path+0x41/0xa2
> [1.798992] ? parse_header+0x40/0x10a
> [1.798992] do_name+0x78/0x2b5
> [1.798992] write_buffer+0x27/0x37
> [1.798992] flush_buffer+0x34/0x8b
> [1.798992] ? md_run_setup+0x8a/0x8a
> [1.798992] unlz4+0x20b/0x27c
> [1.798992] ? write_buffer+0x37/0x37
> [1.798992] ? decompress_method+0x80/0x80
> [1.798992] unpack_to_rootfs+0x17a/0x2b7
> [1.798992] ? md_run_setup+0x8a/0x8a
> [1.798992] ? clean_rootfs+0x159/0x159
> [1.798992] populate_rootfs+0x5d/0x105
> [1.798992] do_one_initcall+0x86/0x169
> [1.798992] ? do_early_param+0x8e/0x8e
> [1.798992] kernel_init_freeable+0x16a/0x1f4
> [1.798992] ? rest_init+0xaa/0xaa
> [1.798992] kernel_init+0xa/0xfa
> [1.798992] ret_from_fork+0x35/0x40
>
> You may reproduce the issue with the following initrd:
> truncate -s 8388313 a
>
> SECONDFILENAME=
> truncate -s 10 $SECONDFILENAME
> echo "a\n$SECONDFILENAME" | cpio -o --format=newc | lz4 -l > initrd.img.lz4
>
> This places the second filename in the cpio near the allocation boundary made
> by lz4 decompression and should trigger the bug.
>
> Fixes: 9da3f2b74054 ("x86/fault: BUG() when uaccess helpers fault on kernel
> addresses")
>
> Cc: Jann Horn
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: x...@kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Pascal Bouchareine
> Signed-off-by: Arthur Gautier
> ---
> arch/x86/include/asm/uaccess.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index 780f2b42c8efe..2c272dc43e05a 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
Re: [PATCH] net: phy: xgmiitorgmii: Support generic PHY status read
From: Paul Kocialkowski Date: Fri, 15 Feb 2019 17:17:08 +0100 > Some PHY drivers like the generic one do not provide a read_status > callback on their own but rely on genphy_read_status being called > directly. > > With the current code, this results in a NULL function pointer call. > Call genphy_read_status instead when there is no specific callback. > > Signed-off-by: Paul Kocialkowski Applied, thanks. Unfortunately I only noticed your updated version with the Fixes tag after pushing this version out. I'll be more careful next time :)
Re: [PATCH][next] mlxsw: core: fix spelling mistake "temprature" -> "temperature"
From: Colin King Date: Fri, 15 Feb 2019 15:11:53 + > From: Colin Ian King > > There is a spelling mistake in several dev_err messages, fix these. > > Signed-off-by: Colin Ian King Applied, thanks Colin.
Re: [PATCH v2 0/6] Add clock support for Actions Semi S500 SoC
Hi Stephen, On Fri, Feb 01, 2019 at 09:23:43AM +0530, Manivannan Sadhasivam wrote: > Hi Stephen, > > On Tue, Jan 15, 2019 at 09:03:34AM +0530, Manivannan Sadhasivam wrote: > > Hello, > > > > This patchset adds common clock support for Actions Semi S500 SoC of > > the Owl family SoCs. This series is based on the initial work done > > by Edgar Bernardi Righi. https://patchwork.kernel.org/cover/10587527/ > > > > Since there isn't any update from him for long time, I took the liberty > > to modify his patches, address review comments and send to list for review. > > > > This series has been tested on Allo Sparky SBC. > > > > Can you please merge the clk patches so that I can take the DT bits through > Actions sub-tree? > Any update on this patchset? Thanks, Mani > Thanks, > Mani > > > Thanks, > > Mani > > > > Changes in v2: > > > > * Incorporated review comments from Stephen for driver cleanup. > > > > Edgar Bernardi Righi (1): > > dt-bindings: clock: Add DT bindings for Actions Semi S500 CMU > > > > Manivannan Sadhasivam (5): > > clk: actions: Add configurable PLL delay > > ARM: dts: Add CMU support for Actions Semi Owl S500 SoC > > ARM: dts: Remove fake UART clock for S500 based SBCs > > clk: actions: Add clock driver for S500 SoC > > MAINTAINERS: Add linux-actions mailing list for Actions Semi > > > > .../bindings/clock/actions,owl-cmu.txt| 7 +- > > MAINTAINERS | 1 + > > arch/arm/boot/dts/owl-s500-cubieboard6.dts| 7 - > > .../arm/boot/dts/owl-s500-guitar-bb-rev-b.dts | 7 - > > arch/arm/boot/dts/owl-s500-sparky.dts | 7 - > > arch/arm/boot/dts/owl-s500.dtsi | 22 + > > drivers/clk/actions/Kconfig | 5 + > > drivers/clk/actions/Makefile | 1 + > > drivers/clk/actions/owl-pll.c | 2 +- > > drivers/clk/actions/owl-pll.h | 30 +- > > drivers/clk/actions/owl-s500.c| 525 ++ > > include/dt-bindings/clock/actions,s500-cmu.h | 78 +++ > > 12 files changed, 661 insertions(+), 31 deletions(-) > > create mode 100644 drivers/clk/actions/owl-s500.c > > create mode 100644 include/dt-bindings/clock/actions,s500-cmu.h > > > > -- > > 2.17.1 > >
Re: [PATCH v2 1/3] dt-bindings: ufs: Add HI3670 UFS controller binding
On Fri, Jan 11, 2019 at 03:35:02PM -0600, Rob Herring wrote: > On Sat, 5 Jan 2019 12:58:57 +0530, Manivannan Sadhasivam wrote: > > Add devicetree binding for HI3670 UFS controller. HI3760 SoC is very > > similar to HI3660 SoC with almost same IPs. Only major difference in terms > > of UFS is the PHY. HI3670 has 10nm PHY. But since the original driver > > (HI3660 UFS) cannot make HI3670 UFS functional, a separate compatible > > is added for HI3670 without any fallback. > > > > Signed-off-by: Manivannan Sadhasivam > > --- > > Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > Reviewed-by: Rob Herring Martin, Can you please take the bindings patch also? DT patch will go through HiSi tree. Thanks, Mani
Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch
On February 14, 2019 2:14:29 AM PST, Peter Zijlstra
wrote:
>On Wed, Feb 13, 2019 at 02:49:47PM -0800, Andy Lutomirski wrote:
>
>> Do we need to backport this thing?
>
>Possibly, just to be safe.
>
>> The problem can’t be too widespread or we would have heard of it
>before.
>
>Yes, so far we've been lucky.
>
>---
>Subject: sched/x86: Save [ER]FLAGS on context switch
>From: Peter Zijlstra
>Date: Thu Feb 14 10:30:52 CET 2019
>
>Effectively revert commit:
>
> 2c7577a75837 ("sched/x86_64: Don't save flags on context switch")
>
>Specifically because SMAP uses FLAGS.AC which invalidates the claim
>that the kernel has clean flags.
>
>In particular; while preemption from interrupt return is fine (the
>IRET frame on the exception stack contains FLAGS) it breaks any code
>that does synchonous scheduling, including preempt_enable().
>
>This has become a significant issue ever since commit:
>
>5b24a7a2aa20 ("Add 'unsafe' user access functions for batched
>accesses")
>
>provided for means of having 'normal' C code between STAC / CLAC,
>exposing the FLAGS.AC state. So far this hasn't led to trouble,
>however fix it before it comes apart.
>
>Fixes: 5b24a7a2aa20 ("Add 'unsafe' user access functions for batched
>accesses")
>Acked-by: Andy Lutomirski
>Reported-by: Julien Thierry
>Signed-off-by: Peter Zijlstra (Intel)
>---
> arch/x86/entry/entry_32.S|2 ++
> arch/x86/entry/entry_64.S|2 ++
> arch/x86/include/asm/switch_to.h |1 +
> 3 files changed, 5 insertions(+)
>
>--- a/arch/x86/entry/entry_32.S
>+++ b/arch/x86/entry/entry_32.S
>@@ -650,6 +650,7 @@ ENTRY(__switch_to_asm)
> pushl %ebx
> pushl %edi
> pushl %esi
>+ pushfl
>
> /* switch stack */
> movl%esp, TASK_threadsp(%eax)
>@@ -672,6 +673,7 @@ ENTRY(__switch_to_asm)
> #endif
>
> /* restore callee-saved registers */
>+ popfl
> popl%esi
> popl%edi
> popl%ebx
>--- a/arch/x86/entry/entry_64.S
>+++ b/arch/x86/entry/entry_64.S
>@@ -291,6 +291,7 @@ ENTRY(__switch_to_asm)
> pushq %r13
> pushq %r14
> pushq %r15
>+ pushfq
>
> /* switch stack */
> movq%rsp, TASK_threadsp(%rdi)
>@@ -313,6 +314,7 @@ ENTRY(__switch_to_asm)
> #endif
>
> /* restore callee-saved registers */
>+ popfq
> popq%r15
> popq%r14
> popq%r13
>--- a/arch/x86/include/asm/switch_to.h
>+++ b/arch/x86/include/asm/switch_to.h
>@@ -40,6 +40,7 @@ asmlinkage void ret_from_fork(void);
> * order of the fields must match the code in __switch_to_asm().
> */
> struct inactive_task_frame {
>+ unsigned long flags;
> #ifdef CONFIG_X86_64
> unsigned long r15;
> unsigned long r14;
This implies we invoke schedule -- a restricted operation (consider may_sleep)
during execution of STAC-enabled code, but *not* as an exception or interrupt,
since those preserve the flags.
I have serious concerns about this. This is more or less saying that we have
left an unlimited gap and have had AC escape.
Does *anyone* see a need to allow this? I got a question at LPC from someone
about this, and what they were trying to do once all the layers had been
unwound was so far down the wrong track for a root problem that actually has a
very simple solution.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH] ata: fix a race condition when internal cmd time out
For internal cmds, we will unmap DMA memory associated with the cmd
before we abort the cmd. If DMA transfering data before the aborting,
bus error will occured.
ata_exec_internal_sg
->ata_port_freeze if timeout
->ata_qc_complete
->ata_sg_clean
dma transfering data = bus error
->ap->ops->post_internal_cmd
->sas_ata_post_internal
->sas_ata_internal_abort
->abort the cmd
Fix this by move post_internal_cmd() before unmapping the DMA memory
when time out. Notice that we have to set ATA_QCFLAG_FAILED flag before
calling post_internal_cmd() so that the aborting will work.
Reported-by: luojian
Signed-off-by: Jason Yan
---
drivers/ata/libata-core.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adf28788cab5..d0ff5711e805 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1665,6 +1665,13 @@ unsigned ata_exec_internal_sg(struct ata_device *dev,
*/
if (qc->flags & ATA_QCFLAG_ACTIVE) {
qc->err_mask |= AC_ERR_TIMEOUT;
+ qc->flags |= ATA_QCFLAG_FAILED;
+
+ spin_unlock_irqrestore(ap->lock, flags);
+ /* do post_internal_cmd */
+ if (ap->ops->post_internal_cmd)
+ ap->ops->post_internal_cmd(qc);
+ spin_lock_irqsave(ap->lock, flags);
if (ap->ops->error_handler)
ata_port_freeze(ap);
@@ -1679,9 +1686,10 @@ unsigned ata_exec_internal_sg(struct ata_device *dev,
spin_unlock_irqrestore(ap->lock, flags);
}
- /* do post_internal_cmd */
- if (ap->ops->post_internal_cmd)
- ap->ops->post_internal_cmd(qc);
+ if (!(qc->err_mask & AC_ERR_TIMEOUT))
+ /* do post_internal_cmd */
+ if (ap->ops->post_internal_cmd)
+ ap->ops->post_internal_cmd(qc);
/* perform minimal error analysis */
if (qc->flags & ATA_QCFLAG_FAILED) {
--
2.14.4
Re: [PATCH v5 00/10] Add support for TISCI irqchip drivers
Hi Marc, On 2/12/2019 1:12 PM, Lokesh Vutla wrote: > TI AM65x SoC based on K3 architecture introduced support for Events > which are message based interrupts with minimal latency. These events > are not compatible with regular interrupts and are valid only through > an event transport lane. An Interrupt Aggregator(INTA) is introduced > to convert these events to interrupts. INTA can also group 64 events > into a single interrupt. Now the SoC has many peripherals and a large > number of event sources (time sync or DMA), the use of events is > completely dependent on a user's specific application, which drives a > need for maximum flexibility in which event sources are used in the > system. It is also completely up to software control as to how the > events are serviced. > > Because of the huge flexibility there are certain standard peripherals > (like GPIO etc)where all interrupts cannot be directly corrected to host > interrupt controller. For this purpose, Interrupt Router(INTR) is > introduced in the SoC. INTR just does a classic interrupt redirection. > > So the SoC has 3 types of interrupt controllers: > - GIC500 > - Interrupt Router > - Interrupt Aggregator > > Below is a diagrammatic view of how SoC integration of these interrupt > controllers:(https://pastebin.ubuntu.com/p/9ngV3jdGj2/) > > Device Index-x Device Index-y >| | >| | > > \ / > \ / > \ (global events) / > +---+ +-+ > | | | | > | INTA | | GPIO | > | | | | > +---+ +-+ > | (vint)| > | | > \|/| > +---+| > | |<---+ > | INTR| > | | > +---+ > | > | > \|/ (gic irq) > +---+ > | | > | GIC | > | | > +---+ > > While at it, TISCI abstracts the handling of all above IRQ routes where > interrupt sources are not directly connected to host interrupt controller. > That would be configuration of Interrupt Aggregator and Interrupt Router. > > This series adds support for: > - TISCI commands needed for IRQ configuration > - Interrupt Router(INTR) and Interrupt Aggregator(INTA) drivers Sorry to bother you again. Any chance you can take a quick look at the series? Thanks and regards, Lokesh
Re: [PATCH][V2] scsi: qla2xxx: remove redundant null check on pointer sess
Colin, > The null check on pointer sess and the subsequent call is redundant as > sess is null on all the the paths that lead to the out_term2 label. > Hence the null check and the call can be removed. Also remove the > redundant setting of sess to NULL as this is not required now. Applied to 5.1/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Hi Rob,
On 2/12/2019 1:12 PM, Lokesh Vutla wrote:
> Add the DT binding documentation for Interrupt router driver.
>
> Signed-off-by: Lokesh Vutla
> ---
> Changes since v4:
> - None
>
> .../interrupt-controller/ti,sci-intr.txt | 85 +++
> MAINTAINERS | 1 +
> 2 files changed, 86 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> new file mode 100644
> index ..4b0ca797fda1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> @@ -0,0 +1,85 @@
> +Texas Instruments K3 Interrupt Router
> +=
> +
> +The Interrupt Router (INTR) module provides a mechanism to route M
> +interrupt inputs to N interrupt outputs, where all M inputs are selectable
> +to be driven per N output. There is one register per output (MUXCNTL_N) that
> +controls the selection.
> +
> +
> + Interrupt Router
> + +--+
> + | Inputs Outputs |
> ++---+| +--+ |
> +| GPIO |--->| | irq0 | | Host IRQ
> ++---+| +--+ | controller
> + |.+-+ | +---+
> ++---+|.| 0 | |->| IRQ |
> +| INTA |--->|.+-+ | +---+
> ++---+|. . |
> + | +--+ . |
> + | | irqM |+-+ |
> + | +--+| N | |
> + | +-+ |
> + +--+
> +
> +Configuration of these MUXCNTL_N registers is done by a system controller
> +(like the Device Memory and Security Controller on K3 AM654 SoC). System
> +controller will keep track of the used and unused registers within the
> Router.
> +Driver should request the system controller to get the range of GIC IRQs
> +assigned to the requesting hosts. It is the drivers responsibility to keep
> +track of Host IRQs.
> +
> +Communication between the host processor running an OS and the system
> +controller happens through a protocol called TI System Control Interface
> +(TISCI protocol). For more details refer:
> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +TISCI Interrupt Router Node:
> +
> +- compatible:Must be "ti,sci-intr".
> +- interrupt-controller: Identifies the node as an interrupt controller
> +- #interrupt-cells: Specifies the number of cells needed to encode an
> + interrupt source. The value should be 4.
> + First cell should contain the TISCI device ID of source
> + Second cell should contain the interrupt source offset
> + within the device
> + Third cell specifies the trigger type as defined
> + in interrupts.txt in this directory.
> + Fourth cell should be 1 if the irq is coming from
> + interrupt aggregator else 0.
> +- ti,sci:Phandle to TI-SCI compatible System controller node.
> +- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
Please help me here. As said this is the TISCI device id for the host
interrupt controller. While sending message to the system co-processor
this ID needs to be specified so that the irq route gets discovered and
configured. Atleast with the current design device Ids are not
discoverable. Can you mention what can be improved here? Is there any
such example where a firmware supports querying the deivce ids?
Also do you have any further comments on this patch?
Thanks and regards,
Lokesh
> +- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the
> host irqs
> + assigned to this interrupt router. Each subtype id
> + corresponds to a range of host irqs.
> +
> +For more details on TISCI IRQ resource management refer:
> +http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
> +
> +Example:
> +
> +The following example demonstrates both interrupt router node and the
> consumer
> +node(main gpio) on the AM654 SoC:
> +
> +main_intr: interrupt-controller0 {
> + compatible = "ti,sci-intr";
> + interrupt-controller;
> + interrupt-parent = <>;
> + #interrupt-cells = <4>;
> + ti,sci = <>;
> + ti,sci-dst-id = <56>;
> + ti,sci-rm-range-girq = <0x1>;
> +};
> +
> +main_gpio0:
Re: [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Hi Tony, On 2/15/2019 9:46 PM, Tony Lindgren wrote: > Hi, > > * Lokesh Vutla [190214 18:03]: >> On 2/14/2019 11:16 PM, Tony Lindgren wrote: >>> But I'd rather have a proper hardware based phandle + index >>> type mapping in the dts if possible though. >> >> The idea about sysfw here is that Linux is not aware of anything about >> this device(Interrupt Router). It cannot even access any of its >> registers. As a user Linux should know who is the parent to which the >> Interrut router output should be configured. Then query sysfw about the >> range of gic irqs allocated to it. Now for configuration, Linux should >> pass the the input to interrupt router, gic irq no, and gic id(by which >> sysfw uniquely identifies GIC interrupt controller with the SoC). Based >> on these parameters Interrupt Router registers gets configured. > > If the interrupt router hardawre is hidden away from Linux, > just leave it out of the device tree completely and have the > interrupt controller driver request the routing. Yes while requesting you should at-least specify which is your destination interrupt-controller Else how does the sysfw even know to whom the requester wants the routing to happen to. You do know that we are dealing with a heterogeneous system where there are more the one destination interrupt controllers(GIC, R5 VIM etc etc..). This is what the DT property is specifying and we cannot query a device based on a name. > > The dts node for the interrupt controller should describe a > proper Linux device, that is with reg entries and so on. You are asking to just keep the compatible property :) I am no where denying that. But the cases where the firmware does the configuration DT spec[1] clearly mentions about the interface. Please take a look at arm-psci devicetree binding documentation where the function ids are represented using which each psci function is invoked. [1] https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2/devicetree-specification-v0.2.pdf Thanks and regards, Lokesh
Re: [PATCH] scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached
John, > The sysfs phy_identifier attribute for a sas_end_device comes > from the rphy phy_identifier value. Applied to 5.0/scsi-fixes, thank you! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2 3/4] Makefile: lld: tell clang to use lld
On Thu, Feb 14, 2019 at 8:08 AM Nick Desaulniers wrote: > > On Wed, Feb 13, 2019 at 6:59 AM Masahiro Yamada > wrote: > > > > On Tue, Feb 12, 2019 at 5:42 AM wrote: > > > > > > This is needed because clang doesn't select which linker to use based on > > > $LD but rather -fuse-ld=lld. This is problematic especially for > > > cc-ldoption, which checks for linker flag support via invoking the > > > compiler, rather than the linker. > > > > > > Sorry, please explain what kind of problem > > this patch solves. > > > > > > > > [1] $(LD) is used to link vmlinux, modules, etc. > > > > [2] $(CC) is used to link vdso, etc. > > and -fuse-ld= selects which linker is invoked from $(CC) > > It solves case 2. > > > > > > > Is it a problem to use a different > > type of linker for [1] and [2] ? > > Ideally, no, but I can think of at least one case where it might be > problematic to mix linkers like that: > You might be mixing linker flags added via ld-option from one linker > that aren't actually supported by the other linker. You can do this only when you are sure that the _exactly_ same linker is used. In my understanding, -fuse-ld=lld does not guarantee it. -- Best Regards Masahiro Yamada
Re: [PATCH v2 2/4] Makefile: clang: choose GCC_TOOLCHAIN_DIR not on LD
On Tue, Feb 12, 2019 at 5:42 AM wrote:
>
> This causes an issue when trying to build with `make LD=ld.lld` if
> ld.lld and the rest of your cross tools aren't in the same directory
> (ex. /usr/local/bin) (as is the case for Android's build system), as the
> GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point
> where LLVM tools are, not GCC/binutils tools are located.
>
> Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by
> binutils for which LLVM does not provide a substitute for, such as
> elfedit.
>
> Fixes commit 785f11aa595b ("kbuild: Add better clang cross build support")
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/341
> Suggested-by: Nathan Chancellor
> Reviewed-by: Nathan Chancellor
> Tested-by: Nathan Chancellor
> Signed-off-by: Nick Desaulniers
> ---
This one looks correct to me.
Applied to linux-kbuild.
> Changes V1->V2:
> * add reviewed and tested tags.
>
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 86cf35d1d79d..d3b65e96d183 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -492,7 +492,7 @@ endif
> ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
> ifneq ($(CROSS_COMPILE),)
> CLANG_FLAGS:= --target=$(notdir $(CROSS_COMPILE:%-=%))
> -GCC_TOOLCHAIN_DIR := $(dir $(shell which $(LD)))
> +GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
> CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)
> GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
> endif
> --
> 2.20.1.791.gb4d0f1c61a-goog
>
--
Best Regards
Masahiro Yamada
[PATCH v2 net-next] mdio_bus: Fix PTR_ERR() usage after initialization to constant
Fix coccinelle warning:
./drivers/net/phy/mdio_bus.c:51:5-12: ERROR: PTR_ERR applied after
initialization to constant on line 44
./drivers/net/phy/mdio_bus.c:52:5-12: ERROR: PTR_ERR applied after
initialization to constant on line 44
fix this by using IS_ERR before PTR_ERR
Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
Signed-off-by: YueHaibing
---
v2: remove variable 'ret'
---
drivers/net/phy/mdio_bus.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 3d31358..debc74c 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -48,11 +48,12 @@ static int mdiobus_register_gpiod(struct mdio_device
*mdiodev)
gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
"reset-gpios", 0, GPIOD_OUT_LOW,
"PHY reset");
- if (PTR_ERR(gpiod) == -ENOENT ||
- PTR_ERR(gpiod) == -ENOSYS)
- gpiod = NULL;
- else if (IS_ERR(gpiod))
- return PTR_ERR(gpiod);
+ if (IS_ERR(gpiod)) {
+ if (PTR_ERR(gpiod) == -ENOENT || PTR_ERR(gpiod) == -ENOSYS)
+ gpiod = NULL;
+ else
+ return PTR_ERR(gpiod);
+ }
mdiodev->reset = gpiod;
--
2.7.4
Re: [PATCH v2 3/3] scsi: ufs: Add HI3670 SoC UFS driver support
Manivannan, > Ping on this patch! Applied to 5.1/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2 4/4] Makefile: lld: set -O2 linker flag when linking with LLD
On Tue, Feb 12, 2019 at 5:42 AM wrote: > > For arm64: > 0.34% size improvement with lld -O2 over lld for vmlinux. > 3.3% size improvement with lld -O2 over lld for Image.lz4-dtb. > > Link: https://github.com/ClangBuiltLinux/linux/issues/343 > Suggested-by: Rui Ueyama > Suggested-by: Nathan Chancellor > Reviewed-by: Nathan Chancellor > Tested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers > --- > Changes V1->V2: > * add tested and reviewed by tags. > > Makefile | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Makefile b/Makefile > index 00e8e01d23fc..8011555745aa 100644 > --- a/Makefile > +++ b/Makefile > @@ -718,6 +718,10 @@ else > KBUILD_CFLAGS += -Wno-unused-but-set-variable > endif > > +ifdef CONFIG_LD_IS_LLD > +KBUILD_LDFLAGS += -O2 > +endif > + I wondered why this option should be added only for lld, and I found the answer in the "Link:" "for bfd, didn't seem to change the size at all (I can't recall if this was arm64 or x86 I had tested with though)." Hmm, I see. My 'man ld' says it is currently effective only for shared libraries. -O level If level is a numeric values greater than zero ld optimizes the output. This might take significantly longer and therefore probably should only be enabled for the final binary. At the moment this option only affects ELF shared library generation. Future releases of the linker may make more use of this option. Also currently there is no difference in the linker's behaviour for different non-zero values of this option. Again this may change with future releases. I am fine with adding it unconditionally as long as it is harmless for bfd, gold. > KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable) > ifdef CONFIG_FRAME_POINTER > KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls > -- > 2.20.1.791.gb4d0f1c61a-goog > -- Best Regards Masahiro Yamada
[PATCH] parisc: Fix ptrace syscall number modification
Commit 910cd32e552e ("parisc: Fix and enable seccomp filter support")
introduced a regression in ptrace-based syscall tampering: when tracer
changes syscall number to -1, the kernel fails to initialize %r28 with
-ENOSYS and subsequently fails to return the error code of the failed
syscall to userspace.
This erroneous behaviour could be observed with a simple strace syscall
fault injection command which is expected to print something like this:
$ strace -a0 -ewrite -einject=write:error=enospc echo hello
write(1, "hello\n", 6) = -1 ENOSPC (No space left on device) (INJECTED)
write(2, "echo: ", 6) = -1 ENOSPC (No space left on device) (INJECTED)
write(2, "write error", 11) = -1 ENOSPC (No space left on device) (INJECTED)
write(2, "\n", 1) = -1 ENOSPC (No space left on device) (INJECTED)
+++ exited with 1 +++
After commit 910cd32e552ea09caa89cdbe328e468979b030dd it loops printing
something like this instead:
write(1, "hello\n", 6../strace: Failed to tamper with process 12345:
unexpectedly got no error (return value 0, error 0)
) = 0 (INJECTED)
This bug was found by strace test suite.
Fixes: 910cd32e552e ("parisc: Fix and enable seccomp filter support")
Cc: sta...@vger.kernel.org # v4.5+
Signed-off-by: Dmitry V. Levin
---
N.B. I have no parisc box to test the patch.
arch/parisc/kernel/ptrace.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/parisc/kernel/ptrace.c b/arch/parisc/kernel/ptrace.c
index 2582df1c529b..9177f3e68b93 100644
--- a/arch/parisc/kernel/ptrace.c
+++ b/arch/parisc/kernel/ptrace.c
@@ -308,15 +308,17 @@ long compat_arch_ptrace(struct task_struct *child,
compat_long_t request,
long do_syscall_trace_enter(struct pt_regs *regs)
{
- if (test_thread_flag(TIF_SYSCALL_TRACE) &&
- tracehook_report_syscall_entry(regs)) {
- /*
-* Tracing decided this syscall should not happen or the
-* debugger stored an invalid system call number. Skip
-* the system call and the system call restart handling.
-*/
- regs->gr[20] = -1UL;
- goto out;
+ if (test_thread_flag(TIF_SYSCALL_TRACE)) {
+ regs->gr[28] = -ENOSYS;
+ if (tracehook_report_syscall_entry(regs)) {
+ /*
+* Tracing decided this syscall should not happen or the
+* debugger stored an invalid system call number. Skip
+* the system call and the system call restart handling.
+*/
+ regs->gr[20] = -1UL;
+ return -1;
+ }
}
/* Do the secure computing check after ptrace. */
--
ldv
Re: [PATCH net-next] mdio_bus: Fix PTR_ERR() usage after initialization to constant
On 2019/2/1 12:24, Al Viro wrote:
> On Tue, Jan 29, 2019 at 11:30:27AM +0800, YueHaibing wrote:
gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
"reset-gpios", 0, GPIOD_OUT_LOW,
"PHY reset");
- if (PTR_ERR(gpiod) == -ENOENT ||
- PTR_ERR(gpiod) == -ENOSYS)
- gpiod = NULL;
- else if (IS_ERR(gpiod))
- return PTR_ERR(gpiod);
+ if (IS_ERR(gpiod)) {
+ ret = PTR_ERR(gpiod);
+ if (ret == -ENOENT || ret == -ENOSYS)
+ gpiod = NULL;
+ else
+ return ret;
+ }
>
> Rule of the thumb: PTR_ERR(p) == -E... is almost always better off
> as p == ERR_PTR(-E...)
Ok, will fix it.
>
> .
>
[PATCH net-next] ptr_ring: remove duplicated include from ptr_ring.h
Remove duplicated include. Signed-off-by: YueHaibing --- include/linux/ptr_ring.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h index 186cd8e..8da46ac 100644 --- a/include/linux/ptr_ring.h +++ b/include/linux/ptr_ring.h @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #endif -- 2.7.4
Re: [PATCH v2] of: unittest: unflatten device tree on UML when testing
On 2/15/19 6:18 PM, Frank Rowand wrote:
> On 2/15/19 4:46 PM, Brendan Higgins wrote:
>> UML supports enabling OF, and is useful for running the device tree
>> tests, so add support for unflattening device tree blobs so we can
>> actually use it.
>>
>> Signed-off-by: Brendan Higgins
>> ---
>> drivers/of/unittest.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
>> index 84427384654d5..6de34d5fa0e85 100644
>> --- a/drivers/of/unittest.c
>> +++ b/drivers/of/unittest.c
>> @@ -2527,6 +2527,9 @@ static int __init of_unittest(void)
>> }
>> of_node_put(np);
>>
>> +if (IS_ENABLED(CONFIG_UML))
>> +unittest_unflatten_overlay_base();
>> +
>
> This is still the wrong location. It should be at the top of the function.
>
> I'll try moving it to the top and see if it still works -- should only
> take me a few minutes.
Yep, see below.
> -Frank
>
>> pr_info("start of unittest - you will see error messages\n");
>> of_unittest_check_tree_linkage();
>> of_unittest_check_phandles();
>>
>
>
This is probably white space damaged because I used cut and paste,
but this is what I meant above.
Tested on 5.0-rc3.
Applied patches 1-14 of series:
[RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing
framework
booted uml, saw the expected 219 pass, 1 fail.
Applied the following patch, saw the expected 224 pass, 0 fail.
I did not apply patch 15 of the other series, but applying patch 15
should still result in errors on boot, as I reported in the mail
thread for that patch series.
---
drivers/of/unittest.c |4
1 file changed, 4 insertions(+)
Index: b/drivers/of/unittest.c
===
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -2514,6 +2514,10 @@ static int __init of_unittest(void)
int res;
/* adding data for unittest */
+
+ if (IS_ENABLED(CONFIG_UML))
+ unittest_unflatten_overlay_base();
+
res = unittest_data_add();
if (res)
return res;
Re: [PATCH] powerpc: use $(origin ARCH) to select KBUILD_DEFCONFIG
On Sat, Feb 16, 2019 at 1:11 AM Mathieu Malaterre wrote: > > On Fri, Feb 15, 2019 at 10:41 AM Masahiro Yamada > wrote: > > > > I often test all Kconfig commands for all architectures. To ease my > > workflow, I want 'make defconfig' at least working without any cross > > compiler. > > > > Currently, arch/powerpc/Makefile checks CROSS_COMPILE to decide the > > default defconfig source. > > > > If CROSS_COMPILE is unset, it is likely to be the native build, so > > 'uname -m' is useful to choose the defconfig. If CROSS_COMPILE is set, > > the user is cross-building (i.e. 'uname -m' is probably x86_64), so > > it falls back to ppc64_defconfig. Yup, make sense. > > > > However, I want to run 'make ARCH=* defconfig' without setting > > CROSS_COMPILE for each architecture. > > > > My suggestion is to check $(origin ARCH). > > > > When you cross-compile the kernel, you need to set ARCH from your > > environment or from the command line. > > > > For the native build, you do not need to set ARCH. The default in > > the top Makefile is used: > > > > ARCH?= $(SUBARCH) > > > > Hence, $(origin ARCH) returns 'file'. > > > > Before this commit, 'make ARCH=powerpc defconfig' failed: > > In case you have not seen it, please check: > > http://patchwork.ozlabs.org/patch/1037835/ I did not know that because I do not subscribe to ppc ML. Michael's patch looks good to me. If you mimic x86, the following will work: diff --git a/Makefile b/Makefile index 86cf35d..eb9552d 100644 --- a/Makefile +++ b/Makefile @@ -356,6 +356,11 @@ ifeq ($(ARCH),sh64) SRCARCH := sh endif +# Additional ARCH settings for powerpc +ifneq ($(filter ppc%,$(ARCH)),) + SRCARCH := powerpc +endif + KCONFIG_CONFIG ?= .config export KCONFIG_CONFIG diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 488c9ed..ff01fef 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -34,10 +34,10 @@ ifdef CONFIG_PPC_BOOK3S_32 KBUILD_CFLAGS += -mcpu=powerpc endif -ifeq ($(CROSS_COMPILE),) -KBUILD_DEFCONFIG := $(shell uname -m)_defconfig -else +ifeq ($(ARCH),powerpc) KBUILD_DEFCONFIG := ppc64_defconfig +else +KBUILD_DEFCONFIG := $(ARCH)_defconfig endif ifdef CONFIG_PPC64 diff --git a/scripts/subarch.include b/scripts/subarch.include index 6506828..c98323f 100644 --- a/scripts/subarch.include +++ b/scripts/subarch.include @@ -8,6 +8,6 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ -e s/sun4u/sparc64/ \ -e s/arm.*/arm/ -e s/sa110/arm/ \ -e s/s390x/s390/ -e s/parisc64/parisc/ \ - -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ + -e s/mips.*/mips/ \ -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \ -e s/riscv.*/riscv/) -- Best Regards Masahiro Yamada
Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
On Fri, 15 Feb 2019 18:14:21 -0800
Andy Lutomirski wrote:
> > In the uprobes case, we have:
> >
> > static nokprobe_inline int
> > probe_mem_read(void *dest, void *src, size_t size)
> > {
> >void __user *vaddr = (void __force __user *)src;
> >
> >return copy_from_user(dest, vaddr, size) ? -EFAULT : 0;
> > }
> >
> > Because that is adding probes on userspace code.
> >
> >
>
> Can the kprobe case call probe_kernel_read? Maybe it does already?
Yes, the probe_mem_read() is only used in the trace_probe_tmpl.h which
for uprobes is the above "copy_from_user()" and for the kprobes case it
is probe_kernel_read().
-- Steve
Re: [PATCH v2] of: unittest: unflatten device tree on UML when testing
On 2/15/19 4:46 PM, Brendan Higgins wrote:
> UML supports enabling OF, and is useful for running the device tree
> tests, so add support for unflattening device tree blobs so we can
> actually use it.
>
> Signed-off-by: Brendan Higgins
> ---
> drivers/of/unittest.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 84427384654d5..6de34d5fa0e85 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -2527,6 +2527,9 @@ static int __init of_unittest(void)
> }
> of_node_put(np);
>
> + if (IS_ENABLED(CONFIG_UML))
> + unittest_unflatten_overlay_base();
> +
This is still the wrong location. It should be at the top of the function.
I'll try moving it to the top and see if it still works -- should only
take me a few minutes.
-Frank
> pr_info("start of unittest - you will see error messages\n");
> of_unittest_check_tree_linkage();
> of_unittest_check_phandles();
>
Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
> On Feb 15, 2019, at 6:08 PM, Steven Rostedt wrote:
>
> On Fri, 15 Feb 2019 17:32:55 -0800
> Andy Lutomirski wrote:
>
>>> I added you just because I wanted help getting the change log correct,
>>> as that's what Linus was complaining about. I kept using "kernel
>>> address" when the sample bug used for the patch was really a
>>> non-canonical address (as Linus said, it's just garbage. Neither kernel
>>> or user space). But I pointed out that this can also bug if the
>>> address is canonical and in the kernel address space. The old code
>>> didn't complain about non-canonical or kernel address faulting before
>>> commit 9da3f2b7405, which only talks about kernel address space
>>> faulting (which is why I only mentioned that in my messages).
>>>
>>> Would changing all the mention of "kernel address" to "non user space"
>>> be accurate?
>>>
>>
>> I think “kernel address” is right. It’s illegal to access anything that
>> isn’t known to be a valid kernel address while in KERNEL_DS.
>
> But an non-canonical address is not a "kernel address", and that will
> cause a bug too.
Indeed. A non-canonical address is not known to be a valid kernel address. I
stand by my slightly pedantic statement :)
> This patch came about because it was changed that if
> we do a uaccess on something other than a user space address and take a
> fault (either because it was a non-canonical address, or a kernel
> address), we BUG! Where before that one patch, it would just return a
> fault.
>
>>
>> The old __copy seems likely to have always been a bit bogus.
>>
>> BTW, what is this probe_mem_read() thing? Some minimal inspection suggests
>> it’s a buggy reimplementation of probe_kernel_read(). Can you delete it and
>> just use probe_kernel_read() directly?
>
> Well, the issue is that we have trace_probe_tmpl.h in that same
> directory, which does the work for kprobes and uprobes. The
> trace_kprobes.c defines all the functions for handling kprobes, and
> trace_uprobes.c does all the handling of uprobes, then they include
> trace_probe_tmpl.h which does the bulk of the work.
>
> In the uprobes case, we have:
>
> static nokprobe_inline int
> probe_mem_read(void *dest, void *src, size_t size)
> {
>void __user *vaddr = (void __force __user *)src;
>
>return copy_from_user(dest, vaddr, size) ? -EFAULT : 0;
> }
>
> Because that is adding probes on userspace code.
>
>
Can the kprobe case call probe_kernel_read? Maybe it does already?
find_get_entries_tag regression bisected
Hi Willy,
Piotr reports the following crash can be triggered on latest mainline:
EXT4-fs (pmem5): recovery complete
EXT4-fs (pmem5): mounted filesystem with ordered data mode. Opts: dax
[ cut here ]
kernel BUG at mm/pgtable-generic.c:127!
invalid opcode: [#1] SMP PTI
CPU: 28 PID: 1193 Comm: a.out Tainted: GW OE 4.19.0-rc5+ #2907
[..]
RIP: 0010:pmdp_huge_clear_flush+0x1e/0x80
[..]
Call Trace:
dax_writeback_mapping_range+0x473/0x8a0
? print_shortest_lock_dependencies+0x40/0x40
? jbd2_journal_stop+0xef/0x470
? ext4_fill_super+0x3071/0x3110
? __lock_is_held+0x4f/0x90
? __lock_is_held+0x4f/0x90
ext4_dax_writepages+0xed/0x2f0
do_writepages+0x41/0xe0
__filemap_fdatawrite_range+0xbe/0xf0
file_write_and_wait_range+0x4c/0xa0
ext4_sync_file+0xa6/0x4f0
I bisected this regression to commit c1901cd33cf4 "page cache: Convert
find_get_entries_tag to XArray". I suspect another case of pte vs pmd
confusion.
Below is the small reproducer from Piotr, it triggers in a qemu
environment with emulated pmem, but only with ext4 that I can see, but
I did not dig too deep. Let me know if anything jumps out to you. I'll
otherwise take a deeper look in the coming days.
#include
#include
#include
#include
#include
#include
#define MB (1ULL << 20)
int
main(int argc, char *argv[])
{
int ret;
int fd;
off_t size = 2 * MB;
char *path = argv[1];
fd = open(path, O_RDWR | O_CREAT | O_EXCL, 0666);
assert(fd > 0);
ret = ftruncate(fd, size);
assert(ret == 0);
char *addr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
assert(addr != MAP_FAILED);
memset((char*)addr, '0', 1);
ret = msync(addr + 4096, 1, MS_SYNC);
assert(ret == 0);
close(fd);
return 0;
}
Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
On Fri, 15 Feb 2019 17:32:55 -0800
Andy Lutomirski wrote:
> > I added you just because I wanted help getting the change log correct,
> > as that's what Linus was complaining about. I kept using "kernel
> > address" when the sample bug used for the patch was really a
> > non-canonical address (as Linus said, it's just garbage. Neither kernel
> > or user space). But I pointed out that this can also bug if the
> > address is canonical and in the kernel address space. The old code
> > didn't complain about non-canonical or kernel address faulting before
> > commit 9da3f2b7405, which only talks about kernel address space
> > faulting (which is why I only mentioned that in my messages).
> >
> > Would changing all the mention of "kernel address" to "non user space"
> > be accurate?
> >
>
> I think “kernel address” is right. It’s illegal to access anything that isn’t
> known to be a valid kernel address while in KERNEL_DS.
But an non-canonical address is not a "kernel address", and that will
cause a bug too. This patch came about because it was changed that if
we do a uaccess on something other than a user space address and take a
fault (either because it was a non-canonical address, or a kernel
address), we BUG! Where before that one patch, it would just return a
fault.
>
> The old __copy seems likely to have always been a bit bogus.
>
> BTW, what is this probe_mem_read() thing? Some minimal inspection suggests
> it’s a buggy reimplementation of probe_kernel_read(). Can you delete it and
> just use probe_kernel_read() directly?
Well, the issue is that we have trace_probe_tmpl.h in that same
directory, which does the work for kprobes and uprobes. The
trace_kprobes.c defines all the functions for handling kprobes, and
trace_uprobes.c does all the handling of uprobes, then they include
trace_probe_tmpl.h which does the bulk of the work.
In the uprobes case, we have:
static nokprobe_inline int
probe_mem_read(void *dest, void *src, size_t size)
{
void __user *vaddr = (void __force __user *)src;
return copy_from_user(dest, vaddr, size) ? -EFAULT : 0;
}
Because that is adding probes on userspace code.
-- Steve
Re: [PATCH] efi/libstub: refactor cmd_stubcopy
On Sat, Feb 16, 2019 at 12:38 AM Ard Biesheuvel
wrote:
>
> On Fri, 15 Feb 2019 at 06:49, Masahiro Yamada
> wrote:
> >
> > On Tue, Feb 12, 2019 at 4:26 PM Ard Biesheuvel
> > wrote:
> > >
> > > On Tue, 12 Feb 2019 at 04:45, Masahiro Yamada
> > > wrote:
> > > >
> > > > It took me a while to understand what is going on in the nested
> > > > if-blocks.
> > > >
> > > > Simplify it by removing unneeded code.
> > > >
> > > > - if_changed automatically adds 'set -e', so any failure in the
> > > > series of commands makes it immediately fail as a whole.
> > > > So, the outer if block is entirely redundant.
> > > >
> > > > - Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
> > > > target"), GNU Make automatically deletes the target on any failure
> > > > in its recipe. The explicit 'rm -f $@' is redundant.
> > > >
> > > > - surrounding commands with ( ) will spawn a subshell to execute them
> > > > in it, but it is rarely useful to do so.
> > > >
> > > > Signed-off-by: Masahiro Yamada
> > >
> > > Assuming that it still works as expected:
> > >
> > > Acked-by: Ard Biesheuvel
> > >
> > > You can test this by adding a statically initialized global function
> > > pointer to any of the libstub source files that get built for ARM.
> > >
> > > Thanks!
> >
> >
> > I tried that, and it failed as expected.
> >
>
> Great, thanks for double checking.
>
> Are you taking this directly, or do you want me to take it via the EFI
> tree? Either is fine with me
>
>
Could you apply it to your EFI tree?
Thanks.
--
Best Regards
Masahiro Yamada
Re: [PATCH] Fix resume for ELAN2097 touchscreen.
Happy new year. I think you might be right. I found some discussions about Dell disabling S3 support in a recent bios due to a C-state bug. I'll try to investigate a bit more this weekend. Jim On Fri, Feb 15, 2019 at 1:25 AM Kai-Heng Feng wrote: > > Hi Jiri and James, > > > On Feb 15, 2019, at 15:35, Jiri Kosina wrote: > > > > On Thu, 14 Feb 2019, james broadus wrote: > > > >>> This should be fixed in hid.git#for-5.1/i2c-hid already by commit > >>> 1475af255e18f. Could you please confirm that? > >>> > >> > >> Hi Jiri. That change mutes the log messages, but I'm still counting > >> around 35000 interrupts per second after resume and touch does not work. > >> With the reset, the device works properly. > > > > Ah, I see. Should your patch then actually replace 1475af255e18f? > > Sorry for the late reply, was off because of Lunar new year. > > Commit 1475af255e18f is to silence the message when using the touchpad, so > it’s different to this patch. > > I’ve seen similar bugs happens on new platforms that defaults S2Idle (Modern > Standby), but user uses S3 instead. > On those systems, S3 was never tested, so the BIOS doesn’t cut the touchpad’s > power off during S3, and the IRQ line wasn’t getting properly reset. > > So if the platform defaults to S2Idle but user wants to use S3, this issue > happens. > If that’s the case, maybe it’s better to report to the platform vendor. > > Kai-Heng > > > > > Thanks, > > > > -- > > Jiri Kosina > > SUSE Labs > > >
Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
> On Feb 15, 2019, at 4:19 PM, Steven Rostedt wrote: > > On Fri, 15 Feb 2019 15:49:35 -0800 > Andy Lutomirski wrote: > >> I’m missing most of the context here, but even probe_kernel_...() is >> unwise for a totally untrustworthy address. It could be MMIO, for >> example. > > True, but kprobes are used like modules, and only allowed by root. They > are used to poke literally anywhere one wants. That's the entire > purpose of kprobes. > >> >> If needed, we could come up with a safe-ish helper for tracing. For >> direct-map addresses, probe_kernel_...() is probably okay. Same for >> the current stack. Otherwise we could walk the page tables and check >> that the address is cacheable, I suppose, although this is slightly >> dubious if we don’t also check MTRRs. We could also check that the PA >> is in main memory, I suppose, although this may have unfortunate >> interactions with the MCE code. > > I added you just because I wanted help getting the change log correct, > as that's what Linus was complaining about. I kept using "kernel > address" when the sample bug used for the patch was really a > non-canonical address (as Linus said, it's just garbage. Neither kernel > or user space). But I pointed out that this can also bug if the > address is canonical and in the kernel address space. The old code > didn't complain about non-canonical or kernel address faulting before > commit 9da3f2b7405, which only talks about kernel address space > faulting (which is why I only mentioned that in my messages). > > Would changing all the mention of "kernel address" to "non user space" > be accurate? > I think “kernel address” is right. It’s illegal to access anything that isn’t known to be a valid kernel address while in KERNEL_DS. The old __copy seems likely to have always been a bit bogus. BTW, what is this probe_mem_read() thing? Some minimal inspection suggests it’s a buggy reimplementation of probe_kernel_read(). Can you delete it and just use probe_kernel_read() directly? > For reference: > > http://lkml.kernel.org/r/20190215174945.557218...@goodmis.org > http://lkml.kernel.org/r/20190215142015.860423...@goodmis.org > > -- Steve
[PATCH -next] ASoC: wm8741: Make function 'wm8741_mute' static
Fixes the following sparse warning:
sound/soc/codecs/wm8741.c:371:5: warning:
symbol 'wm8741_mute' was not declared. Should it be static?
Fixes: 36b1599340b5 ("ASoC: wm8741: Add digital mute callback")
Signed-off-by: Wei Yongjun
---
sound/soc/codecs/wm8741.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8741.c b/sound/soc/codecs/wm8741.c
index a4b8c459ea57..546ea735f534 100644
--- a/sound/soc/codecs/wm8741.c
+++ b/sound/soc/codecs/wm8741.c
@@ -368,7 +368,7 @@ static int wm8741_set_dai_fmt(struct snd_soc_dai *codec_dai,
return 0;
}
-int wm8741_mute(struct snd_soc_dai *codec_dai, int mute)
+static int wm8741_mute(struct snd_soc_dai *codec_dai, int mute)
{
struct snd_soc_component *component = codec_dai->component;
[PATCH -next] misc: fastrpc: Fix return value check in fastrpc_map_create()
In case of error, the function dma_buf_get() returns ERR_PTR() and never
returns NULL. The NULL test in the return value check should be replaced
with IS_ERR().
Signed-off-by: Wei Yongjun
---
drivers/misc/fastrpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 4b0db33896df..7edceaa6adaa 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -496,8 +496,8 @@ static int fastrpc_map_create(struct fastrpc_user *fl, int
fd,
map->fl = fl;
map->fd = fd;
map->buf = dma_buf_get(fd);
- if (!map->buf) {
- err = -EINVAL;
+ if (IS_ERR(map->buf)) {
+ err = PTR_ERR(map->buf);
goto get_err;
}
Re: [PATCH] ARM: dts: rockchip: add chosen node on veyron chromebooks
On Fri, Feb 15, 2019 at 3:09 PM Heiko Stübner wrote: > > Hi Enric, > > Am Freitag, 15. Februar 2019, 12:51:50 CET schrieb Enric Balletbo i Serra: > > In order to use earlycon, the stdout-path property needs to be set > > in the chosen node. > > > > Signed-off-by: Enric Balletbo i Serra > > What's the reason for adding this only for the Chromebook variants? > Uart2 is pretty much the standard output for all devices, so I'd assume > at least all veyron boards should use uart2 as well, making this ideally > live in the rk3288-veyron.dtsi instead? Yep, all veyriants use uart 2, even when they're not chromebooks. Feel free to put it in the other file instead. Otherwise it'll make things like the Asus Chromebit (mickey), AOpen Chromebox mini (fievel), and AOpen Chromebase (tiger) unhappy while debugging. The rk3288-veyron-chromebook.dtsi file is more for things that make a chromebook portable. Ex: built in display, lid switch, cros-ec. Note how we have no uart2 references either in our tree in the chromebook specific dtsi: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi Alexandru Stan (amstan)
[PATCH -next] ASoC: samsung: i2s: Fix return value check in i2s_create_secondary_device()
In case of error, the function platform_device_register_simple() returns
ERR_PTR() and never returns NULL. The NULL test in the return value
check should be replaced with IS_ERR().
Fixes: 7196c64c7d0c ("ASoC: samsung: i2s: Restore support for the secondary
PCM")
Signed-off-by: Wei Yongjun
---
sound/soc/samsung/i2s.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 72f0cb7abb30..15844c00c3cd 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1342,8 +1342,8 @@ static int i2s_create_secondary_device(struct
samsung_i2s_priv *priv)
int ret;
pdev = platform_device_register_simple("samsung-i2s-sec", -1, NULL, 0);
- if (!pdev)
- return -ENOMEM;
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
ret = device_attach(>dev);
if (ret < 0) {
[PATCH] doc: cgroup: correct the wrong information about measure of memory pressure
Since PSI has implemented some kind of measure of memory pressure, the statement about lack of such measure is not true anymore. Cc: Tejun Heo Cc: Johannes Weiner Cc: Jonathan Corbet Signed-off-by: Yang Shi --- Documentation/admin-guide/cgroup-v2.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 7bf3f12..9a92013 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1310,8 +1310,7 @@ network to a file can use all available memory but can also operate as performant with a small amount of memory. A measure of memory pressure - how much the workload is being impacted due to lack of memory - is necessary to determine whether a workload needs more -memory; unfortunately, memory pressure monitoring mechanism isn't -implemented yet. +memory. Memory Ownership -- 1.8.3.1
Re: [PATCH -next] drm: Remove set but not used variable 'gem'
YueHaibing writes: > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/gpu/drm/vc4/vc4_txp.c: In function 'vc4_txp_connector_atomic_check': > drivers/gpu/drm/vc4/vc4_txp.c:252:29: warning: > variable 'gem' set but not used [-Wunused-but-set-variable] > struct drm_gem_cma_object *gem; > ^ > > Signed-off-by: YueHaibing Pushed to drm-misc-next. Thanks! signature.asc Description: PGP signature
[PATCH v2] of: unittest: unflatten device tree on UML when testing
UML supports enabling OF, and is useful for running the device tree
tests, so add support for unflattening device tree blobs so we can
actually use it.
Signed-off-by: Brendan Higgins
---
drivers/of/unittest.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 84427384654d5..6de34d5fa0e85 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -2527,6 +2527,9 @@ static int __init of_unittest(void)
}
of_node_put(np);
+ if (IS_ENABLED(CONFIG_UML))
+ unittest_unflatten_overlay_base();
+
pr_info("start of unittest - you will see error messages\n");
of_unittest_check_tree_linkage();
of_unittest_check_phandles();
--
2.21.0.rc0.258.g878e2cd30e-goog
Re: [PATCH 2/2] Input: add Apple SPI keyboard and trackpad driver.
On Sun, Feb 10, 2019 at 03:18:34AM -0800, Life is hard, and then you die wrote:
> On Wed, Feb 06, 2019 at 10:22:56PM +0200, Andy Shevchenko wrote:
> > On Mon, Feb 04, 2019 at 12:19:47AM -0800, Ronald Tschalär wrote:
> > > +#define debug_print(mask, fmt, ...) \
> > > + do { \
> > > + if (debug & mask) \
> > > + printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); \
> > > + } while (0)
> > > +
> > > +#define debug_print_header(mask) \
> > > + debug_print(mask, "--- %s ---\n", \
> > > + applespi_debug_facility(mask))
> > > +
> > > +#define debug_print_buffer(mask, fmt, ...) \
> > > + do { \
> > > + if (debug & mask) \
> > > + print_hex_dump(KERN_DEBUG, pr_fmt(fmt), \
> > > +DUMP_PREFIX_NONE, 32, 1, ##__VA_ARGS__, \
> > > +false); \
> > > + } while (0)
> >
> > I'm not sure we need all of these... But okay, the driver is
> > reverse-engineered, perhaps we can drop it later on.
>
> These have been extremely useful for debugging; but yes, they are for
> debugging only. They also explicitly do not use the dynamic-debug
> facilities because
> 1. those can't be enabled at a function or line level on the kernel
> command line (the docs indicate this should work, but it doesn't,
> or at the very least I've been unable to figure out how, at least
> for those drivers built as modules)
Hmm... Usually you put either module_name.dyndbg into kernel command line to
enable Dynamic Debug on built-in modules, or modprobe module_name dyndbg if
it's built as a module.
> 2. the expressions to enable them quite brittle (in particular the
> line-based ones) since they (may) change any time the code is
> changed - having stable commands to give to users and put in
> documentation (e.g.
> "echo 0x200 > /sys/module/applespi/parameters/debug") is
> quite valuable.
> 3. In at least two places we log different types of packets in the
> same lines of code - dynamic-debug would only allow enabling or
> disabling logging of all packets, unless we do something like
> create separate functions for logging each type of packet.
> > > +static unsigned int fnmode = 1;
> > > +module_param(fnmode, uint, 0644);
> > > +MODULE_PARM_DESC(fnmode, "Mode of fn key on Apple keyboards (0 =
> > > disabled, [1] = fkeyslast, 2 = fkeysfirst)");
> >
> > fn -> Fn ?
>
> The physical key is actually labelled "fn" (no uppercase). But will
> certainly change it if you still wish.
I think Fn would be suitable (on the computer I'm typing this message the
special keys are all marked in small case, but we don't change HP driver to
state 'ctrl' instead 'Ctrl', for example, do we?).
> > Btw, do we need all these parameters? Can't we do modify behaviour run-time
> > using some Input framework facilities?
>
> I'm not aware of any way to do so. I suppose the event callback could
> be used/extended to send "configuration" data, but that would require
> changes to the input core.
>
> Also, for what it's worth, current drivers such as hid-apple (from
> which 'fnmode' and 'iso_layout' were copied and intentionally kept the
> same) use this approach too.
Hmm... Okay, I leave this to Input maintainers.
> > > +static int touchpad_dimensions[4];
> > > +module_param_array(touchpad_dimensions, int, NULL, 0444);
> > > +MODULE_PARM_DESC(touchpad_dimensions, "The pixel dimensions of the
> > > touchpad, as x_min,x_max,y_min,y_max .");
> >
> > We have some parsers for similar data as in format
> >
> > %dx%d%+d%+d ?
> >
> > For example, 200x100+20+10.
>
> Maybe it's just my grep-foo that is lacking, but I couldn't find
> anything useful. There is some stuff for framebuffer video modes, but
> that is too different and not really amenable for use here. OTOH, a
> simple sscanf(buf, "%dx%d+%d+%d", ...) would parse this just fine
> without the need for any fancier parser.
>
> OTOH, I'm not sure this format is any better: internally we need
> x/y min/max, not x/y/w/h (though obviously the two are trivially
> convertable); and for the user it doesn't really matter since they would
> basically be getting the dimensions from running with debug set to
> 0x1 and using that output to set this param, i.e. I don't see any
> inherent advantage of using x/y/w/h.
I would stick with some more or less standard notation. The XxY+W+H is widely
used in X11 world.
If you have better examples for input devices, choose them. My point that it
would be better to be a standard to some extent.
> > > +/**
> > > + * struct keyboard_protocol - keyboard message.
> > > + * message.type = 0x0110, message.length = 0x000a
> > > + *
> > > + * @unknown1:unknown
> > > + * @modifiers: bit-set of modifier/control keys pressed
> > > + * @unknown2:unknown
> > > + * @keys_pressed:the (non-modifier) keys currently pressed
> > > + * @fn_pressed: whether the
RE: [PATCH V4 2/2] clk: imx: scu: add cpu frequency scaling support
Hi, Stephen Best Regards! Anson Huang > -Original Message- > From: Stephen Boyd [mailto:sb...@kernel.org] > Sent: 2019年2月16日 7:58 > To: devicet...@vger.kernel.org; feste...@gmail.com; > ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org; linux- > c...@vger.kernel.org; linux-kernel@vger.kernel.org; mark.rutl...@arm.com; > mturque...@baylibre.com; robh...@kernel.org; s.ha...@pengutronix.de; > shawn...@kernel.org; viresh.ku...@linaro.org; Aisheng Dong > ; Anson Huang ; Daniel > Baluta > Cc: dl-linux-imx > Subject: Re: [PATCH V4 2/2] clk: imx: scu: add cpu frequency scaling support > > Quoting Anson Huang (2019-02-13 17:54:08) > > On NXP's i.MX SoCs with system controller inside, CPU frequency > > scaling can ONLY be done by system controller firmware, and it can > > ONLY be requested from secure mode, so Linux kernel has to call ARM > > SMC to trap to ARM-Trusted-Firmware to request system controller > > firmware to do CPU frequency scaling. > > > > This patch adds i.MX system controller CPU frequency scaling support, > > it reuses cpufreq-dt driver and implement the CPU frequency scaling > > inside SCU clock driver. > > > > Signed-off-by: Anson Huang > > --- > > Acked-by: Stephen Boyd > > Unless you wanted me to pick this patch up into clk-next? Yes, please, we want to support cpu-freq scaling in Linux next tree ASAP. Thanks, Anson.
Re: [PATCH V6 2/2] clk: imx: scu: add cpu frequency scaling support
Quoting Anson Huang (2019-02-14 01:55:57) > On NXP's i.MX SoCs with system controller inside, CPU frequency > scaling can ONLY be done by system controller firmware, and it > can ONLY be requested from secure mode, so Linux kernel has to > call ARM SMC to trap to ARM-Trusted-Firmware to request system > controller firmware to do CPU frequency scaling. > > This patch adds i.MX system controller CPU frequency scaling support, > it reuses cpufreq-dt driver and implement the CPU frequency scaling > inside SCU clock driver. > > Signed-off-by: Anson Huang > --- Acked-by: Stephen Boyd
Re: [PATCH net-next 1/3] net: stmmac: Fix NAPI poll in TX path when in multi-queue
On 2/15/19 5:42 AM, Jose Abreu wrote:
> Commit 8fce33317023 introduced the concept of NAPI per-channel and
> independent cleaning of TX path.
>
> This is currently breaking performance in some cases. The scenario
> happens when all packets are being received in Queue 0 but the TX is
> performed in Queue != 0.
>
> Fix this by using different NAPI instances per each TX and RX queue, as
> suggested by Florian.
>
> Signed-off-by: Jose Abreu
> Cc: Florian Fainelli
> Cc: Joao Pinto
> Cc: David S. Miller
> Cc: Giuseppe Cavallaro
> Cc: Alexandre Torgue
> ---
[snip]
> - if (work_done < budget && napi_complete_done(napi, work_done)) {
> - int stat;
> + priv->xstats.napi_poll++;
>
> + work_done = stmmac_tx_clean(priv, budget, chan);
> + if (work_done < budget && napi_complete_done(napi, work_done))
You should not be bounding your TX queue against the NAPI budge, it
should run unbound and clean as much as it can, which could be the
entire ring size if that is how many packets you pushed between
interrupts. That could be the cause of poor performance as well.
--
Florian
Re: [PATCH net-next v2 0/9] net: Get rid of switchdev_port_attr_get()
On 2/15/19 2:53 PM, Florian Fainelli wrote: > Hi all, > > This patch series splits the removal of the switchdev_ops that was > proposed a few times before and first tackles the easy part which is the > removal of the single call to switchdev_port_attr_get() within the > bridge code. > > As suggestd by Ido, this patch series adds a > SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS which is used in the same > context as the caller of switchdev_port_attr_set(), so not deferred, and > then the operation is carried out in deferred context with setting a > support bridge port flag. > > Follow-up patches will do the switchdev_ops removal after introducing > the proper helpers for the switchdev blocking notifier to work across > stacked devices (unlike the previous submissions). David, please ignore this version, I will repost one that actually builds, need to keep mangling with my kernel configuration and keep those drivers enabled... > > Changes in v2: > > - differentiate callers not supporting switchdev_port_attr_set() from > the driver not being able to support specific bridge flags > > - pass "mask" instead of "flags" for the PRE_BRIDGE_FLAGS check > > - skip prepare phase for PRE_BRIDGE_FLAGS > > - corrected documentation a bit more > > - tested bridge_vlan_aware.sh with veth/VRF > > Florian Fainelli (9): > Documentation: networking: switchdev: Update port parent ID section > net: switchdev: Add PORT_PRE_BRIDGE_FLAGS > mlxsw: spectrum: Handle PORT_PRE_BRIDGE_FLAGS > staging: fsl-dpaa2: ethsw: Handle PORT_PRE_BRIDGE_FLAGS > net: dsa: Add setter for SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS > rocker: Check Handle PORT_PRE_BRIDGE_FLAGS > net: bridge: Stop calling switchdev_port_attr_get() > net: Remove SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT > net: Get rid of switchdev_port_attr_get() > > Documentation/networking/switchdev.txt| 16 ++-- > .../mellanox/mlxsw/spectrum_switchdev.c | 38 +- > drivers/net/ethernet/rocker/rocker_main.c | 75 +++ > drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 32 > include/net/switchdev.h | 13 +--- > net/bridge/br_switchdev.c | 11 ++- > net/dsa/dsa_priv.h| 6 ++ > net/dsa/port.c| 17 + > net/dsa/slave.c | 24 +++--- > 9 files changed, 128 insertions(+), 104 deletions(-) > -- Florian
Re: [PATCH] clk: samsung: s3c2443: Mark expected switch fall-through
Quoting Kees Cook (2019-02-12 10:57:05) > On Mon, Feb 11, 2019 at 11:41 PM Krzysztof Kozlowski wrote: > > > > It is just the GCC which has to be fixed not the code. You want to > > adjust the code for specific version of GCC and what if GCC changes > > its warning? For example GCC might require "fall through: "... or any > > other syntax. Another point - what about clang's syntax? > > -Wimplicit-fallthrough=3 is stricter and maps to -Wextra, hence its > choice. GCC's levels were chosen based on the existing linters, static > analyzers, etc. The patterns are unlikely to change (see the gcc > man-page). > > Clang doesn't recognize anything in C mode (hopefully this will be > fixed in the future[1]). > > As long as one of the compilers is able to check this, we'll avoid the > bugs associated with this mis-pattern. Gustavo's efforts here have > found kind of a lot of bugs, so I think it's worth a little churn to > add these (and make minor adjustments to existing comments). Just curious, what compilation phase does this check run in? Could we gain a macro like FALLTHRU or even lowercase 'fallthru' that expanded to whatever the compiler wants to see and then there would only be "one way" to do this? It would alleviate the above concerns, but maybe I'm rehashing something that's already been proposed and rejected. Of course, I'm happy to merge any of these patches that tweak things so no worries either way.
Re: [RFC v4 15/17] of: unittest: migrate tests to run on KUnit
On 2/14/19 1:37 PM, Brendan Higgins wrote:
> Migrate tests without any cleanup, or modifying test logic in anyway to
> run under KUnit using the KUnit expectation and assertion API.
>
> Signed-off-by: Brendan Higgins
> ---
> drivers/of/Kconfig|1 +
> drivers/of/unittest.c | 1310 +
> 2 files changed, 671 insertions(+), 640 deletions(-)
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index ad3fcad4d75b8..f309399deac20 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -15,6 +15,7 @@ if OF
> config OF_UNITTEST
> bool "Device Tree runtime unit tests"
> depends on !SPARC
> + depends on KUNIT
> select IRQ_DOMAIN
> select OF_EARLY_FLATTREE
> select OF_RESOLVE
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
These comments are from applying the patches to 5.0-rc3.
The final hunk of this patch fails to apply because it depends upon
[PATCH v1 0/1] of: unittest: unflatten device tree on UML when testing.
If I apply that patch then I can apply patches 15 through 17.
If I apply patches 1 through 14 and boot the uml kernel then the devicetree
unittest result is:
### dt-test ### FAIL of_unittest_overlay_high_level():2372 overlay_base_root
not initialized
### dt-test ### end of unittest - 219 passed, 1 failed
This is as expected from your previous reports, and is fixed after
applying
[PATCH v1 0/1] of: unittest: unflatten device tree on UML when testing.
with the devicetree unittest result of:
### dt-test ### end of unittest - 224 passed, 0 failed
After adding patch 15, there are a lot of "unittest internal error" messages.
-Frank
> index effa4e2b9d992..96de69ccb3e63 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -26,186 +26,189 @@
>
> #include
>
> +#include ### dt-test ### end of unittest - 224 passed, 0 failed
> +
> #include "of_private.h"
>
> -static struct unittest_results {
> - int passed;
> - int failed;
> -} unittest_results;
> -
> -#define unittest(result, fmt, ...) ({ \
> - bool failed = !(result); \
> - if (failed) { \
> - unittest_results.failed++; \
> - pr_err("FAIL %s():%i " fmt, __func__, __LINE__, ##__VA_ARGS__);
> \
> - } else { \
> - unittest_results.passed++; \
> - pr_debug("pass %s():%i\n", __func__, __LINE__); \
> - } \
> - failed; \
> -})
> -
> -static void __init of_unittest_find_node_by_name(void)
> +static void of_unittest_find_node_by_name(struct kunit *test)
> {
> struct device_node *np;
> const char *options, *name;
>
> np = of_find_node_by_path("/testcase-data");
> name = kasprintf(GFP_KERNEL, "%pOF", np);
> - unittest(np && !strcmp("/testcase-data", name),
> - "find /testcase-data failed\n");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> + KUNIT_EXPECT_STREQ_MSG(test, "/testcase-data", name,
> +"find /testcase-data failed\n");
> of_node_put(np);
> kfree(name);
>
> /* Test if trailing '/' works */
> - np = of_find_node_by_path("/testcase-data/");
> - unittest(!np, "trailing '/' on /testcase-data/ should fail\n");
> + KUNIT_EXPECT_EQ_MSG(test, of_find_node_by_path("/testcase-data/"), NULL,
> + "trailing '/' on /testcase-data/ should fail\n");
>
> np = of_find_node_by_path("/testcase-data/phandle-tests/consumer-a");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> name = kasprintf(GFP_KERNEL, "%pOF", np);
> - unittest(np && !strcmp("/testcase-data/phandle-tests/consumer-a", name),
> + KUNIT_EXPECT_STREQ_MSG(
> + test, "/testcase-data/phandle-tests/consumer-a", name,
> "find /testcase-data/phandle-tests/consumer-a failed\n");
> of_node_put(np);
> kfree(name);
>
> np = of_find_node_by_path("testcase-alias");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> name = kasprintf(GFP_KERNEL, "%pOF", np);
> - unittest(np && !strcmp("/testcase-data", name),
> - "find testcase-alias failed\n");
> + KUNIT_EXPECT_STREQ_MSG(test, "/testcase-data", name,
> +"find testcase-alias failed\n");
> of_node_put(np);
> kfree(name);
>
> /* Test if trailing '/' works on aliases */
> - np = of_find_node_by_path("testcase-alias/");
> - unittest(!np, "trailing '/' on testcase-alias/ should fail\n");
> + KUNIT_EXPECT_EQ_MSG(test, of_find_node_by_path("testcase-alias/"), NULL,
> + "trailing '/' on testcase-alias/ should fail\n");
>
> np = of_find_node_by_path("testcase-alias/phandle-tests/consumer-a");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> name = kasprintf(GFP_KERNEL, "%pOF", np);
> - unittest(np && !strcmp("/testcase-data/phandle-tests/consumer-a", name),
> + KUNIT_EXPECT_STREQ_MSG(
> + test,
Re: [PATCH 6/8] ARM: at91: pm: add ULP1 support for SAM9X60
Quoting claudiu.bez...@microchip.com (2019-02-14 07:54:57) > From: Claudiu Beznea > > Add ULP1 support for SAM9X60. In pm_suspend.S enable RC oscillator in > PMC if it is not enabled. At resume the state before suspend is > restored. > > Signed-off-by: Claudiu Beznea > --- > include/linux/clk/at91_pmc.h| 1 + Acked-by: Stephen Boyd
Re: [PATCH v2 05/11] mfd: pm8xxx: disassociate old virq if hwirq mapping already exists
On Fri, Feb 15, 2019 at 01:28:02PM -0800, Stephen Boyd wrote:
> Quoting Brian Masney (2019-02-15 05:47:33)
> > On Thu, Feb 14, 2019 at 09:51:26PM -0800, Stephen Boyd wrote:
> > > > diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> > > > index 8eb2528793f9..2f99a98ccee5 100644
> > > > --- a/drivers/mfd/qcom-pm8xxx.c
> > > > +++ b/drivers/mfd/qcom-pm8xxx.c
> > > > @@ -380,6 +380,12 @@ static void pm8xxx_irq_domain_map(struct
> > > > pm_irq_chip *chip,
> > > > struct irq_domain *domain, unsigned
> > > > int irq,
> > > > irq_hw_number_t hwirq, unsigned int
> > > > type)
> > > > {
> > > > + unsigned int old_virq;
> > > > +
> > > > + old_virq = irq_find_mapping(domain, hwirq);
> > > > + if (old_virq)
> > > > + irq_domain_disassociate(domain, old_virq);
> > >
> > > Is it possible to pass 'true' for the 'realloc' argument to
> > > __irq_domain_alloc_irqs() and then this disassociate change isn't
> > > needed?
> >
> > The kernel doc for __irq_domain_alloc_irqs() says that the realloc
> > parameter is mainly to support legacy IRQs. I don't think its a good
> > idea to add new code that'll stay past the end of this patch series
> > on top of that legacy interface.
> >
>
> Ok. The other side of the argument is that this is the only user of
> irq_domain_disassociate(), which may also be some sort of legacy
> interface that isn't supposed to be used. Looking at the commit that
> exposed it, it seems to be that it's there for legacy reasons.
>
> commit 43a775916d63d1c822107b39987192ca5ced445c
> Author: Jiang Liu
> Date: Mon Jun 9 16:20:05 2014 +0800
>
> genirq: Export irq_domain_disassociate() to architecture interrupt drivers
>
> Export irq_domain_disassociate() to architecture interrupt drivers,
> so it could be used to handle legacy IRQ descriptors on x86.
>
> So maybe we should just use the realloc argument and bury the
> disassociate API in irqdomain.c because it's not supposed to be used?
> Or does the realloc path not work for some reason?
I haven't tried the realloc path yet. Let's back up further so that we
are both starting with the same assumptions. Do you want to keep either
your proposed change (realloc argument) or the existing
irq_domain_disassociate change in mainline past the end of this patch
series? If it is going to continue to be a temporary shim that will be
reverted at the end of the patch series (like I did here), then I don't
see the point in this extra work since this patch is only here to keep
it bisectable and works. We're not using any legacy interfaces by the
end of this patch series.
Brian
Re: [PATCH net-next v5] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
On 14/02/2019 04:44, Callum Sinclair wrote:
> Currently the only way to clear the forwarding cache was to delete the
> entries one by one using the MRT_DEL_MFC socket option or to destroy and
> recreate the socket.
>
> Create a new socket option which with the use of optional flags can
> clear any combination of multicast entries (static or not static) and
> multicast vifs (static or not static).
>
> Calling the new socket option MRT_FLUSH with the flags MRT_FLUSH_MFC and
> MRT_FLUSH_VIFS will clear all entries and vifs on the socket except for
> static entries.
>
> Signed-off-by: Callum Sinclair
> ---
> v1 -> v2:
> Implemented additional flags for static entries
> v2 -> v3:
> Cleaned up flag logic so any combination of routes can be cleared.
> Fixed style errors
> Fixed incorrect flag values
> v3 -> v4:
> Fixed style errors
> Fixed incorrect flag (MRT_FLUSH was used instead of MRT_FLUSH_VIFS)
> v4 -> v5:
> Only clear the unresolved queue when MRT_FLUSH_MFC flag is set.
>
> include/uapi/linux/mroute.h | 9 -
> include/uapi/linux/mroute6.h | 9 -
> net/ipv4/ipmr.c | 75 +-
> net/ipv6/ip6mr.c | 78 +++-
> 4 files changed, 115 insertions(+), 56 deletions(-)
>
+1 about Nicolas' comments, other than that looks good:
Signed-off-by: Nikolay Aleksandrov
> diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
> index 5d37a9ccce63..11c8c1fc1124 100644
> --- a/include/uapi/linux/mroute.h
> +++ b/include/uapi/linux/mroute.h
> @@ -28,12 +28,19 @@
> #define MRT_TABLE(MRT_BASE+9)/* Specify mroute table ID
> */
> #define MRT_ADD_MFC_PROXY(MRT_BASE+10) /* Add a (*,*|G) mfc entry
> */
> #define MRT_DEL_MFC_PROXY(MRT_BASE+11) /* Del a (*,*|G) mfc entry
> */
> -#define MRT_MAX (MRT_BASE+11)
> +#define MRT_FLUSH(MRT_BASE+12) /* Flush all mfc entries and/or vifs
> */
> +#define MRT_MAX (MRT_BASE+12)
>
> #define SIOCGETVIFCNTSIOCPROTOPRIVATE/* IP protocol privates
> */
> #define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
> #define SIOCGETRPF (SIOCPROTOPRIVATE+2)
>
> +/* MRT_FLUSH optional flags */
> +#define MRT_FLUSH_MFC1 /* Flush multicast entries */
> +#define MRT_FLUSH_MFC_STATIC 2 /* Flush static multicast entries */
> +#define MRT_FLUSH_VIFS 4 /* Flush multicast vifs */
> +#define MRT_FLUSH_VIFS_STATIC8 /* Flush static multicast vifs
> */
> +
> #define MAXVIFS 32
> typedef unsigned long vifbitmap_t; /* User mode code depends on this lot */
> typedef unsigned short vifi_t;
> diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
> index cc006390..ac84ef11b29c 100644
> --- a/include/uapi/linux/mroute6.h
> +++ b/include/uapi/linux/mroute6.h
> @@ -31,12 +31,19 @@
> #define MRT6_TABLE (MRT6_BASE+9) /* Specify mroute table ID
> */
> #define MRT6_ADD_MFC_PROXY (MRT6_BASE+10) /* Add a (*,*|G) mfc entry
> */
> #define MRT6_DEL_MFC_PROXY (MRT6_BASE+11) /* Del a (*,*|G) mfc entry
> */
> -#define MRT6_MAX (MRT6_BASE+11)
> +#define MRT6_FLUSH (MRT6_BASE+12) /* Flush all mfc entries and/or vifs
> */
> +#define MRT6_MAX (MRT6_BASE+12)
>
> #define SIOCGETMIFCNT_IN6SIOCPROTOPRIVATE/* IP protocol privates
> */
> #define SIOCGETSGCNT_IN6 (SIOCPROTOPRIVATE+1)
> #define SIOCGETRPF (SIOCPROTOPRIVATE+2)
>
> +/* MRT6_FLUSH optional flags */
> +#define MRT6_FLUSH_MFC 1 /* Flush multicast entries */
> +#define MRT6_FLUSH_MFC_STATIC2 /* Flush static multicast
> entries */
> +#define MRT6_FLUSH_VIFS 4 /* Flushing multicast vifs */
> +#define MRT6_FLUSH_VIFS_STATIC 8 /* Flush static multicast vifs
> */
> +
> #define MAXMIFS 32
> typedef unsigned long mifbitmap_t; /* User mode code depends on this lot */
> typedef unsigned short mifi_t;
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index e536970557dd..53869779af74 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -110,7 +110,7 @@ static int ipmr_cache_report(struct mr_table *mrt,
> static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
>int cmd);
> static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
> -static void mroute_clean_tables(struct mr_table *mrt, bool all);
> +static void mroute_clean_tables(struct mr_table *mrt, int flags);
> static void ipmr_expire_process(struct timer_list *t);
>
> #ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
> @@ -415,7 +415,8 @@ static struct mr_table *ipmr_new_table(struct net *net,
> u32 id)
> static void ipmr_free_table(struct mr_table *mrt)
> {
> del_timer_sync(>ipmr_expire_timer);
> - mroute_clean_tables(mrt, true);
> + mroute_clean_tables(mrt, MRT_FLUSH_VIFS | MRT_FLUSH_VIFS_STATIC |
Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch
On Fri, Feb 15, 2019 at 3:34 PM Peter Zijlstra wrote: > > Now, EFLAGS bit 1 is supposedly always 1, but it really doesn't seem to > matter for POPF. Correct, it's "read as 1", you can try to write it and it doesn't matter. > I went through the other flags, and aside from VIP/VIF (I've no clue), > they looks like 0 should be just fine. So 0 is a perfectly valid initializer in the sense that it _works_, I just want it to be something that was thought about, not just a random "initialize to zero" without thinking. Even just a comment about it would be fine. But it might also be good to show that it's an explicit eflags value and just use X86_EFLAGS_FIXED as the initializer. Linus
[PATCH] platform/x86: intel_pmc_core: Avoid a u32 overflow
The register (SLP_S0_RES) at offset slp_s0_offset is a 32 bit register.
The pmc_core_adjust_slp_s0_step() could overflow the u32 value while
returning it after adjusting the step. Thus change to u64, this is
already accounted for in debugfs attribute (that wants to output a
64 bit value).
Signed-off-by: Rajat Jain
---
drivers/platform/x86/intel_pmc_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel_pmc_core.c
b/drivers/platform/x86/intel_pmc_core.c
index 22dbf115782e..f90f4dd25151 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -328,9 +328,9 @@ static inline void pmc_core_reg_write(struct pmc_dev
*pmcdev, int
writel(val, pmcdev->regbase + reg_offset);
}
-static inline u32 pmc_core_adjust_slp_s0_step(u32 value)
+static inline u64 pmc_core_adjust_slp_s0_step(u32 value)
{
- return value * SPT_PMC_SLP_S0_RES_COUNTER_STEP;
+ return (u64)value * SPT_PMC_SLP_S0_RES_COUNTER_STEP;
}
static int pmc_core_dev_state_get(void *data, u64 *val)
--
2.21.0.rc0.258.g878e2cd30e-goog
Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
On Fri, 15 Feb 2019 15:49:35 -0800 Andy Lutomirski wrote: > I’m missing most of the context here, but even probe_kernel_...() is > unwise for a totally untrustworthy address. It could be MMIO, for > example. True, but kprobes are used like modules, and only allowed by root. They are used to poke literally anywhere one wants. That's the entire purpose of kprobes. > > If needed, we could come up with a safe-ish helper for tracing. For > direct-map addresses, probe_kernel_...() is probably okay. Same for > the current stack. Otherwise we could walk the page tables and check > that the address is cacheable, I suppose, although this is slightly > dubious if we don’t also check MTRRs. We could also check that the PA > is in main memory, I suppose, although this may have unfortunate > interactions with the MCE code. I added you just because I wanted help getting the change log correct, as that's what Linus was complaining about. I kept using "kernel address" when the sample bug used for the patch was really a non-canonical address (as Linus said, it's just garbage. Neither kernel or user space). But I pointed out that this can also bug if the address is canonical and in the kernel address space. The old code didn't complain about non-canonical or kernel address faulting before commit 9da3f2b7405, which only talks about kernel address space faulting (which is why I only mentioned that in my messages). Would changing all the mention of "kernel address" to "non user space" be accurate? For reference: http://lkml.kernel.org/r/20190215174945.557218...@goodmis.org http://lkml.kernel.org/r/20190215142015.860423...@goodmis.org -- Steve
[PATCH] i2c: Allow recovery of the initial IRQ by a i2c client device.
A previous change allowed i2c client devices to discover new IRQs upon
reprobe. By clearing the IRQ in i2c_device_remove. However, if an IRQ was
assigned in i2c_new_device, that information is lost.
For example, the touchscreen and trackpad devices on a Dell Inspiron laptop
are I2C devices whose IRQs are defined by ACPI extended IRQ types. The
client device structures are initialized during an ACPI walk. After
removing the i2c_hid device, modprobe fails.
This change caches the initial IRQ value in i2c_new_device and then resets
the client device IRQ to the initial value in i2c_device_remove.
Fixes: 6f108dd70d30 ("i2c: Clear client->irq in i2c_device_remove")
Signed-off-by: Jim Broadus
---
drivers/i2c/i2c-core-base.c | 9 +
include/linux/i2c.h | 1 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 28460f6a60cc..af87a16ac3a5 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -430,7 +430,7 @@ static int i2c_device_remove(struct device *dev)
dev_pm_clear_wake_irq(>dev);
device_init_wakeup(>dev, false);
- client->irq = 0;
+ client->irq = client->init_irq;
return status;
}
@@ -741,10 +741,11 @@ i2c_new_device(struct i2c_adapter *adap, struct
i2c_board_info const *info)
client->flags = info->flags;
client->addr = info->addr;
- client->irq = info->irq;
- if (!client->irq)
- client->irq = i2c_dev_irq_from_resources(info->resources,
+ client->init_irq = info->irq;
+ if (!client->init_irq)
+ client->init_irq = i2c_dev_irq_from_resources(info->resources,
info->num_resources);
+ client->irq = client->init_irq;
strlcpy(client->name, info->type, sizeof(client->name));
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 65b4eaed1d96..7e748648c7d3 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -333,6 +333,7 @@ struct i2c_client {
char name[I2C_NAME_SIZE];
struct i2c_adapter *adapter;/* the adapter we sit on*/
struct device dev; /* the device structure */
+ int init_irq; /* irq set at initialization*/
int irq;/* irq issued by device */
struct list_head detected;
#if IS_ENABLED(CONFIG_I2C_SLAVE)
--
2.20.1
Re: Crash in list_add_leaf_cfs_rq due to bad tmp_alone_branch
Hi Vincent,
On Fri, Jan 25, 2019 at 6:31 AM Vincent Guittot
wrote:
>
> Hi Sargun,
>
> On Mon, 21 Jan 2019 at 15:46, Vincent Guittot
> wrote:
> >
> > Hi Sargun,
> >
> > Le Friday 18 Jan 2019 à 15:06:28 (+0100), Vincent Guittot a écrit :
> > > On Fri, 18 Jan 2019 at 11:16, Vincent Guittot
> > > wrote:
> > > >
> > > > On Wed, 9 Jan 2019 at 23:43, Sargun Dhillon wrote:
> > > > >
> > > > > On Wed, Jan 9, 2019 at 2:14 PM Sargun Dhillon
> > > > > wrote:
> > > > > >
> > > > > > I picked up c40f7d74c741a907cfaeb73a7697081881c497d0 sched/fair: Fix
> > > > > > infinite loop in update_blocked_averages() by reverting a9e7f6544b9c
> > > > > > and put it on top of 4.19.13. In addition to this, I uninlined
> > > > > > list_add_leaf_cfs_rq for debugging.
> > >
> > > With the fix above applied, the code that manages the leaf_cfs_rq_list
> > > is the same since v4.9.
> > > Have you noticed similar problem on other older kernel version between
> > > v4.9 and v4.19 ? The problem might have been introduce while modifying
> > > other part of the scheduler like the sequence for adding/removing
> > > cgroup.
> > >
> > > Knowing the most recent kernel version without the problem could help
> > > to narrow the problem
> > >
> > > Thanks,
> > > Vincent
> > >
> > > > > >
> > > > > > This revealed a new bug that we didn't get to because we kept
> > > > > > getting
> > > > > > crashes from the previous issue. When we are running with cgroups
> > > > > > that
> > > > > > are rapidly changing, with CFS bandwidth control, and in addition
> > > > > > using the cpusets cgroup, we see this crash. Specifically, it seems
> > > > > > to
> > > > > > occur with cgroups that are throttled and we change the allowed
> > > > > > cpuset.
> > > >
> > > > Thanks for the context, I will try to reproduce the problem and
> > > > understand how we can stop in the middle of walking to the
> > > > sched_entity branch with a parent not already added
> > > >
> > > > How many cgroup level have you got in you setup ?
> > > >
> > > > > >
> > > > >
> > > > > This patch from Gabriel should fix the problem:
> > > > >
> > > > >
> > > > > [PATCH] sched/fair: Reset tmp_alone_branch on cfs_rq delete
> > > > >
> > > > > When a child cfs_rq is added to the leaf cfs_rq list before its parent
> > > > > tmp_alone_branch is set to point to the child in preparation for the
> > > > > parent being added.
> > > > >
> > > > > If the child is deleted before the parent is added then
> > > > > tmp_alone_branch
> > > > > points to a freed cfs_rq. Any future reference to tmp_alone_branch
> > > > > will
> > > > > result in a use after free.
> > > >
> > > > So, the patch below is a temporary fix that helps to recover from the
> > > > situation where tmp_alone_branch doesn't finished back to
> > > > rq->leaf_cfs_rq_list
> > > > But this situation should not happened at the beginning
> >
> > I have been able to reproduce the situation where tmp_alone_branch doesn't
> > point to rq->leaf_cfs_rq_list after enqueuing a task.
> >
> > Can you try the patch below which ensures all cfs_rq of a cgroup branch will
> > be added in the list even if throttled ?
>
> Did you get a chance to test this patch ?
>
> Regards,
> Vincent
>
> >
> > The algorithm used to order cfs_rq in rq->leaf_cfs_rq_list assumes that
> > it will walk down to root the 1st time a cfs_rq is used and we will finished
> > to add either a cfs_rq without parent or a cfs_rq with a parent that is
> > already
> > on the list. But this is not always true in presence of throttling.
> > Because a cfs_rq can be throttled even if it has never been used but other
> > CPUS
> > of the cgroup have already used all the bandwdith, we are not sure to go
> > down to
> > the root and add all cfs_rq in the list.
> >
> > Ensure that all cfs_rq will be added in the list even if they are throttled.
> >
> > Signed-off-by: Vincent Guittot
> > ---
> > kernel/sched/fair.c | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 6483834..ae468ab 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -352,6 +352,20 @@ static inline void list_del_leaf_cfs_rq(struct cfs_rq
> > *cfs_rq)
> > }
> > }
> >
> > +static inline void list_add_branch_cfs_rq(struct sched_entity *se, struct
> > rq *rq)
> > +{
> > +struct cfs_rq *cfs_rq;
> > +
> > + for_each_sched_entity(se) {
> > + cfs_rq = cfs_rq_of(se);
> > + list_add_leaf_cfs_rq(cfs_rq);
> > +
> > + /* If parent is already in the list, we can stop */
> > + if (rq->tmp_alone_branch == >leaf_cfs_rq_list)
> > + break;
> > + }
> > +}
> > +
> > /* Iterate through all leaf cfs_rq's on a runqueue: */
> > #define for_each_leaf_cfs_rq(rq, cfs_rq) \
> > list_for_each_entry_rcu(cfs_rq, >leaf_cfs_rq_list,
> > leaf_cfs_rq_list)
> > @@ -5177,6 +5191,9 @@ enqueue_task_fair(struct rq *rq, struct task_struct
> > *p,
[PATCH] x86: uaccess: fix regression in unsafe_get_user
From: Arthur Gautier
When extracting an initramfs, a filename may be near an allocation boundary.
Should that happen, strncopy_from_user will invoke unsafe_get_user which
may cross the allocation boundary. Should that happen, unsafe_get_user will
trigger a page fault, and strncopy_from_user would then bailout to
byte_at_a_time behavior.
unsafe_get_user is unsafe by nature, and rely on pagefault to detect boundaries.
After 9da3f2b74054 ("x86/fault: BUG() when uaccess helpers fault on kernel
addresses")
it may no longer rely on pagefault as the new page fault handler would
trigger a BUG().
This commit allows unsafe_get_user to explicitly trigger pagefaults and
handle them directly with the error target label.
Kernel bug:
[0.965251] Unpacking initramfs...
[1.797025] BUG: pagefault on kernel address 0xae80c0c7e000 in
non-whitelisted uaccess
[1.798992] BUG: unable to handle kernel paging request at ae80c0c7e000
[1.798992] #PF error: [normal kernel read fault]
[1.798992] PGD 68526067 P4D 68526067 PUD 68527067 PMD 67f0d067 PTE 0
[1.798992] Oops: [#1] SMP PTI
[1.798992] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc6+ #14
[1.798992] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[1.798992] RIP: 0010:strncpy_from_user+0x67/0xe0
[1.798992] Code: fe fe 48 39 ca 49 ba 80 80 80 80 80 80 80 80 48 0f 46 ca
31 c0 45 31 db 49 89 c8 4c 89 c1 48 29 c1 48 83 f9 07 76 49 44 89 d9 <4c> 8b 0c
06 85 c9 75 3e 49 8d 0c 19 4c 89 0c 07 49 f7 d1 4c 21 c9
[1.798992] RSP: :ae80c031fc40 EFLAGS: 00050216
[1.798992] RAX: 0040 RBX: fefefefefefefeff RCX:
[1.798992] RDX: 0fe0 RSI: ae80c0c7dfba RDI: 8b3d27cce020
[1.798992] RBP: ff9c R08: 0fe0 R09: caccd29190978b86
[1.798992] R10: 8080808080808080 R11: R12: ae80c0c7dfba
[1.798992] R13: ae80c031fd00 R14: R15:
[1.798992] FS: () GS:8b3d28a0()
knlGS:
[1.798992] CS: 0010 DS: ES: CR0: 80050033
[1.798992] CR2: ae80c0c7e000 CR3: 3a60e001 CR4: 00360eb0
[1.798992] Call Trace:
[1.798992] getname_flags+0x69/0x187
[1.798992] user_path_at_empty+0x1e/0x41
[1.798992] vfs_statx+0x70/0xcc
[1.798992] clean_path+0x41/0xa2
[1.798992] ? parse_header+0x40/0x10a
[1.798992] do_name+0x78/0x2b5
[1.798992] write_buffer+0x27/0x37
[1.798992] flush_buffer+0x34/0x8b
[1.798992] ? md_run_setup+0x8a/0x8a
[1.798992] unlz4+0x20b/0x27c
[1.798992] ? write_buffer+0x37/0x37
[1.798992] ? decompress_method+0x80/0x80
[1.798992] unpack_to_rootfs+0x17a/0x2b7
[1.798992] ? md_run_setup+0x8a/0x8a
[1.798992] ? clean_rootfs+0x159/0x159
[1.798992] populate_rootfs+0x5d/0x105
[1.798992] do_one_initcall+0x86/0x169
[1.798992] ? do_early_param+0x8e/0x8e
[1.798992] kernel_init_freeable+0x16a/0x1f4
[1.798992] ? rest_init+0xaa/0xaa
[1.798992] kernel_init+0xa/0xfa
[1.798992] ret_from_fork+0x35/0x40
You may reproduce the issue with the following initrd:
truncate -s 8388313 a
SECONDFILENAME=
truncate -s 10 $SECONDFILENAME
echo "a\n$SECONDFILENAME" | cpio -o --format=newc | lz4 -l > initrd.img.lz4
This places the second filename in the cpio near the allocation boundary made
by lz4 decompression and should trigger the bug.
Fixes: 9da3f2b74054 ("x86/fault: BUG() when uaccess helpers fault on kernel
addresses")
Cc: Jann Horn
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Pascal Bouchareine
Signed-off-by: Arthur Gautier
---
arch/x86/include/asm/uaccess.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 780f2b42c8efe..2c272dc43e05a 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -724,7 +724,9 @@ static __must_check inline bool user_access_begin(const
void __user *ptr, size_t
do {
\
int __gu_err;
\
__inttype(*(ptr)) __gu_val;
\
+ current->kernel_uaccess_faults_ok++;
\
__get_user_size(__gu_val, (ptr), sizeof(*(ptr)), __gu_err, -EFAULT);
\
+ current->kernel_uaccess_faults_ok--;
\
(x) = (__force __typeof__(*(ptr)))__gu_val;
\
if (unlikely(__gu_err)) goto err_label;
\
} while (0)
--
2.20.1
Re: [PATCH V4 2/2] clk: imx: scu: add cpu frequency scaling support
Quoting Anson Huang (2019-02-13 17:54:08) > On NXP's i.MX SoCs with system controller inside, CPU frequency > scaling can ONLY be done by system controller firmware, and it > can ONLY be requested from secure mode, so Linux kernel has to > call ARM SMC to trap to ARM-Trusted-Firmware to request system > controller firmware to do CPU frequency scaling. > > This patch adds i.MX system controller CPU frequency scaling support, > it reuses cpufreq-dt driver and implement the CPU frequency scaling > inside SCU clock driver. > > Signed-off-by: Anson Huang > --- Acked-by: Stephen Boyd Unless you wanted me to pick this patch up into clk-next?
Re: [PATCH v2 1/2] ARC: U-boot: check arguments paranoidly
[...]
> -char __initdata *uboot_arg;
> +unsigned int __initdata uboot_arg;
Why ?
In both places it is actually used, it is intended as a pointer. The cast for
range check is needed but lets cast there. See below for real reason.
> -static inline int is_kernel(unsigned long addr)
> +static inline bool uboot_arg_invalid(unsigned int addr)
> {
> - if (addr >= (unsigned long)_stext && addr <= (unsigned long)_end)
> - return 1;
> +
> + /* Check that address doesn't clobber resident kernel image */
> + return addr >= (unsigned int)_stext && addr <= (unsigned int)_end;
...
> +
> + /* see if U-boot passed an external Device Tree blob */
> + if (uboot_tag == UBOOT_TAG_DTB) {
> + machine_desc = setup_machine_fdt((void *)uboot_arg);
On a 64-bit paradigm, with LP64 ABI, this will break since int will be 4b, while
pointer 8b.
I'll fix it up locally and push !
-Vineet
Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
> On Feb 15, 2019, at 2:15 PM, Steven Rostedt wrote:
>
> On Fri, 15 Feb 2019 09:55:32 -0800
> Linus Torvalds wrote:
>
>>> On Fri, Feb 15, 2019 at 9:49 AM Steven Rostedt wrote:
>>>
>>> From: Changbin Du
>>>
>>> The userspace can ask kprobe to intercept strings at any memory address,
>>> including invalid kernel address.
>>
>> Again, this is not about a "kernel address" at all.
>>
>> It's neither a kernel address _nor_ a user address. It's an invalid
>> address entirely, and there is nothing that makes it "kernel".
>>
>> Please don't talk about "invalid kernel addresses" when it is no such thing.
>>
>
> Ah, I see what you are saying. The example of the bug that the patch
> fixed used a non-canonical address, which is "garbage", and not kernel
> or user space. Point taken.
>
> But the issue is deeper than that. This code never bugged until the
> following commit was added:
>
> 9da3f2b7405 "x86/fault: BUG() when uaccess helpers fault on kernel addresses"
>
> Before that commit, this worked fine.
>
> In fact, we can trigger the same bug (with a slightly different
> message), if we use a kernel space address.
>
> To test this, I added the following variable somewhere in the code:
>
> void *sdr_ptr = 0x70112200;
>
> And then did the following:
>
> # echo 'p:fault do_sys_open arg=+0(@sdr_ptr):string' >
> /debug/tracing/kprobe_events
>
> Which will read the sdr_ptr variable just like the example did with
> +0(+0(%si)):string.
> But this time I control the what address it is triggered on.
>
> And it crashed with:
>
> [ 1447.876799] BUG: pagefault on kernel address 0x70112200 in
> non-whitelisted uaccess
>
> The above message in the bug in the patch was:
> "BUG: GPF in non-whitelisted uaccess (non-canonical address?)"
>
> [ 1447.885053] BUG: unable to handle kernel paging request at 70112200
> [ 1447.891997] #PF error: [normal kernel read fault]
> [ 1447.896695] PGD 8a212067 P4D 8a212067 PUD 0
> [ 1447.900679] BUG: pagefault on kernel address 0x70112200 in
> non-whitelisted uaccess
> [ 1447.900967] Oops: [#1] PREEMPT SMP PTI
> [ 1447.913394] CPU: 7 PID: 1688 Comm: cat Not tainted 5.0.0-rc5-test+ #28
> [ 1447.919905] Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A,
> BIOS K01 v03.03 07/14/2016
> [ 1447.928843] RIP: 0010:process_fetch_insn+0x1a0/0x470
> [ 1447.933804] Code: ff f0 80 48 03 80 83 80 18 1a 00 00 01 31 c9 eb 10 48 83
> c2 01 85 c0 75 1f 81 f9 ff 0f 00 00 7f 17 0f 1f 00 0f ae e8 44 89 e0 <40> 8a
> 32 0f 1f 00 83 c1 01 40 84 f6 75 d9 65 48 8b 14 25 00 5c 01
> [ 1447.952520] RSP: 0018:b77b80673d08 EFLAGS: 00010246
> [ 1447.957736] RAX: RBX: 91bfb7ab2c30 RCX:
>
> [ 1447.964857] RDX: 70112200 RSI: 97267a80 RDI:
> 7000
> [ 1447.971981] RBP: R08: 70112200 R09:
> 91c014518000
> [ 1447.979105] R10: 91c01451801c R11: 91c0185e5800 R12:
>
> [ 1447.986226] R13: R14: R15:
>
> [ 1447.993342] FS: () GS:91c01a9c()
> knlGS:
> [ 1448.001417] CS: 0010 DS: ES: CR0: 80050033
> [ 1448.007157] CR2: 70112200 CR3: b3f32004 CR4:
> 001606e0
> [ 1448.014280] Call Trace:
> [ 1448.016737] kprobe_trace_func+0x278/0x360
> [ 1448.020834] ? preempt_count_sub+0x98/0xe0
> [ 1448.024931] ? do_sys_open+0x5/0x220
> [ 1448.028503] kprobe_dispatcher+0x36/0x50
> [ 1448.032426] ? do_sys_open+0x1/0x220
> [ 1448.036002] kprobe_ftrace_handler+0xb5/0x120
> [ 1448.040356] ftrace_ops_assist_func+0x87/0x110
> [ 1448.044797] 0xc06a30bf
> [ 1448.047939] ? __ia32_sys_open+0x20/0x20
> [ 1448.051860] ? do_syscall_64+0x1c/0x160
> [ 1448.055694] ? do_sys_open+0x1/0x220
> [ 1448.059268] do_sys_open+0x5/0x220
> [ 1448.062672] do_syscall_64+0x60/0x160
> [ 1448.066335] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Which triggered on the address: 0x70112200
>
> Which is perfectly canonical.
>
> The reason I use "kernel address" is because this became an issue after
> "x86/fault: BUG() when uaccess helpers fault on kernel addresses" was
> added and that explicitly states "kernel address".
>
> That patch added:
>
> + /*
> +* This is a faulting memory access in kernel space, on a kernel
> +* address, in a usercopy function. This can e.g. be caused by
> improper
> +* use of helpers like __put_user and by improper attempts to access
> +* userspace addresses in KERNEL_DS regions.
> +* The one (semi-)legitimate exception are
> probe_kernel_{read,write}(),
> +* which can be invoked from places like kgdb, /dev/mem (for reading)
> +* and privileged BPF code (for reading).
> +* The probe_kernel_*() functions set the kernel_uaccess_faults_ok
> flag
> +* to tell us that faulting on kernel addresses, and even
Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA
On Fri, Feb 15, 2019 at 03:00:31PM -0700, Jason Gunthorpe wrote: > On Fri, Feb 15, 2019 at 06:31:36PM +, Christopher Lameter wrote: > > On Fri, 15 Feb 2019, Matthew Wilcox wrote: > > > > > > Since RDMA is something similar: Can we say that a file that is used for > > > > RDMA should not use the page cache? > > > > > > That makes no sense. The page cache is the standard synchronisation point > > > for filesystems and processes. The only problems come in for the things > > > which bypass the page cache like O_DIRECT and DAX. > > > > It makes a lot of sense since the filesystems play COW etc games with the > > pages and RDMA is very much like O_DIRECT in that the pages are modified > > directly under I/O. It also bypasses the page cache in case you have > > not noticed yet. > > It is quite different, O_DIRECT modifies the physical blocks on the > storage, bypassing the memory copy. > Really? I thought O_DIRECT allowed the block drivers to write to/from user space buffers. But the _storage_ was still under the control of the block drivers? > > RDMA modifies the memory copy. > > pages are necessary to do RDMA, and those pages have to be flushed to > disk.. So I'm not seeing how it can be disconnected from the page > cache? I don't disagree with this. Ira > > Jason
Re: [PATCH v3 8/9] s390: ap: Cleanup on removing the AP device
On 2/14/19 8:51 AM, Pierre Morel wrote:
When the device is remove, we must make sure to
clear the interruption and reset the AP device.
We also need to clear the CRYCB of the guest.
Signed-off-by: Pierre Morel
---
drivers/s390/crypto/vfio_ap_drv.c | 92 +++
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
drivers/s390/crypto/vfio_ap_private.h | 2 +
3 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index 03153e6..50428be 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -5,6 +5,7 @@
* Copyright IBM Corp. 2018
*
* Author(s): Tony Krowiak
+ * Pierre Morel
*/
#include
@@ -12,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include "vfio_ap_private.h"
#define VFIO_AP_ROOT_NAME "vfio_ap"
@@ -64,6 +67,88 @@ static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
return 0;
}
+/*
+ * vfio_ap_drain_queue
+ * @q: the queue to drain
+ *
+ * This function waits until the queue is empty.
+ */
+static void vfio_ap_drain_queue(struct vfio_ap_queue *q)
+{
+ struct ap_queue_status status;
+ int retry = 20;
+
+ status = ap_tapq(q->apqn, NULL);
+ while (!status.queue_empty && retry--) {
+ msleep(200);
+ status = ap_tapq(q->apqn, NULL);
+ }
+ if (retry <= 0) {
+ pr_warn("%s: queue not empty after zapq on apqn 0x%04x\n",
+ __func__, q->apqn);
+ }
+}
+
+/*
+ * vfio_ap_zapq
+ * @q: The queue to zerro
+ *
+ * It is best effort, no return value is done, however on success
+ * we will drain the queue before getting the queue back to the
+ * AP bus.
+ */
+static void vfio_ap_zapq(struct vfio_ap_queue *q)
+{
+ struct ap_queue_status status;
+ int retry = 20;
+
+ do {
+ status = ap_zapq(q->apqn);
+ switch (status.response_code) {
+ case AP_RESPONSE_RESET_IN_PROGRESS:
+ case AP_RESPONSE_BUSY:
+ msleep(20);
+ break;
+ default:
+ pr_warn("%s: zapq error %02x on apqn 0x%04x\n",
+ __func__, status.response_code, q->apqn);
+ return;
+ case AP_RESPONSE_NORMAL:
+ vfio_ap_drain_queue(q);
+ return;
+ }
+ } while (retry--);
+ pr_warn("%s: zapq retry count exceeded code %02x on apqn 0x%04x\n",
+ __func__, status.response_code, q->apqn);
+}
+
+/**
+ * vfio_ap_update_crycb
+ * @q: A pointer to the queue being removed
+ *
+ * We clear the APID of the queue, making this queue unusable for the guest.
+ * After this function we can reset the queue without to fear a race with
+ * the guest to access the queue again.
+ * We do not fear race with the host as we still get the device.
+ */
+static void vfio_ap_update_crycb(struct vfio_ap_queue *q)
+{
+ struct ap_matrix_mdev *matrix_mdev = q->matrix;
+
+ if (!matrix_mdev)
+ return;
+
+ clear_bit_inv(AP_QID_CARD(q->apqn), matrix_mdev->matrix.apm);
+
+ if (!matrix_mdev->kvm)
+ return;
+
+ kvm_arch_crypto_set_masks(matrix_mdev->kvm,
+ matrix_mdev->matrix.apm,
+ matrix_mdev->matrix.aqm,
+ matrix_mdev->matrix.adm);
+}
+
/**
* vfio_ap_queue_dev_remove:
*
@@ -74,6 +159,13 @@ static void vfio_ap_queue_dev_remove(struct ap_device
*apdev)
struct vfio_ap_queue *q;
q = dev_get_drvdata(>device);
+ if (!q)
+ return;
+
+ vfio_ap_update_crycb(q);
The root user is warned in the Limitations section of the vfio-ap.txt
doc delivered with the AP pass-through support warns that the
administrator (i.e., root user) should ensure that AP devices are not
removed without taking proper care to ensure they are not in use by a
guest. I am currently working on a patch set to handle this, so this
may simply get ripped out when those patches are integrated. That may
very well be simultaneously with this patch series as I plan on posting
those soon.
If this call is to remain, then you ought to update the vfio-ap.txt
document to let users know that when queues are unbound, the guests
will lose access to them unbeknown to the admin of the guest.
+ vfio_ap_zapq(q);
One last thing. I've explained before that prior to the AP bus
invoking this remove callback, it flushes and zeroizes the
queue. Why do you insist it needs to be done again in the remove
callback?
+
+ vfio_ap_free_irq(q);
kfree(q);
}
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 5664cf3..7ec957c 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++
Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch
On Fri, Feb 15, 2019 at 06:40:34PM +0100, Peter Zijlstra wrote: > On Fri, Feb 15, 2019 at 09:18:00AM -0800, Linus Torvalds wrote: > > On Thu, Feb 14, 2019 at 11:34 AM Peter Zijlstra > > wrote: > > > > > > Something like the below, right? > > > > > > + frame->flags = 0; > > > + frame->flags = 0; > > > > Those are not valid flag values. > > > > Can you popf them? Yes. > > > > Do they make sense? No. > > > > It has the IF flag clear, for example. Is that intentional? If it is, > > Uhmm. yeah, that's bonkers. We should have interrupts disabled here. > I'll go read up on the eflags and figure out what they _should_ be right > about there. I misread (I'm forever confused about what way around IF goes), but you said it right; IF=0 is interrupts disabled and we very much have that in the middle of context switch. (just for giggles I set IF for the initial flags value; and it comes unstuck _real_ quick) Now, EFLAGS bit 1 is supposedly always 1, but it really doesn't seem to matter for POPF. I went through the other flags, and aside from VIP/VIF (I've no clue), they looks like 0 should be just fine.
Re: [PATCH v3 8/9] s390: ap: Cleanup on removing the AP device
On 2/14/19 8:51 AM, Pierre Morel wrote:
When the device is remove, we must make sure to
clear the interruption and reset the AP device.
We also need to clear the CRYCB of the guest.
Signed-off-by: Pierre Morel
---
drivers/s390/crypto/vfio_ap_drv.c | 92 +++
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
drivers/s390/crypto/vfio_ap_private.h | 2 +
3 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index 03153e6..50428be 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -5,6 +5,7 @@
* Copyright IBM Corp. 2018
*
* Author(s): Tony Krowiak
+ * Pierre Morel
*/
#include
@@ -12,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include "vfio_ap_private.h"
#define VFIO_AP_ROOT_NAME "vfio_ap"
@@ -64,6 +67,88 @@ static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
return 0;
}
+/*
+ * vfio_ap_drain_queue
+ * @q: the queue to drain
+ *
+ * This function waits until the queue is empty.
+ */
+static void vfio_ap_drain_queue(struct vfio_ap_queue *q)
+{
+ struct ap_queue_status status;
+ int retry = 20;
+
+ status = ap_tapq(q->apqn, NULL);
+ while (!status.queue_empty && retry--) {
+ msleep(200);
+ status = ap_tapq(q->apqn, NULL);
+ }
+ if (retry <= 0) {
+ pr_warn("%s: queue not empty after zapq on apqn 0x%04x\n",
+ __func__, q->apqn);
+ }
+}
+
+/*
+ * vfio_ap_zapq
+ * @q: The queue to zerro
+ *
+ * It is best effort, no return value is done, however on success
+ * we will drain the queue before getting the queue back to the
+ * AP bus.
+ */
+static void vfio_ap_zapq(struct vfio_ap_queue *q)
+{
+ struct ap_queue_status status;
+ int retry = 20;
+
+ do {
+ status = ap_zapq(q->apqn);
+ switch (status.response_code) {
+ case AP_RESPONSE_RESET_IN_PROGRESS:
+ case AP_RESPONSE_BUSY:
+ msleep(20);
+ break;
+ default:
+ pr_warn("%s: zapq error %02x on apqn 0x%04x\n",
+ __func__, status.response_code, q->apqn);
+ return;
+ case AP_RESPONSE_NORMAL:
+ vfio_ap_drain_queue(q);
I don't think this is necessary. The zeroize is performed on
each AP-queue entry in an AP queue. My understanding is that when a
reset or zeroize is pending, any AP instructions subsequently issued
are rejected with condition-code 3 indicating an AP queue reset is in
progress. It is also my understanding that once the AP commands
currently executing in a given AP queue entry complete, the queue
entry will be zeroized. So it seems to me that there is no need to
"drain" the queue, it will have already been done by the zeroize.
If you agree we don't need to "drain" the queue, then I'd rather just
make the zapq function in the vfio_ap_ops.c non-static and make it
available to the driver. There is no sense in duplicating this code. In
fact, even if you keep the draining function, you still don't need to
duplicate a zaapq instruction here, you can just call the vfio_ap_ops.c
version and then drain the queue on AP_RESPONSE_NORMAL.
+ return;
+ }
+ } while (retry--);
+ pr_warn("%s: zapq retry count exceeded code %02x on apqn 0x%04x\n",
+ __func__, status.response_code, q->apqn);
+}
+
+/**
+ * vfio_ap_update_crycb
+ * @q: A pointer to the queue being removed
+ *
+ * We clear the APID of the queue, making this queue unusable for the guest.
+ * After this function we can reset the queue without to fear a race with
+ * the guest to access the queue again.
+ * We do not fear race with the host as we still get the device.
+ */
+static void vfio_ap_update_crycb(struct vfio_ap_queue *q)
+{
+ struct ap_matrix_mdev *matrix_mdev = q->matrix;
+
+ if (!matrix_mdev)
+ return;
+
+ clear_bit_inv(AP_QID_CARD(q->apqn), matrix_mdev->matrix.apm);
+
+ if (!matrix_mdev->kvm)
+ return;
+
+ kvm_arch_crypto_set_masks(matrix_mdev->kvm,
+ matrix_mdev->matrix.apm,
+ matrix_mdev->matrix.aqm,
+ matrix_mdev->matrix.adm);
+}
+
/**
* vfio_ap_queue_dev_remove:
*
@@ -74,6 +159,13 @@ static void vfio_ap_queue_dev_remove(struct ap_device
*apdev)
struct vfio_ap_queue *q;
q = dev_get_drvdata(>device);
+ if (!q)
+ return;
+
+ vfio_ap_update_crycb(q);
+ vfio_ap_zapq(q);
+
+ vfio_ap_free_irq(q);
If you make the zapq function in vfio_ap_ops.c available to the driver
rather than duplicating it in this file, you won't need this call
to
Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs
On Fri 2019-02-15 22:41:31, Jacek Anaszewski wrote: > Hi Pavel, > > On 2/14/19 1:28 PM, Pavel Machek wrote: > >Hi! > > > >Jacek, could we get you to comment here? I'd prefer "hardware" trigger... > > What prevents use from using pattern trigger with its hw_pattern file? > > Do you remember drivers/leds/leds-sc27xx-bltc.c and its breathing mode, > for which pattern trigger was introduced? Yes, we can do that. But forget heartbeat and blinking now. Problem I'm getting at is that this LED can either be software controlled (showing for example disk activity) or it can show whether the battery is charging (autonomously, in hardware, will work even after kernel crash). 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: [PATCH v2] tty: serial: meson_uart: Add support for kernel debugger
Julien Masson writes: > The kgdb invokes the poll_put_char and poll_get_char when communicating > with the host. This patch implement the serial polling hooks for the > meson_uart to be used for KGDB debugging over serial line. > > Signed-off-by: Julien Masson Looks good, and very useful thanks! I'm adding this to a testing branch which will get included into the 'integ' branch of my amlogic tree for some broader testing. Kevin
Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs
Hi, On 2/15/19 11:31 PM, Jacek Anaszewski wrote: On 2/15/19 11:26 PM, Hans de Goede wrote: I think that should work fine, which means that we can use the timer and pattern trigger support for the blinking and breathing modes. That still leaves the switching between user and hw-control modes, as discussed the hw-controlled mode could be modelled as a new "hardware" trigger, but then we cannot choose between on/blink/breathing when in hw-controlled mode. As Pavel mentioned, that would require some sort of composed trigger, where we have both the hardware and timer triggers active for example. I think it might be easier to just allow turning on/off the hardware control mode through a special "hardware_control" sysfs attribute and then use the existing timer and pattern triggers for blinking / breathing. Pattern trigger exposes pattern file by default and hw_pattern if pattern_set/get ops are provided. Writing them enables software and hardware pattern respectively. This is not about software vs hardware pattern. There are 2 *orthogonal*, separate problems/challenges with this LED controller: 1) It has hardware blinking and breathing, as discussed this can be controlled through the timer and pattern triggers, so this problem is solved. 2) It has 2 operating modes: a) Automatic/hardware controlled, in this mode the LED is turned off or on (where on can be continues on, blinking or breathing) by the hardware itself, when in this mode we / userspace is not in control of the LED b) Manual/user controlled mode, in this mode we / userspace can control of the LED. Currently there is no API in the ledclass to switch a LED from automatic controlled to user controlled and back, This is what the proposed hardware trigger was for, to switch to automatic mode. A problem with this is that we still want to be able to chose between continues on, blinking or breathing (when on), configure the max brightness, etc. Since there cannot be more then 1 trigger active, with the hardware trigger solution we cannot say we want automatic control (hardware trigger) and blinking when the automatic mode says the LED should be on (timer trigger) as that would mean having 2 triggers active with the hardware trigger solution. As such I think the switch between automatic and manual control would be best exported through a special "hardware_control" sysfs attribute and then use the existing timer and pattern triggers for blinking / breathing. Regards, Hans
Re: [PATCH 1/2] misc: fastrpc: select CONFIG_DMA_SHARED_BUFFER
On 2/15/19 2:40 AM, Srinivas Kandagatla wrote: > Fastrpc is a dma buf exporter as well, so select the corresponding > DMA_SHARED_BUFFER config to fix below compilation errors on platforms > without this config. > > ld: drivers/misc/fastrpc.o: in function 'fastrpc_free_map': > fastrpc.c:(.text+0xbe): undefined reference to 'dma_buf_unmap_attachment' > ld: fastrpc.c:(.text+0xcb): undefined reference to 'dma_buf_detach' > ld: fastrpc.c:(.text+0xd4): undefined reference to 'dma_buf_put' > ld: drivers/misc/fastrpc.o: in function 'fastrpc_map_create': > fastrpc.c:(.text+0xb2b): undefined reference to 'dma_buf_get' > ld: fastrpc.c:(.text+0xb47): undefined reference to 'dma_buf_attach' > ld: fastrpc.c:(.text+0xb61): undefined reference to 'dma_buf_map_attachment' > ld: fastrpc.c:(.text+0xc36): undefined reference to 'dma_buf_put' > ld: fastrpc.c:(.text+0xc48): undefined reference to 'dma_buf_detach' > ld: drivers/misc/fastrpc.o: in function 'fastrpc_device_ioctl': > fastrpc.c:(.text+0x1756): undefined reference to 'dma_buf_get' > ld: fastrpc.c:(.text+0x1776): undefined reference to 'dma_buf_put' > ld: fastrpc.c:(.text+0x1780): undefined reference to 'dma_buf_put' > ld: fastrpc.c:(.text+0x1abf): undefined reference to 'dma_buf_export' > ld: fastrpc.c:(.text+0x1ae7): undefined reference to 'dma_buf_fd' > ld: fastrpc.c:(.text+0x1cb5): undefined reference to 'dma_buf_put' > ld: fastrpc.c:(.text+0x1cca): undefined reference to 'dma_buf_put' > > Reported-by: Randy Dunlap > Signed-off-by: Srinivas Kandagatla Acked-by: Randy Dunlap # build-tested Thanks. > --- > drivers/misc/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 7e0726253755..53cd16f795d6 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -299,6 +299,7 @@ config QCOM_FASTRPC > tristate "Qualcomm FastRPC" > depends on ARCH_QCOM || COMPILE_TEST > depends on RPMSG > + select DMA_SHARED_BUFFER > help > Provides a communication mechanism that allows for clients to > make remote method invocations across processor boundary to > -- ~Randy
Re: [PATCH v3 7/9] s390: ap: implement PAPQ AQIC interception in kernel
On 2/14/19 8:51 AM, Pierre Morel wrote:
We register the AP PQAP instruction hook during the open
of the mediated device. And unregister it on release.
In the AP PQAP instruction hook, if we receive a demand to
enable IRQs,
- we retrieve the vfio_ap_queue based on the APQN we receive
in REG1,
- we retrieve the page of the guest address, (NIB), from
register REG2
- we the mediated device to use the VFIO pinning infratrsucture
to pin the page of the guest address,
- we retrieve the pointer to KVM to register the guest ISC
and retrieve the host ISC
- finaly we activate GISA
If we receive a demand to disable IRQs,
- we deactivate GISA
- unregister from the GIB
- unping the NIB
Signed-off-by: Pierre Morel
---
drivers/s390/crypto/ap_bus.h | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 191 +-
drivers/s390/crypto/vfio_ap_private.h | 2 +
3 files changed, 191 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/crypto/ap_bus.h b/drivers/s390/crypto/ap_bus.h
index bfc66e4..323f2aa 100644
--- a/drivers/s390/crypto/ap_bus.h
+++ b/drivers/s390/crypto/ap_bus.h
@@ -43,6 +43,7 @@ static inline int ap_test_bit(unsigned int *ptr, unsigned int
nr)
#define AP_RESPONSE_BUSY 0x05
#define AP_RESPONSE_INVALID_ADDRESS 0x06
#define AP_RESPONSE_OTHERWISE_CHANGED 0x07
+#define AP_RESPONSE_INVALID_GISA 0x08
#define AP_RESPONSE_Q_FULL0x10
#define AP_RESPONSE_NO_PENDING_REPLY 0x10
#define AP_RESPONSE_INDEX_TOO_BIG 0x11
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 6eddc2c..5664cf3 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -77,6 +77,28 @@ static void vfio_ap_put_queue(struct vfio_ap_queue *q)
q->dev = NULL;
}
+/**
+ * vfio_ap_free_irq:
+ * @q: The vfio_ap_queue
+ *
+ * Unpin the guest NIB
+ * Unregister the ISC from the GIB alert
+ * Clear the vfio_ap_queue intern fields
+ */
+static void vfio_ap_free_irq(struct vfio_ap_queue *q)
+{
+ unsigned long pfn = q->nib >> PAGE_SHIFT;
+
+ if (!q)
+ return;
+ if (q->nib)
+ vfio_unpin_pages(mdev_dev(q->matrix->mdev), , 1);
+ if (q->isc)
+ kvm_s390_gisc_unregister(q->matrix->kvm, q->isc);
+ q->nib = 0;
+ q->isc = 0;
+}
+
static void vfio_ap_matrix_init(struct ap_config_info *info,
struct ap_matrix *matrix)
{
@@ -98,6 +120,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct
mdev_device *mdev)
return -ENOMEM;
}
+ matrix_mdev->mdev = mdev;
vfio_ap_matrix_init(_dev->info, _mdev->matrix);
mdev_set_drvdata(mdev, matrix_mdev);
mutex_lock(_dev->lock);
@@ -781,6 +804,156 @@ static const struct attribute_group
*vfio_ap_mdev_attr_groups[] = {
};
/**
+ * vfio_ap_clrirq: Disable Interruption for a APQN
+ *
+ * @dev: the device associated with the ap_queue
+ * @q: the vfio_ap_queue holding AQIC parameters
+ *
+ * Issue the host side PQAP/AQIC
+ * On success: unpin the NIB saved in *q and unregister from GIB
+ * interface
+ *
+ * Return the ap_queue_status returned by the ap_aqic()
+ */
+static struct ap_queue_status vfio_ap_clrirq(struct vfio_ap_queue *q)
+{
+ struct ap_qirq_ctrl aqic_gisa = {};
+ struct ap_queue_status status;
+
+ status = ap_aqic(q->apqn, aqic_gisa, NULL);
+ if (!status.response_code)
+ vfio_ap_free_irq(q);
+
+ return status;
+}
+
+/**
+ * vfio_ap_setirq: Enable Interruption for a APQN
+ *
+ * @dev: the device associated with the ap_queue
+ * @q: the vfio_ap_queue holding AQIC parameters
+ *
+ * Pin the NIB saved in *q
+ * Register the guest ISC to GIB interface and retrieve the
+ * host ISC to issue the host side PQAP/AQIC
+ *
+ * Response.status may be set to following Response Code in case of error:
+ * - AP_RESPONSE_INVALID_ADDRESS: vfio_pin_pages failed
+ * - AP_RESPONSE_OTHERWISE_CHANGED: Hypervizor GISA internal error
+ *
+ * Otherwise return the ap_queue_status returned by the ap_aqic()
+ */
+static struct ap_queue_status vfio_ap_setirq(struct vfio_ap_queue *q)
+{
+ struct ap_qirq_ctrl aqic_gisa = {};
+ struct ap_queue_status status = {};
+ struct kvm_s390_gisa *gisa;
+ struct kvm *kvm;
+ unsigned long g_pfn, h_nib, h_pfn;
+ int ret;
+
+ kvm = q->matrix->kvm;
+ gisa = kvm->arch.gisa_int.origin;
+
+ g_pfn = q->nib >> PAGE_SHIFT;
+ ret = vfio_pin_pages(mdev_dev(q->matrix->mdev), _pfn, 1,
+IOMMU_READ | IOMMU_WRITE, _pfn);
+ switch (ret) {
+ case 1:
+ break;
+ case -EINVAL:
+ case -E2BIG:
+ status.response_code = AP_RESPONSE_INVALID_ADDRESS;
+ /* Fallthrough */
+ default:
+ return status;
+ }
+
+ h_nib = (h_pfn << PAGE_SHIFT) | (q->nib & ~PAGE_MASK);
Re: [PATCH] ARM: dts: rockchip: add chosen node on veyron chromebooks
Hi Enric,
Am Freitag, 15. Februar 2019, 12:51:50 CET schrieb Enric Balletbo i Serra:
> In order to use earlycon, the stdout-path property needs to be set
> in the chosen node.
>
> Signed-off-by: Enric Balletbo i Serra
What's the reason for adding this only for the Chromebook variants?
Uart2 is pretty much the standard output for all devices, so I'd assume
at least all veyron boards should use uart2 as well, making this ideally
live in the rk3288-veyron.dtsi instead?
Heiko
> ---
>
> arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
> b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi index
> b54746df3661..8890967ed572 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
> +++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
> @@ -62,6 +62,10 @@
> pwm-off-delay-ms = <10>;
> };
>
> + chosen {
> + stdout-path = "serial2:115200n8";
> + };
> +
> gpio-charger {
> compatible = "gpio-charger";
> charger-type = "mains";
Re: [PATCH v1 1/1] of: unittest: unflatten device tree on UML when testing
On 2/15/19 1:49 AM, Brendan Higgins wrote:
> On Thu, Feb 14, 2019 at 6:48 PM Frank Rowand wrote:
>>
>> On 2/14/19 5:26 PM, Brendan Higgins wrote:
>>> On Thu, Feb 14, 2019 at 4:10 PM Frank Rowand wrote:
On 2/12/19 10:53 AM, Brendan Higgins wrote:
> UML supports enabling OF, and is useful for running the device tree
> tests, so add support for unflattening device tree blobs so we can
> actually use it.
>
> Signed-off-by: Brendan Higgins
> ---
> drivers/of/unittest.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 84427384654d5..effa4e2b9d992 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -2527,6 +2527,9 @@ static int __init of_unittest(void)
> }
> of_node_put(np);
>
> + if (IS_ENABLED(CONFIG_UML))
> + unflatten_device_tree();
> +
> pr_info("start of unittest - you will see error messages\n");
> of_unittest_check_tree_linkage();
> of_unittest_check_phandles();
>
(Insert my usual disclaimer that I am clueless about UML, I still need to
learn
about it...)
This does not look correct to me.
A few lines earlier in of_unittest(), the live devicetree needs to exist
for
unittest_data_data() and a few of_*() functions to succeed. So it seems
that the unflatten_device_tree() for uml should be at the beginning of
of_unittest().
>>>
>>> It is true that other functions ahead of it depend on the presence of
>>> a device tree, but an unflattened tree does get linked in somewhere
>>> else. Despite that, this is needed for overlay_base_root. I got
>>> similar behavior if you don't link in a flattened device tree on x86.
>>> Thus, the order in which you call them doesn't actually seem to
>>> matter. I found no difference from changing the order in UML myself.
>>>
>>> Without my patch we get the following error,
>>> ### dt-test ### FAIL of_unittest_overlay_high_level():2372
>>> overlay_base_root not initialized
>>> ### dt-test ### end of unittest - 219 passed, 1 failed
>>>
>>> With my patch we get:
>>> ### dt-test ### end of unittest - 224 passed, 0 failed
>>
>> Thanks for reporting both the failure and the success cases,
>> that helps me understand a little bit better.
>>
>> If instead of the above patch, if you add the following (untested,
>> not even compile tested) to the beginning of of_unittest():
>>
>> if (IS_ENABLED(CONFIG_UML))
>> unittest_unflatten_overlay_base();
>>
>> does that also result in a good test result of:
>>
>> ### dt-test ### end of unittest - 224 passed, 0 failed
>
> Yep, I just tried it. It works as you suspected.
>
>>
>> I think I need to find some time to build and boot a UML kernel soon.
>
> It's really no big deal, just copy the .config I sent and build with
> `make ARCH=um` then you "boot" the kernel with `./linux` (note this
> will mess up your terminal settings); that's it! (Shameless plug: you
> can also try it out with the KUnit patchset with
> `./tools/testing/kunit/kunit.py --timeout=30 --jobs=12 --defconfig`,
> which builds the kernel with a pretty similar config, boots the
> kernel, and then parses the output for you. ;-) )
Thanks, that was enough info to prod me into building and "booting"
a uml kernel. I have another framework that I use, so I did not
try kunit.py, but reading that filled in any missing details that
I needed.
As I mentioned, I used my own framework, but the commands that it
emitted essentially boil down to a rather simple recipe:
export ARCH=um
make kunit_defconfig
make olddefconfig
make linux
# KBUILD_OUTPUT is my build directory
${KBUILD_OUTPUT}/linux mem=256m
>
>>
>> My current _guess_ is that the original problem was not a failure to
>> unflatten any present devicetree in UML but instead that the UML
>> kernel does not call unflatten_device_tree() and thus fails to
>> indirectly call unittest_unflatten_overlay_base(), which is
>> called by unflatten_device_tree().
>
> I think you are right. Sorry for not noticing this before making my
> change. Since it was pretty much the only architecture (the only one I
> care about) that does not unflatten DT, I assumed that was the
> problem. I didn't put too much thought into it after that point beyond
> making sure that it did what I wanted.
>
>>
>> unittest_unflatten_overlay_base() is an unfortunate wart that I
>> added, but I don't have a better alternative yet.
>
> Hey, I get it. No worries.
>
> In any case, it seems like unittest_unflatten_overlay_base() is the
> right function to call there. I will send out patch. Do you want me to
Thanks for the updated patch.
> send a patch on top of this one, or do you want to revert this one and
> for me to send a v2 follow up to this patch? I don't care either way,
> whatever you guys prefer.
>
> Cheers
>
Re: [PATCH 2/2] arm64: dts: Add SEI Robotics SEI510 Board
Neil Armstrong writes: > The SEI Robotics SEI510 Board is based on the Amlogic G12A S905X2 > and has the following features : > - Amlogic G12A S905X2 SoC > - 10/100 Ethernet > - USB2 + USB3 ports > - Micro SDCard Port > - Audio + CVBS AV Jack port > - HDMI 2.1 + CEC Port > - ADC Touch Button > - Far-Field Microphone Array + Mono HP > - IR Sensor > - IR Emmiter LED Array > - RGB Led > > Signed-off-by: Neil Armstrong [...] > diff --git a/arch/arm64/boot/dts/amlogic/Makefile > b/arch/arm64/boot/dts/amlogic/Makefile > index 0821fed4c074..2709f7ede908 100644 > --- a/arch/arm64/boot/dts/amlogic/Makefile > +++ b/arch/arm64/boot/dts/amlogic/Makefile > @@ -1,6 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > dtb-$(CONFIG_ARCH_MESON) += meson-axg-s400.dtb > dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb > +dtb-$(CONFIG_ARCH_MESON) += meson-g12a-sei510.dtb nit: not sorted alphabetically. I'll move it bofore u200 when applying. Thanks for the new board support! Kevin
Re: [patch V5 4/8] nvme-pci: Simplify interrupt allocation
On Fri, 15 Feb 2019, Thomas Gleixner wrote:
> On Fri, 15 Feb 2019, Ming Lei wrote:
> > > + * If only one interrupt is available, combine write and read
> > > + * queues. If 'write_queues' is set, ensure it leaves room for at
> > > + * least one read queue.
> > > + */
> > > + if (nrirqs == 1)
> > > + nr_read_queues = 0;
> > > + else if (write_queues >= nrirqs)
> > > + nr_read_queues = nrirqs - 1;
> > > + else
> > > + nr_read_queues = nrirqs - write_queues;
> > > +
> > > + dev->io_queues[HCTX_TYPE_DEFAULT] = nrirqs - nr_read_queues;
> > > + affd->set_size[HCTX_TYPE_DEFAULT] = nrirqs - nr_read_queues;
> > > + dev->io_queues[HCTX_TYPE_READ] = nr_read_queues;
> > > + affd->set_size[HCTX_TYPE_READ] = nr_read_queues;
> > > + affd->nr_sets = nr_read_queues ? 2 : 1;
> > > }
> >
> > .calc_sets is called only if more than .pre_vectors is available,
> > then dev->io_queues[HCTX_TYPE_DEFAULT] may not be set in case of
> > (nvecs == affd->pre_vectors + affd->post_vectors).
>
> Hmm, good catch. The delta patch below should fix that, but I have to go
> through all the possible cases in pci_alloc_irq_vectors_affinity() once
> more with brain awake.
The existing logic in the driver is somewhat strange. If there is only a
single interrupt available, i.e. no separation of admin and I/O queue, then
dev->io_queues[HCTX_TYPE_DEFAULT] is still set to 1.
Now with the callback scheme (independent of my changes) that breaks in
various ways:
1) irq_create_affinity_masks() bails out early:
if (nvecs == affd->pre_vectors + affd->post_vectors)
return NULL;
So the callback won't be invoked and the last content of
dev->io_queues is preserved. By chance this might end up with
dev->io_queues[HCTX_TYPE_DEFAULT] = 1;
dev->io_queues[HCTX_TYPE_READ] = 0;
but that does not happen by design.
2) pci_alloc_irq_vectors_affinity() has the following flow:
__pci_enable_msix_range()
for (...) {
__pci_enable_msix()
}
If that fails because MSIX is not supported, then the affinity
spreading code has not been called yet and neither the callback.
Now it goes on and tries MSI, which is the same as the above.
When that fails because MSI is not supported, same situation as above
and the code tries to allocate the legacy interrupt.
Now with the initial initialization that case is covered, but not the
following error case:
Assume MSIX is enabled, but __pci_enable_msix() fails with -ENOMEM
after having called irq_create_affinity_masks() and subsequently the
callback with maxvecs.
Then pci_alloc_irq_vectors_affinity() will try MSI and fail _BEFORE_
the callback is invoked.
The next step is to install the leagcy interrupt, but that does not
invoke the affinity code and neither the callback.
At the end dev->io_queues[*] are still initialized with the failed
attempt of enabling MSIX based on maxvecs.
Result: inconsistent state ...
I have an idea how to fix that, but that's again a task for brain being
awake. Will take care of that tomorrow morning.
Thanks,
tglx
