* RE: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Chris Preimesberger @ 2018-09-27 18:56 UTC (permalink / raw)
To: 'Andrew Lunn', Eran Ben Elisha
Cc: Neil Horman, linville@tuxdriver.com, netdev@vger.kernel.org
In-Reply-To: <20180927163805.GI12979@lunn.ch>
I greatly appreciate everyone's work on this. Thank you to all.
I've had Mellanox support case # 00508027 open for this issue,
and just now requested an updated driver from them to resolve,
explaining that really smart ethtool developers figured out this
was due to the Mellanox driver not reporting thresholds to ethtool.
I intend to post back here for posterity if/when I get an updated
driver that fixes the issue.
Thanks again!!
Chris Preimesberger | Test & Validation Engineer
Transition Networks, Inc.
chrisp@transition.com
direct: +1.952.996.1509 | fax: +1.952.941.2322 | www.transition.com
-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Thursday, September 27, 2018 11:38 AM
To: Chris Preimesberger
Cc: Eran Ben Elisha; Neil Horman; linville@tuxdriver.com; netdev@vger.kernel.org
Subject: Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
On Thu, Sep 27, 2018 at 04:08:24PM +0000, Chris Preimesberger wrote:
> Please correct me if I'm wrong, but...
> It looks like Eran's proposed fix would remove all warning and alarm
> indications from ethtool's output. It's worth mentioning that for me,
> the following fields always reported correctly as Off while no alarm
> condition was present and On while alarm condition(s) were present
> *per the QSFP's true/programmed threshold values* *not per the
> incorrectly reported threshold values*
These alarm values are in the first page. So the information the driver returns does contain this information. What is missing is the thresholds, which are not provided by the driver.
But there is a comment in the code:
/*
* There is no clear identifier to signify the existence of
* optical diagnostics similar to SFF-8472. So checking existence
* of page 3, will provide the gurantee for existence of alarms
* and thresholds
* If pagging support exists, then supports_alarms is marked as 1
*/
These alarm values are optional. The spec says so. So in order to decide if they are implemented, ethtool looks to see if the thresholds are available. If there are thresholds, it makes sense the alarms are implemented.
Unfortunately, the driver never returns the thresholds. So ethtool has no real choice and won't display the alarms since it cannot determine if they are valid.
In order to get alarms, the driver needs to be extended to return all the pages.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-09-28 1:09 UTC (permalink / raw)
To: Andrew Lunn
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <CAHmME9q7WRGF3TTRhhy0i_EB4ad2DaSD=tnHM92zfV4Cckyw=A@mail.gmail.com>
On Fri, Sep 28, 2018 at 12:37 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Will do. v7 will include the wg_ prefix.
$ nm *.o | while read a b c; do [[ $b == T ]] && echo $c; done | grep -v ^wg_
cleanup_module
init_module
Success.
^ permalink raw reply
* Re: [PATCH net 01/11] netpoll: do not test NAPI_STATE_SCHED in poll_one_napi()
From: Song Liu @ 2018-09-27 18:33 UTC (permalink / raw)
To: Michael Chan
Cc: Eric Dumazet, David Miller, Netdev, aviad.krawczyk@huawei.com,
dougmill@linux.vnet.ibm.com, yisen.zhuang@huawei.com,
mst@redhat.com, jasowang@redhat.com, harish.patil@cavium.com,
Chopra, Manish, netanel@amazon.com,
linux-net-drivers@solarflare.com, tlfalcon@linux.vnet.ibm.com
In-Reply-To: <CACKFLikRw2a+JW1FCdR4o09Oz0Y0Cy3tNXdrA3K=EHNHykk=Ug@mail.gmail.com>
> On Sep 27, 2018, at 11:25 AM, Michael Chan <michael.chan@broadcom.com> wrote:
>
> On Thu, Sep 27, 2018 at 9:32 AM Eric Dumazet <edumazet@google.com> wrote:
>>
>> Since we do no longer require NAPI drivers to provide
>> an ndo_poll_controller(), napi_schedule() has not been done
>> before poll_one_napi() invocation.
>>
>> So testing NAPI_STATE_SCHED is likely to cause early returns.
>>
>> While we are at it, remove outdated comment.
>>
>> Note to future bisections : This change might surface prior
>> bugs in drivers. See commit 73f21c653f93 ("bnxt_en: Fix TX
>> timeout during netpoll.") for one occurrence.
>>
>> Fixes: ac3d9dd034e5 ("netpoll: make ndo_poll_controller() optional")
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Tested-by: Song Liu <songliubraving@fb.com>
>> Cc: Michael Chan <michael.chan@broadcom.com>
>
> Reviewed-and-tested-by: Michael Chan <michael.chan@broadcom.com>
Reviewed-and-tested-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* pull request: bluetooth 2018-09-27
From: Johan Hedberg @ 2018-09-27 18:28 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
Hi Dave,
Here's one more Bluetooth fix for 4.19, fixing the handling of an
attempt to unpair a device while pairing is in progress.
Let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit 3f32d0be6c16b902b687453c962d17eea5b8ea19:
tipc: lock wakeup & inputq at tipc_link_reset() (2018-09-25 20:48:56 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream
for you to fetch changes up to cb28c306b93b71f2741ce1a5a66289db26715f4d:
Bluetooth: SMP: fix crash in unpairing (2018-09-26 12:39:32 +0300)
----------------------------------------------------------------
Matias Karhumaa (1):
Bluetooth: SMP: fix crash in unpairing
net/bluetooth/mgmt.c | 7 ++-----
net/bluetooth/smp.c | 29 +++++++++++++++++++++++++----
net/bluetooth/smp.h | 3 ++-
3 files changed, 29 insertions(+), 10 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH net 01/11] netpoll: do not test NAPI_STATE_SCHED in poll_one_napi()
From: Michael Chan @ 2018-09-27 18:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Netdev, aviad.krawczyk, Song Liu, dougmill,
yisen.zhuang, mst, jasowang, harish.patil, Chopra, Manish,
netanel, linux-net-drivers, tlfalcon
In-Reply-To: <20180927163201.56609-2-edumazet@google.com>
On Thu, Sep 27, 2018 at 9:32 AM Eric Dumazet <edumazet@google.com> wrote:
>
> Since we do no longer require NAPI drivers to provide
> an ndo_poll_controller(), napi_schedule() has not been done
> before poll_one_napi() invocation.
>
> So testing NAPI_STATE_SCHED is likely to cause early returns.
>
> While we are at it, remove outdated comment.
>
> Note to future bisections : This change might surface prior
> bugs in drivers. See commit 73f21c653f93 ("bnxt_en: Fix TX
> timeout during netpoll.") for one occurrence.
>
> Fixes: ac3d9dd034e5 ("netpoll: make ndo_poll_controller() optional")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Song Liu <songliubraving@fb.com>
> Cc: Michael Chan <michael.chan@broadcom.com>
Reviewed-and-tested-by: Michael Chan <michael.chan@broadcom.com>
^ permalink raw reply
* [PATCH net-next] tcp: up initial rmem to 128KB and SYN rwin to around 64KB
From: Yuchung Cheng @ 2018-09-27 18:21 UTC (permalink / raw)
To: davem, edumazet; +Cc: netdev, ncardwell, weiwan, soheil, Yuchung Cheng
Previously TCP initial receive buffer is ~87KB by default and
the initial receive window is ~29KB (20 MSS). This patch changes
the two numbers to 128KB and ~64KB (rounding down to the multiples
of MSS) respectively. The patch also simplifies the calculations s.t.
the two numbers are directly controlled by sysctl tcp_rmem[1]:
1) Initial receiver buffer budget (sk_rcvbuf): while this should
be configured via sysctl tcp_rmem[1], previously tcp_fixup_rcvbuf()
always override and set a larger size when a new connection
establishes.
2) Initial receive window in SYN: previously it is set to 20
packets if MSS <= 1460. The number 20 was based on the initial
congestion window of 10: the receiver needs twice amount to
avoid being limited by the receive window upon out-of-order
delivery in the first window burst. But since this only
applies if the receiving MSS <= 1460, connection using large MTU
(e.g. to utilize receiver zero-copy) may be limited by the
receive window.
With this patch TCP memory configuration is more straight-forward and
more properly sized to modern high-speed networks by default. Several
popular stacks have been announcing 64KB rwin in SYNs as well.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp.c | 4 ++--
net/ipv4/tcp_input.c | 25 ++-----------------------
net/ipv4/tcp_output.c | 25 ++++---------------------
3 files changed, 8 insertions(+), 46 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 69c236943f56..dcf51fbf5ec7 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3896,8 +3896,8 @@ void __init tcp_init(void)
init_net.ipv4.sysctl_tcp_wmem[2] = max(64*1024, max_wshare);
init_net.ipv4.sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;
- init_net.ipv4.sysctl_tcp_rmem[1] = 87380;
- init_net.ipv4.sysctl_tcp_rmem[2] = max(87380, max_rshare);
+ init_net.ipv4.sysctl_tcp_rmem[1] = 131072;
+ init_net.ipv4.sysctl_tcp_rmem[2] = max(131072, max_rshare);
pr_info("Hash tables configured (established %u bind %u)\n",
tcp_hashinfo.ehash_mask + 1, tcp_hashinfo.bhash_size);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index d703a0b3b6a2..7a59f6a96212 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -426,26 +426,7 @@ static void tcp_grow_window(struct sock *sk, const struct sk_buff *skb)
}
}
-/* 3. Tuning rcvbuf, when connection enters established state. */
-static void tcp_fixup_rcvbuf(struct sock *sk)
-{
- u32 mss = tcp_sk(sk)->advmss;
- int rcvmem;
-
- rcvmem = 2 * SKB_TRUESIZE(mss + MAX_TCP_HEADER) *
- tcp_default_init_rwnd(mss);
-
- /* Dynamic Right Sizing (DRS) has 2 to 3 RTT latency
- * Allow enough cushion so that sender is not limited by our window
- */
- if (sock_net(sk)->ipv4.sysctl_tcp_moderate_rcvbuf)
- rcvmem <<= 2;
-
- if (sk->sk_rcvbuf < rcvmem)
- sk->sk_rcvbuf = min(rcvmem, sock_net(sk)->ipv4.sysctl_tcp_rmem[2]);
-}
-
-/* 4. Try to fixup all. It is made immediately after connection enters
+/* 3. Try to fixup all. It is made immediately after connection enters
* established state.
*/
void tcp_init_buffer_space(struct sock *sk)
@@ -454,8 +435,6 @@ void tcp_init_buffer_space(struct sock *sk)
struct tcp_sock *tp = tcp_sk(sk);
int maxwin;
- if (!(sk->sk_userlocks & SOCK_RCVBUF_LOCK))
- tcp_fixup_rcvbuf(sk);
if (!(sk->sk_userlocks & SOCK_SNDBUF_LOCK))
tcp_sndbuf_expand(sk);
@@ -485,7 +464,7 @@ void tcp_init_buffer_space(struct sock *sk)
tp->snd_cwnd_stamp = tcp_jiffies32;
}
-/* 5. Recalculate window clamp after socket hit its memory bounds. */
+/* 4. Recalculate window clamp after socket hit its memory bounds. */
static void tcp_clamp_window(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index fe7855b090e4..059b67af28b1 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -195,21 +195,6 @@ static inline void tcp_event_ack_sent(struct sock *sk, unsigned int pkts,
inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK);
}
-
-u32 tcp_default_init_rwnd(u32 mss)
-{
- /* Initial receive window should be twice of TCP_INIT_CWND to
- * enable proper sending of new unsent data during fast recovery
- * (RFC 3517, Section 4, NextSeg() rule (2)). Further place a
- * limit when mss is larger than 1460.
- */
- u32 init_rwnd = TCP_INIT_CWND * 2;
-
- if (mss > 1460)
- init_rwnd = max((1460 * init_rwnd) / mss, 2U);
- return init_rwnd;
-}
-
/* Determine a window scaling and initial window to offer.
* Based on the assumption that the given amount of space
* will be offered. Store the results in the tp structure.
@@ -244,7 +229,10 @@ void tcp_select_initial_window(const struct sock *sk, int __space, __u32 mss,
if (sock_net(sk)->ipv4.sysctl_tcp_workaround_signed_windows)
(*rcv_wnd) = min(space, MAX_TCP_WINDOW);
else
- (*rcv_wnd) = space;
+ (*rcv_wnd) = min_t(u32, space, U16_MAX);
+
+ if (init_rcv_wnd)
+ *rcv_wnd = min(*rcv_wnd, init_rcv_wnd * mss);
(*rcv_wscale) = 0;
if (wscale_ok) {
@@ -257,11 +245,6 @@ void tcp_select_initial_window(const struct sock *sk, int __space, __u32 mss,
(*rcv_wscale)++;
}
}
-
- if (!init_rcv_wnd) /* Use default unless specified otherwise */
- init_rcv_wnd = tcp_default_init_rwnd(mss);
- *rcv_wnd = min(*rcv_wnd, init_rcv_wnd * mss);
-
/* Set the clamp no higher than max representable value */
(*window_clamp) = min_t(__u32, U16_MAX << (*rcv_wscale), *window_clamp);
}
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* [PATCH net-next 6/7] selinux: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
security/selinux/nlmsgtab.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
index 74b951f55608..3c45f50e987d 100644
--- a/security/selinux/nlmsgtab.c
+++ b/security/selinux/nlmsgtab.c
@@ -80,6 +80,7 @@ static const struct nlmsg_perm nlmsg_route_perms[] =
{ RTM_NEWSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ },
{ RTM_GETSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ },
{ RTM_NEWCACHEREPORT, NETLINK_ROUTE_SOCKET__NLMSG_READ },
+ { RTM_GETADDR2, NETLINK_ROUTE_SOCKET__NLMSG_READ },
};
static const struct nlmsg_perm nlmsg_tcpdiag_perms[] =
@@ -159,7 +160,7 @@ int selinux_nlmsg_lookup(u16 sclass, u16 nlmsg_type, u32 *perm)
switch (sclass) {
case SECCLASS_NETLINK_ROUTE_SOCKET:
/* RTM_MAX always point to RTM_SETxxxx, ie RTM_NEWxxx + 3 */
- BUILD_BUG_ON(RTM_MAX != (RTM_NEWCHAIN + 3));
+ BUILD_BUG_ON(RTM_MAX != (RTM_GETADDR2 + 1));
err = nlmsg_perm(nlmsg_type, perm, nlmsg_route_perms,
sizeof(nlmsg_route_perms));
break;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 4/7] decnet: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/decnet/dn_dev.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c
index d0b3e69c6b39..8da6ca154c08 100644
--- a/net/decnet/dn_dev.c
+++ b/net/decnet/dn_dev.c
@@ -738,10 +738,12 @@ static void dn_ifaddr_notify(int event, struct dn_ifaddr *ifa)
rtnl_set_sk_err(&init_net, RTNLGRP_DECnet_IFADDR, err);
}
-static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
+static int dn_nl_dump_ifaddr_common(struct sk_buff *skb,
+ struct netlink_callback *cb, int rtm_type)
{
struct net *net = sock_net(skb->sk);
- int idx, dn_idx = 0, skip_ndevs, skip_naddr;
+ int err, idx, dn_idx = 0, skip_ndevs, skip_naddr;
+ struct nlattr *tb[IFA_MAX+1];
struct net_device *dev;
struct dn_dev *dn_db;
struct dn_ifaddr *ifa;
@@ -749,6 +751,13 @@ static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
if (!net_eq(net, &init_net))
return 0;
+ if (rtm_type == RTM_GETADDR2) {
+ err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
+ dn_ifa_policy, NULL);
+ if (err < 0)
+ return err;
+ }
+
skip_ndevs = cb->args[0];
skip_naddr = cb->args[1];
@@ -787,6 +796,16 @@ static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
+static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return dn_nl_dump_ifaddr_common(skb, cb, RTM_GETADDR);
+}
+
+static int dn_nl_dump_ifaddr2(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return dn_nl_dump_ifaddr_common(skb, cb, RTM_GETADDR2);
+}
+
static int dn_dev_get_first(struct net_device *dev, __le16 *addr)
{
struct dn_dev *dn_db;
@@ -1410,6 +1429,8 @@ void __init dn_dev_init(void)
dn_nl_deladdr, NULL, 0);
rtnl_register_module(THIS_MODULE, PF_DECnet, RTM_GETADDR,
NULL, dn_nl_dump_ifaddr, 0);
+ rtnl_register_module(THIS_MODULE, PF_DECnet, RTM_GETADDR2,
+ NULL, dn_nl_dump_ifaddr2, 0);
proc_create_seq("decnet_dev", 0444, init_net.proc_net, &dn_dev_seq_ops);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 3/7] ipv6: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/ipv6/addrconf.c | 30 ++++++++++++++++++++++++------
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index a9a317322388..6e76e5cc76c4 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5003,7 +5003,7 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
}
static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
- enum addr_type_t type)
+ enum addr_type_t type, int rtm_version)
{
struct net *net = sock_net(skb->sk);
struct nlattr *tb[IFA_MAX+1];
@@ -5020,8 +5020,14 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
s_idx = idx = cb->args[1];
s_ip_idx = ip_idx = cb->args[2];
- if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
- ifa_ipv6_policy, NULL) >= 0) {
+ if (rtm_version == RTM_GETADDR2) {
+ int err;
+
+ err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb,
+ IFA_MAX, ifa_ipv6_policy, NULL);
+ if (err < 0)
+ return err;
+
if (tb[IFA_TARGET_NETNSID]) {
netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]);
@@ -5068,14 +5074,21 @@ static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
{
enum addr_type_t type = UNICAST_ADDR;
- return inet6_dump_addr(skb, cb, type);
+ return inet6_dump_addr(skb, cb, type, RTM_GETADDR);
+}
+
+static int inet6_dump_ifaddr2(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ enum addr_type_t type = UNICAST_ADDR;
+
+ return inet6_dump_addr(skb, cb, type, RTM_GETADDR2);
}
static int inet6_dump_ifmcaddr(struct sk_buff *skb, struct netlink_callback *cb)
{
enum addr_type_t type = MULTICAST_ADDR;
- return inet6_dump_addr(skb, cb, type);
+ return inet6_dump_addr(skb, cb, type, RTM_GETMULTICAST);
}
@@ -5083,7 +5096,7 @@ static int inet6_dump_ifacaddr(struct sk_buff *skb, struct netlink_callback *cb)
{
enum addr_type_t type = ANYCAST_ADDR;
- return inet6_dump_addr(skb, cb, type);
+ return inet6_dump_addr(skb, cb, type, RTM_GETANYCAST);
}
static int inet6_rtm_getaddr(struct sk_buff *in_skb, struct nlmsghdr *nlh,
@@ -6833,6 +6846,11 @@ int __init addrconf_init(void)
RTNL_FLAG_DOIT_UNLOCKED);
if (err < 0)
goto errout;
+ err = rtnl_register_module(THIS_MODULE, PF_INET6, RTM_GETADDR2,
+ inet6_rtm_getaddr, inet6_dump_ifaddr2,
+ RTNL_FLAG_DOIT_UNLOCKED);
+ if (err < 0)
+ goto errout;
err = rtnl_register_module(THIS_MODULE, PF_INET6, RTM_GETMULTICAST,
NULL, inet6_dump_ifmcaddr, 0);
if (err < 0)
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 1/7] rtnetlink: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
include/uapi/linux/rtnetlink.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 46399367627f..e167f90c3d7a 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -157,6 +157,9 @@ enum {
RTM_GETCHAIN,
#define RTM_GETCHAIN RTM_GETCHAIN
+ RTM_GETADDR2 = 106,
+#define RTM_GETADDR2 RTM_GETADDR2
+
__RTM_MAX,
#define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1)
};
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 0/7] rtnetlink: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Christian Brauner (7):
rtnetlink: add RTM_GETADDR2
ipv4: add RTM_GETADDR2
ipv6: add RTM_GETADDR2
decnet: add RTM_GETADDR2
phonet: add RTM_GETADDR2
selinux: add RTM_GETADDR2
rtnetlink: enable RTM_GETADDR2
include/uapi/linux/rtnetlink.h | 3 +++
net/core/rtnetlink.c | 1 +
net/decnet/dn_dev.c | 25 +++++++++++++++++++++++--
net/ipv4/devinet.c | 24 +++++++++++++++++++++---
net/ipv6/addrconf.c | 30 ++++++++++++++++++++++++------
net/phonet/pn_netlink.c | 25 +++++++++++++++++++++++--
security/selinux/nlmsgtab.c | 3 ++-
7 files changed, 97 insertions(+), 14 deletions(-)
--
2.17.1
^ permalink raw reply
* RE: [PATCH] net/ncsi: Add NCSI OEM command for FB Tiogapass
From: Justin.Lee1 @ 2018-09-27 17:46 UTC (permalink / raw)
To: joel
Cc: amithash, vijaykhemka, sam, linux-aspeed, openbmc, sdasari,
netdev, christian
In-Reply-To: <CACPK8XfuXa19dGRqL+Ycdgh1LKmoQNuqGvtrrOgeNyvTZR01kQ@mail.gmail.com>
> Thanks for the overview. We look forward to your patches; please
> include the same cc list as this series.
> I think it makes sense to have some OEM NCSI handing purely in the
> kenrel. This would allow eg. the MAC address of an interface to be
> correct at boot, without requiring userspace to come up first.
> I have also heard stories of temperature sensors over NCSI. Those
> would make sense to be hwmon drivers, which again would mean handling
> them in the kernel.
> Justin, Vijay, can you please list the known NCSI OEM
> commands/extensions that we plan on implementing?
In our implementation, All OEM commands are transparent to Kernel.
We don't plan to add any specific handler in the Kernel.
Thanks,
Justin
^ permalink raw reply
* Re: [PATCH net V2] vhost-vsock: fix use after free
From: Michael S. Tsirkin @ 2018-09-27 23:50 UTC (permalink / raw)
To: Jason Wang
Cc: stefanha, kvm, virtualization, netdev, linux-kernel,
sergei.shtylyov
In-Reply-To: <588ed28b-7e4b-9dc8-92ce-d75692836c9e@redhat.com>
On Fri, Sep 28, 2018 at 07:37:37AM +0800, Jason Wang wrote:
>
>
> On 2018年09月28日 01:04, Michael S. Tsirkin wrote:
> > On Thu, Sep 27, 2018 at 08:22:04PM +0800, Jason Wang wrote:
> > > The access of vsock is not protected by vhost_vsock_lock. This may
> > > lead to use after free since vhost_vsock_dev_release() may free the
> > > pointer at the same time.
> > >
> > > Fix this by holding the lock during the access.
> > >
> > > Reported-by:syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
> > > Fixes: 16320f363ae1 ("vhost-vsock: add pkt cancel capability")
> > > Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
> > > Cc: Stefan Hajnoczi<stefanha@redhat.com>
> > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > Wow is that really the best we can do?
>
> For net/stable, probably yes.
>
> > A global lock on a data path
> > operation?
>
> It's already there,
&vhost_vsock_lock? were is it takes on data path?
> and the patch only increase the critical section.
>
> > Granted use after free is nasty but Stefan said he sees
> > a way to fix it using a per socket refcount. He's on vacation
> > until Oct 4 though ...
> >
>
> Stefan has acked the pacth, so I think it's ok? We can do optimization for
> -next on top.
>
> Thanks
Well on high SMP serializing can drop performance as much as x100 so I'm
not sure it's appropriate - seems to fix a bug but can introduce a
regression. Let's see how does a proper fix look first?
--
MST
^ permalink raw reply
* Re: [PATCH net V2] vhost-vsock: fix use after free
From: Jason Wang @ 2018-09-27 23:37 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: stefanha, kvm, virtualization, netdev, linux-kernel,
sergei.shtylyov
In-Reply-To: <20180927123539-mutt-send-email-mst@kernel.org>
On 2018年09月28日 01:04, Michael S. Tsirkin wrote:
> On Thu, Sep 27, 2018 at 08:22:04PM +0800, Jason Wang wrote:
>> The access of vsock is not protected by vhost_vsock_lock. This may
>> lead to use after free since vhost_vsock_dev_release() may free the
>> pointer at the same time.
>>
>> Fix this by holding the lock during the access.
>>
>> Reported-by:syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
>> Fixes: 16320f363ae1 ("vhost-vsock: add pkt cancel capability")
>> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
>> Cc: Stefan Hajnoczi<stefanha@redhat.com>
>> Signed-off-by: Jason Wang<jasowang@redhat.com>
> Wow is that really the best we can do?
For net/stable, probably yes.
> A global lock on a data path
> operation?
It's already there, and the patch only increase the critical section.
> Granted use after free is nasty but Stefan said he sees
> a way to fix it using a per socket refcount. He's on vacation
> until Oct 4 though ...
>
Stefan has acked the pacth, so I think it's ok? We can do optimization
for -next on top.
Thanks
^ permalink raw reply
* [PATCH] qed: fix spelling mistake "b_cb_registred" -> "b_cb_registered"
From: Colin King @ 2018-09-27 17:04 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake struct field name, rename it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 12 ++++++------
drivers/net/ethernet/qlogic/qed/qed_ll2.h | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.c b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
index 14ac9cab2653..da13117a604a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
@@ -63,8 +63,8 @@
#include "qed_sp.h"
#include "qed_rdma.h"
-#define QED_LL2_RX_REGISTERED(ll2) ((ll2)->rx_queue.b_cb_registred)
-#define QED_LL2_TX_REGISTERED(ll2) ((ll2)->tx_queue.b_cb_registred)
+#define QED_LL2_RX_REGISTERED(ll2) ((ll2)->rx_queue.b_cb_registered)
+#define QED_LL2_TX_REGISTERED(ll2) ((ll2)->tx_queue.b_cb_registered)
#define QED_LL2_TX_SIZE (256)
#define QED_LL2_RX_SIZE (4096)
@@ -1404,7 +1404,7 @@ int qed_ll2_acquire_connection(void *cxt, struct qed_ll2_acquire_data *data)
&p_hwfn->p_ll2_info[i],
&p_ll2_info->rx_queue.rx_sb_index,
&p_ll2_info->rx_queue.p_fw_cons);
- p_ll2_info->rx_queue.b_cb_registred = true;
+ p_ll2_info->rx_queue.b_cb_registered = true;
}
if (data->input.tx_num_desc) {
@@ -1413,7 +1413,7 @@ int qed_ll2_acquire_connection(void *cxt, struct qed_ll2_acquire_data *data)
&p_hwfn->p_ll2_info[i],
&p_ll2_info->tx_queue.tx_sb_index,
&p_ll2_info->tx_queue.p_fw_cons);
- p_ll2_info->tx_queue.b_cb_registred = true;
+ p_ll2_info->tx_queue.b_cb_registered = true;
}
*data->p_connection_handle = i;
@@ -1929,7 +1929,7 @@ int qed_ll2_terminate_connection(void *cxt, u8 connection_handle)
/* Stop Tx & Rx of connection, if needed */
if (QED_LL2_TX_REGISTERED(p_ll2_conn)) {
- p_ll2_conn->tx_queue.b_cb_registred = false;
+ p_ll2_conn->tx_queue.b_cb_registered = false;
smp_wmb(); /* Make sure this is seen by ll2_lb_rxq_completion */
rc = qed_sp_ll2_tx_queue_stop(p_hwfn, p_ll2_conn);
if (rc)
@@ -1940,7 +1940,7 @@ int qed_ll2_terminate_connection(void *cxt, u8 connection_handle)
}
if (QED_LL2_RX_REGISTERED(p_ll2_conn)) {
- p_ll2_conn->rx_queue.b_cb_registred = false;
+ p_ll2_conn->rx_queue.b_cb_registered = false;
smp_wmb(); /* Make sure this is seen by ll2_lb_rxq_completion */
rc = qed_sp_ll2_rx_queue_stop(p_hwfn, p_ll2_conn);
if (rc)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.h b/drivers/net/ethernet/qlogic/qed/qed_ll2.h
index f65817012e97..1a5c1ae01474 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.h
@@ -79,7 +79,7 @@ struct qed_ll2_rx_queue {
struct qed_chain rxq_chain;
struct qed_chain rcq_chain;
u8 rx_sb_index;
- bool b_cb_registred;
+ bool b_cb_registered;
__le16 *p_fw_cons;
struct list_head active_descq;
struct list_head free_descq;
@@ -93,7 +93,7 @@ struct qed_ll2_tx_queue {
spinlock_t lock;
struct qed_chain txq_chain;
u8 tx_sb_index;
- bool b_cb_registred;
+ bool b_cb_registered;
__le16 *p_fw_cons;
struct list_head active_descq;
struct list_head free_descq;
--
2.17.1
^ permalink raw reply related
* Re: bpf: Massive skbuff_head_cache memory leak?
From: Dmitry Vyukov @ 2018-09-27 16:53 UTC (permalink / raw)
To: Eric Dumazet, Tetsuo Handa
Cc: Daniel Borkmann, Alexei Starovoitov, Network Development,
David S. Miller, Andrew Morton, Michal Hocko, John Johansen,
syzkaller
In-Reply-To: <CACT4Y+Zw9y+EFDkZTWKKynPg-3c4_iUHaptCn16t9pBQx9d6bQ@mail.gmail.com>
On Thu, Sep 27, 2018 at 6:47 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Thu, Sep 27, 2018 at 12:27 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Thu, Sep 27, 2018 at 1:35 AM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 09/26/2018 02:22 PM, Daniel Borkmann wrote:
>>>> On 09/26/2018 11:09 PM, Tetsuo Handa wrote:
>>>>> Hello, Alexei and Daniel.
>>>>>
>>>>> Can you show us how to run testcases you are testing?
>>>>
>>>> Sorry for the delay; currently quite backlogged but will definitely take a look
>>>> at these reports. Regarding your question: majority of test cases are in the
>>>> kernel tree under selftests, see tools/testing/selftests/bpf/ .
>>>>
>>>
>>> Its unlikely to be apparmor. I went through the reports and saw nothing that
>>> would indicate apparmor involvement, but the primary reason is what is being tested
>>> in upstream apparmor atm.
>>>
>>> The current upstream code does nothing directly with skbuffs. Its
>>> possible that the audit code paths (kernel audit does grab skbuffs)
>>> could, but there are only a couple cases that would be triggered in
>>> the current fuzzing so this seems to be an unlikely source for such a
>>> large leak.
>>
>>
>> Ack. There is no direct evidence against apparmor, I am just trying to
>> get at least some hooks re the root cause.
>>
>> From all the weak indirect evidence, I leaning towards skb allocation
>> in an infinite loop (or a timer with infinite rate).
>>
>>>>> On 2018/09/22 22:25, Tetsuo Handa wrote:
>>>>>> Hello.
>>>>>>
>>>>>> syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git / net-next.git trees.
>>>>>>
>>>>>> INFO: rcu detected stall in br_multicast_port_group_expired (2)
>>>>>> https://syzkaller.appspot.com/bug?id=15c7ad8cf35a07059e8a697a22527e11d294bc94
>>>>>>
>>>>>> INFO: rcu detected stall in tun_chr_close
>>>>>> https://syzkaller.appspot.com/bug?id=6c50618bde03e5a2eefdd0269cf9739c5ebb8270
>>>>>>
>>>>>> INFO: rcu detected stall in discover_timer
>>>>>> https://syzkaller.appspot.com/bug?id=55da031ddb910e58ab9c6853a5784efd94f03b54
>>>>>>
>>>>>> INFO: rcu detected stall in ret_from_fork (2)
>>>>>> https://syzkaller.appspot.com/bug?id=c83129a6683b44b39f5b8864a1325893c9218363
>>>>>>
>>>>>> INFO: rcu detected stall in addrconf_rs_timer
>>>>>> https://syzkaller.appspot.com/bug?id=21c029af65f81488edbc07a10ed20792444711b6
>>>>>>
>>>>>> INFO: rcu detected stall in kthread (2)
>>>>>> https://syzkaller.appspot.com/bug?id=6accd1ed11c31110fed1982f6ad38cc9676477d2
>>>>>>
>>>>>> INFO: rcu detected stall in ext4_filemap_fault
>>>>>> https://syzkaller.appspot.com/bug?id=817e38d20e9ee53390ac361bf0fd2007eaf188af
>>>>>>
>>>>>> INFO: rcu detected stall in run_timer_softirq (2)
>>>>>> https://syzkaller.appspot.com/bug?id=f5a230a3ff7822f8d39fddf8485931bd06ae47fe
>>>>>>
>>>>>> INFO: rcu detected stall in bpf_prog_ADDR
>>>>>> https://syzkaller.appspot.com/bug?id=fb4911fd0e861171cc55124e209f810a0dd68744
>>>>>>
>>>>>> INFO: rcu detected stall in __run_timers (2)
>>>>>> https://syzkaller.appspot.com/bug?id=65416569ddc8d2feb8f19066aa761f5a47f7451a
>>>>>>
>>>>>> The cause of lockup seems to be flood of printk() messages from memory allocation
>>>>>> failures, and one of out_of_memory() messages indicates that skbuff_head_cache
>>>>>> usage is huge enough to suspect in-kernel memory leaks.
>>>>>>
>>>>>> [ 1554.547011] skbuff_head_cache 1847887KB 1847887KB
>>>>>>
>>>>>> Unfortunately, we cannot find from logs what syzbot is trying to do
>>>>>> because constant printk() messages is flooding away syzkaller messages.
>>>>>> Can you try running your testcases with kmemleak enabled?
>>>>>>
>>>>>
>>>>> On 2018/09/27 2:35, Dmitry Vyukov wrote:
>>>>>> I also started suspecting Apparmor. We switched to Apparmor on Aug 30:
>>>>>> https://groups.google.com/d/msg/syzkaller-bugs/o73lO4KGh0w/j9pcH2tSBAAJ
>>>>>> Now the instances that use SELinux and Smack explicitly contain that
>>>>>> in the name, but the rest are Apparmor.
>>>>>> Aug 30 roughly matches these assorted "task hung" reports. Perhaps
>>>>>> some Apparmor hook leaks a reference to skbs?
>>>>>
>>>>> Maybe. They have CONFIG_DEFAULT_SECURITY="apparmor". But I'm wondering why
>>>>> this problem is not occurring on linux-next.git when this problem is occurring
>>>>> on bpf.git / bpf-next.git / net.git / net-next.git trees. Is syzbot running
>>>>> different testcases depending on which git tree is targeted?
>>>>>
>>> this is another reason that it is doubtful that its apparmor.
>
> On Thu, Sep 27, 2018 at 2:52 PM, edumazet
>> Have you tried kmemleak perhaps, it might give us a clue, but it seems
>> obvious the leak would be in TX path.
>
> So, I've tried. Now what? :)
>
> I've uploaded all reports to:
> https://drive.google.com/file/d/107LUW0zmYbXmxfQCWoLpeenxXJsXIkxj/view?usp=sharing
> This is on net tree d4ce58082f206bf6e7d697380c7bc5480a8b0264
>
> memory leak in __lookup_hash 33 Sep 27 2018 16:35:50
> memory leak in new_inode_pseudo 43 Sep 27 2018 16:41:14
> memory leak in path_openat 1 Sep 27 2018 16:12:53
> memory leak in rhashtable_init 1 Sep 27 2018 16:41:41
> memory leak in shmem_symlink 4 Sep 27 2018 16:34:34
> memory leak in __anon_vma_prepare 1 Sep 27 2018 17:30:02
> memory leak in __do_execve_file 4 Sep 27 2018 18:14:10
> memory leak in __do_sys_perf_event_open 2 Sep 27 2018 17:40:05
> memory leak in __es_insert_extent 3 Sep 27 2018 17:24:52
> memory leak in __getblk_gfp 3 Sep 27 2018 18:19:30
> memory leak in __handle_mm_fault 1 Sep 27 2018 18:11:31
> memory leak in __hw_addr_create_ex 2 Sep 27 2018 18:10:56
> memory leak in __ip_mc_inc_group 13 Sep 27 2018 18:24:31
> memory leak in __khugepaged_enter 1 Sep 27 2018 15:40:25
> memory leak in __list_lru_init 27 Sep 27 2018 17:30:48
> memory leak in __neigh_create 12 Sep 27 2018 17:40:28
> memory leak in __netlink_create 1 Sep 27 2018 15:40:23
> memory leak in __register_sysctl_table 1 Sep 27 2018 17:36:57
> memory leak in __send_signal 1 Sep 27 2018 18:30:48
> memory leak in __sys_socket 7 Sep 27 2018 15:43:20
> memory leak in anon_inode_getfile 4 Sep 27 2018 18:17:29
> memory leak in bpf_prog_store_orig_filter 1 Sep 27 2018 17:59:14
> memory leak in br_multicast_new_group 2 Sep 27 2018 18:16:42
> memory leak in br_multicast_new_port_group 3 Sep 27 2018 18:17:39
> memory leak in build_sched_domains 2 Sep 27 2018 17:28:55
> memory leak in clone_mnt 2 Sep 27 2018 18:18:48
> memory leak in compute_effective_progs 1 Sep 27 2018 18:35:15
> memory leak in create_empty_buffers 1 Sep 27 2018 17:35:42
> memory leak in create_filter_start 2 Sep 27 2018 18:16:00
> memory leak in create_pipe_files 3 Sep 27 2018 18:21:47
> memory leak in do_ip6t_set_ctl 1 Sep 27 2018 15:40:21
> memory leak in do_ipt_set_ctl 1 Sep 27 2018 17:37:35
> memory leak in do_signalfd4 1 Sep 27 2018 18:00:45
> memory leak in do_syslog 2 Sep 27 2018 18:06:22
> memory leak in ep_insert 11 Sep 27 2018 17:39:14
> memory leak in ep_ptable_queue_proc 3 Sep 27 2018 17:37:17
> memory leak in ext4_mb_new_group_pa 1 Sep 27 2018 17:36:04
> memory leak in ext4_mb_new_inode_pa 3 Sep 27 2018 17:39:19
> memory leak in fdb_create 13 Sep 27 2018 18:24:03
> memory leak in fib6_add_1 11 Sep 27 2018 18:19:53
> memory leak in fib_table_insert 1 Sep 27 2018 17:36:49
> memory leak in find_get_context 1 Sep 27 2018 15:42:00
> memory leak in fsnotify_add_mark_locked 11 Sep 27 2018 17:31:41
> memory leak in idr_get_free 2 Sep 27 2018 18:17:34
> memory leak in iget_locked 1 Sep 27 2018 17:52:59
> memory leak in inet_frag_find 3 Sep 27 2018 18:23:53
> memory leak in inotify_update_watch 25 Sep 27 2018 17:30:59
> memory leak in ioc_create_icq 1 Sep 27 2018 15:42:40
> memory leak in ip6_pol_route 4 Sep 27 2018 18:24:59
> memory leak in ip6_route_info_create 1 Sep 27 2018 17:38:09
> memory leak in ip6t_register_table 1 Sep 27 2018 17:35:39
> memory leak in ip_route_output_key_hash_rcu 4 Sep 27 2018 18:21:21
> memory leak in ipt_register_table 3 Sep 27 2018 17:39:58
> memory leak in ipv6_add_addr 1 Sep 27 2018 17:38:49
> memory leak in load_elf_binary 1 Sep 27 2018 18:09:44
> memory leak in map_create 9 Sep 27 2018 18:25:10
> memory leak in memcg_update_all_list_lrus 1 Sep 27 2018 15:39:36
> memory leak in ndisc_send_rs 1 Sep 27 2018 17:50:03
> memory leak in neigh_table_init 6 Sep 27 2018 17:23:41
> memory leak in nf_hook_entries_grow 5 Sep 27 2018 15:43:41
> memory leak in packet_sendmsg 1 Sep 27 2018 18:08:43
> memory leak in pcpu_create_chunk 1 Sep 27 2018 17:48:41
> memory leak in prepare_creds 18 Sep 27 2018 17:29:10
> memory leak in prepare_kernel_cred 15 Sep 27 2018 18:23:42
> memory leak in process_preds 2 Sep 27 2018 18:11:01
> memory leak in rht_deferred_worker 9 Sep 27 2018 18:24:29
> memory leak in sched_init_domains 2 Sep 27 2018 18:12:42
> memory leak in sctp_addr_wq_mgmt 1 Sep 27 2018 17:46:20
> memory leak in sget 5 Sep 27 2018 18:03:40
> memory leak in shmem_symlink 30 Sep 27 2018 17:32:09
> memory leak in skb_clone 3 Sep 27 2018 18:13:22
> memory leak in submit_bh_wbc 1 Sep 27 2018 17:49:06
> memory leak in tracepoint_probe_register_prio 1 Sep 27 2018 17:39:13
> memory leak in xt_replace_table 4 Sep 27 2018 15:43:19
> memory leak in __delayacct_tsk_init 2 Sep 27 2018 17:02:53
> memory leak in disk_expand_part_tbl 1 Sep 27 2018 16:59:05
> memory leak in do_ip6t_set_ctl 14 Sep 27 2018 15:46:37
> memory leak in neigh_table_init 4 Sep 27 2018 17:10:29
> memory leak in do_check 1 Sep 27 2018 18:38:13
I see at least 3 bridge-related:
memory leak in skb_clone
memory leak in br_multicast_new_group
memory leak in br_multicast_new_port_group
^ permalink raw reply
* Re: [PATCH] netfilter: check if the socket netns is correct.
From: Guenter Roeck @ 2018-09-27 23:08 UTC (permalink / raw)
To: Flavio Leitner
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20180927225824.GT2702@plex.lan>
On Thu, Sep 27, 2018 at 07:58:24PM -0300, Flavio Leitner wrote:
> On Thu, Sep 27, 2018 at 01:46:29PM -0700, Guenter Roeck wrote:
> > Hi Flavio,
> >
> > On Wed, Jun 27, 2018 at 10:34:25AM -0300, Flavio Leitner wrote:
> > > Netfilter assumes that if the socket is present in the skb, then
> > > it can be used because that reference is cleaned up while the skb
> > > is crossing netns.
> > >
> > > We want to change that to preserve the socket reference in a future
> > > patch, so this is a preparation updating netfilter to check if the
> > > socket netns matches before use it.
> > >
> > > Signed-off-by: Flavio Leitner <fbl@redhat.com>
> > > Acked-by: Florian Westphal <fw@strlen.de>
> > > Signed-off-by: David S. Miller <davem@davemloft.net>
> > > ---
> > ...
> > > --- a/net/netfilter/xt_socket.c
> > > +++ b/net/netfilter/xt_socket.c
> > > @@ -56,8 +56,12 @@ socket_match(const struct sk_buff *skb, struct xt_action_param *par,
> > > struct sk_buff *pskb = (struct sk_buff *)skb;
> > > struct sock *sk = skb->sk;
> > >
> > > + if (!net_eq(xt_net(par), sock_net(sk)))
> > > + sk = NULL;
> > > +
> >
> > I am having trouble with this code. With CONFIG_NET_NS enabled, it crashes
> > for me in read_pnet() because sk is NULL.
> >
> > > if (!sk)
> > > sk = nf_sk_lookup_slow_v4(xt_net(par), skb, xt_in(par));
> >
> > The old code seems to suggest that sk == NULL was possible.
> >
> > I see the problem with the Chrome OS kernel rebased to v4.19-rc5, so I
> > can not guarantee that this really an upstream problem. The change seems
> > odd, though. Are you sure that it is not (or, rather, no longer) necessary
> > to check if sk == NULL before dereferencing it in sock_net() ?
>
> Oops, it is necessary but if it's not and the netns doesn't match, we need
> do the lookup. So, could you check if this fixes the problem for you?
>
> From a5f927e7f1368d753f87cb978d630d786d5adb62 Mon Sep 17 00:00:00 2001
> From: Flavio Leitner <fbl@redhat.com>
> Date: Thu, 27 Sep 2018 19:36:28 -0300
> Subject: [PATCH] xt_socket: check sk before checking for netns.
>
> Only check for the network namespace if the socket is available.
>
> Fixes: f564650106a6 ("netfilter: check if the socket netns is correct.")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
This fixes the problem for me.
Tested-by: Guenter Roeck <linux@roeck-us.net>
Thanks,
Guenter
> ---
> net/netfilter/xt_socket.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
> index 0472f3472842..ada144e5645b 100644
> --- a/net/netfilter/xt_socket.c
> +++ b/net/netfilter/xt_socket.c
> @@ -56,7 +56,7 @@ socket_match(const struct sk_buff *skb, struct xt_action_param *par,
> struct sk_buff *pskb = (struct sk_buff *)skb;
> struct sock *sk = skb->sk;
>
> - if (!net_eq(xt_net(par), sock_net(sk)))
> + if (sk && !net_eq(xt_net(par), sock_net(sk)))
> sk = NULL;
>
> if (!sk)
> @@ -117,7 +117,7 @@ socket_mt6_v1_v2_v3(const struct sk_buff *skb, struct xt_action_param *par)
> struct sk_buff *pskb = (struct sk_buff *)skb;
> struct sock *sk = skb->sk;
>
> - if (!net_eq(xt_net(par), sock_net(sk)))
> + if (sk && !net_eq(xt_net(par), sock_net(sk)))
> sk = NULL;
>
> if (!sk)
> --
> 2.14.4
>
^ permalink raw reply
* Re: bpf: Massive skbuff_head_cache memory leak?
From: Dmitry Vyukov @ 2018-09-27 16:47 UTC (permalink / raw)
To: Eric Dumazet, Tetsuo Handa
Cc: Daniel Borkmann, Alexei Starovoitov, Network Development,
David S. Miller, Andrew Morton, Michal Hocko, John Johansen,
syzkaller
In-Reply-To: <CACT4Y+Y8==5_89uoTk1Ryqhj+pCxbv+KsF9oDUvEp=ch3VHdeg@mail.gmail.com>
On Thu, Sep 27, 2018 at 12:27 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Thu, Sep 27, 2018 at 1:35 AM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 09/26/2018 02:22 PM, Daniel Borkmann wrote:
>>> On 09/26/2018 11:09 PM, Tetsuo Handa wrote:
>>>> Hello, Alexei and Daniel.
>>>>
>>>> Can you show us how to run testcases you are testing?
>>>
>>> Sorry for the delay; currently quite backlogged but will definitely take a look
>>> at these reports. Regarding your question: majority of test cases are in the
>>> kernel tree under selftests, see tools/testing/selftests/bpf/ .
>>>
>>
>> Its unlikely to be apparmor. I went through the reports and saw nothing that
>> would indicate apparmor involvement, but the primary reason is what is being tested
>> in upstream apparmor atm.
>>
>> The current upstream code does nothing directly with skbuffs. Its
>> possible that the audit code paths (kernel audit does grab skbuffs)
>> could, but there are only a couple cases that would be triggered in
>> the current fuzzing so this seems to be an unlikely source for such a
>> large leak.
>
>
> Ack. There is no direct evidence against apparmor, I am just trying to
> get at least some hooks re the root cause.
>
> From all the weak indirect evidence, I leaning towards skb allocation
> in an infinite loop (or a timer with infinite rate).
>
>>>> On 2018/09/22 22:25, Tetsuo Handa wrote:
>>>>> Hello.
>>>>>
>>>>> syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git / net-next.git trees.
>>>>>
>>>>> INFO: rcu detected stall in br_multicast_port_group_expired (2)
>>>>> https://syzkaller.appspot.com/bug?id=15c7ad8cf35a07059e8a697a22527e11d294bc94
>>>>>
>>>>> INFO: rcu detected stall in tun_chr_close
>>>>> https://syzkaller.appspot.com/bug?id=6c50618bde03e5a2eefdd0269cf9739c5ebb8270
>>>>>
>>>>> INFO: rcu detected stall in discover_timer
>>>>> https://syzkaller.appspot.com/bug?id=55da031ddb910e58ab9c6853a5784efd94f03b54
>>>>>
>>>>> INFO: rcu detected stall in ret_from_fork (2)
>>>>> https://syzkaller.appspot.com/bug?id=c83129a6683b44b39f5b8864a1325893c9218363
>>>>>
>>>>> INFO: rcu detected stall in addrconf_rs_timer
>>>>> https://syzkaller.appspot.com/bug?id=21c029af65f81488edbc07a10ed20792444711b6
>>>>>
>>>>> INFO: rcu detected stall in kthread (2)
>>>>> https://syzkaller.appspot.com/bug?id=6accd1ed11c31110fed1982f6ad38cc9676477d2
>>>>>
>>>>> INFO: rcu detected stall in ext4_filemap_fault
>>>>> https://syzkaller.appspot.com/bug?id=817e38d20e9ee53390ac361bf0fd2007eaf188af
>>>>>
>>>>> INFO: rcu detected stall in run_timer_softirq (2)
>>>>> https://syzkaller.appspot.com/bug?id=f5a230a3ff7822f8d39fddf8485931bd06ae47fe
>>>>>
>>>>> INFO: rcu detected stall in bpf_prog_ADDR
>>>>> https://syzkaller.appspot.com/bug?id=fb4911fd0e861171cc55124e209f810a0dd68744
>>>>>
>>>>> INFO: rcu detected stall in __run_timers (2)
>>>>> https://syzkaller.appspot.com/bug?id=65416569ddc8d2feb8f19066aa761f5a47f7451a
>>>>>
>>>>> The cause of lockup seems to be flood of printk() messages from memory allocation
>>>>> failures, and one of out_of_memory() messages indicates that skbuff_head_cache
>>>>> usage is huge enough to suspect in-kernel memory leaks.
>>>>>
>>>>> [ 1554.547011] skbuff_head_cache 1847887KB 1847887KB
>>>>>
>>>>> Unfortunately, we cannot find from logs what syzbot is trying to do
>>>>> because constant printk() messages is flooding away syzkaller messages.
>>>>> Can you try running your testcases with kmemleak enabled?
>>>>>
>>>>
>>>> On 2018/09/27 2:35, Dmitry Vyukov wrote:
>>>>> I also started suspecting Apparmor. We switched to Apparmor on Aug 30:
>>>>> https://groups.google.com/d/msg/syzkaller-bugs/o73lO4KGh0w/j9pcH2tSBAAJ
>>>>> Now the instances that use SELinux and Smack explicitly contain that
>>>>> in the name, but the rest are Apparmor.
>>>>> Aug 30 roughly matches these assorted "task hung" reports. Perhaps
>>>>> some Apparmor hook leaks a reference to skbs?
>>>>
>>>> Maybe. They have CONFIG_DEFAULT_SECURITY="apparmor". But I'm wondering why
>>>> this problem is not occurring on linux-next.git when this problem is occurring
>>>> on bpf.git / bpf-next.git / net.git / net-next.git trees. Is syzbot running
>>>> different testcases depending on which git tree is targeted?
>>>>
>> this is another reason that it is doubtful that its apparmor.
On Thu, Sep 27, 2018 at 2:52 PM, edumazet
> Have you tried kmemleak perhaps, it might give us a clue, but it seems
> obvious the leak would be in TX path.
So, I've tried. Now what? :)
I've uploaded all reports to:
https://drive.google.com/file/d/107LUW0zmYbXmxfQCWoLpeenxXJsXIkxj/view?usp=sharing
This is on net tree d4ce58082f206bf6e7d697380c7bc5480a8b0264
memory leak in __lookup_hash 33 Sep 27 2018 16:35:50
memory leak in new_inode_pseudo 43 Sep 27 2018 16:41:14
memory leak in path_openat 1 Sep 27 2018 16:12:53
memory leak in rhashtable_init 1 Sep 27 2018 16:41:41
memory leak in shmem_symlink 4 Sep 27 2018 16:34:34
memory leak in __anon_vma_prepare 1 Sep 27 2018 17:30:02
memory leak in __do_execve_file 4 Sep 27 2018 18:14:10
memory leak in __do_sys_perf_event_open 2 Sep 27 2018 17:40:05
memory leak in __es_insert_extent 3 Sep 27 2018 17:24:52
memory leak in __getblk_gfp 3 Sep 27 2018 18:19:30
memory leak in __handle_mm_fault 1 Sep 27 2018 18:11:31
memory leak in __hw_addr_create_ex 2 Sep 27 2018 18:10:56
memory leak in __ip_mc_inc_group 13 Sep 27 2018 18:24:31
memory leak in __khugepaged_enter 1 Sep 27 2018 15:40:25
memory leak in __list_lru_init 27 Sep 27 2018 17:30:48
memory leak in __neigh_create 12 Sep 27 2018 17:40:28
memory leak in __netlink_create 1 Sep 27 2018 15:40:23
memory leak in __register_sysctl_table 1 Sep 27 2018 17:36:57
memory leak in __send_signal 1 Sep 27 2018 18:30:48
memory leak in __sys_socket 7 Sep 27 2018 15:43:20
memory leak in anon_inode_getfile 4 Sep 27 2018 18:17:29
memory leak in bpf_prog_store_orig_filter 1 Sep 27 2018 17:59:14
memory leak in br_multicast_new_group 2 Sep 27 2018 18:16:42
memory leak in br_multicast_new_port_group 3 Sep 27 2018 18:17:39
memory leak in build_sched_domains 2 Sep 27 2018 17:28:55
memory leak in clone_mnt 2 Sep 27 2018 18:18:48
memory leak in compute_effective_progs 1 Sep 27 2018 18:35:15
memory leak in create_empty_buffers 1 Sep 27 2018 17:35:42
memory leak in create_filter_start 2 Sep 27 2018 18:16:00
memory leak in create_pipe_files 3 Sep 27 2018 18:21:47
memory leak in do_ip6t_set_ctl 1 Sep 27 2018 15:40:21
memory leak in do_ipt_set_ctl 1 Sep 27 2018 17:37:35
memory leak in do_signalfd4 1 Sep 27 2018 18:00:45
memory leak in do_syslog 2 Sep 27 2018 18:06:22
memory leak in ep_insert 11 Sep 27 2018 17:39:14
memory leak in ep_ptable_queue_proc 3 Sep 27 2018 17:37:17
memory leak in ext4_mb_new_group_pa 1 Sep 27 2018 17:36:04
memory leak in ext4_mb_new_inode_pa 3 Sep 27 2018 17:39:19
memory leak in fdb_create 13 Sep 27 2018 18:24:03
memory leak in fib6_add_1 11 Sep 27 2018 18:19:53
memory leak in fib_table_insert 1 Sep 27 2018 17:36:49
memory leak in find_get_context 1 Sep 27 2018 15:42:00
memory leak in fsnotify_add_mark_locked 11 Sep 27 2018 17:31:41
memory leak in idr_get_free 2 Sep 27 2018 18:17:34
memory leak in iget_locked 1 Sep 27 2018 17:52:59
memory leak in inet_frag_find 3 Sep 27 2018 18:23:53
memory leak in inotify_update_watch 25 Sep 27 2018 17:30:59
memory leak in ioc_create_icq 1 Sep 27 2018 15:42:40
memory leak in ip6_pol_route 4 Sep 27 2018 18:24:59
memory leak in ip6_route_info_create 1 Sep 27 2018 17:38:09
memory leak in ip6t_register_table 1 Sep 27 2018 17:35:39
memory leak in ip_route_output_key_hash_rcu 4 Sep 27 2018 18:21:21
memory leak in ipt_register_table 3 Sep 27 2018 17:39:58
memory leak in ipv6_add_addr 1 Sep 27 2018 17:38:49
memory leak in load_elf_binary 1 Sep 27 2018 18:09:44
memory leak in map_create 9 Sep 27 2018 18:25:10
memory leak in memcg_update_all_list_lrus 1 Sep 27 2018 15:39:36
memory leak in ndisc_send_rs 1 Sep 27 2018 17:50:03
memory leak in neigh_table_init 6 Sep 27 2018 17:23:41
memory leak in nf_hook_entries_grow 5 Sep 27 2018 15:43:41
memory leak in packet_sendmsg 1 Sep 27 2018 18:08:43
memory leak in pcpu_create_chunk 1 Sep 27 2018 17:48:41
memory leak in prepare_creds 18 Sep 27 2018 17:29:10
memory leak in prepare_kernel_cred 15 Sep 27 2018 18:23:42
memory leak in process_preds 2 Sep 27 2018 18:11:01
memory leak in rht_deferred_worker 9 Sep 27 2018 18:24:29
memory leak in sched_init_domains 2 Sep 27 2018 18:12:42
memory leak in sctp_addr_wq_mgmt 1 Sep 27 2018 17:46:20
memory leak in sget 5 Sep 27 2018 18:03:40
memory leak in shmem_symlink 30 Sep 27 2018 17:32:09
memory leak in skb_clone 3 Sep 27 2018 18:13:22
memory leak in submit_bh_wbc 1 Sep 27 2018 17:49:06
memory leak in tracepoint_probe_register_prio 1 Sep 27 2018 17:39:13
memory leak in xt_replace_table 4 Sep 27 2018 15:43:19
memory leak in __delayacct_tsk_init 2 Sep 27 2018 17:02:53
memory leak in disk_expand_part_tbl 1 Sep 27 2018 16:59:05
memory leak in do_ip6t_set_ctl 14 Sep 27 2018 15:46:37
memory leak in neigh_table_init 4 Sep 27 2018 17:10:29
memory leak in do_check 1 Sep 27 2018 18:38:13
^ permalink raw reply
* Re: [PATCH v2 bpf-next] bpf: test_bpf: add init_net to dev for flow_dissector
From: Willem de Bruijn @ 2018-09-27 16:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: songliubraving, Network Development, Daniel Borkmann, Kernel Team,
Willem de Bruijn, Petar Penkov
In-Reply-To: <f83d10c4-b5fd-0223-e1b6-d376751c3da2@gmail.com>
On Thu, Sep 27, 2018 at 12:40 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 09/27/2018 09:34 AM, Song Liu wrote:
> > Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> > However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> > the system with the following stack trace:
> >
> > This patch fixes tes_bpf by using init_net in the dummy dev.
> >
> > Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> > Reported-by: Eric Dumazet <edumazet@google.com>
> > Cc: Willem de Bruijn <willemb@google.com>
> > Cc: Petar Penkov <ppenkov@google.com>
> > Signed-off-by: Song Liu <songliubraving@fb.com>
> > ---
>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Thanks!
^ permalink raw reply
* Re: [PATCH] netfilter: check if the socket netns is correct.
From: Flavio Leitner @ 2018-09-27 22:58 UTC (permalink / raw)
To: Guenter Roeck
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20180927204629.GA4680@roeck-us.net>
On Thu, Sep 27, 2018 at 01:46:29PM -0700, Guenter Roeck wrote:
> Hi Flavio,
>
> On Wed, Jun 27, 2018 at 10:34:25AM -0300, Flavio Leitner wrote:
> > Netfilter assumes that if the socket is present in the skb, then
> > it can be used because that reference is cleaned up while the skb
> > is crossing netns.
> >
> > We want to change that to preserve the socket reference in a future
> > patch, so this is a preparation updating netfilter to check if the
> > socket netns matches before use it.
> >
> > Signed-off-by: Flavio Leitner <fbl@redhat.com>
> > Acked-by: Florian Westphal <fw@strlen.de>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> > ---
> ...
> > --- a/net/netfilter/xt_socket.c
> > +++ b/net/netfilter/xt_socket.c
> > @@ -56,8 +56,12 @@ socket_match(const struct sk_buff *skb, struct xt_action_param *par,
> > struct sk_buff *pskb = (struct sk_buff *)skb;
> > struct sock *sk = skb->sk;
> >
> > + if (!net_eq(xt_net(par), sock_net(sk)))
> > + sk = NULL;
> > +
>
> I am having trouble with this code. With CONFIG_NET_NS enabled, it crashes
> for me in read_pnet() because sk is NULL.
>
> > if (!sk)
> > sk = nf_sk_lookup_slow_v4(xt_net(par), skb, xt_in(par));
>
> The old code seems to suggest that sk == NULL was possible.
>
> I see the problem with the Chrome OS kernel rebased to v4.19-rc5, so I
> can not guarantee that this really an upstream problem. The change seems
> odd, though. Are you sure that it is not (or, rather, no longer) necessary
> to check if sk == NULL before dereferencing it in sock_net() ?
Oops, it is necessary but if it's not and the netns doesn't match, we need
do the lookup. So, could you check if this fixes the problem for you?
>From a5f927e7f1368d753f87cb978d630d786d5adb62 Mon Sep 17 00:00:00 2001
From: Flavio Leitner <fbl@redhat.com>
Date: Thu, 27 Sep 2018 19:36:28 -0300
Subject: [PATCH] xt_socket: check sk before checking for netns.
Only check for the network namespace if the socket is available.
Fixes: f564650106a6 ("netfilter: check if the socket netns is correct.")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
net/netfilter/xt_socket.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 0472f3472842..ada144e5645b 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -56,7 +56,7 @@ socket_match(const struct sk_buff *skb, struct xt_action_param *par,
struct sk_buff *pskb = (struct sk_buff *)skb;
struct sock *sk = skb->sk;
- if (!net_eq(xt_net(par), sock_net(sk)))
+ if (sk && !net_eq(xt_net(par), sock_net(sk)))
sk = NULL;
if (!sk)
@@ -117,7 +117,7 @@ socket_mt6_v1_v2_v3(const struct sk_buff *skb, struct xt_action_param *par)
struct sk_buff *pskb = (struct sk_buff *)skb;
struct sock *sk = skb->sk;
- if (!net_eq(xt_net(par), sock_net(sk)))
+ if (sk && !net_eq(xt_net(par), sock_net(sk)))
sk = NULL;
if (!sk)
--
2.14.4
^ permalink raw reply related
* Re: [PATCH v2 bpf-next] bpf: test_bpf: add init_net to dev for flow_dissector
From: Eric Dumazet @ 2018-09-27 16:39 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: daniel, kernel-team, Willem de Bruijn, Petar Penkov
In-Reply-To: <20180927163441.3918751-1-songliubraving@fb.com>
On 09/27/2018 09:34 AM, Song Liu wrote:
> Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> the system with the following stack trace:
>
> This patch fixes tes_bpf by using init_net in the dummy dev.
>
> Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> Reported-by: Eric Dumazet <edumazet@google.com>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Petar Penkov <ppenkov@google.com>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks.
^ permalink raw reply
* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Andrew Lunn @ 2018-09-27 16:38 UTC (permalink / raw)
To: Chris Preimesberger
Cc: Eran Ben Elisha, Neil Horman, linville@tuxdriver.com,
netdev@vger.kernel.org
In-Reply-To: <82CEAF9FFBA4DD428B132074FB91DF7D5F6489E3@CSI-MAILSRV.csicompanies.internal>
On Thu, Sep 27, 2018 at 04:08:24PM +0000, Chris Preimesberger wrote:
> Please correct me if I'm wrong, but...
> It looks like Eran's proposed fix would remove all warning and
> alarm indications from ethtool's output. It's worth mentioning
> that for me, the following fields always reported correctly
> as Off while no alarm condition was present
> and On while alarm condition(s) were present
> *per the QSFP's true/programmed threshold values*
> *not per the incorrectly reported threshold values*
These alarm values are in the first page. So the information the
driver returns does contain this information. What is missing is the
thresholds, which are not provided by the driver.
But there is a comment in the code:
/*
* There is no clear identifier to signify the existence of
* optical diagnostics similar to SFF-8472. So checking existence
* of page 3, will provide the gurantee for existence of alarms
* and thresholds
* If pagging support exists, then supports_alarms is marked as 1
*/
These alarm values are optional. The spec says so. So in order to
decide if they are implemented, ethtool looks to see if the thresholds
are available. If there are thresholds, it makes sense the alarms are
implemented.
Unfortunately, the driver never returns the thresholds. So ethtool has
no real choice and won't display the alarms since it cannot determine
if they are valid.
In order to get alarms, the driver needs to be extended to return all
the pages.
Andrew
^ permalink raw reply
* [PATCH v2 bpf-next] bpf: test_bpf: add init_net to dev for flow_dissector
From: Song Liu @ 2018-09-27 16:34 UTC (permalink / raw)
To: netdev; +Cc: daniel, kernel-team, Song Liu, Willem de Bruijn, Petar Penkov
Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
However, this is not true for test_bpf. As a result, test_bpf.ko crashes
the system with the following stack trace:
[ 1133.716622] BUG: unable to handle kernel paging request at 0000000000001030
[ 1133.716623] PGD 8000001fbf7ee067
[ 1133.716624] P4D 8000001fbf7ee067
[ 1133.716624] PUD 1f6c1cf067
[ 1133.716625] PMD 0
[ 1133.716628] Oops: 0000 [#1] SMP PTI
[ 1133.716630] CPU: 7 PID: 40473 Comm: modprobe Kdump: loaded Not tainted 4.19.0-rc5-00805-gca11cc92ccd2 #1167
[ 1133.716631] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM12.5 12/06/2017
[ 1133.716638] RIP: 0010:__skb_flow_dissect+0x83/0x1680
[ 1133.716639] Code: 04 00 00 41 0f b7 44 24 04 48 85 db 4d 8d 14 07 0f 84 01 02 00 00 48 8b 43 10 48 85 c0 0f 84 e5 01 00 00 48 8b 80 a8 04 00 00 <48> 8b 90 30 10 00 00 48 85 d2 0f 84 dd 01 00 00 31 c0 b9 05 00 00
[ 1133.716640] RSP: 0018:ffffc900303c7a80 EFLAGS: 00010282
[ 1133.716642] RAX: 0000000000000000 RBX: ffff881fea0b7400 RCX: 0000000000000000
[ 1133.716643] RDX: ffffc900303c7bb4 RSI: ffffffff8235c3e0 RDI: ffff881fea0b7400
[ 1133.716643] RBP: ffffc900303c7b80 R08: 0000000000000000 R09: 000000000000000e
[ 1133.716644] R10: ffffc900303c7bb4 R11: ffff881fb6840400 R12: ffffffff8235c3e0
[ 1133.716645] R13: 0000000000000008 R14: 000000000000001e R15: ffffc900303c7bb4
[ 1133.716646] FS: 00007f54e75d3740(0000) GS:ffff881fff5c0000(0000) knlGS:0000000000000000
[ 1133.716648] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1133.716649] CR2: 0000000000001030 CR3: 0000001f6c226005 CR4: 00000000003606e0
[ 1133.716649] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1133.716650] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1133.716651] Call Trace:
[ 1133.716660] ? sched_clock_cpu+0xc/0xa0
[ 1133.716662] ? sched_clock_cpu+0xc/0xa0
[ 1133.716665] ? log_store+0x1b5/0x260
[ 1133.716667] ? up+0x12/0x60
[ 1133.716669] ? skb_get_poff+0x4b/0xa0
[ 1133.716674] ? __kmalloc_reserve.isra.47+0x2e/0x80
[ 1133.716675] skb_get_poff+0x4b/0xa0
[ 1133.716680] bpf_skb_get_pay_offset+0xa/0x10
[ 1133.716686] ? test_bpf_init+0x578/0x1000 [test_bpf]
[ 1133.716690] ? netlink_broadcast_filtered+0x153/0x3d0
[ 1133.716695] ? free_pcppages_bulk+0x324/0x600
[ 1133.716696] ? 0xffffffffa0279000
[ 1133.716699] ? do_one_initcall+0x46/0x1bd
[ 1133.716704] ? kmem_cache_alloc_trace+0x144/0x1a0
[ 1133.716709] ? do_init_module+0x5b/0x209
[ 1133.716712] ? load_module+0x2136/0x25d0
[ 1133.716715] ? __do_sys_finit_module+0xba/0xe0
[ 1133.716717] ? __do_sys_finit_module+0xba/0xe0
[ 1133.716719] ? do_syscall_64+0x48/0x100
[ 1133.716724] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
This patch fixes tes_bpf by using init_net in the dummy dev.
Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
Reported-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Petar Penkov <ppenkov@google.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
---
lib/test_bpf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 08d3d59dca17..aa22bcaec1dc 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -6494,6 +6494,7 @@ static struct sk_buff *populate_skb(char *buf, int size)
skb->queue_mapping = SKB_QUEUE_MAP;
skb->vlan_tci = SKB_VLAN_TCI;
skb->vlan_proto = htons(ETH_P_IP);
+ dev_net_set(&dev, &init_net);
skb->dev = &dev;
skb->dev->ifindex = SKB_DEV_IFINDEX;
skb->dev->type = SKB_DEV_TYPE;
--
2.17.1
^ permalink raw reply related
* [PATCH net 11/11] ibmvnic: remove ndo_poll_controller
From: Eric Dumazet @ 2018-09-27 16:32 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Michael Chan, Aviad Krawczyk, Song Liu,
Douglas Miller, Yisen Zhuang, Michael S . Tsirkin, Jason Wang,
Harish Patil, Manish Chopra, Netanel Belgazal,
Solarflare linux maintainers, Thomas Falcon, John Allen
In-Reply-To: <20180927163201.56609-1-edumazet@google.com>
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all the queues under load.
ibmvnic uses NAPI for TX completions, so we better let core
networking stack call the napi->poll() to avoid the capture.
ibmvnic_netpoll_controller() was completely wrong anyway,
as it was scheduling NAPI to service RX queues (instead of TX),
so I doubt netpoll ever worked on this driver.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Cc: John Allen <jallen@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 4f0daf67b18df2dcf11d7a406ebc1982e0fee466..699ef942b615c3a22053ba1419399317a6642cfa 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2207,19 +2207,6 @@ static int ibmvnic_poll(struct napi_struct *napi, int budget)
return frames_processed;
}
-#ifdef CONFIG_NET_POLL_CONTROLLER
-static void ibmvnic_netpoll_controller(struct net_device *dev)
-{
- struct ibmvnic_adapter *adapter = netdev_priv(dev);
- int i;
-
- replenish_pools(netdev_priv(dev));
- for (i = 0; i < adapter->req_rx_queues; i++)
- ibmvnic_interrupt_rx(adapter->rx_scrq[i]->irq,
- adapter->rx_scrq[i]);
-}
-#endif
-
static int wait_for_reset(struct ibmvnic_adapter *adapter)
{
int rc, ret;
@@ -2292,9 +2279,6 @@ static const struct net_device_ops ibmvnic_netdev_ops = {
.ndo_set_mac_address = ibmvnic_set_mac,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = ibmvnic_tx_timeout,
-#ifdef CONFIG_NET_POLL_CONTROLLER
- .ndo_poll_controller = ibmvnic_netpoll_controller,
-#endif
.ndo_change_mtu = ibmvnic_change_mtu,
.ndo_features_check = ibmvnic_features_check,
};
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* [PATCH net 10/11] sfc-falcon: remove ndo_poll_controller
From: Eric Dumazet @ 2018-09-27 16:32 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Michael Chan, Aviad Krawczyk, Song Liu,
Douglas Miller, Yisen Zhuang, Michael S . Tsirkin, Jason Wang,
Harish Patil, Manish Chopra, Netanel Belgazal,
Solarflare linux maintainers, Thomas Falcon, Edward Cree,
Bert Kenward
In-Reply-To: <20180927163201.56609-1-edumazet@google.com>
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all the queues under load.
sfc-falcon uses NAPI for TX completions, so we better let core
networking stack call the napi->poll() to avoid the capture.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
Cc: Edward Cree <ecree@solarflare.com>
Cc: Bert Kenward <bkenward@solarflare.com>
---
drivers/net/ethernet/sfc/falcon/efx.c | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/drivers/net/ethernet/sfc/falcon/efx.c b/drivers/net/ethernet/sfc/falcon/efx.c
index dd5530a4f8c8936868aed7171bd9481f93730d76..03e2455c502eacd9a4fd5c7fd320a9edcf265f77 100644
--- a/drivers/net/ethernet/sfc/falcon/efx.c
+++ b/drivers/net/ethernet/sfc/falcon/efx.c
@@ -2052,29 +2052,6 @@ static void ef4_fini_napi(struct ef4_nic *efx)
ef4_fini_napi_channel(channel);
}
-/**************************************************************************
- *
- * Kernel netpoll interface
- *
- *************************************************************************/
-
-#ifdef CONFIG_NET_POLL_CONTROLLER
-
-/* Although in the common case interrupts will be disabled, this is not
- * guaranteed. However, all our work happens inside the NAPI callback,
- * so no locking is required.
- */
-static void ef4_netpoll(struct net_device *net_dev)
-{
- struct ef4_nic *efx = netdev_priv(net_dev);
- struct ef4_channel *channel;
-
- ef4_for_each_channel(channel, efx)
- ef4_schedule_channel(channel);
-}
-
-#endif
-
/**************************************************************************
*
* Kernel net device interface
@@ -2250,9 +2227,6 @@ static const struct net_device_ops ef4_netdev_ops = {
.ndo_set_mac_address = ef4_set_mac_address,
.ndo_set_rx_mode = ef4_set_rx_mode,
.ndo_set_features = ef4_set_features,
-#ifdef CONFIG_NET_POLL_CONTROLLER
- .ndo_poll_controller = ef4_netpoll,
-#endif
.ndo_setup_tc = ef4_setup_tc,
#ifdef CONFIG_RFS_ACCEL
.ndo_rx_flow_steer = ef4_filter_rfs,
--
2.19.0.605.g01d371f741-goog
^ 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