- Dec 08, 2021
-
-
Florian Westphal authored
earlier patch added IP_TOS setsockopt support, this allows to get the value set by earlier setsockopt. Extends mptcp_put_int_option to handle u8 input/output by adding required cast. Reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Davide Caratti authored
a non-zero 'id' is sufficient to identify MPTCP endpoints: allow changing the value of 'backup' bit by simply specifying the endpoint id. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/158 Signed-off-by:
Davide Caratti <dcaratti@redhat.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Florian Westphal authored
client & server use a unix socket connection to communicate outside of the mptcp connection. This allows the consumer to know in advance how many bytes have been (or will be) sent by the peer. This allows stricter checks on the bytecounts reported by TCP_INQ cmsg. Suggested-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Florian Westphal authored
Allows to query in-sequence data ready for read(), total bytes in write queue and total bytes in write queue that have not yet been sent. v2: remove unneeded READ_ONCE() (Paolo Abeni) v3: check for new data unconditionally in SIOCINQ ioctl (Mat Martineau) Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Florian Westphal authored
Do checks on the returned inq counter. Fail on: 1. Huge value (> 1 kbyte, test case files are 1 kb) 2. last hint larger than returned bytes when read was short 3. erronenous indication of EOF. 3) happens when a hint of X bytes reads X-1 on next call but next recvmsg returns more data (instead of EOF). Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Florian Westphal authored
Support the TCP_INQ setsockopt. This is a boolean that tells recvmsg path to include the remaining in-sequence bytes in the cmsg data. v2: do not use CB(skb)->offset, increment map_seq instead (Paolo Abeni) v3: adjust CB(skb)->map_seq when taking skb from ofo queue (Paolo Abeni) Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/224 Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
vrf_rt6_release() and vrf_rtable_release() changes dst->dev Instead of dev_hold(ndev); dev_put(odev); We should use dev_replace_track(odev, ndev, &dst->dev_tracker, GFP_KERNEL); If we do not transfer dst->dev_tracker to the new device, we will get warnings from ref_tracker_dir_exit() when odev is finally dismantled. Fixes: 9038c320 ("net: dst: add net device refcount tracking to dst_entry") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20211207055603.1926372-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- Dec 07, 2021
-
-
Tony Lu authored
Currently, buffers are cleared when smc connections are created and buffers are reused. This slows down the speed of establishing new connections. In most cases, the applications want to establish connections as quickly as possible. This patch moves memset() from connection creation path to release and buffer unuse path, this trades off between speed of establishing and release. Test environments: - CPU Intel Xeon Platinum 8 core, mem 32 GiB, nic Mellanox CX4 - socket sndbuf / rcvbuf: 16384 / 131072 bytes - w/o first round, 5 rounds, avg, 100 conns batch per round - smc_buf_create() use bpftrace kprobe, introduces extra latency Latency benchmarks for smc_buf_create(): w/o patch : 19040.0 ns w/ patch : 1932.6 ns ratio : 10.2% (-89.8%) Latency benchmarks for socket create and connect: w/o patch : 143.3 us w/ patch : 102.2 us ratio : 71.3% (-28.7%) The latency of establishing connections is reduced by 28.7%. Signed-off-by:
Tony Lu <tonylu@linux.alibaba.com> Reviewed-by:
Wen Gu <guwen@linux.alibaba.com> Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Link: https://lore.kernel.org/r/20211203113331.2818873-1-kgraul@linux.ibm.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Guangbin Huang authored
This reverts commit 5ac4f180 . Sorry for taking no notice that the function devlink_register() has been already declared as void, so it is needs to revert this patch. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Link: https://lore.kernel.org/r/20211204012448.51360-1-huangguangbin2@huawei.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
José Expósito authored
One-element and zero-length arrays are deprecated and should be replaced with flexible-array members: https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays Replace zero-length array with flexible-array member and make use of the struct_size() helper. Link: https://github.com/KSPP/linux/issues/78 Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Reviewed-by:
Volodymyr Mytnyk <vmytnyk@marvell.com> Tested-by:
Volodymyr Mytnyk <vmytnyk@marvell.com> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20211204171349.22776-1-jose.exposito89@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Arnd Bergmann authored
The iosm driver started using relayfs, but is missing the Kconfig logic to ensure it's built into the kernel: x86_64-linux-ld: drivers/net/wwan/iosm/iosm_ipc_trace.o: in function `ipc_trace_create_buf_file_handler': iosm_ipc_trace.c:(.text+0x16): undefined reference to `relay_file_operations' x86_64-linux-ld: drivers/net/wwan/iosm/iosm_ipc_trace.o: in function `ipc_trace_subbuf_start_handler': iosm_ipc_trace.c:(.text+0x31): undefined reference to `relay_buf_full' x86_64-linux-ld: drivers/net/wwan/iosm/iosm_ipc_trace.o: in function `ipc_trace_ctrl_file_write': iosm_ipc_trace.c:(.text+0xd5): undefined reference to `relay_flush' x86_64-linux-ld: drivers/net/wwan/iosm/iosm_ipc_trace.o: in function `ipc_trace_port_rx': Fixes: 00ef3256 ("net: wwan: iosm: device trace collection using relayfs") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by:
M Chetan Kumar <m.chetan.kumar@linux.intel.com> Link: https://lore.kernel.org/r/20211204174033.950528-1-arnd@kernel.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Vladimir reported csum issues after my recent change in skb_postpull_rcsum() Issue here is the following: initial skb->csum is the csum of [part to be pulled][rest of packet] Old code: skb->csum = csum_sub(skb->csum, csum_partial(pull, pull_length, 0)); New code: skb->csum = ~csum_partial(pull, pull_length, ~skb->csum); This is broken if the csum of [pulled part] happens to be equal to skb->csum, because end result of skb->csum is 0 in new code, instead of being 0xffffffff David Laight suggested to use skb->csum = -csum_partial(pull, pull_length, -skb->csum); I based my patches on existing code present in include/net/seg6.h, update_csum_diff4() and update_csum_diff16() which might need a similar fix. I guess that my tests, mostly pulling 40 bytes of IPv6 header were not providing enough entropy to hit this bug. v2: added wsum_negate() to make sparse happy. Fixes: 29c30026 ("net: optimize skb_postpull_rcsum()") Fixes: 0bd28476 ("gro: optimize skb_gro_postpull_rcsum()") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Suggested-by:
David Laight <David.Laight@ACULAB.COM> Cc: David Lebrun <dlebrun@google.com> Tested-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20211204045356.3659278-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: add preliminary netdev refcount tracking Two first patches add a generic infrastructure, that will be used to get tracking of refcount increments/decrements. The general idea is to be able to precisely pair each decrement with a corresponding prior increment. Both share a cookie, basically a pointer to private data storing stack traces. The third patch adds dev_hold_track() and dev_put_track() helpers (CONFIG_NET_DEV_REFCNT_TRACKER) Then a series of 20 patches converts some dev_hold()/dev_put() pairs to new hepers : dev_hold_track() and dev_put_track(). Hopefully this will be used by developpers and syzbot to root cause bugs that cause netdevice dismantles freezes. With CONFIG_PCPU_DEV_REFCNT=n option, we were able to detect some class of bugs, but too late (when too many dev_put() were happening). Another series will be sent after this one is merged. v3: moved NET_DEV_REFCNT_TRACKER to net/Kconfig.debug added "depends on DEBUG_KERNEL && STACKTRACE_SUPPORT" to hopefully get rid of kbuild reports for ARCH=nios2 Reworded patch 3 changelog. Added missing htmldocs (Jakub) v2: added four additional patches, added netdev_tracker_alloc() and netdev_tracker_free() addressed build error (kernel bots), use GFP_ATOMIC in test_ref_tracker_timer_func() ==================== Link: https://lore.kernel.org/r/20211205042217.982127-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Add a netdevice_tracker inside struct net_device, to track the self reference when a device is in lweventlist. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Note that other ip_tunnel users do not seem to hold a reference on tunnel->dev. Probably needs some investigations. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
We want to track all dev_hold()/dev_put() to ease leak hunting. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
We want to track all dev_hold()/dev_put() to ease leak hunting. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
This helper might hold a netdev reference for a long time, lets add reference tracking. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
This will help debugging pesky netdev reference leaks. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
This helps debugging net device refcount leaks. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
net device are refcounted. Over the years we had numerous bugs caused by imbalanced dev_hold() and dev_put() calls. The general idea is to be able to precisely pair each decrement with a corresponding prior increment. Both share a cookie, basically a pointer to private data storing stack traces. This patch adds dev_hold_track() and dev_put_track(). To use these helpers, each data structure owning a refcount should also use a "netdevice_tracker" to pair the hold and put. netdevice_tracker dev_tracker; ... dev_hold_track(dev, &dev_tracker, GFP_ATOMIC); ... dev_put_track(dev, &dev_tracker); Whenever a leak happens, we will get precise stack traces of the point dev_hold_track() happened, at device dismantle phase. We will also get a stack trace if too many dev_put_track() for the same netdevice_tracker are attempted. This is guarded by CONFIG_NET_DEV_REFCNT_TRACKER option. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
This module uses reference tracker, forcing two issues. 1) Double free of a tracker 2) leak of two trackers, one being allocated from softirq context. "modprobe test_ref_tracker" would emit the following traces. (Use scripts/decode_stacktrace.sh if necessary) [ 171.648681] reference already released. [ 171.653213] allocated in: [ 171.656523] alloctest_ref_tracker_alloc2+0x1c/0x20 [test_ref_tracker] [ 171.656526] init_module+0x86/0x1000 [test_ref_tracker] [ 171.656528] do_one_initcall+0x9c/0x220 [ 171.656532] do_init_module+0x60/0x240 [ 171.656536] load_module+0x32b5/0x3610 [ 171.656538] __do_sys_init_module+0x148/0x1a0 [ 171.656540] __x64_sys_init_module+0x1d/0x20 [ 171.656542] do_syscall_64+0x4a/0xb0 [ 171.656546] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 171.656549] freed in: [ 171.659520] alloctest_ref_tracker_free+0x13/0x20 [test_ref_tracker] [ 171.659522] init_module+0xec/0x1000 [test_ref_tracker] [ 171.659523] do_one_initcall+0x9c/0x220 [ 171.659525] do_init_module+0x60/0x240 [ 171.659527] load_module+0x32b5/0x3610 [ 171.659529] __do_sys_init_module+0x148/0x1a0 [ 171.659532] __x64_sys_init_module+0x1d/0x20 [ 171.659534] do_syscall_64+0x4a/0xb0 [ 171.659536] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 171.659575] ------------[ cut here ]------------ [ 171.659576] WARNING: CPU: 5 PID: 13016 at lib/ref_tracker.c:112 ref_tracker_free+0x224/0x270 [ 171.659581] Modules linked in: test_ref_tracker(+) [ 171.659591] CPU: 5 PID: 13016 Comm: modprobe Tainted: G S 5.16.0-smp-DEV #290 [ 171.659595] RIP: 0010:ref_tracker_free+0x224/0x270 [ 171.659599] Code: 5e 41 5f 5d c3 48 c7 c7 04 9c 74 a6 31 c0 e8 62 ee 67 00 83 7b 14 00 75 1a 83 7b 18 00 75 30 4c 89 ff 4c 89 f6 e8 9c 00 69 00 <0f> 0b bb ea ff ff ff eb ae 48 c7 c7 3a 0a 77 a6 31 c0 e8 34 ee 67 [ 171.659601] RSP: 0018:ffff89058ba0bbd0 EFLAGS: 00010286 [ 171.659603] RAX: 0000000000000029 RBX: ffff890586b19780 RCX: 08895bff57c7d100 [ 171.659604] RDX: c0000000ffff7fff RSI: 0000000000000282 RDI: ffffffffc0407000 [ 171.659606] RBP: ffff89058ba0bc88 R08: 0000000000000000 R09: ffffffffa6f342e0 [ 171.659607] R10: 00000000ffff7fff R11: 0000000000000000 R12: 000000008f000000 [ 171.659608] R13: 0000000000000014 R14: 0000000000000282 R15: ffffffffc0407000 [ 171.659609] FS: 00007f97ea29d740(0000) GS:ffff8923ff940000(0000) knlGS:0000000000000000 [ 171.659611] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 171.659613] CR2: 00007f97ea299000 CR3: 0000000186b4a004 CR4: 00000000001706e0 [ 171.659614] Call Trace: [ 171.659615] <TASK> [ 171.659631] ? alloctest_ref_tracker_free+0x13/0x20 [test_ref_tracker] [ 171.659633] ? init_module+0x105/0x1000 [test_ref_tracker] [ 171.659636] ? do_one_initcall+0x9c/0x220 [ 171.659638] ? do_init_module+0x60/0x240 [ 171.659641] ? load_module+0x32b5/0x3610 [ 171.659644] ? __do_sys_init_module+0x148/0x1a0 [ 171.659646] ? __x64_sys_init_module+0x1d/0x20 [ 171.659649] ? do_syscall_64+0x4a/0xb0 [ 171.659652] ? entry_SYSCALL_64_after_hwframe+0x44/0xae [ 171.659656] ? 0xffffffffc040a000 [ 171.659658] alloctest_ref_tracker_free+0x13/0x20 [test_ref_tracker] [ 171.659660] init_module+0x105/0x1000 [test_ref_tracker] [ 171.659663] do_one_initcall+0x9c/0x220 [ 171.659666] do_init_module+0x60/0x240 [ 171.659669] load_module+0x32b5/0x3610 [ 171.659672] __do_sys_init_module+0x148/0x1a0 [ 171.659676] __x64_sys_init_module+0x1d/0x20 [ 171.659678] do_syscall_64+0x4a/0xb0 [ 171.659694] ? exc_page_fault+0x6e/0x140 [ 171.659696] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 171.659698] RIP: 0033:0x7f97ea3dbe7a [ 171.659700] Code: 48 8b 0d 61 8d 06 00 f7 d8 64 89 01 48 83 c8 ff c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2e 8d 06 00 f7 d8 64 89 01 48 [ 171.659701] RSP: 002b:00007ffea67ce608 EFLAGS: 00000246 ORIG_RAX: 00000000000000af [ 171.659703] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f97ea3dbe7a [ 171.659704] RDX: 00000000013a0ba0 RSI: 0000000000002808 RDI: 00007f97ea299000 [ 171.659705] RBP: 00007ffea67ce670 R08: 0000000000000003 R09: 0000000000000000 [ 171.659706] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000013a1048 [ 171.659707] R13: 00000000013a0ba0 R14: 0000000001399930 R15: 00000000013a1030 [ 171.659709] </TASK> [ 171.659710] ---[ end trace f5dbd6afa41e60a9 ]--- [ 171.659712] leaked reference. [ 171.663393] alloctest_ref_tracker_alloc0+0x1c/0x20 [test_ref_tracker] [ 171.663395] test_ref_tracker_timer_func+0x9/0x20 [test_ref_tracker] [ 171.663397] call_timer_fn+0x31/0x140 [ 171.663401] expire_timers+0x46/0x110 [ 171.663403] __run_timers+0x16f/0x1b0 [ 171.663404] run_timer_softirq+0x1d/0x40 [ 171.663406] __do_softirq+0x148/0x2d3 [ 171.663408] leaked reference. [ 171.667101] alloctest_ref_tracker_alloc1+0x1c/0x20 [test_ref_tracker] [ 171.667103] init_module+0x81/0x1000 [test_ref_tracker] [ 171.667104] do_one_initcall+0x9c/0x220 [ 171.667106] do_init_module+0x60/0x240 [ 171.667108] load_module+0x32b5/0x3610 [ 171.667111] __do_sys_init_module+0x148/0x1a0 [ 171.667113] __x64_sys_init_module+0x1d/0x20 [ 171.667115] do_syscall_64+0x4a/0xb0 [ 171.667117] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 171.667131] ------------[ cut here ]------------ [ 171.667132] WARNING: CPU: 5 PID: 13016 at lib/ref_tracker.c:30 ref_tracker_dir_exit+0x104/0x130 [ 171.667136] Modules linked in: test_ref_tracker(+) [ 171.667144] CPU: 5 PID: 13016 Comm: modprobe Tainted: G S W 5.16.0-smp-DEV #290 [ 171.667147] RIP: 0010:ref_tracker_dir_exit+0x104/0x130 [ 171.667150] Code: 01 00 00 00 00 ad de 48 89 03 4c 89 63 08 48 89 df e8 20 a0 d5 ff 4c 89 f3 4d 39 ee 75 a8 4c 89 ff 48 8b 75 d0 e8 7c 05 69 00 <0f> 0b eb 0c 4c 89 ff 48 8b 75 d0 e8 6c 05 69 00 41 8b 47 08 83 f8 [ 171.667151] RSP: 0018:ffff89058ba0bc68 EFLAGS: 00010286 [ 171.667154] RAX: 08895bff57c7d100 RBX: ffffffffc0407010 RCX: 000000000000003b [ 171.667156] RDX: 000000000000003c RSI: 0000000000000282 RDI: ffffffffc0407000 [ 171.667157] RBP: ffff89058ba0bc98 R08: 0000000000000000 R09: ffffffffa6f342e0 [ 171.667159] R10: 00000000ffff7fff R11: 0000000000000000 R12: dead000000000122 [ 171.667160] R13: ffffffffc0407010 R14: ffffffffc0407010 R15: ffffffffc0407000 [ 171.667162] FS: 00007f97ea29d740(0000) GS:ffff8923ff940000(0000) knlGS:0000000000000000 [ 171.667164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 171.667166] CR2: 00007f97ea299000 CR3: 0000000186b4a004 CR4: 00000000001706e0 [ 171.667169] Call Trace: [ 171.667170] <TASK> [ 171.667171] ? 0xffffffffc040a000 [ 171.667173] init_module+0x126/0x1000 [test_ref_tracker] [ 171.667175] do_one_initcall+0x9c/0x220 [ 171.667179] do_init_module+0x60/0x240 [ 171.667182] load_module+0x32b5/0x3610 [ 171.667186] __do_sys_init_module+0x148/0x1a0 [ 171.667189] __x64_sys_init_module+0x1d/0x20 [ 171.667192] do_syscall_64+0x4a/0xb0 [ 171.667194] ? exc_page_fault+0x6e/0x140 [ 171.667196] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 171.667199] RIP: 0033:0x7f97ea3dbe7a [ 171.667200] Code: 48 8b 0d 61 8d 06 00 f7 d8 64 89 01 48 83 c8 ff c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2e 8d 06 00 f7 d8 64 89 01 48 [ 171.667201] RSP: 002b:00007ffea67ce608 EFLAGS: 00000246 ORIG_RAX: 00000000000000af [ 171.667203] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f97ea3dbe7a [ 171.667204] RDX: 00000000013a0ba0 RSI: 0000000000002808 RDI: 00007f97ea299000 [ 171.667205] RBP: 00007ffea67ce670 R08: 0000000000000003 R09: 0000000000000000 [ 171.667206] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000013a1048 [ 171.667207] R13: 00000000013a0ba0 R14: 0000000001399930 R15: 00000000013a1030 [ 171.667209] </TASK> [ 171.667210] ---[ end trace f5dbd6afa41e60aa ]--- Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
It can be hard to track where references are taken and released. In networking, we have annoying issues at device or netns dismantles, and we had various proposals to ease root causing them. This patch adds new infrastructure pairing refcount increases and decreases. This will self document code, because programmers will have to associate increments/decrements. This is controled by CONFIG_REF_TRACKER which can be selected by users of this feature. This adds both cpu and memory costs, and thus should probably be used with care. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- Dec 04, 2021
-
-
Jakub Kicinski authored
Manish Chopra says: ==================== qed*: enhancements This series adds below enhancements for qed/qede drivers patch 1: Improves tx timeout debug data logs. patch 2: Add ESL(Enhanced system lockdown) priv flag cap/status support. v2: * Fixed cosmetic issues in both patches * Added ESL feature description in patch #2 Please consider applying it to "net-next" ==================== Link: https://lore.kernel.org/r/20211202210157.25530-1-manishc@marvell.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Manish Chopra authored
ESL(Enhanced System Lockdown) was designed to lock PCI adapter firmware images and prevent changes to critical non-volatile configuration data so that uncontrolled, malicious or unintentional modification to the adapters are avoided, ensuring it's operational state. Once this feature is enabled, the device is locked, rejecting any modification to non-volatile images. Once unlocked, the protection is off such that firmware and non-volatile configurations may be altered. Driver just reflects the capability and status of this through the ethtool private flag. Signed-off-by:
Manish Chopra <manishc@marvell.com> Signed-off-by:
Prabhakar Kushwaha <pkushwaha@marvell.com> Signed-off-by:
Alok Prasad <palok@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Manish Chopra authored
This patch add some new qed APIs to query status block info and report various data to MFW on tx timeout event Along with that it enhances qede to dump more debug logs (not just specific to the queue which was reported by stack) on tx timeout which includes various other basic metadata about all tx queues and other info (like status block etc.) Signed-off-by:
Manish Chopra <manishc@marvell.com> Signed-off-by:
Prabhakar Kushwaha <pkushwaha@marvell.com> Signed-off-by:
Alok Prasad <palok@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- Dec 03, 2021
-
-
Dan Carpenter authored
The devm_ioremap() function does not return error pointers. It returns NULL. Fixes: db8bcaad ("net: lan966x: add the basic lan966x driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-