* Re: [PATCH 0/7] Netfilter fixes for net
From: David Miller @ 2019-08-15 21:02 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190814092440.20087-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 14 Aug 2019 11:24:33 +0200
> This patchset contains Netfilter fixes for net:
>
> 1) Extend selftest to cover flowtable with ipsec, from Florian Westphal.
>
> 2) Fix interaction of ipsec with flowtable, also from Florian.
>
> 3) User-after-free with bound set to rule that fails to load.
>
> 4) Adjust state and timeout for flows that expire.
>
> 5) Timeout update race with flows in teardown state.
>
> 6) Ensure conntrack id hash calculation use invariants as input,
> from Dirk Morris.
>
> 7) Do not push flows into flowtable for TCP fin/rst packets.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thanks.
^ permalink raw reply
* [PATCH] ath10k: add cleanup in ath10k_sta_state()
From: Wenwen Wang @ 2019-08-15 21:04 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kalle Valo, David S. Miller,
open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER,
open list:NETWORKING DRIVERS (WIRELESS),
open list:NETWORKING DRIVERS, open list
If 'sta->tdls' is false, no cleanup is executed, leading to memory/resource
leaks, e.g., 'arsta->tx_stats'. To fix this issue, perform cleanup before
go to the 'exit' label.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/wireless/ath/ath10k/mac.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0606416..f99e6d2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6548,8 +6548,12 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
spin_unlock_bh(&ar->data_lock);
- if (!sta->tdls)
+ if (!sta->tdls) {
+ ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
+ ath10k_mac_dec_num_stations(arvif, sta);
+ kfree(arsta->tx_stats);
goto exit;
+ }
ret = ath10k_wmi_update_fw_tdls_state(ar, arvif->vdev_id,
WMI_TDLS_ENABLE_ACTIVE);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 1/3] net/tls: use RCU protection on icsk->icsk_ulp_data
From: Jakub Kicinski @ 2019-08-15 21:32 UTC (permalink / raw)
To: Davide Caratti
Cc: Boris Pismenny, John Fastabend, Dave Watson, Aviad Yehezkel,
David S. Miller, netdev
In-Reply-To: <b7c351a5ad6c756129d036fd87db6b4edcd3cb6a.1565882584.git.dcaratti@redhat.com>
On Thu, 15 Aug 2019 18:00:42 +0200, Davide Caratti wrote:
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> We need to make sure context does not get freed while diag
> code is interrogating it. Free struct tls_context with
> kfree_rcu().
>
> We add the __rcu annotation directly in icsk, and cast it
> away in the datapath accessor. Presumably all ULPs will
> do a similar thing.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> include/net/inet_connection_sock.h | 2 +-
> include/net/tls.h | 9 +++++++--
> net/core/sock_map.c | 2 +-
> net/tls/tls_device.c | 2 +-
> net/tls/tls_main.c | 31 +++++++++++++++++++++++-------
> 5 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
> index c57d53e7e02c..895546058a20 100644
> --- a/include/net/inet_connection_sock.h
> +++ b/include/net/inet_connection_sock.h
> @@ -97,7 +97,7 @@ struct inet_connection_sock {
> const struct tcp_congestion_ops *icsk_ca_ops;
> const struct inet_connection_sock_af_ops *icsk_af_ops;
> const struct tcp_ulp_ops *icsk_ulp_ops;
> - void *icsk_ulp_data;
> + void __rcu *icsk_ulp_data;
> void (*icsk_clean_acked)(struct sock *sk, u32 acked_seq);
> struct hlist_node icsk_listen_portaddr_node;
> unsigned int (*icsk_sync_mss)(struct sock *sk, u32 pmtu);
> diff --git a/include/net/tls.h b/include/net/tls.h
> index 41b2d41bb1b8..4997742475cd 100644
> --- a/include/net/tls.h
> +++ b/include/net/tls.h
> @@ -41,6 +41,7 @@
> #include <linux/tcp.h>
> #include <linux/skmsg.h>
> #include <linux/netdevice.h>
> +#include <linux/rcupdate.h>
>
> #include <net/tcp.h>
> #include <net/strparser.h>
> @@ -290,6 +291,7 @@ struct tls_context {
>
> struct list_head list;
> refcount_t refcount;
> + struct rcu_head rcu;
> };
>
> enum tls_offload_ctx_dir {
> @@ -348,7 +350,7 @@ struct tls_offload_context_rx {
> #define TLS_OFFLOAD_CONTEXT_SIZE_RX \
> (sizeof(struct tls_offload_context_rx) + TLS_DRIVER_STATE_SIZE_RX)
>
> -void tls_ctx_free(struct tls_context *ctx);
> +void tls_ctx_free(struct sock *sk, struct tls_context *ctx);
> int wait_on_pending_writer(struct sock *sk, long *timeo);
> int tls_sk_query(struct sock *sk, int optname, char __user *optval,
> int __user *optlen);
> @@ -467,7 +469,10 @@ static inline struct tls_context *tls_get_ctx(const struct sock *sk)
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
>
> - return icsk->icsk_ulp_data;
> + /* Use RCU on icsk_ulp_data only for sock diag code,
> + * TLS data path doesn't need rcu_dereference().
> + */
> + return (__force void *)icsk->icsk_ulp_data;
> }
>
> static inline void tls_advance_record_sn(struct sock *sk,
> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> index 1330a7442e5b..01998860afaa 100644
> --- a/net/core/sock_map.c
> +++ b/net/core/sock_map.c
> @@ -345,7 +345,7 @@ static int sock_map_update_common(struct bpf_map *map, u32 idx,
> return -EINVAL;
> if (unlikely(idx >= map->max_entries))
> return -E2BIG;
> - if (unlikely(icsk->icsk_ulp_data))
> + if (unlikely(rcu_access_pointer(icsk->icsk_ulp_data)))
> return -EINVAL;
>
> link = sk_psock_init_link();
> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> index d184230665eb..436df5b4bb60 100644
> --- a/net/tls/tls_device.c
> +++ b/net/tls/tls_device.c
> @@ -61,7 +61,7 @@ static void tls_device_free_ctx(struct tls_context *ctx)
> if (ctx->rx_conf == TLS_HW)
> kfree(tls_offload_ctx_rx(ctx));
>
> - tls_ctx_free(ctx);
> + tls_ctx_free(NULL, ctx);
> }
>
> static void tls_device_gc_task(struct work_struct *work)
> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> index 9cbbae606ced..04829bef514c 100644
> --- a/net/tls/tls_main.c
> +++ b/net/tls/tls_main.c
> @@ -251,14 +251,31 @@ static void tls_write_space(struct sock *sk)
> ctx->sk_write_space(sk);
> }
>
> -void tls_ctx_free(struct tls_context *ctx)
> +/**
> + * tls_ctx_free() - free TLS ULP context
> + * @sk: socket to with @ctx is attached
> + * @ctx: TLS context structure
> + *
> + * Free TLS context. If @sk is %NULL caller guarantees that the socket
> + * to which @ctx was attached has no outstanding references.
> + */
> +void tls_ctx_free(struct sock *sk, struct tls_context *ctx)
> {
> + struct inet_connection_sock *icsk;
> +
> if (!ctx)
> return;
>
> memzero_explicit(&ctx->crypto_send, sizeof(ctx->crypto_send));
> memzero_explicit(&ctx->crypto_recv, sizeof(ctx->crypto_recv));
> - kfree(ctx);
> +
> + if (sk) {
> + icsk = inet_csk(sk);
> + rcu_assign_pointer(icsk->icsk_ulp_data, NULL);
Now that we kind of want to set the icsk_ulp_data to NULL under the
callback_lock I think we should let the callers do it.
> + kfree_rcu(ctx, rcu);
> + } else {
> + kfree(ctx);
> + }
> }
>
> static void tls_sk_proto_cleanup(struct sock *sk,
> @@ -306,7 +323,7 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
>
> write_lock_bh(&sk->sk_callback_lock);
> if (free_ctx)
> - icsk->icsk_ulp_data = NULL;
> + rcu_assign_pointer(icsk->icsk_ulp_data, NULL);
> sk->sk_prot = ctx->sk_proto;
> write_unlock_bh(&sk->sk_callback_lock);
> release_sock(sk);
> @@ -319,7 +336,7 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
> ctx->sk_proto_close(sk, timeout);
>
> if (free_ctx)
> - tls_ctx_free(ctx);
> + tls_ctx_free(sk, ctx);
> }
>
> static int do_tls_getsockopt_tx(struct sock *sk, char __user *optval,
> @@ -608,7 +625,7 @@ static struct tls_context *create_ctx(struct sock *sk)
> if (!ctx)
> return NULL;
>
> - icsk->icsk_ulp_data = ctx;
> + rcu_assign_pointer(icsk->icsk_ulp_data, ctx);
> ctx->setsockopt = sk->sk_prot->setsockopt;
> ctx->getsockopt = sk->sk_prot->getsockopt;
> ctx->sk_proto_close = sk->sk_prot->close;
> @@ -649,8 +666,8 @@ static void tls_hw_sk_destruct(struct sock *sk)
>
> ctx->sk_destruct(sk);
> /* Free ctx */
> - tls_ctx_free(ctx);
> - icsk->icsk_ulp_data = NULL;
> + tls_ctx_free(sk, ctx);
> + rcu_assign_pointer(icsk->icsk_ulp_data, NULL);
Let's reorder the assignment before the free.
> }
>
> static int tls_hw_prot(struct sock *sk)
^ permalink raw reply
* Re: [PATCH net-next 2/3] tcp: ulp: add functions to dump ulp-specific information
From: Jakub Kicinski @ 2019-08-15 21:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Davide Caratti, Boris Pismenny, John Fastabend, Dave Watson,
Aviad Yehezkel, David S. Miller, netdev
In-Reply-To: <228db5cc-9b10-521f-9031-e0f86f5ded3e@gmail.com>
On Thu, 15 Aug 2019 20:46:01 +0200, Eric Dumazet wrote:
> On 8/15/19 6:00 PM, Davide Caratti wrote:
>
> >
> > + if (net_admin) {
> > + const struct tcp_ulp_ops *ulp_ops;
> > +
> > + rcu_read_lock();
> > + ulp_ops = icsk->icsk_ulp_ops;
> > + if (ulp_ops)
> > + err = tcp_diag_put_ulp(skb, sk, ulp_ops);
> > + rcu_read_unlock();
> > + if (err)
> > + return err;
> > + }
> > return 0;
>
>
> Why is rcu_read_lock() and rcu_read_unlock() used at all ?
>
> icsk->icsk_ulp_ops does not seem to be rcu protected ?
>
> If this was, then an rcu_dereference() would be appropriate.
Indeed it's ulp_data not ulp_ops that are protected. Davide,
perhaps we could push the RCU lock into tls_get_info(), after all?
And tls_context has to use rcu_deference there, as Eric points out,
plus we should probably NULL-check it.
^ permalink raw reply
* linux-next: Fixes tags need some work in the net-next tree
From: Stephen Rothwell @ 2019-08-15 21:51 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Srinivas Neeli, Marc Kleine-Budde, Appana Durga Kedareswara rao,
Michal Simek, Venkatesh Yadav Abbarapu
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
Hi all,
In commit
3e994ff28f86 ("can: xilinx_can: xcan_set_bittiming(): fix the data phase btr1 calculation")
Fixes tag
Fixes: c223da6 ("can: xilinx_can: Add support for CANFD FD frames")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
In commit
9d06bcb9aa48 ("can: xilinx_can: xcan_rx_fifo_get_next_frame(): fix FSR register FL and RI mask values for canfd 2.0")
Fixes tag
Fixes: c223da6 ("can: xilinx_can: Add support for CANFD FD frames")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
In commit
e6997dd26884 ("can: xilinx_can: fix the data update logic for CANFD FD frames")
Fixes tag
Fixes: c223da6 ("can: xilinx_can: Add support for CANFD FD frames")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
In commit
93bbd6c5eeb1 ("can: xilinx_can: xcanfd_rx(): fix FSR register handling in the RX path")
Fixes tag
Fixes: c223da6 ("can: xilinx_can: Add support for CANFD FD frames")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
In commit
6b0d35891c83 ("can: xilinx_can: xcan_probe(): skip error message on deferred probe")
Fixes tag
Fixes: b1201e44 ("can: xilinx CAN controller support")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: memory leak in nr_loopback_queue
From: syzbot @ 2019-08-15 21:53 UTC (permalink / raw)
To: davem, linux-hams, linux-kernel, netdev, ralf, syzkaller-bugs
In-Reply-To: <000000000000a7f012058a0c7a65@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 41de5963 Merge tag 'Wimplicit-fallthrough-5.3-rc5' of git:..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12408f1c600000
kernel config: https://syzkaller.appspot.com/x/.config?x=6c5e70dcab57c6af
dashboard link: https://syzkaller.appspot.com/bug?extid=470d1a4a7b7a7c225881
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=164de5ee600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1114f222600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+470d1a4a7b7a7c225881@syzkaller.appspotmail.com
executing program
executing program
executing program
executing program
executing program
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 50.960s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 50.960s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.030s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.030s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.100s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.100s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.160s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.160s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.240s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.240s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.300s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.300s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.370s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.370s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.430s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.430s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
^ permalink raw reply
* linux-next: Signed-off-by missing for commits in the net-next tree
From: Stephen Rothwell @ 2019-08-15 21:53 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Andy Grover,
Gerd Rausch, Chris Mason
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
Hi all,
Commits
11740ef44829 ("rds: check for excessive looping in rds_send_xmit")
65dedd7fe1f2 ("RDS: limit the number of times we loop in rds_send_xmit")
are missing a Signed-off-by from their authors.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commits in the net-next tree
From: Gerd Rausch @ 2019-08-15 22:06 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking, Chris Mason, andy
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Andy Grover,
Chris Mason
In-Reply-To: <20190816075312.64959223@canb.auug.org.au>
Hi,
Just added the e-mail addresses I found using a simple "google search",
in order to reach out to the original authors of these commits:
Chris Mason and Andy Grover.
I'm hoping they still remember their work from 7-8 years ago.
Thanks,
Gerd
On 15/08/2019 14.53, Stephen Rothwell wrote:
> Hi all,
>
> Commits
>
> 11740ef44829 ("rds: check for excessive looping in rds_send_xmit")
> 65dedd7fe1f2 ("RDS: limit the number of times we loop in rds_send_xmit")
>
> are missing a Signed-off-by from their authors.
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Alexei Starovoitov @ 2019-08-15 23:08 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jordan Glover, Daniel Colascione, Song Liu, Kees Cook, Networking,
bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team,
Lorenz Bauer, Jann Horn, Greg KH, Linux API, LSM List
In-Reply-To: <CALCETrUv+g+cb79FJ1S4XuV0K=kowFkPXpzoC99svoOfs4-Kvg@mail.gmail.com>
On Thu, Aug 15, 2019 at 11:36:43AM -0700, Andy Lutomirski wrote:
> On Thu, Aug 15, 2019 at 10:29 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Aug 15, 2019 at 11:24:54AM +0000, Jordan Glover wrote:
> > > systemd --user processes aren't "less privileged". The are COMPLETELY unprivileged.
> > > Granting them cap_bpf is the same as granting it to every other unprivileged user
> > > process. Also unprivileged user process can start systemd --user process with any
> > > command they like.
> >
> > systemd itself is trusted. It's the same binary whether it runs as pid=1
> > or as pid=123. One of the use cases is to make IPAddressDeny= work with --user.
> > Subset of that feature already works with AmbientCapabilities=CAP_NET_ADMIN.
> > CAP_BPF is a natural step in the same direction.
> >
>
> I have the feeling that we're somehow speaking different languages.
> What, precisely, do you mean when you say "systemd itself is trusted"?
> Do you mean "the administrator trusts that the /lib/systemd/systemd
> binary is not malicious"? Do you mean "the administrator trusts that
> the running systemd process is not malicious"?
please see
https://github.com/systemd/systemd/commit/4c1567f29aeb60a6741874bca8a8e3a0bd69ed01
I'm not advocating for or against this approach.
Call it 'security hole' or 'better security'.
There are two categories of people for any feature like this.
My point that there is a demand to use bpf for non-root and CAP_NET_ADMIN
level of privileges is acceptable.
Another option is to relax all of bpf to CAP_NET_ADMIN instead of CAP_SYS_ADMIN.
But CAP_BPF is clearly better way.
> My suggestions upthread for incrementally making bpf() depend less on
> privilege would accomplish this goal.
As I pointed out countless times it would make the system overall _less_ secure.
One of the goals here is to do sysctl kernel.unprivileged_bpf_disabled=1 to
make it _more_ secure.
^ permalink raw reply
* Re: [PATCH net-next v6 6/6] net: mscc: PTP Hardware Clock (PHC) support
From: Richard Cochran @ 2019-08-15 23:08 UTC (permalink / raw)
To: David Miller
Cc: antoine.tenart, alexandre.belloni, UNGLinuxDriver, netdev,
thomas.petazzoni, allan.nielsen, andrew
In-Reply-To: <20190814.124939.490620650140226969.davem@davemloft.net>
On Wed, Aug 14, 2019 at 12:49:39PM -0400, David Miller wrote:
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Date: Mon, 12 Aug 2019 16:45:37 +0200
>
> > This patch adds support for PTP Hardware Clock (PHC) to the Ocelot
> > switch for both PTP 1-step and 2-step modes.
> >
> > Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
>
> Richard, I really need your review on this patch.
I had acked the v3, but it seems that Antoine overlooked that. In any
case, this looks good to go.
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v7 3/3] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Tao Ren @ 2019-08-15 23:13 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S . Miller,
Vladimir Oltean, Arun Parameswaran, Justin Chen,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20190811234016.3674056-1-taoren@fb.com>
Hi Andrew / Florian / Heiner / Vladimir,
Any further suggestions on the patch series?
Thanks,
Tao
On 8/11/19 4:40 PM, Tao Ren wrote:
> The BCM54616S PHY cannot work properly in RGMII->1000Base-X mode, mainly
> because genphy functions are designed for copper links, and 1000Base-X
> (clause 37) auto negotiation needs to be handled differently.
>
> This patch enables 1000Base-X support for BCM54616S by customizing 3
> driver callbacks, and it's verified to be working on Facebook CMM BMC
> platform (RGMII->1000Base-KX):
>
> - probe: probe callback detects PHY's operation mode based on
> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
> Control register.
>
> - config_aneg: calls genphy_c37_config_aneg when the PHY is running in
> 1000Base-X mode; otherwise, genphy_config_aneg will be called.
>
> - read_status: calls genphy_c37_read_status when the PHY is running in
> 1000Base-X mode; otherwise, genphy_read_status will be called.
>
> Note: BCM54616S PHY can also be configured in RGMII->100Base-FX mode, and
> 100Base-FX support is not available as of now.
>
> Signed-off-by: Tao Ren <taoren@fb.com>
> ---
> Changes in v7:
> - Add comment "BCM54616S 100Base-FX is not supported".
> Changes in v6:
> - nothing changed.
> Changes in v5:
> - include Heiner's patch "net: phy: add support for clause 37
> auto-negotiation" into the series.
> - use genphy_c37_config_aneg and genphy_c37_read_status in BCM54616S
> PHY driver's callback when the PHY is running in 1000Base-X mode.
> Changes in v4:
> - add bcm54616s_config_aneg_1000bx() to deal with auto negotiation in
> 1000Base-X mode.
> Changes in v3:
> - rename bcm5482_read_status to bcm54xx_read_status so the callback can
> be shared by BCM5482 and BCM54616S.
> Changes in v2:
> - Auto-detect PHY operation mode instead of passing DT node.
> - move PHY mode auto-detect logic from config_init to probe callback.
> - only set speed (not including duplex) in read_status callback.
> - update patch description with more background to avoid confusion.
> - patch #1 in the series ("net: phy: broadcom: set features explicitly
> for BCM54616") is dropped.
>
> drivers/net/phy/broadcom.c | 57 +++++++++++++++++++++++++++++++++++---
> include/linux/brcmphy.h | 10 +++++--
> 2 files changed, 61 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 937d0059e8ac..5fd9293513d8 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
> /*
> * Select 1000BASE-X register set (primary SerDes)
> */
> - reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
> - bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
> - reg | BCM5482_SHD_MODE_1000BX);
> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
> + reg | BCM54XX_SHD_MODE_1000BX);
>
> /*
> * LED1=ACTIVITYLED, LED3=LINKSPD[2]
> @@ -451,12 +451,47 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
> return ret;
> }
>
> +static int bcm54616s_probe(struct phy_device *phydev)
> +{
> + int val, intf_sel;
> +
> + val = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + if (val < 0)
> + return val;
> +
> + /* The PHY is strapped in RGMII-fiber mode when INTERF_SEL[1:0]
> + * is 01b, and the link between PHY and its link partner can be
> + * either 1000Base-X or 100Base-FX.
> + * RGMII-1000Base-X is properly supported, but RGMII-100Base-FX
> + * support is still missing as of now.
> + */
> + intf_sel = (val & BCM54XX_SHD_INTF_SEL_MASK) >> 1;
> + if (intf_sel == 1) {
> + val = bcm_phy_read_shadow(phydev, BCM54616S_SHD_100FX_CTRL);
> + if (val < 0)
> + return val;
> +
> + /* Bit 0 of the SerDes 100-FX Control register, when set
> + * to 1, sets the MII/RGMII -> 100BASE-FX configuration.
> + * When this bit is set to 0, it sets the GMII/RGMII ->
> + * 1000BASE-X configuration.
> + */
> + if (!(val & BCM54616S_100FX_MODE))
> + phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
> + }
> +
> + return 0;
> +}
> +
> static int bcm54616s_config_aneg(struct phy_device *phydev)
> {
> int ret;
>
> /* Aneg firsly. */
> - ret = genphy_config_aneg(phydev);
> + if (phydev->dev_flags & PHY_BCM_FLAGS_MODE_1000BX)
> + ret = genphy_c37_config_aneg(phydev);
> + else
> + ret = genphy_config_aneg(phydev);
>
> /* Then we can set up the delay. */
> bcm54xx_config_clock_delay(phydev);
> @@ -464,6 +499,18 @@ static int bcm54616s_config_aneg(struct phy_device *phydev)
> return ret;
> }
>
> +static int bcm54616s_read_status(struct phy_device *phydev)
> +{
> + int err;
> +
> + if (phydev->dev_flags & PHY_BCM_FLAGS_MODE_1000BX)
> + err = genphy_c37_read_status(phydev);
> + else
> + err = genphy_read_status(phydev);
> +
> + return err;
> +}
> +
> static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
> {
> int val;
> @@ -655,6 +702,8 @@ static struct phy_driver broadcom_drivers[] = {
> .config_aneg = bcm54616s_config_aneg,
> .ack_interrupt = bcm_phy_ack_intr,
> .config_intr = bcm_phy_config_intr,
> + .read_status = bcm54616s_read_status,
> + .probe = bcm54616s_probe,
> }, {
> .phy_id = PHY_ID_BCM5464,
> .phy_id_mask = 0xfffffff0,
> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
> index 6db2d9a6e503..b475e7f20d28 100644
> --- a/include/linux/brcmphy.h
> +++ b/include/linux/brcmphy.h
> @@ -200,9 +200,15 @@
> #define BCM5482_SHD_SSD 0x14 /* 10100: Secondary SerDes control */
> #define BCM5482_SHD_SSD_LEDM 0x0008 /* SSD LED Mode enable */
> #define BCM5482_SHD_SSD_EN 0x0001 /* SSD enable */
> -#define BCM5482_SHD_MODE 0x1f /* 11111: Mode Control Register */
> -#define BCM5482_SHD_MODE_1000BX 0x0001 /* Enable 1000BASE-X registers */
>
> +/* 10011: SerDes 100-FX Control Register */
> +#define BCM54616S_SHD_100FX_CTRL 0x13
> +#define BCM54616S_100FX_MODE BIT(0) /* 100-FX SerDes Enable */
> +
> +/* 11111: Mode Control Register */
> +#define BCM54XX_SHD_MODE 0x1f
> +#define BCM54XX_SHD_INTF_SEL_MASK GENMASK(2, 1) /* INTERF_SEL[1:0] */
> +#define BCM54XX_SHD_MODE_1000BX BIT(0) /* Enable 1000-X registers */
>
> /*
> * EXPANSION SHADOW ACCESS REGISTERS. (PHY REG 0x15, 0x16, and 0x17)
>
^ permalink raw reply
* Re: [PATCH net-next v7 3/3] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Vladimir Oltean @ 2019-08-15 23:15 UTC (permalink / raw)
To: Tao Ren
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S . Miller,
Arun Parameswaran, Justin Chen, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org
In-Reply-To: <fee3faa1-2de1-b480-983e-07f4587f2f79@fb.com>
Hi Tao,
On Fri, 16 Aug 2019 at 02:13, Tao Ren <taoren@fb.com> wrote:
>
> Hi Andrew / Florian / Heiner / Vladimir,
>
> Any further suggestions on the patch series?
>
>
> Thanks,
>
> Tao
>
> On 8/11/19 4:40 PM, Tao Ren wrote:
> > The BCM54616S PHY cannot work properly in RGMII->1000Base-X mode, mainly
> > because genphy functions are designed for copper links, and 1000Base-X
> > (clause 37) auto negotiation needs to be handled differently.
> >
> > This patch enables 1000Base-X support for BCM54616S by customizing 3
> > driver callbacks, and it's verified to be working on Facebook CMM BMC
> > platform (RGMII->1000Base-KX):
> >
> > - probe: probe callback detects PHY's operation mode based on
> > INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
> > Control register.
> >
> > - config_aneg: calls genphy_c37_config_aneg when the PHY is running in
> > 1000Base-X mode; otherwise, genphy_config_aneg will be called.
> >
> > - read_status: calls genphy_c37_read_status when the PHY is running in
> > 1000Base-X mode; otherwise, genphy_read_status will be called.
> >
> > Note: BCM54616S PHY can also be configured in RGMII->100Base-FX mode, and
> > 100Base-FX support is not available as of now.
> >
> > Signed-off-by: Tao Ren <taoren@fb.com>
> > ---
The patchset looks good to me. However I am not a maintainer.
If it helps,
Acked-by: Vladimir Oltean <olteanv@gmail.com>
> > Changes in v7:
> > - Add comment "BCM54616S 100Base-FX is not supported".
> > Changes in v6:
> > - nothing changed.
> > Changes in v5:
> > - include Heiner's patch "net: phy: add support for clause 37
> > auto-negotiation" into the series.
> > - use genphy_c37_config_aneg and genphy_c37_read_status in BCM54616S
> > PHY driver's callback when the PHY is running in 1000Base-X mode.
> > Changes in v4:
> > - add bcm54616s_config_aneg_1000bx() to deal with auto negotiation in
> > 1000Base-X mode.
> > Changes in v3:
> > - rename bcm5482_read_status to bcm54xx_read_status so the callback can
> > be shared by BCM5482 and BCM54616S.
> > Changes in v2:
> > - Auto-detect PHY operation mode instead of passing DT node.
> > - move PHY mode auto-detect logic from config_init to probe callback.
> > - only set speed (not including duplex) in read_status callback.
> > - update patch description with more background to avoid confusion.
> > - patch #1 in the series ("net: phy: broadcom: set features explicitly
> > for BCM54616") is dropped.
> >
> > drivers/net/phy/broadcom.c | 57 +++++++++++++++++++++++++++++++++++---
> > include/linux/brcmphy.h | 10 +++++--
> > 2 files changed, 61 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> > index 937d0059e8ac..5fd9293513d8 100644
> > --- a/drivers/net/phy/broadcom.c
> > +++ b/drivers/net/phy/broadcom.c
> > @@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
> > /*
> > * Select 1000BASE-X register set (primary SerDes)
> > */
> > - reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
> > - bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
> > - reg | BCM5482_SHD_MODE_1000BX);
> > + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> > + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
> > + reg | BCM54XX_SHD_MODE_1000BX);
> >
> > /*
> > * LED1=ACTIVITYLED, LED3=LINKSPD[2]
> > @@ -451,12 +451,47 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
> > return ret;
> > }
> >
> > +static int bcm54616s_probe(struct phy_device *phydev)
> > +{
> > + int val, intf_sel;
> > +
> > + val = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> > + if (val < 0)
> > + return val;
> > +
> > + /* The PHY is strapped in RGMII-fiber mode when INTERF_SEL[1:0]
> > + * is 01b, and the link between PHY and its link partner can be
> > + * either 1000Base-X or 100Base-FX.
> > + * RGMII-1000Base-X is properly supported, but RGMII-100Base-FX
> > + * support is still missing as of now.
> > + */
> > + intf_sel = (val & BCM54XX_SHD_INTF_SEL_MASK) >> 1;
> > + if (intf_sel == 1) {
> > + val = bcm_phy_read_shadow(phydev, BCM54616S_SHD_100FX_CTRL);
> > + if (val < 0)
> > + return val;
> > +
> > + /* Bit 0 of the SerDes 100-FX Control register, when set
> > + * to 1, sets the MII/RGMII -> 100BASE-FX configuration.
> > + * When this bit is set to 0, it sets the GMII/RGMII ->
> > + * 1000BASE-X configuration.
> > + */
> > + if (!(val & BCM54616S_100FX_MODE))
> > + phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int bcm54616s_config_aneg(struct phy_device *phydev)
> > {
> > int ret;
> >
> > /* Aneg firsly. */
> > - ret = genphy_config_aneg(phydev);
> > + if (phydev->dev_flags & PHY_BCM_FLAGS_MODE_1000BX)
> > + ret = genphy_c37_config_aneg(phydev);
> > + else
> > + ret = genphy_config_aneg(phydev);
> >
> > /* Then we can set up the delay. */
> > bcm54xx_config_clock_delay(phydev);
> > @@ -464,6 +499,18 @@ static int bcm54616s_config_aneg(struct phy_device *phydev)
> > return ret;
> > }
> >
> > +static int bcm54616s_read_status(struct phy_device *phydev)
> > +{
> > + int err;
> > +
> > + if (phydev->dev_flags & PHY_BCM_FLAGS_MODE_1000BX)
> > + err = genphy_c37_read_status(phydev);
> > + else
> > + err = genphy_read_status(phydev);
> > +
> > + return err;
> > +}
> > +
> > static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
> > {
> > int val;
> > @@ -655,6 +702,8 @@ static struct phy_driver broadcom_drivers[] = {
> > .config_aneg = bcm54616s_config_aneg,
> > .ack_interrupt = bcm_phy_ack_intr,
> > .config_intr = bcm_phy_config_intr,
> > + .read_status = bcm54616s_read_status,
> > + .probe = bcm54616s_probe,
> > }, {
> > .phy_id = PHY_ID_BCM5464,
> > .phy_id_mask = 0xfffffff0,
> > diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
> > index 6db2d9a6e503..b475e7f20d28 100644
> > --- a/include/linux/brcmphy.h
> > +++ b/include/linux/brcmphy.h
> > @@ -200,9 +200,15 @@
> > #define BCM5482_SHD_SSD 0x14 /* 10100: Secondary SerDes control */
> > #define BCM5482_SHD_SSD_LEDM 0x0008 /* SSD LED Mode enable */
> > #define BCM5482_SHD_SSD_EN 0x0001 /* SSD enable */
> > -#define BCM5482_SHD_MODE 0x1f /* 11111: Mode Control Register */
> > -#define BCM5482_SHD_MODE_1000BX 0x0001 /* Enable 1000BASE-X registers */
> >
> > +/* 10011: SerDes 100-FX Control Register */
> > +#define BCM54616S_SHD_100FX_CTRL 0x13
> > +#define BCM54616S_100FX_MODE BIT(0) /* 100-FX SerDes Enable */
> > +
> > +/* 11111: Mode Control Register */
> > +#define BCM54XX_SHD_MODE 0x1f
> > +#define BCM54XX_SHD_INTF_SEL_MASK GENMASK(2, 1) /* INTERF_SEL[1:0] */
> > +#define BCM54XX_SHD_MODE_1000BX BIT(0) /* Enable 1000-X registers */
> >
> > /*
> > * EXPANSION SHADOW ACCESS REGISTERS. (PHY REG 0x15, 0x16, and 0x17)
> >
Regards,
-Vladimir
^ permalink raw reply
* Re: [PATCH net-next v7 3/3] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Tao Ren @ 2019-08-15 23:19 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S . Miller,
Arun Parameswaran, Justin Chen, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org
In-Reply-To: <CA+h21hr-uiCAQTXerg8ScKhnVhT15pM70m_Jw_f=gZrt1DCRkw@mail.gmail.com>
On 8/15/19 4:15 PM, Vladimir Oltean wrote:
> Hi Tao,
>
> On Fri, 16 Aug 2019 at 02:13, Tao Ren <taoren@fb.com> wrote:
>>
>> Hi Andrew / Florian / Heiner / Vladimir,
>>
>> Any further suggestions on the patch series?
>>
>>
>> Thanks,
>>
>> Tao
>>
>> On 8/11/19 4:40 PM, Tao Ren wrote:
>>> The BCM54616S PHY cannot work properly in RGMII->1000Base-X mode, mainly
>>> because genphy functions are designed for copper links, and 1000Base-X
>>> (clause 37) auto negotiation needs to be handled differently.
>>>
>>> This patch enables 1000Base-X support for BCM54616S by customizing 3
>>> driver callbacks, and it's verified to be working on Facebook CMM BMC
>>> platform (RGMII->1000Base-KX):
>>>
>>> - probe: probe callback detects PHY's operation mode based on
>>> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
>>> Control register.
>>>
>>> - config_aneg: calls genphy_c37_config_aneg when the PHY is running in
>>> 1000Base-X mode; otherwise, genphy_config_aneg will be called.
>>>
>>> - read_status: calls genphy_c37_read_status when the PHY is running in
>>> 1000Base-X mode; otherwise, genphy_read_status will be called.
>>>
>>> Note: BCM54616S PHY can also be configured in RGMII->100Base-FX mode, and
>>> 100Base-FX support is not available as of now.
>>>
>>> Signed-off-by: Tao Ren <taoren@fb.com>
>>> ---
>
> The patchset looks good to me. However I am not a maintainer.
> If it helps,
>
> Acked-by: Vladimir Oltean <olteanv@gmail.com>
Thank you Vladimir!
Cheers,
Tao
^ permalink raw reply
* Re: [PATCH net-next v6 0/6] net: mscc: PTP Hardware Clock (PHC) support
From: David Miller @ 2019-08-15 23:31 UTC (permalink / raw)
To: antoine.tenart
Cc: richardcochran, alexandre.belloni, UNGLinuxDriver, netdev,
thomas.petazzoni, allan.nielsen, andrew
In-Reply-To: <20190812144537.14497-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Mon, 12 Aug 2019 16:45:31 +0200
> This series introduces the PTP Hardware Clock (PHC) support to the Mscc
> Ocelot switch driver. In order to make use of this, a new register bank
> is added and described in the device tree, as well as a new interrupt.
> The use this bank and interrupt was made optional in the driver for dt
> compatibility reasons.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net 0/2] rxrpc: Fix local endpoint handling
From: David Miller @ 2019-08-15 23:33 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <156577967167.1405.3581547705200268244.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Wed, 14 Aug 2019 11:47:51 +0100
> Here's a pair of patches that fix two issues in the handling of local
> endpoints (rxrpc_local structs):
>
> (1) Use list_replace_init() rather than list_replace() if we're going to
> unconditionally delete the replaced item later, lest the list get
> corrupted.
>
> (2) Don't access the rxrpc_local object after passing our ref to the
> workqueue, not even to illuminate tracepoints, as the work function
> may cause the object to be freed. We have to cache the information
> beforehand.
Pulled, thanks David.
^ permalink raw reply
* Re: [PATCH net-next 4/4 v2] net: ethernet: mediatek: Add MT7628/88 SoC support
From: David Miller @ 2019-08-15 23:36 UTC (permalink / raw)
To: sr; +Cc: netdev, opensource, daniel, sean.wang, john
In-Reply-To: <20190814111825.10855-4-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Wed, 14 Aug 2019 13:18:25 +0200
> +static int txd_to_idx(struct mtk_tx_ring *ring, struct mtk_tx_dma *dma)
> +{
> + return ((u32)dma - (u32)ring->dma) / sizeof(*dma);
> +}
This will definitely warn on 64-bit, and you should avoid that even if this
driver can not possibly be built on 64-bit platforms.
You cannot truncate a pointer to an integer which is potentially smaller
in representation size than a pointer could potentially be.
Just can avoid all of these issues by using real pointer arithmetic and
casting to (char *), or even better, (void *).
^ permalink raw reply
* Re: [PATCH net-next v7 3/3] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Florian Fainelli @ 2019-08-15 23:36 UTC (permalink / raw)
To: Tao Ren, Andrew Lunn, Heiner Kallweit, David S . Miller,
Vladimir Oltean, Arun Parameswaran, Justin Chen, netdev,
linux-kernel, openbmc
In-Reply-To: <20190811234016.3674056-1-taoren@fb.com>
On 8/11/19 4:40 PM, Tao Ren wrote:
> The BCM54616S PHY cannot work properly in RGMII->1000Base-X mode, mainly
> because genphy functions are designed for copper links, and 1000Base-X
> (clause 37) auto negotiation needs to be handled differently.
>
> This patch enables 1000Base-X support for BCM54616S by customizing 3
> driver callbacks, and it's verified to be working on Facebook CMM BMC
> platform (RGMII->1000Base-KX):
>
> - probe: probe callback detects PHY's operation mode based on
> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
> Control register.
>
> - config_aneg: calls genphy_c37_config_aneg when the PHY is running in
> 1000Base-X mode; otherwise, genphy_config_aneg will be called.
>
> - read_status: calls genphy_c37_read_status when the PHY is running in
> 1000Base-X mode; otherwise, genphy_read_status will be called.
>
> Note: BCM54616S PHY can also be configured in RGMII->100Base-FX mode, and
> 100Base-FX support is not available as of now.
>
> Signed-off-by: Tao Ren <taoren@fb.com>
> - reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
> - bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
> - reg | BCM5482_SHD_MODE_1000BX);
> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
> + reg | BCM54XX_SHD_MODE_1000BX);
This could have been a separate patch, but this looks reasonable to me
and this is correct with the datasheet, thanks Tao.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Alexei Starovoitov @ 2019-08-15 23:46 UTC (permalink / raw)
To: Kees Cook
Cc: Andy Lutomirski, Song Liu, Networking, bpf, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Lorenz Bauer, Jann Horn, Greg KH,
Linux API, LSM List
In-Reply-To: <201908151203.FE87970@keescook>
On Thu, Aug 15, 2019 at 12:46:41PM -0700, Kees Cook wrote:
> On Tue, Aug 13, 2019 at 02:58:25PM -0700, Alexei Starovoitov wrote:
> > agree that containers (namespaces) reduce amount of trust necessary
> > for apps to run, but the end goal is not security though.
>
> Unsurprisingly, I totally disagree: this is the very definition of
> improved "security": reduced attack surface, confined trust, etc.
there are different ways to define the meaning of the word "security".
Of course containers reduce attack surface, etc.
The 'attack surface' as a mitigation from malicious users is not always the goal
of running containers. Ask yourself why containers are used in the datacenters
where only root can ssh into a server, only signed packages can
ever be installed, no browsers running, and no remote code is ever downloaded?
> > Linux has become a single user system.
>
> I hope this is just hyperbole, because it's not true in reality. I agree
> that the vast majority of Linux devices are single-user-at-a-time
> systems now (rather than the "shell servers" of yore), but the system
> still has to be expected to confine users from each other, root, and the
> hardware. Switching users on Chrome OS or a distro laptop, etc is still
> very much expected to _mean_ something.
of course.
>
> > If user can ssh into the host they can become root.
> > If arbitrary code can run on the host it will be break out of any sandbox.
> > Containers are not providing the level of security that is enough
> > to run arbitrary code. VMs can do it better, but cpu bugs don't make it easy.
>
> I'm not sure why you draw the line for VMs -- they're just as buggy
> as anything else. Regardless, I reject this line of thinking: yes,
> all software is buggy, but that isn't a reason to give up.
hmm. are you saying you want kernel community to work towards
making containers (namespaces) being able to run arbitrary code
downloaded from the internet?
In other words the problems solved by user space sandboxing, gvisor, etc
should be solved by the kernel?
I really don't think it's a good idea.
> If you look at software safety as a binary, you will always be
> disappointed. If you look at it as it manifests in the real world,
> then there is some perspective to be had. Reachability of flaws becomes
> a major factor; exploit chain length becomes a factor. There are very
> real impacts to be had from security hardening, sandboxing, etc. Of
> course nothing is perfect, but the current state of the world isn't
> as you describe. (And I say this with the knowledge of how long
> the lifetime of bugs are in the kernel.)
No arguing here. Security today is mainly the number of layers.
Hardening at all levels, sanboxing do help.
namespaces is one of the layers provided by the kernel.
The point that the kernel did its job already.
All other security layers are in user space.
Looking for bugs at every layer is still must have.
In the kernel, systemd, qemu, OS, browsers, etc.
Containers provide one level of security. VMs have another.
> > Some people call it more 'secure', but it's clearly not secure for
> > arbitrary code
>
> Perhaps it's just a language issue. "More secure" and "safer" mean
> mostly the same thing to me. I tend to think "safer" is actually
> a superset that includes things that wreck the user experience but
> aren't actually in the privilege manipulation realm. In the traditional
> "security" triad of confidentiality, integrity, and availability, I tend
> to weigh availability less highly, but a bug that stops someone from
> doing their work but doesn't wreck data, let them switch users, etc,
> is still considered a "security" issue by many folks. The fewer bugs
> someone is exposed to improves their security, safety, whatever. The
> easiest way to do that is confinement and its associated attack surface
> reduction. tl;dr: security and safety are very use-case-specific
> continuum, not a binary state.
yep
>
> > When we say 'unprivileged bpf' we really mean arbitrary malicious bpf program.
> > It's been a constant source of pain. The constant blinding, randomization,
> > verifier speculative analysis, all spectre v1, v2, v4 mitigations
> > are simply not worth it. It's a lot of complex kernel code without users.
> > There is not a single use case to allow arbitrary malicious bpf
> > program to be loaded and executed.
>
> The world isn't binary (safe code/malicious code), and we need to build
> systems that can be used safely even when things go wrong. Yes, probably
> no one has a system that _intentionally_ feeds eBPF into the kernel from
> a web form. But there is probably someone who does it unintentionally,
> or has a user login exposed on a system where unpriv BPF is enabled. The
> point is to create primitives as safely as possible so when things DO
> go wrong, they fail safe instead of making things worse.
>
> I'm all for a "less privileged than root" API for eBPF, but I get worried
> when I see "security" being treated as a binary state. Especially when
> it is considered an always-failed state. :)
'security as always failed state' ? hmm.
not sure where this impression came from.
One of the goals here is to do sysctl kernel.unprivileged_bpf_disabled=1
which will make the system overall _more_ secure.
I hope we can agree on that.
^ permalink raw reply
* Re: [v5,0/4] tools: bpftool: add net attach/detach command to attach XDP prog
From: Alexei Starovoitov @ 2019-08-16 0:02 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel T. Lee, Daniel Borkmann, Alexei Starovoitov,
Network Development
In-Reply-To: <20190813144303.10da8ff0@cakuba.netronome.com>
On Tue, Aug 13, 2019 at 2:43 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Tue, 13 Aug 2019 11:46:17 +0900, Daniel T. Lee wrote:
> > Currently, bpftool net only supports dumping progs attached on the
> > interface. To attach XDP prog on interface, user must use other tool
> > (eg. iproute2). By this patch, with `bpftool net attach/detach`, user
> > can attach/detach XDP prog on interface.
> >
> > # bpftool prog
> > 16: xdp name xdp_prog1 tag 539ec6ce11b52f98 gpl
> > loaded_at 2019-08-07T08:30:17+0900 uid 0
> > ...
> > 20: xdp name xdp_fwd_prog tag b9cb69f121e4a274 gpl
> > loaded_at 2019-08-07T08:30:17+0900 uid 0
> >
> > # bpftool net attach xdpdrv id 16 dev enp6s0np0
> > # bpftool net
> > xdp:
> > enp6s0np0(4) driver id 16
> >
> > # bpftool net attach xdpdrv id 20 dev enp6s0np0 overwrite
> > # bpftool net
> > xdp:
> > enp6s0np0(4) driver id 20
> >
> > # bpftool net detach xdpdrv dev enp6s0np0
> > # bpftool net
> > xdp:
> >
> >
> > While this patch only contains support for XDP, through `net
> > attach/detach`, bpftool can further support other prog attach types.
> >
> > XDP attach/detach tested on Mellanox ConnectX-4 and Netronome Agilio.
> >
> > ---
> > Changes in v5:
> > - fix wrong error message, from errno to err with do_attach/detach
>
> The inconsistency in libbpf's error reporting is generally troubling,
> but a problem of this set, so:
>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied. Thanks
^ permalink raw reply
* Re: [PATCH v3 bpf-next] libbpf: make libbpf.map source of truth for libbpf version
From: Alexei Starovoitov @ 2019-08-16 0:04 UTC (permalink / raw)
To: Andrey Ignatov
Cc: Andrii Nakryiko, bpf@vger.kernel.org, netdev@vger.kernel.org,
Alexei Starovoitov, daniel@iogearbox.net,
andrii.nakryiko@gmail.com, Kernel Team
In-Reply-To: <20190814213335.GA90959@rdna-mbp.dhcp.thefacebook.com>
On Wed, Aug 14, 2019 at 3:16 PM Andrey Ignatov <rdna@fb.com> wrote:
>
> Andrii Nakryiko <andriin@fb.com> [Wed, 2019-08-14 13:57 -0700]:
> > Currently libbpf version is specified in 2 places: libbpf.map and
> > Makefile. They easily get out of sync and it's very easy to update one,
> > but forget to update another one. In addition, Github projection of
> > libbpf has to maintain its own version which has to be remembered to be
> > kept in sync manually, which is very error-prone approach.
> >
> > This patch makes libbpf.map a source of truth for libbpf version and
> > uses shell invocation to parse out correct full and major libbpf version
> > to use during build. Now we need to make sure that once new release
> > cycle starts, we need to add (initially) empty section to libbpf.map
> > with correct latest version.
> >
> > This also will make it possible to keep Github projection consistent
> > with kernel sources version of libbpf by adopting similar parsing of
> > version from libbpf.map.
> >
> > v2->v3:
> > - grep -o + sort -rV (Andrey);
> >
> > v1->v2:
> > - eager version vars evaluation (Jakub);
> > - simplified version regex (Andrey);
>
> Acked-by: Andrey Ignatov <rdna@fb.com>
Applied. Thanks
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/3] libbpf: use LFS (_FILE_OFFSET_BITS) instead of direct mmap2 syscall
From: Yonghong Song @ 2019-08-16 0:06 UTC (permalink / raw)
To: Ivan Khoronzhuk, magnus.karlsson@intel.com, bjorn.topel@intel.com
Cc: davem@davemloft.net, hawk@kernel.org, john.fastabend@gmail.com,
jakub.kicinski@netronome.com, daniel@iogearbox.net,
netdev@vger.kernel.org, bpf@vger.kernel.org,
xdp-newbies@vger.kernel.org, linux-kernel@vger.kernel.org,
jlemon@flugsvamp.com, andrii.nakryiko@gmail.com
In-Reply-To: <20190815121356.8848-2-ivan.khoronzhuk@linaro.org>
On 8/15/19 5:13 AM, Ivan Khoronzhuk wrote:
> Drop __NR_mmap2 fork in flavor of LFS, that is _FILE_OFFSET_BITS=64
> (glibc & bionic) / LARGEFILE64_SOURCE (for musl) decision. It allows
> mmap() to use 64bit offset that is passed to mmap2 syscall. As result
> pgoff is not truncated and no need to use direct access to mmap2 for
> 32 bits systems.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: WARNING in tracepoint_probe_register_prio (3)
From: syzbot @ 2019-08-16 0:11 UTC (permalink / raw)
To: ard.biesheuvel, gregkh, gustavo, jeyu, linux-kernel,
mathieu.desnoyers, mingo, netdev, paulmck, paulmck, rostedt,
syzkaller-bugs, tglx
In-Reply-To: <000000000000ab6f84056c786b93@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: ecb9f80d net/mvpp2: Replace tasklet with softirq hrtimer
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=115730ac600000
kernel config: https://syzkaller.appspot.com/x/.config?x=d4cf1ffb87d590d7
dashboard link: https://syzkaller.appspot.com/bug?extid=774fddf07b7ab29a1e55
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11b02a22600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+774fddf07b7ab29a1e55@syzkaller.appspotmail.com
WARNING: CPU: 0 PID: 8824 at kernel/tracepoint.c:243 tracepoint_add_func
kernel/tracepoint.c:243 [inline]
WARNING: CPU: 0 PID: 8824 at kernel/tracepoint.c:243
tracepoint_probe_register_prio+0x216/0x790 kernel/tracepoint.c:315
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 8824 Comm: syz-executor.4 Not tainted 5.3.0-rc3+ #133
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2dc/0x755 kernel/panic.c:219
__warn.cold+0x20/0x4c kernel/panic.c:576
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
fixup_bug arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
RIP: 0010:tracepoint_add_func kernel/tracepoint.c:243 [inline]
RIP: 0010:tracepoint_probe_register_prio+0x216/0x790 kernel/tracepoint.c:315
Code: 48 89 f8 48 c1 e8 03 80 3c 08 00 0f 85 bf 04 00 00 48 8b 45 b8 49 3b
45 08 0f 85 21 ff ff ff 41 bd ef ff ff ff e8 aa 8c fe ff <0f> 0b e8 a3 8c
fe ff 48 c7 c7 20 44 de 88 e8 d7 1d ca 05 44 89 e8
RSP: 0018:ffff88807b5a7498 EFLAGS: 00010293
RAX: ffff8880a87a85c0 RBX: ffffffff89a1eb00 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: ffffffff8173fcd6 RDI: ffff88808afc4698
RBP: ffff88807b5a74f0 R08: ffff8880a87a85c0 R09: fffffbfff11bc885
R10: ffff88807b5a7488 R11: ffffffff88de4427 R12: ffff88808afc4690
R13: 00000000ffffffef R14: 00000000ffffffff R15: ffffffff8177f710
tracepoint_probe_register+0x2b/0x40 kernel/tracepoint.c:335
register_trace_sched_wakeup include/trace/events/sched.h:96 [inline]
tracing_sched_register kernel/trace/trace_sched_switch.c:54 [inline]
tracing_start_sched_switch+0xa8/0x190 kernel/trace/trace_sched_switch.c:106
tracing_start_cmdline_record+0x13/0x20
kernel/trace/trace_sched_switch.c:131
trace_printk_init_buffers kernel/trace/trace.c:3050 [inline]
trace_printk_init_buffers.cold+0xdf/0xe9 kernel/trace/trace.c:3013
bpf_get_trace_printk_proto+0xe/0x20 kernel/trace/bpf_trace.c:338
cgroup_base_func_proto kernel/bpf/cgroup.c:799 [inline]
cgroup_base_func_proto.isra.0+0x10e/0x120 kernel/bpf/cgroup.c:776
cg_sockopt_func_proto+0x53/0x70 kernel/bpf/cgroup.c:1411
check_helper_call+0x141/0x32f0 kernel/bpf/verifier.c:3950
do_check+0x6213/0x89f0 kernel/bpf/verifier.c:7707
bpf_check+0x6f99/0x9948 kernel/bpf/verifier.c:9294
bpf_prog_load+0xe68/0x1670 kernel/bpf/syscall.c:1698
__do_sys_bpf+0xc43/0x3460 kernel/bpf/syscall.c:2849
__se_sys_bpf kernel/bpf/syscall.c:2808 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:2808
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
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:00007fc4bf1dec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000000000070 RSI: 0000000020000180 RDI: 0000000000000005
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc4bf1df6d4
R13: 00000000004bfc7c R14: 00000000004d1938 R15: 00000000ffffffff
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* [RFC PATCH net-next 01/11] net: dsa: sja1105: Add a debugging GPIO for monitoring SPI latency
From: Vladimir Oltean @ 2019-08-16 0:44 UTC (permalink / raw)
To: h.feurstein, mlichvar, richardcochran, andrew, f.fainelli,
broonie
Cc: linux-spi, netdev, Vladimir Oltean
In-Reply-To: <20190816004449.10100-1-olteanv@gmail.com>
I am using this to monitor the gettimex64 callback jitter, i.e. the
time it takes for the SPI controller to retrieve the PTP time from the
switch, and therefore the uncertainty in the time that has just been
read.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
drivers/net/dsa/sja1105/sja1105.h | 4 ++++
drivers/net/dsa/sja1105/sja1105_main.c | 11 +++++++++++
drivers/net/dsa/sja1105/sja1105_ptp.c | 2 ++
3 files changed, 17 insertions(+)
diff --git a/drivers/net/dsa/sja1105/sja1105.h b/drivers/net/dsa/sja1105/sja1105.h
index 3dbfe41b370e..e6371b2c2df1 100644
--- a/drivers/net/dsa/sja1105/sja1105.h
+++ b/drivers/net/dsa/sja1105/sja1105.h
@@ -89,6 +89,7 @@ struct sja1105_private {
bool rgmii_tx_delay[SJA1105_NUM_PORTS];
const struct sja1105_info *info;
struct gpio_desc *reset_gpio;
+ struct gpio_desc *debug_gpio;
struct spi_device *spidev;
struct dsa_switch *ds;
struct sja1105_port ports[SJA1105_NUM_PORTS];
@@ -126,6 +127,9 @@ typedef enum {
SPI_WRITE = 1,
} sja1105_spi_rw_mode_t;
+/* From sja1105_main.c */
+void sja1105_debug_gpio(struct sja1105_private *priv, bool enabled);
+
/* From sja1105_spi.c */
int sja1105_spi_send_packed_buf(const struct sja1105_private *priv,
sja1105_spi_rw_mode_t rw, u64 reg_addr,
diff --git a/drivers/net/dsa/sja1105/sja1105_main.c b/drivers/net/dsa/sja1105/sja1105_main.c
index 17b917d1e6be..82bdc2da8f8f 100644
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++ b/drivers/net/dsa/sja1105/sja1105_main.c
@@ -23,6 +23,15 @@
#include <linux/dsa/8021q.h>
#include "sja1105.h"
+void sja1105_debug_gpio(struct sja1105_private *priv, bool enabled)
+{
+ if (IS_ERR(priv->debug_gpio)) {
+ dev_err(priv->ds->dev, "Bad debug GPIO!\n");
+ return;
+ }
+ gpiod_set_value_cansleep(priv->debug_gpio, enabled);
+}
+
static void sja1105_hw_reset(struct gpio_desc *gpio, unsigned int pulse_len,
unsigned int startup_delay)
{
@@ -2142,6 +2151,8 @@ static int sja1105_probe(struct spi_device *spi)
else
sja1105_hw_reset(priv->reset_gpio, 1, 1);
+ priv->debug_gpio = devm_gpiod_get(dev, "debug", GPIOD_OUT_HIGH);
+
/* Populate our driver private structure (priv) based on
* the device tree node that was probed (spi)
*/
diff --git a/drivers/net/dsa/sja1105/sja1105_ptp.c b/drivers/net/dsa/sja1105/sja1105_ptp.c
index 90a595cc596d..51a0014369fc 100644
--- a/drivers/net/dsa/sja1105/sja1105_ptp.c
+++ b/drivers/net/dsa/sja1105/sja1105_ptp.c
@@ -353,8 +353,10 @@ static u64 sja1105_ptptsclk_read(const struct cyclecounter *cc)
u64 ptptsclk = 0;
int rc;
+ sja1105_debug_gpio(priv, 1);
rc = sja1105_spi_send_int(priv, SPI_READ, regs->ptptsclk,
&ptptsclk, 8);
+ sja1105_debug_gpio(priv, 0);
if (rc < 0)
dev_err_ratelimited(priv->ds->dev,
"failed to read ptp cycle counter: %d\n",
--
2.17.1
^ permalink raw reply related
* [RFC PATCH net-next 00/11] Deterministic SPI latency on NXP
From: Vladimir Oltean @ 2019-08-16 0:44 UTC (permalink / raw)
To: h.feurstein, mlichvar, richardcochran, andrew, f.fainelli,
broonie
Cc: linux-spi, netdev, Vladimir Oltean
Continuing the discussion created by Hubert Feurstein around the
mv88e6xxx driver for MDIO-controlled switches
(https://lkml.org/lkml/2019/8/2/1364), this patchset takes a similar
approach for the NXP LS1021A-TSN board, which has a SPI-controlled DSA
switch (SJA1105).
The patchset is motivated by some experiments done with a logic
analyzer, trying to understand the source of latency (and especially of
the jitter). SJA1105 SPI messages for reading the PTP clock are 12 bytes
in length: 4 for the SPI header and 8 for the timestamp. When looking at
the messages with a scope, there's jitter basically everywhere: between
bits of a frame and between frames in a transfer. The inter-bit jitter
is hardware and impacts us to a lesser extend (is smaller and caused by
the PVT stability of the oscillators, PLLs, etc). We will focus on the
latency between consecutive SPI frames within a 12-byte transfer.
As a preface, revisions of the DSPI controller IP are integrated in many
Freescale/NXP devices. As a result, the driver has 3 modes of operation:
- TCFQ (Transfer Complete Flag mode): The controller signals software
that data has been sent/received after each individual word.
- EOQ (End of Queue mode): The driver can implement batching by making
use of the controller's 4-word deep FIFO.
- DMA (Direct Memory Access mode): The SPI controller's FIFO is no
longer in direct interaction with the driver, but is used to trigger
the RX and TX channels of the eDMA module on the SoC.
In LS1021A, the driver works in the least efficient mode of the 3
(TCFQ). There is a well-known errata that the DSPI controller is broken
in conjunction with the eDMA module. As for the EOQ mode, I have tried
unsuccessfully for a few days to make use of the 4 entry FIFO, and the
hardware simply fails to reliably acknowledge the transmission when the
FIFO gets full. So it looks like we're stuck with the TCFQ mode.
The problem with phc2sys on the LS1021A-TSN board is that in order for
the gettime64() call to complete on the sja1105, the system has to
service 12 IRQs. Intuitively that is excessive and is the main source of
jitter, but let's not get ahead of ourselves.
An outline of the experiments that were done (unless otherwise
mentioned, all of these ran for 120 seconds):
A. First I have measured the (poor) performance of phc2sys under current
conditions. (DSPI driver in IRQ mode, no PTP system timestamping)
offset: min -53310 max 16107 mean -1737.18 std dev 11444.3
delay: min 163680 max 237360 mean 201149 std dev 22446.6
lost servo lock 1 times
B. I switched the .gettime64 callback to .gettimex64, snapshotting the
PTP system timestamp within the sja1105 driver.
offset: min -48923 max 64217 mean -904.137 std dev 17358.1
delay: min 149600 max 203840 mean 169045 std dev 17993.3
lost servo lock 8 times
C. I patched "struct spi_transfer" to contain the PTP system timestamp,
and from the sja1105 driver, I passed this structure to be
snapshotted by the SPI controller's driver (spi-fsl-dspi). This is
the "transfer-level" snapshot.
offset: min -64979 max 38979 mean -416.197 std dev 15367.9
delay: min 125120 max 168320 mean 150286 std dev 17675.3
lost servo lock 10 times
D. I changed the placement of the transfer snapshotting within the DSPI
driver, from "transfer-level" to "byte-level".
offset: min -9021 max 7149 mean -0.418803 std dev 3529.81
delay: min 7840 max 23920 mean 14493.7 std dev 5982.17
lost servo lock 0 times
E. I moved the DSPI driver to poll mode. I went back to collecting the
PTP system timestamps from the sja1105 driver (same as B).
offset: min -4199 max 46643 mean 418.214 std dev 4554.01
delay: min 84000 max 194000 mean 99463.2 std dev 12936.5
lost servo lock 1 times
F. Transfer-level snapshotting in the DSPI driver (same as C), but in
poll mode.
offset: min -24244 max 1115 mean -230.478 std dev 2297.28
delay: min 69440 max 119040 mean 70312.9 std dev 8065.34
lost servo lock 1 times
G. Byte-level snapshotting (same as D) but in poll mode.
offset: min -314 max 288 mean -2.48718 std dev 118.045
delay: min 4880 max 6000 mean 5118.63 std dev 507.258
lost servo lock 0 times
This seemed suspiciously good to me, so I let it run for longer
(58 minutes):
offset: min -26251 max 16416 mean -21.8672 std dev 863.416
delay: min 4720 max 57280 mean 5182.49 std dev 1607.19
lost servo lock 3 times
H. Transfer-level snapshotting (same as F), but with IRQs disabled.
This ran for 86 minutes.
offset: min -1927 max 1843 mean -0.209203 std dev 529.398
delay: min 85440 max 93680 mean 88245 std dev 1454.71
lost servo lock 0 times
I. Byte-level snapshotting (same as G), but with IRQs disabled.
This ran for 102 minutes.
offset: min -378 max 381 mean -0.0083089 std dev 101.495
delay: min 4720 max 5920 mean 5129.38 std dev 154.899
lost servo lock 0 times
As a result, this patchset proposes the implementation of scenario I.
The others were done through temporary patches which are not presented
here due to the difficulty of presenting a coherent git history without
resorting to reverts etc. The gist of each experiment should be clear
though.
The raw data is available for dissection at
https://drive.google.com/open?id=1r9raU9ZeqOqkqts6Lb-ISf5ubLDLP3wk.
The logic analyzer captures can be opened with a free-as-in-beer program
provided by Saleae: https://www.saleae.com/downloads/.
In the capture data one can find the MOSI, SCK SPI signals, as well as a
debug GPIO which was toggled at the same time as the PTP system
timestamp was taken, to give the viewer an impression of what the
software is capturing compared to the actual timing of the SPI transfer.
Attached are also some close-up screenshots of transfers where there is
a clear and huge delay in-between frames of the same 12-byte SPI
transfer. As it turns out, these were all caused by the CPU getting
interrupted by some other IRQ. Approaches H and I are the only ones that
get rid of these glitches. In theory, the byte-level snapshotting should
be less vulnerable to an IRQ interrupting the SPI transfer (because the
time window is much smaller) but as the 58 minutes experiment shows, it
is not immune.
Vladimir Oltean (11):
net: dsa: sja1105: Add a debugging GPIO for monitoring SPI latency
net: dsa: sja1105: Implement the .gettimex64 system call for PTP
spi: Add a PTP system timestamp to the transfer structure
spi: spi-fsl-dspi: Cosmetic cleanup
spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing
spi: spi-fsl-dspi: Implement the PTP system timestamping
spi: spi-fsl-dspi: Add a debugging GPIO for monitoring latency
spi: spi-fsl-dspi: Disable interrupts and preemption during poll mode
transfer
ARM: dts: ls1021a-tsn: Add debugging GPIOs for the SJA1105 and DSPI
drivers
ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
ARM: dts: ls1021a-tsn: Reduce the SJA1105 SPI frequency for debug
arch/arm/boot/dts/ls1021a-tsn.dts | 8 +-
drivers/net/dsa/sja1105/sja1105.h | 8 +-
drivers/net/dsa/sja1105/sja1105_main.c | 15 +-
drivers/net/dsa/sja1105/sja1105_ptp.c | 23 +-
drivers/net/dsa/sja1105/sja1105_spi.c | 34 +-
drivers/spi/spi-fsl-dspi.c | 518 ++++++++++++++-----------
include/linux/spi/spi.h | 4 +
7 files changed, 365 insertions(+), 245 deletions(-)
--
2.17.1
^ permalink raw reply
* [RFC PATCH net-next 03/11] spi: Add a PTP system timestamp to the transfer structure
From: Vladimir Oltean @ 2019-08-16 0:44 UTC (permalink / raw)
To: h.feurstein, mlichvar, richardcochran, andrew, f.fainelli,
broonie
Cc: linux-spi, netdev, Vladimir Oltean
In-Reply-To: <20190816004449.10100-1-olteanv@gmail.com>
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc).
Since there are lots of sources of timing jitter when retrieving the
time from such a device (controller delays, locking contention etc),
introduce a PTP system timestamp structure in struct spi_transfer. This
is to be used by SPI device drivers when they need to know the exact
time at which the underlying device's time was snapshotted.
Because SPI controllers may have jitter even between frames, also
introduce a field which specifies to the controller driver specifically
which byte needs to be snapshotted.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
include/linux/spi/spi.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index af4f265d0f67..5a1e4b24c617 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -13,6 +13,7 @@
#include <linux/completion.h>
#include <linux/scatterlist.h>
#include <linux/gpio/consumer.h>
+#include <linux/ptp_clock_kernel.h>
struct dma_chan;
struct property_entry;
@@ -842,6 +843,9 @@ struct spi_transfer {
u32 effective_speed_hz;
+ struct ptp_system_timestamp *ptp_sts;
+ unsigned int ptp_sts_word_offset;
+
struct list_head transfer_list;
};
--
2.17.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