* [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 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
* 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 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: [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 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
* 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 net-next v3 2/4] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-29 15:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Rob Herring, Leo Li, Alexandru Marginean,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190729153524.GG4110@lunn.ch>
>-----Original Message-----
>From: Andrew Lunn <andrew@lunn.ch>
>Sent: Monday, July 29, 2019 6:35 PM
>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>Cc: David S . Miller <davem@davemloft.net>; Rob Herring
><robh+dt@kernel.org>; Leo Li <leoyang.li@nxp.com>; Alexandru Marginean
><alexandru.marginean@nxp.com>; netdev@vger.kernel.org;
>devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>kernel@vger.kernel.org
>Subject: Re: [PATCH net-next v3 2/4] enetc: Add mdio bus driver for the PCIe
>MDIO endpoint
>
>> + hw->port = pci_iomap(pdev, 0, 0);
>> + if (!bus->priv) {
>
>hw->port ??
>
Yeah, better ignore this for now 😊
It's for the enetc accessors, enetc_port_..().
^ permalink raw reply
* Re: [PATCH bpf-next v5 1/6] include/bpf.h: Remove map_insert_ctx() stubs
From: Jesper Dangaard Brouer @ 2019-07-29 15:42 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, David Miller,
Jakub Kicinski, Björn Töpel, Yonghong Song, brouer
In-Reply-To: <156415721232.13581.13120224208737507294.stgit@alrua-x1>
On Fri, 26 Jul 2019 18:06:52 +0200
Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> From: Toke Høiland-Jørgensen <toke@redhat.com>
>
> When we changed the device and CPU maps to use linked lists instead of
> bitmaps, we also removed the need for the map_insert_ctx() helpers to keep
> track of the bitmaps inside each map. However, it seems I forgot to remove
> the function definitions stubs, so remove those here.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> Acked-by: Yonghong Song <yhs@fb.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* RE: [PATCH net-next v3 2/4] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-29 15:46 UTC (permalink / raw)
To: Claudiu Manoil, Andrew Lunn
Cc: David S . Miller, Rob Herring, Leo Li, Alexandru Marginean,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI1PR04MB48806AF2F6CEDE105B78086696DD0@VI1PR04MB4880.eurprd04.prod.outlook.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
>Behalf Of Claudiu Manoil
>Sent: Monday, July 29, 2019 6:40 PM
>To: Andrew Lunn <andrew@lunn.ch>
>Cc: David S . Miller <davem@davemloft.net>; Rob Herring
><robh+dt@kernel.org>; Leo Li <leoyang.li@nxp.com>; Alexandru Marginean
><alexandru.marginean@nxp.com>; netdev@vger.kernel.org;
>devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>kernel@vger.kernel.org
>Subject: RE: [PATCH net-next v3 2/4] enetc: Add mdio bus driver for the PCIe
>MDIO endpoint
>
>>-----Original Message-----
>>From: Andrew Lunn <andrew@lunn.ch>
>>Sent: Monday, July 29, 2019 6:35 PM
>>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>>Cc: David S . Miller <davem@davemloft.net>; Rob Herring
>><robh+dt@kernel.org>; Leo Li <leoyang.li@nxp.com>; Alexandru Marginean
>><alexandru.marginean@nxp.com>; netdev@vger.kernel.org;
>>devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>linux- kernel@vger.kernel.org
>>Subject: Re: [PATCH net-next v3 2/4] enetc: Add mdio bus driver for the
>>PCIe MDIO endpoint
>>
>>> + hw->port = pci_iomap(pdev, 0, 0);
>>> + if (!bus->priv) {
>>
>>hw->port ??
>>
>
>Yeah, better ignore this for now 😊
>It's for the enetc accessors, enetc_port_..().
Oh I see, it's a mistake. I'm checking the wrong thing.
Sorry. Thanks for the review.
^ permalink raw reply
* Re: [PATCH v4 1/5] vsock/virtio: limit the memory used per-socket
From: Michael S. Tsirkin @ 2019-07-29 15:49 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, Stefan Hajnoczi, David S. Miller,
virtualization, Jason Wang, kvm
In-Reply-To: <20190729153656.zk4q4rob5oi6iq7l@steredhat>
On Mon, Jul 29, 2019 at 05:36:56PM +0200, Stefano Garzarella wrote:
> 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
Interesting. You are right, and at some level the protocol forces copies.
We could try to detect that the actual memory is getting close to
admin limits and force copies on queued packets after the fact.
Is that practical?
And yes we can extend the credit accounting to include buffer size.
That's a protocol change but maybe it makes sense.
--
MST
^ permalink raw reply
* Re: [PATCH iproute2 0/1] Fix s64 argument parsing
From: Stephen Hemminger @ 2019-07-29 15:51 UTC (permalink / raw)
To: Kurt Kanzenbach; +Cc: netdev
In-Reply-To: <20190729110408.fi6xfhc2msg5elih@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Mon, 29 Jul 2019 13:04:09 +0200
Kurt Kanzenbach <kurt.kanzenbach@linutronix.de> wrote:
> On Thu, Jul 04, 2019 at 02:24:26PM +0200, Kurt Kanzenbach wrote:
> > Hi,
> >
> > while using the TAPRIO Qdisc on ARM32 I've noticed that the base_time parameter is
> > incorrectly configured. The problem is the utility function get_s64() used by
> > TAPRIO doesn't parse the value correctly.
>
> polite ping.
>
> >
> > Thanks,
> > Kurt
> >
> > Kurt Kanzenbach (1):
> > utils: Fix get_s64() function
> >
> > lib/utils.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --
> > 2.11.0
> >
Not sure why this got marked "Changes Requested"
Applied.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 00/14] NFC: nxp-nci: clean up and new device support
From: David Miller @ 2019-07-29 15:56 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: clement.perrochaud, charles.gorand, netdev, sedat.dilek
In-Reply-To: <20190729133514.13164-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon, 29 Jul 2019 16:35:00 +0300
> Few people reported that some laptops are coming with new ACPI ID for the
> devices should be supported by nxp-nci driver.
>
> This series adds new ID (patch 2), cleans up the driver from legacy platform
> data and unifies GPIO request for Device Tree and ACPI (patches 3-6), removes
> dead or unneeded code (patches 7, 9, 11), constifies ID table (patch 8),
> removes comma in terminator line for better maintenance (patch 10) and
> rectifies Kconfig entry (patches 12-14).
>
> It also contains a fix for NFC subsystem as suggested by Sedat.
>
> Series has been tested by Sedat.
...
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/1] qed[net-next] Add new ethtool supported port types based on media.
From: David Miller @ 2019-07-29 15:59 UTC (permalink / raw)
To: rahulv; +Cc: netdev, aelior, mkalderon
In-Reply-To: <20190729074959.25286-1-rahulv@marvell.com>
Please don't format the Subject line this way.
The only place 'net-next' should appear is in the initial [] brackted patch
designation [PATCH net-next 1/1], the later one "qed[net-next]" must be
removed and replaced by a colon charater "qed: "
Thanks.
^ permalink raw reply
* Re: [PATCH] arcnet: com90xx: Mark expected switch fall-throughs
From: Kees Cook @ 2019-07-29 15:59 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Michael Grzeschik, David S. Miller, netdev, linux-kernel,
Stephen Rothwell
In-Reply-To: <20190729110953.GA3048@embeddedor>
On Mon, Jul 29, 2019 at 06:09:53AM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: powerpc allyesconfig):
>
> drivers/net/arcnet/com90xx.c: In function 'com90xx_setup':
> include/linux/printk.h:304:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
> printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/arcnet/com90xx.c:695:3: note: in expansion of macro 'pr_err'
> pr_err("Too many arguments\n");
> ^~~~~~
> drivers/net/arcnet/com90xx.c:696:2: note: here
> case 3: /* Mem address */
> ^~~~
> drivers/net/arcnet/com90xx.c:697:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
> shmem = ints[3];
> ~~~~~~^~~~~~~~~
> drivers/net/arcnet/com90xx.c:698:2: note: here
> case 2: /* IRQ */
> ^~~~
> drivers/net/arcnet/com90xx.c:699:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
> irq = ints[2];
> ~~~~^~~~~~~~~
> drivers/net/arcnet/com90xx.c:700:2: note: here
> case 1: /* IO address */
> ^~~~
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> drivers/net/arcnet/com90xx.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/arcnet/com90xx.c b/drivers/net/arcnet/com90xx.c
> index ca4a57c30bf8..bd75d06ad7df 100644
> --- a/drivers/net/arcnet/com90xx.c
> +++ b/drivers/net/arcnet/com90xx.c
> @@ -693,10 +693,13 @@ static int __init com90xx_setup(char *s)
> switch (ints[0]) {
> default: /* ERROR */
> pr_err("Too many arguments\n");
> + /* Fall through */
> case 3: /* Mem address */
> shmem = ints[3];
> + /* Fall through */
> case 2: /* IRQ */
> irq = ints[2];
> + /* Fall through */
> case 1: /* IO address */
> io = ints[1];
> }
> --
> 2.22.0
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] arcnet: com90io: Mark expected switch fall-throughs
From: Kees Cook @ 2019-07-29 16:00 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Michael Grzeschik, David S. Miller, netdev, linux-kernel,
Stephen Rothwell
In-Reply-To: <20190729111320.GA3193@embeddedor>
On Mon, Jul 29, 2019 at 06:13:20AM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: powerpc allyesconfig):
>
> drivers/net/arcnet/com90io.c: In function 'com90io_setup':
> include/linux/printk.h:304:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
> printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/arcnet/com90io.c:365:3: note: in expansion of macro 'pr_err'
> pr_err("Too many arguments\n");
> ^~~~~~
> drivers/net/arcnet/com90io.c:366:2: note: here
> case 2: /* IRQ */
> ^~~~
> drivers/net/arcnet/com90io.c:367:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
> irq = ints[2];
> ~~~~^~~~~~~~~
> drivers/net/arcnet/com90io.c:368:2: note: here
> case 1: /* IO address */
> ^~~~
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> drivers/net/arcnet/com90io.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/arcnet/com90io.c b/drivers/net/arcnet/com90io.c
> index 2c546013a980..186bbf87bc84 100644
> --- a/drivers/net/arcnet/com90io.c
> +++ b/drivers/net/arcnet/com90io.c
> @@ -363,8 +363,10 @@ static int __init com90io_setup(char *s)
> switch (ints[0]) {
> default: /* ERROR */
> pr_err("Too many arguments\n");
> + /* Fall through */
> case 2: /* IRQ */
> irq = ints[2];
> + /* Fall through */
> case 1: /* IO address */
> io = ints[1];
> }
> --
> 2.22.0
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] arcnet: arc-rimi: Mark expected switch fall-throughs
From: Kees Cook @ 2019-07-29 16:00 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Michael Grzeschik, David S. Miller, netdev, linux-kernel,
Stephen Rothwell
In-Reply-To: <20190729111550.GA3327@embeddedor>
On Mon, Jul 29, 2019 at 06:15:50AM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: powerpc allyesconfig):
>
> drivers/net/arcnet/arc-rimi.c: In function 'arcrimi_setup':
> include/linux/printk.h:304:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
> printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/arcnet/arc-rimi.c:365:3: note: in expansion of macro 'pr_err'
> pr_err("Too many arguments\n");
> ^~~~~~
> drivers/net/arcnet/arc-rimi.c:366:2: note: here
> case 3: /* Node ID */
> ^~~~
> drivers/net/arcnet/arc-rimi.c:367:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
> node = ints[3];
> ~~~~~^~~~~~~~~
> drivers/net/arcnet/arc-rimi.c:368:2: note: here
> case 2: /* IRQ */
> ^~~~
> drivers/net/arcnet/arc-rimi.c:369:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
> irq = ints[2];
> ~~~~^~~~~~~~~
> drivers/net/arcnet/arc-rimi.c:370:2: note: here
> case 1: /* IO address */
> ^~~~
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> drivers/net/arcnet/arc-rimi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/arcnet/arc-rimi.c b/drivers/net/arcnet/arc-rimi.c
> index 11c5bad95226..14a5fb378145 100644
> --- a/drivers/net/arcnet/arc-rimi.c
> +++ b/drivers/net/arcnet/arc-rimi.c
> @@ -363,10 +363,13 @@ static int __init arcrimi_setup(char *s)
> switch (ints[0]) {
> default: /* ERROR */
> pr_err("Too many arguments\n");
> + /* 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
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] arcnet: com20020-isa: Mark expected switch fall-throughs
From: Kees Cook @ 2019-07-29 16:01 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Michael Grzeschik, David S. Miller, netdev, linux-kernel,
Geert Uytterhoeven
In-Reply-To: <20190729142503.GA7917@embeddedor>
On Mon, Jul 29, 2019 at 09:25:03AM -0500, Gustavo A. R. Silva wrote:
> 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>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> 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
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v4 1/5] vsock/virtio: limit the memory used per-socket
From: Michael S. Tsirkin @ 2019-07-29 16:01 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, Stefan Hajnoczi, David S. Miller,
virtualization, Jason Wang, kvm
In-Reply-To: <20190729153656.zk4q4rob5oi6iq7l@steredhat>
On Mon, Jul 29, 2019 at 05:36:56PM +0200, Stefano Garzarella wrote:
> 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/
>
So one thing we can easily do is to under-report the
available credit. E.g. if we copy up to 256bytes,
then report just 256bytes for every buffer in the queue.
>
> Thanks,
> Stefano
^ permalink raw reply
* Re: [PATCH bpf-next v5 2/6] xdp: Refactor devmap allocation code for reuse
From: Jesper Dangaard Brouer @ 2019-07-29 16:02 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, David Miller,
Jakub Kicinski, Björn Töpel, Yonghong Song, brouer
In-Reply-To: <156415721358.13581.4862146144828700187.stgit@alrua-x1>
On Fri, 26 Jul 2019 18:06:53 +0200
Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> From: Toke Høiland-Jørgensen <toke@redhat.com>
>
> The subsequent patch to add a new devmap sub-type can re-use much of the
> initialisation and allocation code, so refactor it into separate functions.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> Acked-by: Yonghong Song <yhs@fb.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH 2/5] staging: fsl-dpaa2/ethsw: notify switchdev of offloaded entry
From: Ioana Ciornei @ 2019-07-29 16:11 UTC (permalink / raw)
To: gregkh, linux-kernel
Cc: netdev, davem, andrew, f.fainelli, jiri, Ioana Ciornei
In-Reply-To: <1564416712-16946-1-git-send-email-ioana.ciornei@nxp.com>
Notify switchdev in case the FDB entry was successfully offloaded.
This will help users to make the distinction between entries known to
the HW switch and those that are held only on the software bridge.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index 341c36b3a76d..d6953ac427b1 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -1039,6 +1039,7 @@ static void ethsw_switchdev_event_work(struct work_struct *work)
container_of(work, struct ethsw_switchdev_event_work, work);
struct net_device *dev = switchdev_work->dev;
struct switchdev_notifier_fdb_info *fdb_info;
+ int err;
rtnl_lock();
fdb_info = &switchdev_work->fdb_info;
@@ -1046,9 +1047,16 @@ static void ethsw_switchdev_event_work(struct work_struct *work)
switch (switchdev_work->event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE:
if (is_unicast_ether_addr(fdb_info->addr))
- ethsw_port_fdb_add_uc(netdev_priv(dev), fdb_info->addr);
+ err = ethsw_port_fdb_add_uc(netdev_priv(dev),
+ fdb_info->addr);
else
- ethsw_port_fdb_add_mc(netdev_priv(dev), fdb_info->addr);
+ err = ethsw_port_fdb_add_mc(netdev_priv(dev),
+ fdb_info->addr);
+ if (err)
+ break;
+ fdb_info->offloaded = true;
+ call_switchdev_notifiers(SWITCHDEV_FDB_OFFLOADED, dev,
+ &fdb_info->info, NULL);
break;
case SWITCHDEV_FDB_DEL_TO_DEVICE:
if (is_unicast_ether_addr(fdb_info->addr))
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] staging: fsl-dpaa2/ethsw: add .ndo_fdb_dump callback
From: Ioana Ciornei @ 2019-07-29 16:11 UTC (permalink / raw)
To: gregkh, linux-kernel
Cc: netdev, davem, andrew, f.fainelli, jiri, Ioana Ciornei
In-Reply-To: <1564416712-16946-1-git-send-email-ioana.ciornei@nxp.com>
Implement the .ndo_fdb_dump callback for the switch net devices. The
list of all offloaded FDB entries is retrieved through the dpsw_fdb_dump()
firmware call. Filter the entries by the switch port on which the
callback was called and for each of them create a new neighbour message.
Also remove the requirement from the TODO list.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/TODO | 1 -
drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h | 15 +++-
drivers/staging/fsl-dpaa2/ethsw/dpsw.c | 51 +++++++++++
drivers/staging/fsl-dpaa2/ethsw/dpsw.h | 25 ++++++
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 135 ++++++++++++++++++++++++++++-
5 files changed, 224 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/TODO b/drivers/staging/fsl-dpaa2/ethsw/TODO
index 24b5e95a96f8..4d46857b0b2b 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/TODO
+++ b/drivers/staging/fsl-dpaa2/ethsw/TODO
@@ -1,7 +1,6 @@
* Add I/O capabilities on switch port netdevices. This will allow control
traffic to reach the CPU.
* Add ACL to redirect control traffic to CPU.
-* Add support for displaying learned FDB entries
* Add support for multiple FDBs and switch port partitioning
* MC firmware uprev; the DPAA2 objects used by the Ethernet Switch driver
need to be kept in sync with binary interface changes in MC
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
index 14b974defa3a..5e1339daa7c7 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
@@ -10,7 +10,7 @@
/* DPSW Version */
#define DPSW_VER_MAJOR 8
-#define DPSW_VER_MINOR 0
+#define DPSW_VER_MINOR 1
#define DPSW_CMD_BASE_VERSION 1
#define DPSW_CMD_ID_OFFSET 4
@@ -67,6 +67,7 @@
#define DPSW_CMDID_FDB_ADD_MULTICAST DPSW_CMD_ID(0x086)
#define DPSW_CMDID_FDB_REMOVE_MULTICAST DPSW_CMD_ID(0x087)
#define DPSW_CMDID_FDB_SET_LEARNING_MODE DPSW_CMD_ID(0x088)
+#define DPSW_CMDID_FDB_DUMP DPSW_CMD_ID(0x08A)
/* Macros for accessing command fields smaller than 1byte */
#define DPSW_MASK(field) \
@@ -351,6 +352,18 @@ struct dpsw_cmd_fdb_set_learning_mode {
u8 mode;
};
+struct dpsw_cmd_fdb_dump {
+ __le16 fdb_id;
+ __le16 pad0;
+ __le32 pad1;
+ __le64 iova_addr;
+ __le32 iova_size;
+};
+
+struct dpsw_rsp_fdb_dump {
+ __le16 num_entries;
+};
+
struct dpsw_rsp_get_api_version {
__le16 version_major;
__le16 version_minor;
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw.c b/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
index cabed77b445d..56b0fa789a67 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
@@ -981,6 +981,57 @@ int dpsw_fdb_add_unicast(struct fsl_mc_io *mc_io,
}
/**
+ * dpsw_fdb_dump() - Dump the content of FDB table into memory.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPSW object
+ * @fdb_id: Forwarding Database Identifier
+ * @iova_addr: Data will be stored here as an array of struct fdb_dump_entry
+ * @iova_size: Memory size allocated at iova_addr
+ * @num_entries:Number of entries written at iova_addr
+ *
+ * Return: Completion status. '0' on Success; Error code otherwise.
+ *
+ * The memory allocated at iova_addr must be initialized with zero before
+ * command execution. If the FDB table does not fit into memory MC will stop
+ * after the memory is filled up.
+ * The struct fdb_dump_entry array must be parsed until the end of memory
+ * area or until an entry with mac_addr set to zero is found.
+ */
+int dpsw_fdb_dump(struct fsl_mc_io *mc_io,
+ u32 cmd_flags,
+ u16 token,
+ u16 fdb_id,
+ u64 iova_addr,
+ u32 iova_size,
+ u16 *num_entries)
+{
+ struct dpsw_cmd_fdb_dump *cmd_params;
+ struct dpsw_rsp_fdb_dump *rsp_params;
+ struct fsl_mc_command cmd = { 0 };
+ int err;
+
+ /* prepare command */
+ cmd.header = mc_encode_cmd_header(DPSW_CMDID_FDB_DUMP,
+ cmd_flags,
+ token);
+ cmd_params = (struct dpsw_cmd_fdb_dump *)cmd.params;
+ cmd_params->fdb_id = cpu_to_le16(fdb_id);
+ cmd_params->iova_addr = cpu_to_le64(iova_addr);
+ cmd_params->iova_size = cpu_to_le32(iova_size);
+
+ /* send command to mc */
+ err = mc_send_command(mc_io, &cmd);
+ if (err)
+ return err;
+
+ rsp_params = (struct dpsw_rsp_fdb_dump *)cmd.params;
+ *num_entries = le16_to_cpu(rsp_params->num_entries);
+
+ return 0;
+}
+
+/**
* dpsw_fdb_remove_unicast() - removes an entry from MAC lookup table
* @mc_io: Pointer to MC portal's I/O object
* @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
index 0d9330e01915..25b45850925c 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
@@ -465,6 +465,31 @@ int dpsw_fdb_remove_unicast(struct fsl_mc_io *mc_io,
u16 fdb_id,
const struct dpsw_fdb_unicast_cfg *cfg);
+#define DPSW_FDB_ENTRY_TYPE_DYNAMIC BIT(0)
+#define DPSW_FDB_ENTRY_TYPE_UNICAST BIT(1)
+
+/**
+ * struct fdb_dump_entry - fdb snapshot entry
+ * @mac_addr: MAC address
+ * @type: bit0 - DINAMIC(1)/STATIC(0), bit1 - UNICAST(1)/MULTICAST(0)
+ * @if_info: unicast - egress interface, multicast - number of egress interfaces
+ * @if_mask: multicast - egress interface mask
+ */
+struct fdb_dump_entry {
+ u8 mac_addr[6];
+ u8 type;
+ u8 if_info;
+ u8 if_mask[8];
+};
+
+int dpsw_fdb_dump(struct fsl_mc_io *mc_io,
+ u32 cmd_flags,
+ u16 token,
+ u16 fdb_id,
+ u64 iova_addr,
+ u32 iova_size,
+ u16 *num_entries);
+
/**
* struct dpsw_fdb_multicast_cfg - Multi-cast entry configuration
* @type: Select static or dynamic entry
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index d6953ac427b1..e6423f1e190d 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -22,7 +22,7 @@
/* Minimal supported DPSW version */
#define DPSW_MIN_VER_MAJOR 8
-#define DPSW_MIN_VER_MINOR 0
+#define DPSW_MIN_VER_MINOR 1
#define DEFAULT_VLAN_ID 1
@@ -529,6 +529,138 @@ static int port_get_phys_name(struct net_device *netdev, char *name,
return 0;
}
+struct ethsw_dump_ctx {
+ struct net_device *dev;
+ struct sk_buff *skb;
+ struct netlink_callback *cb;
+ int idx;
+};
+
+static int ethsw_fdb_do_dump(struct fdb_dump_entry *entry,
+ struct ethsw_dump_ctx *dump)
+{
+ int is_dynamic = entry->type & DPSW_FDB_ENTRY_DINAMIC;
+ u32 portid = NETLINK_CB(dump->cb->skb).portid;
+ u32 seq = dump->cb->nlh->nlmsg_seq;
+ struct nlmsghdr *nlh;
+ struct ndmsg *ndm;
+
+ if (dump->idx < dump->cb->args[2])
+ goto skip;
+
+ nlh = nlmsg_put(dump->skb, portid, seq, RTM_NEWNEIGH,
+ sizeof(*ndm), NLM_F_MULTI);
+ if (!nlh)
+ return -EMSGSIZE;
+
+ ndm = nlmsg_data(nlh);
+ ndm->ndm_family = AF_BRIDGE;
+ ndm->ndm_pad1 = 0;
+ ndm->ndm_pad2 = 0;
+ ndm->ndm_flags = NTF_SELF;
+ ndm->ndm_type = 0;
+ ndm->ndm_ifindex = dump->dev->ifindex;
+ ndm->ndm_state = is_dynamic ? NUD_REACHABLE : NUD_NOARP;
+
+ if (nla_put(dump->skb, NDA_LLADDR, ETH_ALEN, entry->mac_addr))
+ goto nla_put_failure;
+
+ nlmsg_end(dump->skb, nlh);
+
+skip:
+ dump->idx++;
+ return 0;
+
+nla_put_failure:
+ nlmsg_cancel(dump->skb, nlh);
+ return -EMSGSIZE;
+}
+
+static int port_fdb_valid_entry(struct fdb_dump_entry *entry,
+ struct ethsw_port_priv *port_priv)
+{
+ int idx = port_priv->idx;
+ int valid;
+
+ if (entry->type & DPSW_FDB_ENTRY_TYPE_UNICAST)
+ valid = entry->if_info == port_priv->idx;
+ else
+ valid = entry->if_mask[idx / 8] & BIT(idx % 8);
+
+ return valid;
+}
+
+static int port_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
+ struct net_device *net_dev,
+ struct net_device *filter_dev, int *idx)
+{
+ struct ethsw_port_priv *port_priv = netdev_priv(net_dev);
+ struct ethsw_core *ethsw = port_priv->ethsw_data;
+ struct device *dev = net_dev->dev.parent;
+ struct fdb_dump_entry *fdb_entries;
+ struct fdb_dump_entry fdb_entry;
+ struct ethsw_dump_ctx dump = {
+ .dev = net_dev,
+ .skb = skb,
+ .cb = cb,
+ .idx = *idx,
+ };
+ dma_addr_t fdb_dump_iova;
+ u16 num_fdb_entries;
+ u32 fdb_dump_size;
+ int err = 0, i;
+ u8 *dma_mem;
+
+ fdb_dump_size = ethsw->sw_attr.max_fdb_entries * sizeof(fdb_entry);
+ dma_mem = kzalloc(fdb_dump_size, GFP_KERNEL);
+ if (!dma_mem)
+ return -ENOMEM;
+
+ memset(dma_mem, 0, fdb_dump_size);
+
+ fdb_dump_iova = dma_map_single(dev, dma_mem, fdb_dump_size,
+ DMA_FROM_DEVICE);
+ if (dma_mapping_error(dev, fdb_dump_iova)) {
+ netdev_err(net_dev, "dma_map_single() failed\n");
+ err = -ENOMEM;
+ goto err_map;
+ }
+
+ err = dpsw_fdb_dump(ethsw->mc_io, 0, ethsw->dpsw_handle, 0,
+ fdb_dump_iova, fdb_dump_size, &num_fdb_entries);
+ if (err) {
+ netdev_err(net_dev, "dpsw_fdb_dump() = %d\n", err);
+ goto err_dump;
+ }
+
+ dma_unmap_single(dev, fdb_dump_iova, fdb_dump_size, DMA_FROM_DEVICE);
+
+ fdb_entries = (struct fdb_dump_entry *)dma_mem;
+ for (i = 0; i < num_fdb_entries; i++) {
+ fdb_entry = fdb_entries[i];
+
+ if (!port_fdb_valid_entry(&fdb_entry, port_priv))
+ continue;
+
+ err = ethsw_fdb_do_dump(&fdb_entry, &dump);
+ if (err)
+ goto end;
+ }
+
+end:
+ *idx = dump.idx;
+
+ kfree(dma_mem);
+
+ return 0;
+
+err_dump:
+ dma_unmap_single(dev, fdb_dump_iova, fdb_dump_size, DMA_TO_DEVICE);
+err_map:
+ kfree(dma_mem);
+ return err;
+}
+
static const struct net_device_ops ethsw_port_ops = {
.ndo_open = port_open,
.ndo_stop = port_stop,
@@ -538,6 +670,7 @@ static int port_get_phys_name(struct net_device *netdev, char *name,
.ndo_change_mtu = port_change_mtu,
.ndo_has_offload_stats = port_has_offload_stats,
.ndo_get_offload_stats = port_get_offload_stats,
+ .ndo_fdb_dump = port_fdb_dump,
.ndo_start_xmit = port_dropframe,
.ndo_get_port_parent_id = swdev_get_port_parent_id,
--
1.9.1
^ permalink raw reply related
* [PATCH 5/5] staging: fsl-dpaa2/ethsw: add .ndo_fdb[add|del] callbacks
From: Ioana Ciornei @ 2019-07-29 16:11 UTC (permalink / raw)
To: gregkh, linux-kernel
Cc: netdev, davem, andrew, f.fainelli, jiri, Ioana Ciornei
In-Reply-To: <1564416712-16946-1-git-send-email-ioana.ciornei@nxp.com>
Add the .ndo_fdb_[add|del] callbacks so that FDB entries not associated
with a master device still end up offloaded.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index 2d3179c6bad8..4b94a01513a7 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -316,6 +316,31 @@ static int ethsw_port_fdb_del_mc(struct ethsw_port_priv *port_priv,
return err;
}
+static int port_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
+ struct net_device *dev, const unsigned char *addr,
+ u16 vid, u16 flags,
+ struct netlink_ext_ack *extack)
+{
+ if (is_unicast_ether_addr(addr))
+ return ethsw_port_fdb_add_uc(netdev_priv(dev),
+ addr);
+ else
+ return ethsw_port_fdb_add_mc(netdev_priv(dev),
+ addr);
+}
+
+static int port_fdb_del(struct ndmsg *ndm, struct nlattr *tb[],
+ struct net_device *dev,
+ const unsigned char *addr, u16 vid)
+{
+ if (is_unicast_ether_addr(addr))
+ return ethsw_port_fdb_del_uc(netdev_priv(dev),
+ addr);
+ else
+ return ethsw_port_fdb_del_mc(netdev_priv(dev),
+ addr);
+}
+
static void port_get_stats(struct net_device *netdev,
struct rtnl_link_stats64 *stats)
{
@@ -670,6 +695,8 @@ static int port_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
.ndo_change_mtu = port_change_mtu,
.ndo_has_offload_stats = port_has_offload_stats,
.ndo_get_offload_stats = port_get_offload_stats,
+ .ndo_fdb_add = port_fdb_add,
+ .ndo_fdb_del = port_fdb_del,
.ndo_fdb_dump = port_fdb_dump,
.ndo_start_xmit = port_dropframe,
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] staging: fsl-dpaa2/ethsw: check added_by_user flag
From: Ioana Ciornei @ 2019-07-29 16:11 UTC (permalink / raw)
To: gregkh, linux-kernel
Cc: netdev, davem, andrew, f.fainelli, jiri, Ioana Ciornei
In-Reply-To: <1564416712-16946-1-git-send-email-ioana.ciornei@nxp.com>
We do not want to offload FDB entries if not added by user as static
entries. Check the added_by_user flag and break if not set.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index e6423f1e190d..2d3179c6bad8 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -1179,6 +1179,8 @@ static void ethsw_switchdev_event_work(struct work_struct *work)
switch (switchdev_work->event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE:
+ if (!fdb_info->added_by_user)
+ break;
if (is_unicast_ether_addr(fdb_info->addr))
err = ethsw_port_fdb_add_uc(netdev_priv(dev),
fdb_info->addr);
@@ -1192,6 +1194,8 @@ static void ethsw_switchdev_event_work(struct work_struct *work)
&fdb_info->info, NULL);
break;
case SWITCHDEV_FDB_DEL_TO_DEVICE:
+ if (!fdb_info->added_by_user)
+ break;
if (is_unicast_ether_addr(fdb_info->addr))
ethsw_port_fdb_del_uc(netdev_priv(dev), fdb_info->addr);
else
--
1.9.1
^ permalink raw reply related
* [PATCH 1/5] staging: fsl-dpaa2/ethsw: remove unused structure
From: Ioana Ciornei @ 2019-07-29 16:11 UTC (permalink / raw)
To: gregkh, linux-kernel
Cc: netdev, davem, andrew, f.fainelli, jiri, Ioana Ciornei
In-Reply-To: <1564416712-16946-1-git-send-email-ioana.ciornei@nxp.com>
The dpsw_cfg structure is only used when creating a new dpsw DPAA2
object. In the DPAA2 architecture, objects are created at boot time by
the firmware or dynamically from userspace while drivers on the fsl-mc
bus only configure those objects.
Remove the structure since it's of no use.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/dpsw.h | 31 -------------------------------
1 file changed, 31 deletions(-)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
index 25635259ce44..0d9330e01915 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
@@ -75,37 +75,6 @@ enum dpsw_component_type {
DPSW_COMPONENT_TYPE_S_VLAN
};
-/**
- * struct dpsw_cfg - DPSW configuration
- * @num_ifs: Number of external and internal interfaces
- * @adv: Advanced parameters; default is all zeros;
- * use this structure to change default settings
- * @adv.options: Enable/Disable DPSW features (bitmap)
- * @adv.max_vlans: Maximum Number of VLAN's; 0 - indicates default 16
- * @adv.max_meters_per_if: Number of meters per interface
- * @adv.max_fdbs: Maximum Number of FDB's; 0 - indicates default 16
- * @adv.max_fdb_entries: Number of FDB entries for default FDB table;
- * 0 - indicates default 1024 entries.
- * @adv.fdb_aging_time: Default FDB aging time for default FDB table;
- * 0 - indicates default 300 seconds
- * @adv.max_fdb_mc_groups: Number of multicast groups in each FDB table;
- * 0 - indicates default 32
- * @adv.component_type: Indicates the component type of this bridge
- */
-struct dpsw_cfg {
- u16 num_ifs;
- struct {
- u64 options;
- u16 max_vlans;
- u8 max_meters_per_if;
- u8 max_fdbs;
- u16 max_fdb_entries;
- u16 fdb_aging_time;
- u16 max_fdb_mc_groups;
- enum dpsw_component_type component_type;
- } adv;
-};
-
int dpsw_enable(struct fsl_mc_io *mc_io,
u32 cmd_flags,
u16 token);
--
1.9.1
^ permalink raw reply related
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