* KMSAN: uninit-value in skb_pull_rcsum
From: syzbot @ 2019-07-29 15:38 UTC (permalink / raw)
To: davem, glider, kuznet, linux-kernel, netdev, syzkaller-bugs,
yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: beaab8a3 fix KASAN build
git tree: kmsan
console output: https://syzkaller.appspot.com/x/log.txt?x=115ac27c600000
kernel config: https://syzkaller.appspot.com/x/.config?x=4db781fe35a84ef5
dashboard link: https://syzkaller.appspot.com/bug?extid=019264c4af66fbb45cac
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
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+019264c4af66fbb45cac@syzkaller.appspotmail.com
==================================================================
BUG: KMSAN: uninit-value in __skb_pull include/linux/skbuff.h:2224 [inline]
BUG: KMSAN: uninit-value in skb_pull_rcsum+0x2fb/0x500
net/core/skbuff.c:3483
CPU: 1 PID: 15024 Comm: syz-executor.2 Not tainted 5.2.0+ #15
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x191/0x1f0 lib/dump_stack.c:113
kmsan_report+0x162/0x2d0 mm/kmsan/kmsan_report.c:109
__msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:294
__skb_pull include/linux/skbuff.h:2224 [inline]
skb_pull_rcsum+0x2fb/0x500 net/core/skbuff.c:3483
__iptunnel_pull_header+0x14d/0xbc0 net/ipv4/ip_tunnel_core.c:94
erspan_rcv net/ipv4/ip_gre.c:279 [inline]
gre_rcv+0x6d9/0x1900 net/ipv4/ip_gre.c:415
gre_rcv+0x2dd/0x3c0 net/ipv4/gre_demux.c:155
ip_protocol_deliver_rcu+0x722/0xbc0 net/ipv4/ip_input.c:204
ip_local_deliver_finish net/ipv4/ip_input.c:231 [inline]
NF_HOOK include/linux/netfilter.h:305 [inline]
ip_local_deliver+0x62a/0x7c0 net/ipv4/ip_input.c:252
dst_input include/net/dst.h:439 [inline]
ip_rcv_finish net/ipv4/ip_input.c:413 [inline]
NF_HOOK include/linux/netfilter.h:305 [inline]
ip_rcv+0x6c5/0x740 net/ipv4/ip_input.c:523
__netif_receive_skb_one_core net/core/dev.c:5009 [inline]
__netif_receive_skb net/core/dev.c:5123 [inline]
process_backlog+0xef5/0x1410 net/core/dev.c:5934
napi_poll net/core/dev.c:6357 [inline]
net_rx_action+0x738/0x1940 net/core/dev.c:6423
__do_softirq+0x4ad/0x858 kernel/softirq.c:293
do_softirq_own_stack+0x49/0x80 arch/x86/entry/entry_64.S:1052
</IRQ>
do_softirq kernel/softirq.c:338 [inline]
__local_bh_enable_ip+0x199/0x1e0 kernel/softirq.c:190
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:682 [inline]
ip_finish_output2+0x20dc/0x25d0 net/ipv4/ip_output.c:229
ip_finish_output+0xd2a/0xfd0 net/ipv4/ip_output.c:315
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip_output+0x541/0x610 net/ipv4/ip_output.c:415
dst_output include/net/dst.h:433 [inline]
ip_local_out net/ipv4/ip_output.c:125 [inline]
ip_send_skb net/ipv4/ip_output.c:1473 [inline]
ip_push_pending_frames+0x243/0x460 net/ipv4/ip_output.c:1493
raw_sendmsg+0x2df8/0x46d0 net/ipv4/raw.c:672
inet_sendmsg+0x48e/0x750 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg net/socket.c:665 [inline]
___sys_sendmsg+0xe92/0x13c0 net/socket.c:2286
__sys_sendmsg net/socket.c:2324 [inline]
__do_sys_sendmsg net/socket.c:2333 [inline]
__se_sys_sendmsg+0x305/0x460 net/socket.c:2331
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2331
do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:302
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x459829
Code: fd 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 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fb0d4758c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000000000000 RSI: 0000000020003d00 RDI: 0000000000000004
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb0d47596d4
R13: 00000000004c7560 R14: 00000000004dcac0 R15: 00000000ffffffff
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:187 [inline]
kmsan_internal_chain_origin+0xcc/0x150 mm/kmsan/kmsan.c:345
kmsan_memcpy_memmove_metadata+0x9f9/0xe00 mm/kmsan/kmsan.c:278
kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:298
__msan_memcpy+0x56/0x70 mm/kmsan/kmsan_instr.c:129
pskb_expand_head+0x38a/0x19f0 net/core/skbuff.c:1510
__skb_cow include/linux/skbuff.h:3036 [inline]
skb_cow_head include/linux/skbuff.h:3070 [inline]
ip_tunnel_xmit+0x2971/0x3320 net/ipv4/ip_tunnel.c:811
__gre_xmit net/ipv4/ip_gre.c:444 [inline]
erspan_xmit+0x1ef8/0x35c0 net/ipv4/ip_gre.c:679
__netdev_start_xmit include/linux/netdevice.h:4406 [inline]
netdev_start_xmit include/linux/netdevice.h:4420 [inline]
xmit_one net/core/dev.c:3288 [inline]
dev_hard_start_xmit+0x51a/0xab0 net/core/dev.c:3304
sch_direct_xmit+0x56c/0x18c0 net/sched/sch_generic.c:309
__dev_xmit_skb net/core/dev.c:3485 [inline]
__dev_queue_xmit+0x1e53/0x4270 net/core/dev.c:3846
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3910
neigh_resolve_output+0xab7/0xb50 net/core/neighbour.c:1486
neigh_output include/net/neighbour.h:511 [inline]
ip_finish_output2+0x1a8e/0x25d0 net/ipv4/ip_output.c:228
ip_finish_output+0xd2a/0xfd0 net/ipv4/ip_output.c:315
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip_output+0x541/0x610 net/ipv4/ip_output.c:415
dst_output include/net/dst.h:433 [inline]
ip_local_out net/ipv4/ip_output.c:125 [inline]
ip_send_skb net/ipv4/ip_output.c:1473 [inline]
ip_push_pending_frames+0x243/0x460 net/ipv4/ip_output.c:1493
raw_sendmsg+0x2df8/0x46d0 net/ipv4/raw.c:672
inet_sendmsg+0x48e/0x750 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg net/socket.c:665 [inline]
___sys_sendmsg+0xe92/0x13c0 net/socket.c:2286
__sys_sendmsg net/socket.c:2324 [inline]
__do_sys_sendmsg net/socket.c:2333 [inline]
__se_sys_sendmsg+0x305/0x460 net/socket.c:2331
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2331
do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:302
entry_SYSCALL_64_after_hwframe+0x63/0xe7
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:187 [inline]
kmsan_internal_poison_shadow+0x53/0xa0 mm/kmsan/kmsan.c:146
kmsan_slab_alloc+0xaa/0x120 mm/kmsan/kmsan_hooks.c:175
slab_alloc_node mm/slub.c:2771 [inline]
__kmalloc_node_track_caller+0xc8f/0xf10 mm/slub.c:4389
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x306/0xa10 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:1055 [inline]
__ip_append_data+0x3901/0x52c0 net/ipv4/ip_output.c:1013
ip_append_data+0x324/0x480 net/ipv4/ip_output.c:1228
raw_sendmsg+0x2d02/0x46d0 net/ipv4/raw.c:666
inet_sendmsg+0x48e/0x750 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg net/socket.c:665 [inline]
___sys_sendmsg+0xe92/0x13c0 net/socket.c:2286
__sys_sendmsg net/socket.c:2324 [inline]
__do_sys_sendmsg net/socket.c:2333 [inline]
__se_sys_sendmsg+0x305/0x460 net/socket.c:2331
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2331
do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:302
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
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 syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH v4 1/5] vsock/virtio: limit the memory used per-socket
From: Stefano Garzarella @ 2019-07-29 15:36 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, Stefan Hajnoczi, David S. Miller,
virtualization, Jason Wang, kvm
In-Reply-To: <20190729095956-mutt-send-email-mst@kernel.org>
On Mon, Jul 29, 2019 at 10:04:29AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 17, 2019 at 01:30:26PM +0200, Stefano Garzarella wrote:
> > Since virtio-vsock was introduced, the buffers filled by the host
> > and pushed to the guest using the vring, are directly queued in
> > a per-socket list. These buffers are preallocated by the guest
> > with a fixed size (4 KB).
> >
> > The maximum amount of memory used by each socket should be
> > controlled by the credit mechanism.
> > The default credit available per-socket is 256 KB, but if we use
> > only 1 byte per packet, the guest can queue up to 262144 of 4 KB
> > buffers, using up to 1 GB of memory per-socket. In addition, the
> > guest will continue to fill the vring with new 4 KB free buffers
> > to avoid starvation of other sockets.
> >
> > This patch mitigates this issue copying the payload of small
> > packets (< 128 bytes) into the buffer of last packet queued, in
> > order to avoid wasting memory.
> >
> > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> > Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>
> This is good enough for net-next, but for net I think we
> should figure out how to address the issue completely.
> Can we make the accounting precise? What happens to
> performance if we do?
>
In order to do more precise accounting maybe we can use the buffer size,
instead of payload size when we update the credit available.
In this way, the credit available for each socket will reflect the memory
actually used.
I should check better, because I'm not sure what happen if the peer sees
1KB of space available, then it sends 1KB of payload (using a 4KB
buffer).
The other option is to copy each packet in a new buffer like I did in
the v2 [2], but this forces us to make a copy for each packet that does
not fill the entire buffer, perhaps too expensive.
[2] https://patchwork.kernel.org/patch/10938741/
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH stable 4.9] tcp: reset sk_send_head in tcp_write_queue_purge
From: Sasha Levin @ 2019-07-29 15:32 UTC (permalink / raw)
To: Mao Wenan; +Cc: gregkh, stable, netdev, linux-kernel
In-Reply-To: <20190729132108.162320-1-maowenan@huawei.com>
On Mon, Jul 29, 2019 at 09:21:08PM +0800, Mao Wenan wrote:
>From: Soheil Hassas Yeganeh <soheil@google.com>
>
>tcp_write_queue_purge clears all the SKBs in the write queue
>but does not reset the sk_send_head. As a result, we can have
>a NULL pointer dereference anywhere that we use tcp_send_head
>instead of the tcp_write_queue_tail.
>
>For example, after a27fd7a8ed38 (tcp: purge write queue upon RST),
>we can purge the write queue on RST. Prior to
>75c119afe14f (tcp: implement rb-tree based retransmit queue),
>tcp_push will only check tcp_send_head and then accesses
>tcp_write_queue_tail to send the actual SKB. As a result, it will
>dereference a NULL pointer.
>
>This has been reported twice for 4.14 where we don't have
>75c119afe14f:
>
>By Timofey Titovets:
>
>[ 422.081094] BUG: unable to handle kernel NULL pointer dereference
>at 0000000000000038
>[ 422.081254] IP: tcp_push+0x42/0x110
>[ 422.081314] PGD 0 P4D 0
>[ 422.081364] Oops: 0002 [#1] SMP PTI
>
>By Yongjian Xu:
>
>BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
>IP: tcp_push+0x48/0x120
>PGD 80000007ff77b067 P4D 80000007ff77b067 PUD 7fd989067 PMD 0
>Oops: 0002 [#18] SMP PTI
>Modules linked in: tcp_diag inet_diag tcp_bbr sch_fq iTCO_wdt
>iTCO_vendor_support pcspkr ixgbe mdio i2c_i801 lpc_ich joydev input_leds shpchp
>e1000e igb dca ptp pps_core hwmon mei_me mei ipmi_si ipmi_msghandler sg ses
>scsi_transport_sas enclosure ext4 jbd2 mbcache sd_mod ahci libahci megaraid_sas
>wmi ast ttm dm_mirror dm_region_hash dm_log dm_mod dax
>CPU: 6 PID: 14156 Comm: [ET_NET 6] Tainted: G D 4.14.26-1.el6.x86_64 #1
>Hardware name: LENOVO ThinkServer RD440 /ThinkServer RD440, BIOS A0TS80A
>09/22/2014
>task: ffff8807d78d8140 task.stack: ffffc9000e944000
>RIP: 0010:tcp_push+0x48/0x120
>RSP: 0018:ffffc9000e947a88 EFLAGS: 00010246
>RAX: 00000000000005b4 RBX: ffff880f7cce9c00 RCX: 0000000000000000
>RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff8807d00f5000
>RBP: ffffc9000e947aa8 R08: 0000000000001c84 R09: 0000000000000000
>R10: ffff8807d00f5158 R11: 0000000000000000 R12: ffff8807d00f5000
>R13: 0000000000000020 R14: 00000000000256d4 R15: 0000000000000000
>FS: 00007f5916de9700(0000) GS:ffff88107fd00000(0000) knlGS:0000000000000000
>CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>CR2: 0000000000000038 CR3: 00000007f8226004 CR4: 00000000001606e0
>Call Trace:
>tcp_sendmsg_locked+0x33d/0xe50
>tcp_sendmsg+0x37/0x60
>inet_sendmsg+0x39/0xc0
>sock_sendmsg+0x49/0x60
>sock_write_iter+0xb6/0x100
>do_iter_readv_writev+0xec/0x130
>? rw_verify_area+0x49/0xb0
>do_iter_write+0x97/0xd0
>vfs_writev+0x7e/0xe0
>? __wake_up_common_lock+0x80/0xa0
>? __fget_light+0x2c/0x70
>? __do_page_fault+0x1e7/0x530
>do_writev+0x60/0xf0
>? inet_shutdown+0xac/0x110
>SyS_writev+0x10/0x20
>do_syscall_64+0x6f/0x140
>? prepare_exit_to_usermode+0x8b/0xa0
>entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>RIP: 0033:0x3135ce0c57
>RSP: 002b:00007f5916de4b00 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
>RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000003135ce0c57
>RDX: 0000000000000002 RSI: 00007f5916de4b90 RDI: 000000000000606f
>RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f5916de8c38
>R10: 0000000000000000 R11: 0000000000000293 R12: 00000000000464cc
>R13: 00007f5916de8c30 R14: 00007f58d8bef080 R15: 0000000000000002
>Code: 48 8b 97 60 01 00 00 4c 8d 97 58 01 00 00 41 b9 00 00 00 00 41 89 f3 4c 39
>d2 49 0f 44 d1 41 81 e3 00 80 00 00 0f 85 b0 00 00 00 <80> 4a 38 08 44 8b 8f 74
>06 00 00 44 89 8f 7c 06 00 00 83 e6 01
>RIP: tcp_push+0x48/0x120 RSP: ffffc9000e947a88
>CR2: 0000000000000038
>---[ end trace 8d545c2e93515549 ]---
>
>There is other scenario which found in stable 4.4:
>Allocated:
> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
>Freed:
> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
>
>BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
>BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
>BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
>
>stable 4.4 and stable 4.9 don't have the commit abb4a8b870b5 ("tcp: purge write queue upon RST")
>which is referred in dbbf2d1e4077,
>in tcp_connect_init, it calls tcp_write_queue_purge, and does not reset sk_send_head, then UAF.
>
>stable 4.14 have the commit abb4a8b870b5 ("tcp: purge write queue upon RST"),
>in tcp_reset, it calls tcp_write_queue_purge(sk), and does not reset sk_send_head, then UAF.
>
>So this patch can be used to fix stable 4.4 and 4.9.
>
>Fixes: a27fd7a8ed38 (tcp: purge write queue upon RST)
>Reported-by: Timofey Titovets <nefelim4ag@gmail.com>
>Reported-by: Yongjian Xu <yongjianchn@gmail.com>
>Signed-off-by: Eric Dumazet <edumazet@google.com>
>Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
>Tested-by: Yongjian Xu <yongjianchn@gmail.com>
>
>Signed-off-by: David S. Miller <davem@davemloft.net>
>Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Signed-off-by: Mao Wenan <maowenan@huawei.com>
So the "Fixes:" commit in the commit message is wrong? What's the actual
commit that this fixes?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] enetc: Clean up local mdio bus allocation
From: Andrew Lunn @ 2019-07-29 15:32 UTC (permalink / raw)
To: Claudiu Manoil
Cc: David S . Miller, Rob Herring, Li Yang, alexandru.marginean,
netdev, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1564394627-3810-2-git-send-email-claudiu.manoil@nxp.com>
On Mon, Jul 29, 2019 at 01:03:44PM +0300, Claudiu Manoil wrote:
> What's needed is basically a pointer to the mdio registers.
> This is one way to store it inside bus->priv allocated space,
> without upsetting sparse.
> Reworked accessors to avoid __iomem casting.
> Used devm_* variant to further clean up the init error /
> remove paths.
>
> Fixes following sparse warning:
> warning: incorrect type in assignment (different address spaces)
> expected void *priv
> got struct enetc_mdio_regs [noderef] <asn:2>*[assigned] regs
>
> Fixes: ebfcb23d62ab ("enetc: Add ENETC PF level external MDIO support")
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Thanks, much nicer.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* RE: [EXT] Re: [PATCH v6 rdma-next 1/6] RDMA/core: Create mmap database and cookie helper functions
From: Michal Kalderon @ 2019-07-29 15:26 UTC (permalink / raw)
To: Jason Gunthorpe, Gal Pressman
Cc: Ariel Elior, dledford@redhat.com, linux-rdma@vger.kernel.org,
davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <20190729140444.GB17990@ziepe.ca>
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Monday, July 29, 2019 5:05 PM
>
> External Email
>
> ----------------------------------------------------------------------
> On Mon, Jul 29, 2019 at 04:53:38PM +0300, Gal Pressman wrote:
> > On 29/07/2019 15:58, Michal Kalderon wrote:
> > >> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> > >> owner@vger.kernel.org> On Behalf Of Jason Gunthorpe
> > >>
> > >>> + xa_lock(&ucontext->mmap_xa);
> > >>> + if (check_add_overflow(ucontext->mmap_xa_page,
> > >>> + (u32)(length >> PAGE_SHIFT),
> > >>> + &next_mmap_page))
> > >>> + goto err_unlock;
> > >>
> > >> I still don't like that this algorithm latches into a permanent
> > >> failure when the xa_page wraps.
> > >>
> > >> It seems worth spending a bit more time here to tidy this.. Keep
> > >> using the mmap_xa_page scheme, but instead do something like
> > >>
> > >> alloc_cyclic_range():
> > >>
> > >> while () {
> > >> // Find first empty element in a cyclic way
> > >> xa_page_first = mmap_xa_page;
> > >> xa_find(xa, &xa_page_first, U32_MAX, XA_FREE_MARK)
> > >>
> > >> // Is there a enough room to have the range?
> > >> if (check_add_overflow(xa_page_first, npages, &xa_page_end)) {
> > >> mmap_xa_page = 0;
> > >> continue;
> > >> }
> > >>
> > >> // See if the element before intersects
> > >> elm = xa_find(xa, &zero, xa_page_end, 0);
> > >> if (elm && intersects(xa_page_first, xa_page_last, elm->first, elm-
> >last)) {
> > >> mmap_xa_page = elm->last + 1;
> > >> continue
> > >> }
> > >>
> > >> // xa_page_first -> xa_page_end should now be free
> > >> xa_insert(xa, xa_page_start, entry);
> > >> mmap_xa_page = xa_page_end + 1;
> > >> return xa_page_start;
> > >> }
> > >>
> > >> Approximately, please check it.
> > > Gal & Jason,
> > >
> > > Coming back to the mmap_xa_page algorithm. I couldn't find some
> background on this.
> > > Why do you need the length to be represented in the mmap_xa_page ?
> > > Why not simply use xa_alloc_cyclic ( like in siw )
>
> I think siw is dealing with only PAGE_SIZE objects, efa had variable sized
> ones.
>
> > > This is simply a key to a mmap object...
> >
> > The intention was that the entry would "occupy" number of xarray
> > elements according to its size (in pages). It wasn't initially like
> > this, but IIRC this was preferred by Jason.
>
> It is not so critical, maybe we could drop it if it is really simplifiying. But it
> doesn't look so hard to make an xa algorithm that will be OK.
>
> The offset/length is shown in things like lsof and what not, and from a
> debugging perspective it makes a lot more sense if the offset/length are
> sensible, ie they should not overlap.
>
Thanks for the clarification
> Jason
^ permalink raw reply
* Re: [PATCH V4 net-next 00/10] net: hns3: some code optimizations & bugfixes & features
From: David Miller @ 2019-07-29 15:25 UTC (permalink / raw)
To: saeedm
Cc: tanhuazhong, yisen.zhuang, salil.mehta, linuxarm, netdev,
linux-kernel
In-Reply-To: <1aa604e4afe85fa9cfd2e47fbb5386c2c1041310.camel@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 29 Jul 2019 05:48:28 +0000
> On Mon, 2019-07-29 at 10:53 +0800, Huazhong Tan wrote:
>> This patch-set includes code optimizations, bugfixes and features for
>> the HNS3 ethernet controller driver.
...
>
> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
Series applied.
^ permalink raw reply
* [PATCH] drivers: net: wireless: rsi: return explicit error values
From: Enrico Weigelt, metux IT consult @ 2019-07-29 15:24 UTC (permalink / raw)
To: linux-kernel; +Cc: amitkarwar, siva8118, kvalo, linux-wireless, netdev
From: Enrico Weigelt <info@metux.net>
Explicitly return constants instead of variable (and rely on
it to be explicitly initialized), if the value is supposed
to be fixed anyways. Align it with the rest of the driver,
which does it the same way.
Signed-off-by: Enrico Weigelt <info@metux.net>
---
drivers/net/wireless/rsi/rsi_91x_sdio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index b42cd50..2a3577d 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -844,11 +844,11 @@ static int rsi_init_sdio_interface(struct rsi_hw *adapter,
struct sdio_func *pfunction)
{
struct rsi_91x_sdiodev *rsi_91x_dev;
- int status = -ENOMEM;
+ int status;
rsi_91x_dev = kzalloc(sizeof(*rsi_91x_dev), GFP_KERNEL);
if (!rsi_91x_dev)
- return status;
+ return -ENOMEM;
adapter->rsi_dev = rsi_91x_dev;
@@ -890,7 +890,7 @@ static int rsi_init_sdio_interface(struct rsi_hw *adapter,
#ifdef CONFIG_RSI_DEBUGFS
adapter->num_debugfs_entries = MAX_DEBUGFS_ENTRIES;
#endif
- return status;
+ return 0;
fail:
sdio_disable_func(pfunction);
sdio_release_host(pfunction);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 11/14] NFC: nxp-nci: Remove unused macro pr_fmt()
From: Sedat Dilek @ 2019-07-29 15:08 UTC (permalink / raw)
To: Andy Shevchenko
Cc: David Miller, clement.perrochaud, charles.gorand, netdev,
Sedat Dilek
In-Reply-To: <CA+icZUW5H+9VJvxViYYEDCJ-mLa-xudqYScjZFJ8eA6200YZmg@mail.gmail.com>
On Mon, Jul 29, 2019 at 4:58 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Mon, Jul 29, 2019 at 12:38 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Fri, Jul 26, 2019 at 02:23:46PM -0700, David Miller wrote:
> > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Date: Thu, 25 Jul 2019 22:35:08 +0300
> > >
> > > > The macro had never been used.
> > > >
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> > > ...
> > > > @@ -12,8 +12,6 @@
> > > > * Copyright (C) 2012 Intel Corporation. All rights reserved.
> > > > */
> > > >
> > > > -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > >
> > > If there are any kernel log messages generated, which is the case in
> > > this file, this is used.
> >
> > AFAICS no, it's not.
> > All nfc_*() macros are built on top of dev_*() ones for which pr_fmt() is no-op.
> > If we would like to have it in that way, we rather should use dev_fmt().
> >
> >
> > > Also, please resubmit this series with a proper header posting containing
> > > a high level description of what this patch series does, how it is doing it,
> > > and why it is doing it that way. Also include a changelog.
> >
> > Will do.
> >
> > Thank you for review!
> >
>
> Can you send out the latest series as v5?
> I got some new? patches from you, but a bit confused now.
>
Thanks for the cover-letter.
- Sedat -
[1] https://marc.info/?l=linux-netdev&m=156440732411578&w=2
^ permalink raw reply
* Re: DSA Rate Limiting in 88E6390
From: Andrew Lunn @ 2019-07-29 15:01 UTC (permalink / raw)
To: Benjamin Beckmeyer; +Cc: netdev
In-Reply-To: <5a632696-946d-504b-1077-f7eb6d31ec19@eks-engel.de>
On Mon, Jul 29, 2019 at 12:30:20PM +0200, Benjamin Beckmeyer wrote:
> Hi all,
> is there a possibility to set the rate limiting for the 6390 with linux tools?
> I've seen that the driver will init all to zero, so rate limiting is disabled,
> but there is no solution for it in the ip tool?
>
> The only thing I found for rate limiting is the tc tool, but I guess this is
> only a software solution?
Hi Benjamin
In Linux, we accelerate the software solution by offloading it to the
hardware. So TC is what you need here.
> Furthermore, does exist a table or a tutorial which functions DSA supports?
> The background is that we are using the DSDT driver (in future maybe the UMSD
> driver) but we would like to switch to the in kernel DSA entirely. And our
> software is using some of the DSDT functions, so I have to find an
> alternative to these functions.
The DSA framework supports offloading TC. There was some patches a
while back adding ingress rate limiting to one of the DSA drivers, via
TC. I forget which, and i don't think they have been merged yet. If
you can find the patchset, it should give you a good idea how you can
implement support in the mv88e6xxx driver.
Andrew
^ permalink raw reply
* [PATCH] net/af_iucv: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-07-29 14:59 UTC (permalink / raw)
To: Julian Wiedmann, Ursula Braun, David S. Miller
Cc: linux-s390, netdev, linux-kernel, Gustavo A. R. Silva,
Geert Uytterhoeven, Kees Cook
Mark switch cases where we are expecting to fall through.
This patch fixes the following warnings:
net/iucv/af_iucv.c: warning: this statement may fall
through [-Wimplicit-fallthrough=]: => 537:3, 519:6, 2246:6, 510:6
Notice that, in this particular case, the code comment is
modified in accordance with what GCC is expecting to find.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/iucv/af_iucv.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index 09e1694b6d34..ebb62a4ebe30 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -512,7 +512,9 @@ static void iucv_sock_close(struct sock *sk)
sk->sk_state = IUCV_DISCONN;
sk->sk_state_change(sk);
}
- case IUCV_DISCONN: /* fall through */
+ /* fall through */
+
+ case IUCV_DISCONN:
sk->sk_state = IUCV_CLOSING;
sk->sk_state_change(sk);
@@ -525,8 +527,9 @@ static void iucv_sock_close(struct sock *sk)
iucv_sock_in_state(sk, IUCV_CLOSED, 0),
timeo);
}
+ /* fall through */
- case IUCV_CLOSING: /* fall through */
+ case IUCV_CLOSING:
sk->sk_state = IUCV_CLOSED;
sk->sk_state_change(sk);
@@ -535,8 +538,9 @@ static void iucv_sock_close(struct sock *sk)
skb_queue_purge(&iucv->send_skb_q);
skb_queue_purge(&iucv->backlog_skb_q);
+ /* fall through */
- default: /* fall through */
+ default:
iucv_sever_path(sk, 1);
}
@@ -2247,10 +2251,10 @@ static int afiucv_hs_rcv(struct sk_buff *skb, struct net_device *dev,
kfree_skb(skb);
break;
}
- /* fall through and receive non-zero length data */
+ /* fall through - and receive non-zero length data */
case (AF_IUCV_FLAG_SHT):
/* shutdown request */
- /* fall through and receive zero length data */
+ /* fall through - and receive zero length data */
case 0:
/* plain data frame */
IUCV_SKB_CB(skb)->class = trans_hdr->iucv_hdr.class;
--
2.22.0
^ permalink raw reply related
* Re: [PATCH v3 11/14] NFC: nxp-nci: Remove unused macro pr_fmt()
From: Sedat Dilek @ 2019-07-29 14:58 UTC (permalink / raw)
To: Andy Shevchenko
Cc: David Miller, clement.perrochaud, charles.gorand, netdev,
Sedat Dilek
In-Reply-To: <20190729094047.GH9224@smile.fi.intel.com>
On Mon, Jul 29, 2019 at 12:38 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Jul 26, 2019 at 02:23:46PM -0700, David Miller wrote:
> > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Date: Thu, 25 Jul 2019 22:35:08 +0300
> >
> > > The macro had never been used.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> > ...
> > > @@ -12,8 +12,6 @@
> > > * Copyright (C) 2012 Intel Corporation. All rights reserved.
> > > */
> > >
> > > -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> > If there are any kernel log messages generated, which is the case in
> > this file, this is used.
>
> AFAICS no, it's not.
> All nfc_*() macros are built on top of dev_*() ones for which pr_fmt() is no-op.
> If we would like to have it in that way, we rather should use dev_fmt().
>
>
> > Also, please resubmit this series with a proper header posting containing
> > a high level description of what this patch series does, how it is doing it,
> > and why it is doing it that way. Also include a changelog.
>
> Will do.
>
> Thank you for review!
>
Can you send out the latest series as v5?
I got some new? patches from you, but a bit confused now.
- Sedat -
^ permalink raw reply
* [PATCH v4 06/14] NFC: nxp-nci: Get rid of code duplication in ->probe()
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andy Shevchenko, Sedat Dilek
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/nfc/nxp-nci/i2c.c | 68 +++++++++------------------------------
1 file changed, 15 insertions(+), 53 deletions(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 7344405feddf..6a627d1b6f85 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -256,48 +256,10 @@ static const struct acpi_gpio_mapping acpi_nxp_nci_gpios[] = {
{ }
};
-static int nxp_nci_i2c_parse_devtree(struct i2c_client *client)
-{
- struct nxp_nci_i2c_phy *phy = i2c_get_clientdata(client);
-
- phy->gpiod_en = devm_gpiod_get(&client->dev, "enable", GPIOD_OUT_LOW);
- if (IS_ERR(phy->gpiod_en)) {
- nfc_err(&client->dev, "Failed to get EN gpio\n");
- return PTR_ERR(phy->gpiod_en);
- }
-
- phy->gpiod_fw = devm_gpiod_get(&client->dev, "firmware", GPIOD_OUT_LOW);
- if (IS_ERR(phy->gpiod_fw)) {
- nfc_err(&client->dev, "Failed to get FW gpio\n");
- return PTR_ERR(phy->gpiod_fw);
- }
-
- return 0;
-}
-
-static int nxp_nci_i2c_acpi_config(struct nxp_nci_i2c_phy *phy)
-{
- struct i2c_client *client = phy->i2c_dev;
- int r;
-
- r = devm_acpi_dev_add_driver_gpios(&client->dev, acpi_nxp_nci_gpios);
- if (r)
- return r;
-
- phy->gpiod_en = devm_gpiod_get(&client->dev, "enable", GPIOD_OUT_LOW);
- phy->gpiod_fw = devm_gpiod_get(&client->dev, "firmware", GPIOD_OUT_LOW);
-
- if (IS_ERR(phy->gpiod_en) || IS_ERR(phy->gpiod_fw)) {
- nfc_err(&client->dev, "No GPIOs\n");
- return -EINVAL;
- }
-
- return 0;
-}
-
static int nxp_nci_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ struct device *dev = &client->dev;
struct nxp_nci_i2c_phy *phy;
int r;
@@ -317,20 +279,20 @@ static int nxp_nci_i2c_probe(struct i2c_client *client,
phy->i2c_dev = client;
i2c_set_clientdata(client, phy);
- if (client->dev.of_node) {
- r = nxp_nci_i2c_parse_devtree(client);
- if (r < 0) {
- nfc_err(&client->dev, "Failed to get DT data\n");
- goto probe_exit;
- }
- } else if (ACPI_HANDLE(&client->dev)) {
- r = nxp_nci_i2c_acpi_config(phy);
- if (r < 0)
- goto probe_exit;
- } else {
- nfc_err(&client->dev, "No platform data\n");
- r = -EINVAL;
- goto probe_exit;
+ r = devm_acpi_dev_add_driver_gpios(dev, acpi_nxp_nci_gpios);
+ if (r)
+ return r;
+
+ phy->gpiod_en = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(phy->gpiod_en)) {
+ nfc_err(dev, "Failed to get EN gpio\n");
+ return PTR_ERR(phy->gpiod_en);
+ }
+
+ phy->gpiod_fw = devm_gpiod_get(dev, "firmware", GPIOD_OUT_LOW);
+ if (IS_ERR(phy->gpiod_fw)) {
+ nfc_err(dev, "Failed to get FW gpio\n");
+ return PTR_ERR(phy->gpiod_fw);
}
r = nxp_nci_probe(phy, &client->dev, &i2c_phy_ops,
--
2.20.1
^ permalink raw reply related
* [PATCH v4 13/14] NFC: nxp-nci: Clarify on supported chips
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andy Shevchenko, Oleg Zhurakivskyy
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
From: Sedat Dilek <sedat.dilek@credativ.de>
This patch clarifies on the supported NXP NCI chips and families
and lists PN547 and PN548 separately which are known as NPC100
respectively NPC300.
This helps to find informations and identify drivers on vendor's
support websites.
For details see the discussion in [1] and [2].
[1] https://marc.info/?t=155774435600001&r=1&w=2
[2] https://patchwork.kernel.org/project/linux-wireless/list/?submitter=33142
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Signed-off-by: Sedat Dilek <sedat.dilek@credativ.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
---
drivers/nfc/nxp-nci/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
index ed6cbdf0f0b4..746b91aa74f0 100644
--- a/drivers/nfc/nxp-nci/Kconfig
+++ b/drivers/nfc/nxp-nci/Kconfig
@@ -3,8 +3,8 @@ config NFC_NXP_NCI
tristate "NXP-NCI NFC driver"
depends on NFC_NCI
---help---
- Generic core driver for NXP NCI chips such as the NPC100
- or PN7150 families.
+ Generic core driver for NXP NCI chips such as the NPC100 (PN547),
+ NPC300 (PN548) or PN7150 families.
This is a driver based on the NCI NFC kernel layers and
will thus not work with NXP libnfc library.
--
2.20.1
^ permalink raw reply related
* [PATCH v4 01/14] NFC: fix attrs checks in netlink interface
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andrey Konovalov, Andy Shevchenko
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
From: Andrey Konovalov <andreyknvl@google.com>
nfc_genl_deactivate_target() relies on the NFC_ATTR_TARGET_INDEX
attribute being present, but doesn't check whether it is actually
provided by the user. Same goes for nfc_genl_fw_download() and
NFC_ATTR_FIRMWARE_NAME.
This patch adds appropriate checks.
Found with syzkaller.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
net/nfc/netlink.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index 4a30309bb67f..60fd2748d0ea 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -970,7 +970,8 @@ static int nfc_genl_dep_link_down(struct sk_buff *skb, struct genl_info *info)
int rc;
u32 idx;
- if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+ if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+ !info->attrs[NFC_ATTR_TARGET_INDEX])
return -EINVAL;
idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
@@ -1018,7 +1019,8 @@ static int nfc_genl_llc_get_params(struct sk_buff *skb, struct genl_info *info)
struct sk_buff *msg = NULL;
u32 idx;
- if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+ if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+ !info->attrs[NFC_ATTR_FIRMWARE_NAME])
return -EINVAL;
idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
--
2.20.1
^ permalink raw reply related
* [PATCH v4 03/14] NFC: nxp-nci: Get rid of platform data
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andy Shevchenko, Sedat Dilek
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
Legacy platform data must go away. We are on the safe side here since
there are no users of it in the kernel.
If anyone by any odd reason needs it the GPIO lookup tables and
built-in device properties at your service.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
---
MAINTAINERS | 1 -
drivers/nfc/nxp-nci/core.c | 1 -
drivers/nfc/nxp-nci/i2c.c | 9 +--------
drivers/nfc/nxp-nci/nxp-nci.h | 1 -
include/linux/platform_data/nxp-nci.h | 19 -------------------
5 files changed, 1 insertion(+), 30 deletions(-)
delete mode 100644 include/linux/platform_data/nxp-nci.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 99f64e395623..f204f7a65428 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11353,7 +11353,6 @@ F: include/net/nfc/
F: include/uapi/linux/nfc.h
F: drivers/nfc/
F: include/linux/platform_data/nfcmrvl.h
-F: include/linux/platform_data/nxp-nci.h
F: Documentation/devicetree/bindings/net/nfc/
NFS, SUNRPC, AND LOCKD CLIENTS
diff --git a/drivers/nfc/nxp-nci/core.c b/drivers/nfc/nxp-nci/core.c
index 8dafc696719f..aed18ca60170 100644
--- a/drivers/nfc/nxp-nci/core.c
+++ b/drivers/nfc/nxp-nci/core.c
@@ -14,7 +14,6 @@
#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/nfc.h>
-#include <linux/platform_data/nxp-nci.h>
#include <net/nfc/nci_core.h>
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 5db71869f04b..47b3b7e612e6 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -23,7 +23,6 @@
#include <linux/gpio/consumer.h>
#include <linux/of_gpio.h>
#include <linux/of_irq.h>
-#include <linux/platform_data/nxp-nci.h>
#include <asm/unaligned.h>
#include <net/nfc/nfc.h>
@@ -304,7 +303,6 @@ static int nxp_nci_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct nxp_nci_i2c_phy *phy;
- struct nxp_nci_nfc_platform_data *pdata;
int r;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
@@ -323,17 +321,12 @@ static int nxp_nci_i2c_probe(struct i2c_client *client,
phy->i2c_dev = client;
i2c_set_clientdata(client, phy);
- pdata = client->dev.platform_data;
-
- if (!pdata && client->dev.of_node) {
+ if (client->dev.of_node) {
r = nxp_nci_i2c_parse_devtree(client);
if (r < 0) {
nfc_err(&client->dev, "Failed to get DT data\n");
goto probe_exit;
}
- } else if (pdata) {
- phy->gpio_en = pdata->gpio_en;
- phy->gpio_fw = pdata->gpio_fw;
} else if (ACPI_HANDLE(&client->dev)) {
r = nxp_nci_i2c_acpi_config(phy);
if (r < 0)
diff --git a/drivers/nfc/nxp-nci/nxp-nci.h b/drivers/nfc/nxp-nci/nxp-nci.h
index 6fe7c45544bf..ae3fb2735a4e 100644
--- a/drivers/nfc/nxp-nci/nxp-nci.h
+++ b/drivers/nfc/nxp-nci/nxp-nci.h
@@ -14,7 +14,6 @@
#include <linux/completion.h>
#include <linux/firmware.h>
#include <linux/nfc.h>
-#include <linux/platform_data/nxp-nci.h>
#include <net/nfc/nci_core.h>
diff --git a/include/linux/platform_data/nxp-nci.h b/include/linux/platform_data/nxp-nci.h
deleted file mode 100644
index 97827ad468e2..000000000000
--- a/include/linux/platform_data/nxp-nci.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Generic platform data for the NXP NCI NFC chips.
- *
- * Copyright (C) 2014 NXP Semiconductors All rights reserved.
- *
- * Authors: Clément Perrochaud <clement.perrochaud@nxp.com>
- */
-
-#ifndef _NXP_NCI_H_
-#define _NXP_NCI_H_
-
-struct nxp_nci_nfc_platform_data {
- unsigned int gpio_en;
- unsigned int gpio_fw;
- unsigned int irq;
-};
-
-#endif /* _NXP_NCI_H_ */
--
2.20.1
^ permalink raw reply related
* [PATCH] arcnet: com20020-isa: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-07-29 14:25 UTC (permalink / raw)
To: Michael Grzeschik, David S. Miller
Cc: netdev, linux-kernel, Gustavo A. R. Silva, Geert Uytterhoeven,
Kees Cook
Mark switch cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/arcnet/com20020-isa.c: warning: this statement may fall
through [-Wimplicit-fallthrough=]: => 205:13, 203:10, 209:7, 201:11,
207:8
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/arcnet/com20020-isa.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/arcnet/com20020-isa.c b/drivers/net/arcnet/com20020-isa.c
index 28510e33924f..cd27fdc1059b 100644
--- a/drivers/net/arcnet/com20020-isa.c
+++ b/drivers/net/arcnet/com20020-isa.c
@@ -197,16 +197,22 @@ static int __init com20020isa_setup(char *s)
switch (ints[0]) {
default: /* ERROR */
pr_info("Too many arguments\n");
+ /* Fall through */
case 6: /* Timeout */
timeout = ints[6];
+ /* Fall through */
case 5: /* CKP value */
clockp = ints[5];
+ /* Fall through */
case 4: /* Backplane flag */
backplane = ints[4];
+ /* Fall through */
case 3: /* Node ID */
node = ints[3];
+ /* Fall through */
case 2: /* IRQ */
irq = ints[2];
+ /* Fall through */
case 1: /* IO address */
io = ints[1];
}
--
2.22.0
^ permalink raw reply related
* [PATCH] init: Kconfig: consistent indentions
From: Enrico Weigelt, metux IT consult @ 2019-07-29 14:48 UTC (permalink / raw)
To: linux-kernel; +Cc: kafai, songliubraving, yhs, netdev, bpf, clang-built-linux
From: Enrico Weigelt <info@metux.net>
Just make the indentions consistent with the rest of the file,
as well as most other Kconfig files.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
init/Kconfig | 54 +++++++++++++++++++++++++++---------------------------
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index bd7d650..1a589c6 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -161,13 +161,13 @@ config LOCALVERSION_AUTO
which is done within the script "scripts/setlocalversion".)
config BUILD_SALT
- string "Build ID Salt"
- default ""
- help
- The build ID is used to link binaries and their debug info. Setting
- this option will use the value in the calculation of the build id.
- This is mostly useful for distributions which want to ensure the
- build is unique between builds. It's safe to leave the default.
+ string "Build ID Salt"
+ default ""
+ help
+ The build ID is used to link binaries and their debug info. Setting
+ this option will use the value in the calculation of the build id.
+ This is mostly useful for distributions which want to ensure the
+ build is unique between builds. It's safe to leave the default.
config HAVE_KERNEL_GZIP
bool
@@ -1294,9 +1294,9 @@ menuconfig EXPERT
select DEBUG_KERNEL
help
This option allows certain base kernel options and settings
- to be disabled or tweaked. This is for specialized
- environments which can tolerate a "non-standard" kernel.
- Only use this if you really know what you are doing.
+ to be disabled or tweaked. This is for specialized
+ environments which can tolerate a "non-standard" kernel.
+ Only use this if you really know what you are doing.
config UID16
bool "Enable 16-bit UID system calls" if EXPERT
@@ -1406,11 +1406,11 @@ config BUG
bool "BUG() support" if EXPERT
default y
help
- Disabling this option eliminates support for BUG and WARN, reducing
- the size of your kernel image and potentially quietly ignoring
- numerous fatal conditions. You should only consider disabling this
- option for embedded systems with no facilities for reporting errors.
- Just say Y.
+ Disabling this option eliminates support for BUG and WARN, reducing
+ the size of your kernel image and potentially quietly ignoring
+ numerous fatal conditions. You should only consider disabling this
+ option for embedded systems with no facilities for reporting errors.
+ Just say Y.
config ELF_CORE
depends on COREDUMP
@@ -1426,8 +1426,8 @@ config PCSPKR_PLATFORM
select I8253_LOCK
default y
help
- This option allows to disable the internal PC-Speaker
- support, saving some memory.
+ This option allows to disable the internal PC-Speaker
+ support, saving some memory.
config BASE_FULL
default y
@@ -1555,18 +1555,18 @@ config KALLSYMS_ALL
bool "Include all symbols in kallsyms"
depends on DEBUG_KERNEL && KALLSYMS
help
- Normally kallsyms only contains the symbols of functions for nicer
- OOPS messages and backtraces (i.e., symbols from the text and inittext
- sections). This is sufficient for most cases. And only in very rare
- cases (e.g., when a debugger is used) all symbols are required (e.g.,
- names of variables from the data sections, etc).
+ Normally kallsyms only contains the symbols of functions for nicer
+ OOPS messages and backtraces (i.e., symbols from the text and inittext
+ sections). This is sufficient for most cases. And only in very rare
+ cases (e.g., when a debugger is used) all symbols are required (e.g.,
+ names of variables from the data sections, etc).
- This option makes sure that all symbols are loaded into the kernel
- image (i.e., symbols from all sections) in cost of increased kernel
- size (depending on the kernel configuration, it may be 300KiB or
- something like this).
+ This option makes sure that all symbols are loaded into the kernel
+ image (i.e., symbols from all sections) in cost of increased kernel
+ size (depending on the kernel configuration, it may be 300KiB or
+ something like this).
- Say N unless you really need all symbols.
+ Say N unless you really need all symbols.
config KALLSYMS_ABSOLUTE_PERCPU
bool
--
1.9.1
^ permalink raw reply related
* [PATCH v4 07/14] NFC: nxp-nci: Get rid of useless label
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andy Shevchenko, Sedat Dilek
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
Return directly in ->probe() since there no special cleaning is needed.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/nfc/nxp-nci/i2c.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 6a627d1b6f85..bec9b1ea78e2 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -265,16 +265,13 @@ static int nxp_nci_i2c_probe(struct i2c_client *client,
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
nfc_err(&client->dev, "Need I2C_FUNC_I2C\n");
- r = -ENODEV;
- goto probe_exit;
+ return -ENODEV;
}
phy = devm_kzalloc(&client->dev, sizeof(struct nxp_nci_i2c_phy),
GFP_KERNEL);
- if (!phy) {
- r = -ENOMEM;
- goto probe_exit;
- }
+ if (!phy)
+ return -ENOMEM;
phy->i2c_dev = client;
i2c_set_clientdata(client, phy);
@@ -298,7 +295,7 @@ static int nxp_nci_i2c_probe(struct i2c_client *client,
r = nxp_nci_probe(phy, &client->dev, &i2c_phy_ops,
NXP_NCI_I2C_MAX_PAYLOAD, &phy->ndev);
if (r < 0)
- goto probe_exit;
+ return r;
r = request_threaded_irq(client->irq, NULL,
nxp_nci_i2c_irq_thread_fn,
@@ -307,7 +304,6 @@ static int nxp_nci_i2c_probe(struct i2c_client *client,
if (r < 0)
nfc_err(&client->dev, "Unable to register IRQ handler\n");
-probe_exit:
return r;
}
--
2.20.1
^ permalink raw reply related
* [PATCH v4 05/14] NFC: nxp-nci: Add GPIO ACPI mapping table
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andy Shevchenko, Sedat Dilek
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
In order to unify GPIO resource request prepare gpiod_get_index()
to behave correctly when there is no mapping provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/nfc/nxp-nci/i2c.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 713c267acf88..7344405feddf 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -247,6 +247,15 @@ static irqreturn_t nxp_nci_i2c_irq_thread_fn(int irq, void *phy_id)
return IRQ_NONE;
}
+static const struct acpi_gpio_params firmware_gpios = { 1, 0, false };
+static const struct acpi_gpio_params enable_gpios = { 2, 0, false };
+
+static const struct acpi_gpio_mapping acpi_nxp_nci_gpios[] = {
+ { "enable-gpios", &enable_gpios, 1 },
+ { "firmware-gpios", &firmware_gpios, 1 },
+ { }
+};
+
static int nxp_nci_i2c_parse_devtree(struct i2c_client *client)
{
struct nxp_nci_i2c_phy *phy = i2c_get_clientdata(client);
@@ -269,9 +278,14 @@ static int nxp_nci_i2c_parse_devtree(struct i2c_client *client)
static int nxp_nci_i2c_acpi_config(struct nxp_nci_i2c_phy *phy)
{
struct i2c_client *client = phy->i2c_dev;
+ int r;
- phy->gpiod_en = devm_gpiod_get_index(&client->dev, NULL, 2, GPIOD_OUT_LOW);
- phy->gpiod_fw = devm_gpiod_get_index(&client->dev, NULL, 1, GPIOD_OUT_LOW);
+ r = devm_acpi_dev_add_driver_gpios(&client->dev, acpi_nxp_nci_gpios);
+ if (r)
+ return r;
+
+ phy->gpiod_en = devm_gpiod_get(&client->dev, "enable", GPIOD_OUT_LOW);
+ phy->gpiod_fw = devm_gpiod_get(&client->dev, "firmware", GPIOD_OUT_LOW);
if (IS_ERR(phy->gpiod_en) || IS_ERR(phy->gpiod_fw)) {
nfc_err(&client->dev, "No GPIOs\n");
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net: bridge: Allow bridge to joing multicast groups
From: Allan W. Nielsen @ 2019-07-29 14:35 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Horatiu Vultur, roopa, davem, bridge, netdev, linux-kernel
In-Reply-To: <e4cd0db9-695a-82a7-7dc0-623ded66a4e5@cumulusnetworks.com>
The 07/29/2019 17:21, Nikolay Aleksandrov wrote:
> On 29/07/2019 16:52, Allan W. Nielsen wrote:
> > The 07/29/2019 15:50, Nikolay Aleksandrov wrote:
> >> On 29/07/2019 15:22, Nikolay Aleksandrov wrote:
> >>> Hi Allan,
> >>> On 29/07/2019 15:14, Allan W. Nielsen wrote:
> >>>> First of all, as mentioned further down in this thread, I realized that our
> >>>> implementation of the multicast floodmasks does not align with the existing SW
> >>>> implementation. We will change this, such that all multicast packets goes to the
> >>>> SW bridge.
> >>>>
> >>>> This changes things a bit, not that much.
> >>>>
> >>>> I actually think you summarized the issue we have (after changing to multicast
> >>>> flood-masks) right here:
> >>>>
> >>>> The 07/26/2019 12:26, Nikolay Aleksandrov wrote:
> >>>>>>> Actually you mentioned non-IP traffic, so the querier stuff is not a problem. This
> >>>>>>> traffic will always be flooded by the bridge (and also a copy will be locally sent up).
> >>>>>>> Thus only the flooding may need to be controlled.
> >>>>
> >>>> This seems to be exactly what we need.
> >>>>
> >>>> Assuming we have a SW bridge (br0) with 4 slave interfaces (eth0-3). We use this
> >>>> on a network where we want to limit the flooding of frames with dmac
> >>>> 01:21:6C:00:00:01 (which is non IP traffic) to eth0 and eth1.
> >>>>
> >>>> One way of doing this could potentially be to support the following command:
> >>>>
> >>>> bridge fdb add 01:21:6C:00:00:01 port eth0
> >>>> bridge fdb append 01:21:6C:00:00:01 port eth1
> >> And the fdbs become linked lists?
> > Yes, it will most likely become a linked list
> >
> >> So we'll increase the complexity for something that is already supported by
> >> ACLs (e.g. tc) and also bridge per-port multicast flood flag ?
> > I do not think it can be supported with the facilities we have today in tc.
> >
> > We can do half of it (copy more fraems to the CPU) with tc, but we can not limit
> > the floodmask of a frame with tc (say we want it to flood to 2 out of 4 slave
> > ports).
> Why not ? You attach an egress filter for the ports and allow that dmac on only
> 2 of the ports.
Because we want a solution which we eventually can offload in HW. And the HW
facilities we have is doing ingress processing (we have no egress ACLs in this
design), and if we try to offload an egress rule, with an ingress HW facility,
then we will run into other issues.
/Allan
^ permalink raw reply
* [PATCH v4 14/14] NFC: nxp-nci: Fix recommendation for NFC_NXP_NCI_I2C Kconfig
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andy Shevchenko, Oleg Zhurakivskyy
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
From: Sedat Dilek <sedat.dilek@credativ.de>
This is a simple cleanup to the Kconfig help text as discussed in [1].
[1] https://marc.info/?t=155774435600001&r=1&w=2
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Signed-off-by: Sedat Dilek <sedat.dilek@credativ.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/nfc/nxp-nci/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
index 746b91aa74f0..e1f71deab6fc 100644
--- a/drivers/nfc/nxp-nci/Kconfig
+++ b/drivers/nfc/nxp-nci/Kconfig
@@ -22,4 +22,4 @@ config NFC_NXP_NCI_I2C
To compile this driver as a module, choose m here. The module will
be called nxp_nci_i2c.
- Say Y if unsure.
+ Say N if unsure.
--
2.20.1
^ permalink raw reply related
* [PATCH v4 08/14] NFC: nxp-nci: Constify acpi_device_id
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andy Shevchenko, Sedat Dilek
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
The content of acpi_device_id is not supposed to change at runtime.
All functions working with acpi_device_id provided by <linux/acpi.h>
work with const acpi_device_id. So mark the non-const structs as const.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/nfc/nxp-nci/i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index bec9b1ea78e2..4e71962dc557 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -330,7 +330,7 @@ static const struct of_device_id of_nxp_nci_i2c_match[] = {
MODULE_DEVICE_TABLE(of, of_nxp_nci_i2c_match);
#ifdef CONFIG_ACPI
-static struct acpi_device_id acpi_id[] = {
+static const struct acpi_device_id acpi_id[] = {
{ "NXP1001" },
{ "NXP7471" },
{ },
--
2.20.1
^ permalink raw reply related
* [PATCH v4 11/14] NFC: nxp-nci: Remove unused macro pr_fmt()
From: Andy Shevchenko @ 2019-07-29 13:35 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Sedat Dilek
Cc: Andy Shevchenko, Sedat Dilek
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
The macro had never been used.
The driver uses mostly the nfc_err(), which, with other macros in the family,
is backed by corresponding dev_err(). pr_fmt() is not used for dev_err()
macro. Moreover, there is no need to print the module name which is part of the
device instance name anyway.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/nfc/nxp-nci/i2c.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 59b0a02a813d..307bd2afbe05 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -12,8 +12,6 @@
* Copyright (C) 2012 Intel Corporation. All rights reserved.
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#include <linux/acpi.h>
#include <linux/delay.h>
#include <linux/i2c.h>
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net: bridge: Allow bridge to joing multicast groups
From: Nikolay Aleksandrov @ 2019-07-29 14:21 UTC (permalink / raw)
To: Allan W. Nielsen
Cc: Horatiu Vultur, roopa, davem, bridge, netdev, linux-kernel
In-Reply-To: <20190729135205.oiuthcyesal4b4ct@lx-anielsen.microsemi.net>
On 29/07/2019 16:52, Allan W. Nielsen wrote:
> The 07/29/2019 15:50, Nikolay Aleksandrov wrote:
>> On 29/07/2019 15:22, Nikolay Aleksandrov wrote:
>>> Hi Allan,
>>> On 29/07/2019 15:14, Allan W. Nielsen wrote:
>>>> First of all, as mentioned further down in this thread, I realized that our
>>>> implementation of the multicast floodmasks does not align with the existing SW
>>>> implementation. We will change this, such that all multicast packets goes to the
>>>> SW bridge.
>>>>
>>>> This changes things a bit, not that much.
>>>>
>>>> I actually think you summarized the issue we have (after changing to multicast
>>>> flood-masks) right here:
>>>>
>>>> The 07/26/2019 12:26, Nikolay Aleksandrov wrote:
>>>>>>> Actually you mentioned non-IP traffic, so the querier stuff is not a problem. This
>>>>>>> traffic will always be flooded by the bridge (and also a copy will be locally sent up).
>>>>>>> Thus only the flooding may need to be controlled.
>>>>
>>>> This seems to be exactly what we need.
>>>>
>>>> Assuming we have a SW bridge (br0) with 4 slave interfaces (eth0-3). We use this
>>>> on a network where we want to limit the flooding of frames with dmac
>>>> 01:21:6C:00:00:01 (which is non IP traffic) to eth0 and eth1.
>>>>
>>>> One way of doing this could potentially be to support the following command:
>>>>
>>>> bridge fdb add 01:21:6C:00:00:01 port eth0
>>>> bridge fdb append 01:21:6C:00:00:01 port eth1
>>>>
>>
>> And the fdbs become linked lists?
> Yes, it will most likely become a linked list
>
>> So we'll increase the complexity for something that is already supported by
>> ACLs (e.g. tc) and also bridge per-port multicast flood flag ?
> I do not think it can be supported with the facilities we have today in tc.
>
> We can do half of it (copy more fraems to the CPU) with tc, but we can not limit
> the floodmask of a frame with tc (say we want it to flood to 2 out of 4 slave
> ports).
>
Why not ? You attach an egress filter for the ports and allow that dmac on only
2 of the ports.
>> I'm sorry but that doesn't sound good to me for a case which is very rare and
>> there are existing ways to solve without incurring performance hits or increasing
>> code complexity.
> I do not consider it rarely, controling the forwarding of L2 multicast frames is
> quite common in the applications we are doing.
>
>> If you find a way to achieve this without incurring a performance hit or significant
>> code complexity increase, and without breaking current use-cases (e.g. unexpected default
>> forwarding behaviour changes) then please send a patch and we can discuss it further with
>> all details present. People have provided enough alternatives which avoid all of the
>> problems.
> Will do, thanks for the guidance.
>
> /Allan
>
^ permalink raw reply
* Re: [PATCH v6 rdma-next 1/6] RDMA/core: Create mmap database and cookie helper functions
From: Jason Gunthorpe @ 2019-07-29 14:11 UTC (permalink / raw)
To: Kamal Heib
Cc: Michal Kalderon, ariel.elior, dledford, galpress, linux-rdma,
davem, netdev
In-Reply-To: <20190728093051.GB5250@kheib-workstation>
On Sun, Jul 28, 2019 at 12:30:51PM +0300, Kamal Heib wrote:
> > Maybe put this in ib_core_uverbs.c ?
> >
> > Kamal, you've been tackling various cleanups, maybe making ib_uverbs
> > unloadable again is something you'd be keen on?
> >
>
> Yes, Could you please give some background on that?
Most of it is my fault from being too careless, but the general notion
is that all of these
$ grep EXPORT_SYMBOL uverbs_main.c uverbs_cmd.c uverbs_marshall.c rdma_core.c uverbs_std_types*.c uverbs_uapi.c
uverbs_main.c:EXPORT_SYMBOL(ib_uverbs_get_ucontext_file);
uverbs_main.c:EXPORT_SYMBOL(rdma_user_mmap_io);
uverbs_cmd.c:EXPORT_SYMBOL(flow_resources_alloc);
uverbs_cmd.c:EXPORT_SYMBOL(ib_uverbs_flow_resources_free);
uverbs_cmd.c:EXPORT_SYMBOL(flow_resources_add);
uverbs_marshall.c:EXPORT_SYMBOL(ib_copy_ah_attr_to_user);
uverbs_marshall.c:EXPORT_SYMBOL(ib_copy_qp_attr_to_user);
uverbs_marshall.c:EXPORT_SYMBOL(ib_copy_path_rec_to_user);
uverbs_marshall.c:EXPORT_SYMBOL(ib_copy_path_rec_from_user);
rdma_core.c:EXPORT_SYMBOL(uverbs_idr_class);
rdma_core.c:EXPORT_SYMBOL(uverbs_close_fd);
rdma_core.c:EXPORT_SYMBOL(uverbs_fd_class);
uverbs_std_types.c:EXPORT_SYMBOL(uverbs_destroy_def_handler);
Need to go into some 'ib_core uverbs support' .c file in the ib_core,
be moved to a header inline, or moved otherwise
Maybe it is now unrealistic that the uapi is so complicated, ie
uverbs_close_fd is just not easy to fixup..
Maybe the only ones that need fixing are ib_uverbs_get_ucontext_file
rdma_user_mmap_io as alot of drivers are entangled on those now.
The other stuff is much harder..
Jason
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox