* Re: [PATCH bpf] tools: bpftool: close prog FD before exit on showing a single program
From: Andrii Nakryiko @ 2019-08-15 20:16 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Quentin Monnet, Alexei Starovoitov, Daniel Borkmann, bpf,
Networking, oss-drivers
In-Reply-To: <20190815110917.657de4e3@cakuba.netronome.com>
On Thu, Aug 15, 2019 at 11:09 AM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Thu, 15 Aug 2019 11:05:16 -0700, Andrii Nakryiko wrote:
> > > > Would it be better to make show_prog(fd) close provided fd instead or
> > > > is it used in some other context where FD should live longer (I
> > > > haven't checked, sorry)?
> > >
> > > I think it used to close that's how the bug crept in. Other than the bug
> > > it's fine the way it is.
> >
> > So are you saying that show_prog() should or should not close FD?
>
> Yup, it we'd have to rename it to indicate it closes the fd, and it's
> only called in two places. Not worth the churn.
OK, I'm fine with that.
Acked-by: Andrii Nakryiko <andriin@fb.com>
^ permalink raw reply
* Re: [PATCH v3 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Brian Norris @ 2019-08-15 20:25 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, Larry Finger,
David Laight, Christoph Hellwig, linux-wireless,
<netdev@vger.kernel.org>, Linux Kernel, linux, Daniel Drake,
stable
In-Reply-To: <20190710083825.7115-1-jian-hong@endlessm.com>
Hi all,
I realize this already is merged, and it had some previous review
comments that led to the decisions in this patch, but I'd still like
to ask here, where I think I'm reaching the relevant parties:
On Wed, Jul 10, 2019 at 1:43 AM Jian-Hong Pan <jian-hong@endlessm.com> wrote:
...
> This patch allocates a new, data-sized skb first in RX ISR. After
> copying the data in, we pass it to the upper layers. However, if skb
> allocation fails, we effectively drop the frame. In both cases, the
> original, full size ring skb is reused.
>
> In addition, by fixing the kernel crash, the RX routine should now
> generally behave better under low memory conditions.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: <stable@vger.kernel.org>
> ---
> v2:
> - Allocate new data-sized skb and put data into it, then pass it to
> mac80211. Reuse the original skb in RX ring by DMA sync.
Is it really wise to force an extra memcpy() for *every* delivery?
Isn't there some other strategy that could be used to properly handle
low-memory scenarios while still passing the original buffer up to
higher layers most of the time? Or is it really so bad to keep
re-allocating RTK_PCI_RX_BUF_SIZE (>8KB) of contiguous memory, to
re-fill the RX ring? And if that is so bad, can we reduce the
requirement for contiguous memory instead? (e.g., keep with smaller
buffers, and perform aggregation / scatter-gather only for frames that
are really larger?)
Anyway, that's mostly a long-term thought, as this patch is good for
fixing the important memory errors, even if it's not necessarily the
ideal solution.
Regards,
Brian
^ permalink raw reply
* [PATCH v2] wimax/i2400m: fix a memory leak bug
From: Wenwen Wang @ 2019-08-15 20:29 UTC (permalink / raw)
To: Wenwen Wang
Cc: Inaky Perez-Gonzalez,
supporter:INTEL WIRELESS WIMAX CONNECTION 2400, David S. Miller,
open list:NETWORKING DRIVERS, open list
In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
to hold the original command line options. Then, the options are parsed.
However, if an error occurs during the parsing process, 'options_orig' is
not deallocated, leading to a memory leak bug. To fix this issue, free
'options_orig' before returning the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/wimax/i2400m/fw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
index e9fc168..489cba9 100644
--- a/drivers/net/wimax/i2400m/fw.c
+++ b/drivers/net/wimax/i2400m/fw.c
@@ -351,13 +351,15 @@ int i2400m_barker_db_init(const char *_options)
}
result = i2400m_barker_db_add(barker);
if (result < 0)
- goto error_add;
+ goto error_parse_add;
}
kfree(options_orig);
}
return 0;
+error_parse_add:
error_parse:
+ kfree(options_orig);
error_add:
kfree(i2400m_barker_db);
return result;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: pch_gbe: Fix memory leaks
From: David Miller @ 2019-08-15 20:42 UTC (permalink / raw)
To: wenwen
Cc: rfontana, allison, alexios.zavras, gregkh, tglx, netdev,
linux-kernel
In-Reply-To: <CAAa=b7ft-crBJm+H9U7Bn2dcgfjQsE8o53p2ryBWK3seQoF3Cg@mail.gmail.com>
From: Wenwen Wang <wenwen@cs.uga.edu>
Date: Thu, 15 Aug 2019 16:03:39 -0400
> On Thu, Aug 15, 2019 at 3:34 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Wenwen Wang <wenwen@cs.uga.edu>
>> Date: Tue, 13 Aug 2019 20:33:45 -0500
>>
>> > In pch_gbe_set_ringparam(), if netif_running() returns false, 'tx_old' and
>> > 'rx_old' are not deallocated, leading to memory leaks. To fix this issue,
>> > move the free statements after the if branch.
>> >
>> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
>>
>> Why would they be "deallocated"? They are still assigned to
>> adapter->tx_ring and adapter->rx_ring.
>
> 'adapter->tx_ring' and 'adapter->rx_ring' has been covered by newly
> allocated 'txdr' and 'rxdr' respectively before this if statement.
That only happens inside of the if() statement, that's why rx_old and
tx_old are only freed in that code path.
^ permalink raw reply
* Re: [PATCH] net: pch_gbe: Fix memory leaks
From: Wenwen Wang @ 2019-08-15 20:46 UTC (permalink / raw)
To: David Miller
Cc: Richard Fontana, Allison Randal, Alexios Zavras,
Greg Kroah-Hartman, Thomas Gleixner,
open list:NETWORKING [GENERAL], open list, Wenwen Wang
In-Reply-To: <20190815.134230.1028411309377288636.davem@davemloft.net>
On Thu, Aug 15, 2019 at 4:42 PM David Miller <davem@davemloft.net> wrote:
>
> From: Wenwen Wang <wenwen@cs.uga.edu>
> Date: Thu, 15 Aug 2019 16:03:39 -0400
>
> > On Thu, Aug 15, 2019 at 3:34 PM David Miller <davem@davemloft.net> wrote:
> >>
> >> From: Wenwen Wang <wenwen@cs.uga.edu>
> >> Date: Tue, 13 Aug 2019 20:33:45 -0500
> >>
> >> > In pch_gbe_set_ringparam(), if netif_running() returns false, 'tx_old' and
> >> > 'rx_old' are not deallocated, leading to memory leaks. To fix this issue,
> >> > move the free statements after the if branch.
> >> >
> >> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> >>
> >> Why would they be "deallocated"? They are still assigned to
> >> adapter->tx_ring and adapter->rx_ring.
> >
> > 'adapter->tx_ring' and 'adapter->rx_ring' has been covered by newly
> > allocated 'txdr' and 'rxdr' respectively before this if statement.
>
> That only happens inside of the if() statement, that's why rx_old and
> tx_old are only freed in that code path.
That happens not only inside of the if statement, but also before the
if statement, just after 'txdr' and 'rxdr' are allocated.
Wenwen
^ permalink raw reply
* Re: [PATCH] net: pch_gbe: Fix memory leaks
From: David Miller @ 2019-08-15 20:51 UTC (permalink / raw)
To: wenwen
Cc: rfontana, allison, alexios.zavras, gregkh, tglx, netdev,
linux-kernel
In-Reply-To: <CAAa=b7duRXsiVBfzbvHhoU000gGh53Mme3ZKCO5SoiTdgRaXtg@mail.gmail.com>
From: Wenwen Wang <wenwen@cs.uga.edu>
Date: Thu, 15 Aug 2019 16:46:05 -0400
> On Thu, Aug 15, 2019 at 4:42 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Wenwen Wang <wenwen@cs.uga.edu>
>> Date: Thu, 15 Aug 2019 16:03:39 -0400
>>
>> > On Thu, Aug 15, 2019 at 3:34 PM David Miller <davem@davemloft.net> wrote:
>> >>
>> >> From: Wenwen Wang <wenwen@cs.uga.edu>
>> >> Date: Tue, 13 Aug 2019 20:33:45 -0500
>> >>
>> >> > In pch_gbe_set_ringparam(), if netif_running() returns false, 'tx_old' and
>> >> > 'rx_old' are not deallocated, leading to memory leaks. To fix this issue,
>> >> > move the free statements after the if branch.
>> >> >
>> >> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
>> >>
>> >> Why would they be "deallocated"? They are still assigned to
>> >> adapter->tx_ring and adapter->rx_ring.
>> >
>> > 'adapter->tx_ring' and 'adapter->rx_ring' has been covered by newly
>> > allocated 'txdr' and 'rxdr' respectively before this if statement.
>>
>> That only happens inside of the if() statement, that's why rx_old and
>> tx_old are only freed in that code path.
>
> That happens not only inside of the if statement, but also before the
> if statement, just after 'txdr' and 'rxdr' are allocated.
Then the assignments inside of the if() statement are redundant.
Something doesn't add up here, please make the code consistent.
^ permalink raw reply
* [PATCH bpf 1/1] xdp: unpin xdp umem pages in error path
From: Ivan Khoronzhuk @ 2019-08-15 20:56 UTC (permalink / raw)
To: bjorn.topel
Cc: magnus.karlsson, jonathan.lemon, davem, ast, daniel,
jakub.kicinski, hawk, john.fastabend, netdev, bpf, linux-kernel,
Ivan Khoronzhuk
Fix mem leak caused by missed unpin routine for umem pages.
Fixes: 8aef7340ae9695 ("commit xsk: introduce xdp_umem_page")
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
Based on bpf/master
net/xdp/xdp_umem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 83de74ca729a..688aac7a6943 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -365,7 +365,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
umem->pages = kcalloc(umem->npgs, sizeof(*umem->pages), GFP_KERNEL);
if (!umem->pages) {
err = -ENOMEM;
- goto out_account;
+ goto out_pin;
}
for (i = 0; i < umem->npgs; i++)
@@ -373,6 +373,8 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
return 0;
+out_pin:
+ xdp_umem_unpin_pages(umem);
out_account:
xdp_umem_unaccount_pages(umem);
return err;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] r8152: divide the tx and rx bottom functions
From: David Miller @ 2019-08-15 20:58 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1394712342-15778-301-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 14 Aug 2019 16:30:17 +0800
> Move the tx bottom function from NAPI to a new tasklet. Then, for
> multi-cores, the bottom functions of tx and rx may be run at same
> time with different cores. This is used to improve performance.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Theoretically, yes.
But do you have actual performance numbers showing this to be worth
the change?
Always provide performance numbers with changes that are supposed to
improve performance.
^ permalink raw reply
* Re: [PATCH net] net/packet: fix race in tpacket_snd()
From: David Miller @ 2019-08-15 21:00 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, syzkaller
In-Reply-To: <20190814091157.215108-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 14 Aug 2019 02:11:57 -0700
> packet_sendmsg() checks tx_ring.pg_vec to decide
> if it must call tpacket_snd().
>
> Problem is that the check is lockless, meaning another thread
> can issue a concurrent setsockopt(PACKET_TX_RING ) to flip
> tx_ring.pg_vec back to NULL.
>
> Given that tpacket_snd() grabs pg_vec_lock mutex, we can
> perform the check again to solve the race.
>
> syzbot reported :
...
> Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH bpf 1/1] xdp: unpin xdp umem pages in error path
From: Jonathan Lemon @ 2019-08-15 21:01 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: bjorn.topel, magnus.karlsson, davem, ast, daniel, jakub.kicinski,
hawk, john.fastabend, netdev, bpf, linux-kernel
In-Reply-To: <20190815205635.6536-1-ivan.khoronzhuk@linaro.org>
On 15 Aug 2019, at 13:56, Ivan Khoronzhuk wrote:
> Fix mem leak caused by missed unpin routine for umem pages.
> Fixes: 8aef7340ae9695 ("commit xsk: introduce xdp_umem_page")
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* 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
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