* Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
From: Ben Greear @ 2018-06-08 14:08 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpULrWMNtgDcrZkc-uLtB0XOVFeZxQ6cFgpXwv7DtA9jzA@mail.gmail.com>
On 06/07/2018 04:59 PM, Cong Wang wrote:
> On Thu, Jun 7, 2018 at 4:48 PM, <greearb@candelatech.com> wrote:
>> diff --git a/include/net/fq_impl.h b/include/net/fq_impl.h
>> index be7c0fa..cb911f0 100644
>> --- a/include/net/fq_impl.h
>> +++ b/include/net/fq_impl.h
>> @@ -78,7 +78,10 @@ static struct sk_buff *fq_tin_dequeue(struct fq *fq,
>> return NULL;
>> }
>>
>> - flow = list_first_entry(head, struct fq_flow, flowchain);
>> + flow = list_first_entry_or_null(head, struct fq_flow, flowchain);
>> +
>> + if (WARN_ON_ONCE(!flow))
>> + return NULL;
>
> This does not make sense either. list_first_entry_or_null()
> returns NULL only when the list is empty, but we already check
> list_empty() right before this code, and it is protected by fq->lock.
>
Nevermind then.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
From: Ben Greear @ 2018-06-08 14:10 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpU8PjkQgmHRSi144L0LHUXrbOKYaetqUV3ECHzWs2cD-A@mail.gmail.com>
On 06/07/2018 05:13 PM, Cong Wang wrote:
> On Thu, Jun 7, 2018 at 4:48 PM, <greearb@candelatech.com> wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> While testing an ath10k firmware that often crashed under load,
>> I was seeing kernel crashes as well. One of them appeared to
>> be a dereference of a NULL flow object in fq_tin_dequeue.
>>
>> I have since fixed the firmware flaw, but I think it would be
>> worth adding the WARN_ON in case the problem appears again.
>>
>> BUG: unable to handle kernel NULL pointer dereference at 000000000000003c
>> IP: ieee80211_tx_dequeue+0xfb/0xb10 [mac80211]
>
> Instead of adding WARN_ON(), you need to think about
> the locking there, it is suspicious:
>
> fq is from struct ieee80211_local:
>
> struct fq *fq = &local->fq;
>
> tin is from struct txq_info:
>
> struct fq_tin *tin = &txqi->tin;
>
> I don't know if fq and tin are supposed to be 1:1, if not there is
> a bug in the locking, because ->new_flows and ->old_flows are
> both inside tin instead of fq, but they are protected by fq->lock....
Maybe whoever put this code together can take a stab at it.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Kirill Kranke @ 2018-06-08 14:45 UTC (permalink / raw)
To: andrew, f.fainelli, davem, netdev; +Cc: Kirill Kranke
In-Reply-To: <20180608134032.GA16663@lunn.ch>
Current generic PHY driver does not work with TJA1100 BroadR-REACH PHY
properly. TJA1100 does not have any standard ability enabled at MII_BMSR
register. Instead it has BroadR-REACH ability at MII_ESTATUS enabled, which
is not handled by generic driver yet. Therefore generic driver is unable to
guess required link speed, duplex etc. Device is started up with 10Mbps
halfduplex which is incorrect.
BroadR-REACH able flag is not specified in IEEE802.3-2015. Which is why I
did not add BroadR-REACH able flag support at generic driver. Once
BroadR-REACH able flag gets into IEEE802.3 it should be reasonable to
support it in the generic PHY driver.
Signed-off-by: Kirill Kranke <kranke.kirill@gmail.com>
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 343989f..7014eb7 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -422,6 +422,14 @@ config TERANETICS_PHY
---help---
Currently supports the Teranetics TN2020
+config TJA1100_PHY
+ tristate "NXP TJA1100 PHY"
+ help
+ Support of NXP TJA1100 BroadR-REACH ethernet PHY.
+ Generic driver is not suitable for TJA1100 PHY while the PHY does not
+ advertise any standard IEEE capabilities. It uses BroadR-REACH able
+ flag instead. This driver configures capabilities of the PHY properly.
+
config VITESSE_PHY
tristate "Vitesse PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b..4d2a69d 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -83,5 +83,6 @@ obj-$(CONFIG_ROCKCHIP_PHY) += rockchip.o
obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_STE10XP) += ste10Xp.o
obj-$(CONFIG_TERANETICS_PHY) += teranetics.o
+obj-$(CONFIG_TJA1100_PHY) += tja1100.o
obj-$(CONFIG_VITESSE_PHY) += vitesse.o
obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
diff --git a/drivers/net/phy/tja1100.c b/drivers/net/phy/tja1100.c
new file mode 100644
index 0000000..cddf4d7
--- /dev/null
+++ b/drivers/net/phy/tja1100.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0
+/* tja1100.c: TJA1100 BoardR-REACH PHY driver.
+ *
+ * Copyright (c) 2017 Kirill Kranke <kirill.kranke@gmail.com>
+ * Author: Kirill Kranke <kirill.kranke@gmail.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+
+static int tja1100_phy_config_init(struct phy_device *phydev)
+{
+ phydev->autoneg = AUTONEG_DISABLE;
+ phydev->speed = SPEED_100;
+ phydev->duplex = DUPLEX_FULL;
+
+ return 0;
+}
+
+static int tja1100_phy_config_aneg(struct phy_device *phydev)
+{
+ if (phydev->autoneg == AUTONEG_ENABLE) {
+ phydev_err(phydev, "autonegotiation is not supported\n");
+ return -EINVAL;
+ }
+
+ if (phydev->speed != SPEED_100 || phydev->duplex != DUPLEX_FULL) {
+ phydev_err(phydev, "only 100MBps Full Duplex allowed\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct phy_driver tja1100_phy_driver[] = {
+ {
+ .phy_id = 0x0180dc48,
+ .phy_id_mask = 0xfffffff0,
+ .name = "NXP TJA1100",
+
+ /* TJA1100 has only 100BASE-BroadR-REACH ability specified
+ * at MII_ESTATUS register. Standard modes are not
+ * supported. Therefore BroadR-REACH allow only 100Mbps
+ * full duplex without autoneg.
+ */
+ .features = SUPPORTED_100baseT_Full | SUPPORTED_MII,
+
+ .config_aneg = tja1100_phy_config_aneg,
+ .config_init = tja1100_phy_config_init,
+
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ }
+};
+
+module_phy_driver(tja1100_phy_driver);
+
+MODULE_DESCRIPTION("NXP TJA1100 driver");
+MODULE_AUTHOR("Kirill Kranke <kkranke@topcon.com>");
+MODULE_LICENSE("GPL");
+
+static struct mdio_device_id __maybe_unused nxp_tbl[] = {
+ { 0x0180dc48, 0xfffffff0 },
+ {}
+};
+
+MODULE_DEVICE_TABLE(mdio, nxp_tbl);
^ permalink raw reply related
* Re: [PATCH net] kcm: fix races on sk_receive_queue
From: David Miller @ 2018-06-08 14:53 UTC (permalink / raw)
To: pabeni; +Cc: netdev, tom, ktkhai
In-Reply-To: <628e0398546aefabd68669450621909d269e1ba8.1528289745.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 6 Jun 2018 15:16:29 +0200
> @@ -1126,7 +1132,7 @@ static int kcm_recvmsg(struct socket *sock, struct msghdr *msg,
>
> lock_sock(sk);
>
> - skb = kcm_wait_data(sk, flags, timeo, &err);
> + skb = kcm_wait_data(sk, flags, peek, timeo, &err);
> if (!skb)
> goto out;
>
Because kcm_wait_data() potentially unlinks now, you will have to kfree the
SKB in the error paths, for example if skb_copy_datagram_msg() fails.
Otherwise we have an SKB leak.
Yeah, it's kind of ugly that kcm_recvmsg() is going to become a pile of
conditional operations based upon the peek boolean. :-/
^ permalink raw reply
* Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
From: Eric Dumazet @ 2018-06-08 14:53 UTC (permalink / raw)
To: Ben Greear, Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <99455a63-4a19-e172-a9b4-e7d8935cb1e0@candelatech.com>
On 06/08/2018 07:10 AM, Ben Greear wrote:
> Maybe whoever put this code together can take a stab at it.
>
This was one one the motivation for the Fixes: tag request.
By doing a git blame, you can find which commit(s) added this code,
and thus CC the author, who might not follow netdev@ closely.
^ permalink raw reply
* Re: [PATCH] net: stmmac: fix build failure due to missing COMMON_CLK dependency
From: David Miller @ 2018-06-08 14:59 UTC (permalink / raw)
To: clabbe; +Cc: alexandre.torgue, peppe.cavallaro, linux-kernel, netdev,
linux-sunxi
In-Reply-To: <1528310722-11512-1-git-send-email-clabbe@baylibre.com>
From: Corentin Labbe <clabbe@baylibre.com>
Date: Wed, 6 Jun 2018 18:45:22 +0000
> This patch fix the build failure on m68k;
> drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.o: In function `ipq806x_gmac_probe':
> dwmac-ipq806x.c:(.text+0xda): undefined reference to `clk_set_rate'
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.o: In function `rk_gmac_probe':
> dwmac-rk.c:(.text+0x1e58): undefined reference to `clk_set_rate'
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.o: In function `stid127_fix_retime_src':
> dwmac-sti.c:(.text+0xd8): undefined reference to `clk_set_rate'
> dwmac-sti.c:(.text+0x114): undefined reference to `clk_set_rate'
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.o:dwmac-sti.c:(.text+0x12c): more undefined references to `clk_set_rate' follow
> Lots of stmmac platform drivers need COMMON_CLK in their Kconfig depends.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Applied.
^ permalink raw reply
* [bpf PATCH v2 0/2] bpf, sockmap IPv6/TCP state fixes
From: John Fastabend @ 2018-06-08 15:06 UTC (permalink / raw)
To: edumazet, weiwan, daniel, ast; +Cc: netdev
ULP are only valid with TCP in ESTABLISHED states. Sockmap was not
following this rule so add a fix to only allow ESTABLISHED states to
be added from the userspace side. On the BPF side we continue to allow
adding sockets to maps from sock_ops events, but only events that are
triggered when entering the ESTABLISHED state. This blocks users from
adding sockets to maps that will not be in the correct TCP state.
Also we stomped on the tcpv6_prot pointer overwriting with the
tcp_prot. This was discovered by syzbot (thanks!) and not found by
selftests because we only have local tests in selftest so even with
ipv6 selftests we did not trigger the splat.
Will follow up with IPv6 tests for selftest regardless it seems like
a miss to not have any IPv6 selftests.
Also these need to go to stable. There will be a small conflict on
the second patch where we add check to the sockhash update function
which did not exist until recently.
---
John Fastabend (2):
bpf: sockmap, fix crash when ipv6 sock is added
bpf: sockmap only allow ESTABLISHED sock state
kernel/bpf/sockmap.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 52 insertions(+), 4 deletions(-)
^ permalink raw reply
* [bpf PATCH v2 1/2] bpf: sockmap, fix crash when ipv6 sock is added
From: John Fastabend @ 2018-06-08 15:06 UTC (permalink / raw)
To: edumazet, weiwan, daniel, ast; +Cc: netdev
In-Reply-To: <20180608145951.15153.80520.stgit@john-Precision-Tower-5810>
This fixes a crash where we assign tcp_prot to IPv6 sockets instead
of tcpv6_prot.
Previously we overwrote the sk->prot field with tcp_prot even in the
AF_INET6 case. This patch ensures the correct tcp_prot and tcpv6_prot
are used. Further, only allow ESTABLISHED connections to join the
map per note in TLS ULP,
/* The TLS ulp is currently supported only for TCP sockets
* in ESTABLISHED state.
* Supporting sockets in LISTEN state will require us
* to modify the accept implementation to clone rather then
* share the ulp context.
*/
Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
'netperf -H [IPv4]'. The ESTABLISHED check resolves the previously
crashing case here.
Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
Reported-by: syzbot+5c063698bdbfac19f363@syzkaller.appspotmail.com
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/sockmap.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 52a91d8..fa9b7f3 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -41,6 +41,7 @@
#include <linux/mm.h>
#include <net/strparser.h>
#include <net/tcp.h>
+#include <net/transp_v6.h>
#include <linux/ptr_ring.h>
#include <net/inet_common.h>
#include <linux/sched/signal.h>
@@ -140,6 +141,7 @@ static int bpf_tcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size);
static int bpf_tcp_sendpage(struct sock *sk, struct page *page,
int offset, size_t size, int flags);
+static void bpf_tcp_close(struct sock *sk, long timeout);
static inline struct smap_psock *smap_psock_sk(const struct sock *sk)
{
@@ -162,6 +164,8 @@ static bool bpf_tcp_stream_read(const struct sock *sk)
}
static struct proto tcp_bpf_proto;
+static struct proto tcpv6_bpf_proto;
+
static int bpf_tcp_init(struct sock *sk)
{
struct smap_psock *psock;
@@ -181,14 +185,30 @@ static int bpf_tcp_init(struct sock *sk)
psock->save_close = sk->sk_prot->close;
psock->sk_proto = sk->sk_prot;
+ if (sk->sk_family == AF_INET6) {
+ tcpv6_bpf_proto = *sk->sk_prot;
+ tcpv6_bpf_proto.close = bpf_tcp_close;
+ } else {
+ tcp_bpf_proto = *sk->sk_prot;
+ tcp_bpf_proto.close = bpf_tcp_close;
+ }
+
if (psock->bpf_tx_msg) {
+ tcpv6_bpf_proto.sendmsg = bpf_tcp_sendmsg;
+ tcpv6_bpf_proto.sendpage = bpf_tcp_sendpage;
+ tcpv6_bpf_proto.recvmsg = bpf_tcp_recvmsg;
+ tcpv6_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
tcp_bpf_proto.sendmsg = bpf_tcp_sendmsg;
tcp_bpf_proto.sendpage = bpf_tcp_sendpage;
tcp_bpf_proto.recvmsg = bpf_tcp_recvmsg;
tcp_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
}
- sk->sk_prot = &tcp_bpf_proto;
+ if (sk->sk_family == AF_INET6)
+ sk->sk_prot = &tcpv6_bpf_proto;
+ else
+ sk->sk_prot = &tcp_bpf_proto;
+
rcu_read_unlock();
return 0;
}
@@ -1111,8 +1131,6 @@ static void bpf_tcp_msg_add(struct smap_psock *psock,
static int bpf_tcp_ulp_register(void)
{
- tcp_bpf_proto = tcp_prot;
- tcp_bpf_proto.close = bpf_tcp_close;
/* Once BPF TX ULP is registered it is never unregistered. It
* will be in the ULP list for the lifetime of the system. Doing
* duplicate registers is not a problem.
^ permalink raw reply related
* [bpf PATCH v2 2/2] bpf: sockmap only allow ESTABLISHED sock state
From: John Fastabend @ 2018-06-08 15:06 UTC (permalink / raw)
To: edumazet, weiwan, daniel, ast; +Cc: netdev
In-Reply-To: <20180608145951.15153.80520.stgit@john-Precision-Tower-5810>
Per the note in the TLS ULP (which is actually a generic statement
regarding ULPs)
/* The TLS ulp is currently supported only for TCP sockets
* in ESTABLISHED state.
* Supporting sockets in LISTEN state will require us
* to modify the accept implementation to clone rather then
* share the ulp context.
*/
After this patch we only allow socks that are in ESTABLISHED state or
are being added via a sock_ops event that is transitioning into an
ESTABLISHED state. By allowing sock_ops events we allow users to
manage sockmaps directly from sock ops programs. The two supported
sock_ops ops are BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB and
BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB.
Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
'netperf -H [IPv4]'.
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index fa9b7f3..4921fb7 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1956,8 +1956,12 @@ static int sock_map_update_elem(struct bpf_map *map,
return -EINVAL;
}
+ /* ULPs are currently supported only for TCP sockets in ESTABLISHED
+ * state.
+ */
if (skops.sk->sk_type != SOCK_STREAM ||
- skops.sk->sk_protocol != IPPROTO_TCP) {
+ skops.sk->sk_protocol != IPPROTO_TCP ||
+ skops.sk->sk_state != TCP_ESTABLISHED) {
fput(socket->file);
return -EOPNOTSUPP;
}
@@ -2318,6 +2322,16 @@ static int sock_hash_update_elem(struct bpf_map *map,
return -EINVAL;
}
+ /* ULPs are currently supported only for TCP sockets in ESTABLISHED
+ * state.
+ */
+ if (skops.sk->sk_type != SOCK_STREAM ||
+ skops.sk->sk_protocol != IPPROTO_TCP ||
+ skops.sk->sk_state != TCP_ESTABLISHED) {
+ fput(socket->file);
+ return -EOPNOTSUPP;
+ }
+
err = sock_hash_ctx_update_elem(&skops, map, key, flags);
fput(socket->file);
return err;
@@ -2403,10 +2417,23 @@ struct sock *__sock_hash_lookup_elem(struct bpf_map *map, void *key)
.map_delete_elem = sock_hash_delete_elem,
};
+static bool bpf_is_valid_sock(struct bpf_sock_ops_kern *ops)
+{
+ return ops->op == BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB ||
+ ops->op == BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB;
+}
+
BPF_CALL_4(bpf_sock_map_update, struct bpf_sock_ops_kern *, bpf_sock,
struct bpf_map *, map, void *, key, u64, flags)
{
WARN_ON_ONCE(!rcu_read_lock_held());
+
+ /* ULPs are currently supported only for TCP sockets in ESTABLISHED
+ * state. This checks that the sock ops triggering the update is
+ * one indicating we are (or will be soon) in an ESTABLISHED state.
+ */
+ if (!bpf_is_valid_sock(bpf_sock))
+ return -EOPNOTSUPP;
return sock_map_ctx_update_elem(bpf_sock, map, key, flags);
}
@@ -2425,6 +2452,9 @@ struct sock *__sock_hash_lookup_elem(struct bpf_map *map, void *key)
struct bpf_map *, map, void *, key, u64, flags)
{
WARN_ON_ONCE(!rcu_read_lock_held());
+
+ if (!bpf_is_valid_sock(bpf_sock))
+ return -EOPNOTSUPP;
return sock_hash_ctx_update_elem(bpf_sock, map, key, flags);
}
^ permalink raw reply related
* Re: [PATCH] wcn36xx: Remove Unicode Byte Order Mark from testcode
From: Ramon Fried @ 2018-06-08 15:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Eyal Ilsar, Kalle Valo, David S . Miller, Arnd Bergmann, netdev,
linux-wireless, open list, wcn36xx
In-Reply-To: <1528375527-22761-1-git-send-email-geert@linux-m68k.org>
On Thu, Jun 7, 2018 at 3:45 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Older gcc (< 4.4) doesn't like files starting with a Unicode BOM:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\357’ in program
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\273’ in program
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\277’ in program
>
> Remove the BOM, the rest of the file is plain ASCII anyway.
>
> Output of "file drivers/net/wireless/ath/wcn36xx/testmode.c" before:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c: C source, UTF-8 Unicode (with BOM) text
>
> and after:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c: C source, ASCII text
>
> Fixes: 87f825e6e246cee0 ("wcn36xx: Add support for Factory Test Mode (FTM)")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Thanks Geert !
Acked-by: Ramon Fried <ramon.fried@gmail.com>
> ---
> drivers/net/wireless/ath/wcn36xx/testmode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/testmode.c b/drivers/net/wireless/ath/wcn36xx/testmode.c
> index 1279064a3b716c2e..51a038022c8b8040 100644
> --- a/drivers/net/wireless/ath/wcn36xx/testmode.c
> +++ b/drivers/net/wireless/ath/wcn36xx/testmode.c
> @@ -1,4 +1,4 @@
> -/*
> +/*
> * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> *
> * Permission to use, copy, modify, and/or distribute this software for any
> --
> 2.7.4
>
>
> _______________________________________________
> wcn36xx mailing list
> wcn36xx@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wcn36xx
^ permalink raw reply
* Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
From: Ben Greear @ 2018-06-08 15:17 UTC (permalink / raw)
To: Michal Kazior
Cc: Cong Wang, Linux Kernel Network Developers,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAM_iQpULrWMNtgDcrZkc-uLtB0XOVFeZxQ6cFgpXwv7DtA9jzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 06/07/2018 04:59 PM, Cong Wang wrote:
> On Thu, Jun 7, 2018 at 4:48 PM, <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org> wrote:
>> diff --git a/include/net/fq_impl.h b/include/net/fq_impl.h
>> index be7c0fa..cb911f0 100644
>> --- a/include/net/fq_impl.h
>> +++ b/include/net/fq_impl.h
>> @@ -78,7 +78,10 @@ static struct sk_buff *fq_tin_dequeue(struct fq *fq,
>> return NULL;
>> }
>>
>> - flow = list_first_entry(head, struct fq_flow, flowchain);
>> + flow = list_first_entry_or_null(head, struct fq_flow, flowchain);
>> +
>> + if (WARN_ON_ONCE(!flow))
>> + return NULL;
>
> This does not make sense either. list_first_entry_or_null()
> returns NULL only when the list is empty, but we already check
> list_empty() right before this code, and it is protected by fq->lock.
>
Hello Michal,
git blame shows you as the author of the fq_impl.h code.
I saw a crash when debugging funky ath10k firmware in a 4.16 + hacks kernel. There was an apparent
mostly-null deref in the fq_tin_dequeue method. According to gdb, it was within
1 line of the dereference of 'flow'.
My hack above is probably not that useful. Cong thinks maybe the locking is bad.
If you get a chance, please review this thread and see if you have any ideas for
a better fix (or better debugging code).
As always, if you would like me to generate you a buggy firmware that will crash
in the tx path and cause all sorts of mayhem in the ath10k driver and wifi stack,
I will be happy to do so.
https://www.mail-archive.com/netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg239738.html
Thanks,
Ben
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [PATCH ethtool 2/6] ethtool: fix RING_VF assignment
From: Keller, Jacob E @ 2018-06-08 15:20 UTC (permalink / raw)
To: Ivan Vecera, linville@tuxdriver.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180608092010.13041-2-cera@cera.cz>
> -----Original Message-----
> From: Ivan Vecera [mailto:cera@cera.cz]
> Sent: Friday, June 08, 2018 2:20 AM
> To: linville@tuxdriver.com
> Cc: netdev@vger.kernel.org; Keller, Jacob E <jacob.e.keller@intel.com>
> Subject: [PATCH ethtool 2/6] ethtool: fix RING_VF assignment
>
> Fixes: 36ee712 ("ethtool: support queue and VF fields for rxclass filters")
> Cc: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
> ---
> rxclass.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rxclass.c b/rxclass.c
> index ce4b382..42d122d 100644
> --- a/rxclass.c
> +++ b/rxclass.c
> @@ -1066,7 +1066,7 @@ static int rxclass_get_val(char *str, unsigned char *p,
> u32 *flags,
> val++;
>
> *(u64 *)&p[opt->offset] &=
> ~ETHTOOL_RX_FLOW_SPEC_RING_VF;
> - *(u64 *)&p[opt->offset] = (u64)val <<
> ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
> + *(u64 *)&p[opt->offset] |= (u64)val <<
> ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
> break;
> }
Hah. Good catch.
Thanks,
Jake
> case OPT_RING_QUEUE: {
> --
> 2.16.4
^ permalink raw reply
* Re: [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Andrew Lunn @ 2018-06-08 15:55 UTC (permalink / raw)
To: Kirill Kranke; +Cc: f.fainelli, davem, netdev
In-Reply-To: <1528469132-9161-1-git-send-email-kranke.kirill@gmail.com>
On Fri, Jun 08, 2018 at 05:45:32PM +0300, Kirill Kranke wrote:
> Current generic PHY driver does not work with TJA1100 BroadR-REACH PHY
> properly. TJA1100 does not have any standard ability enabled at MII_BMSR
> register. Instead it has BroadR-REACH ability at MII_ESTATUS enabled, which
> is not handled by generic driver yet. Therefore generic driver is unable to
> guess required link speed, duplex etc. Device is started up with 10Mbps
> halfduplex which is incorrect.
>
> BroadR-REACH able flag is not specified in IEEE802.3-2015. Which is why I
> did not add BroadR-REACH able flag support at generic driver. Once
> BroadR-REACH able flag gets into IEEE802.3 it should be reasonable to
> support it in the generic PHY driver.
Hi Kirill
Thank for making the changes.
It is normal to put 'v2' after PATCH in the subject line. Also, make a
brief list of changes since the previous version, after a line with
---. They will get removed when the patch is committed, but help
reviewers see what has changed.
For network patches, you should also include which tree these patches
are for. net-next in this case. See the networking FAQ.
>
> Signed-off-by: Kirill Kranke <kranke.kirill@gmail.com>
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 343989f..7014eb7 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -422,6 +422,14 @@ config TERANETICS_PHY
> ---help---
> Currently supports the Teranetics TN2020
>
> +config TJA1100_PHY
> + tristate "NXP TJA1100 PHY"
Please call this NXP_TJA1100_PHY. Putting the vendor first is the
general pattern. Are are a few TI drivers which ignore this, but other
follow this. This also means moving it up so it comes after
NATIONAL_PHY.
> + help
> + Support of NXP TJA1100 BroadR-REACH ethernet PHY.
> + Generic driver is not suitable for TJA1100 PHY while the PHY does not
> + advertise any standard IEEE capabilities. It uses BroadR-REACH able
> + flag instead. This driver configures capabilities of the PHY properly.
>
Does 100Base-T1/cause 96 define a way to identify a PHY which
implements this? I'm just wondering if we can do this in the generic
code, for devices which correctly implement the standard?
+
> config VITESSE_PHY
> tristate "Vitesse PHYs"
> ---help---
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 5805c0b..4d2a69d 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -83,5 +83,6 @@ obj-$(CONFIG_ROCKCHIP_PHY) += rockchip.o
> obj-$(CONFIG_SMSC_PHY) += smsc.o
> obj-$(CONFIG_STE10XP) += ste10Xp.o
> obj-$(CONFIG_TERANETICS_PHY) += teranetics.o
> +obj-$(CONFIG_TJA1100_PHY) += tja1100.o
> obj-$(CONFIG_VITESSE_PHY) += vitesse.o
> obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
> diff --git a/drivers/net/phy/tja1100.c b/drivers/net/phy/tja1100.c
> new file mode 100644
> index 0000000..cddf4d7
> --- /dev/null
> +++ b/drivers/net/phy/tja1100.c
> @@ -0,0 +1,68 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* tja1100.c: TJA1100 BoardR-REACH PHY driver.
> + *
> + * Copyright (c) 2017 Kirill Kranke <kirill.kranke@gmail.com>
> + * Author: Kirill Kranke <kirill.kranke@gmail.com>
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/phy.h>
> +
> +static int tja1100_phy_config_init(struct phy_device *phydev)
> +{
> + phydev->autoneg = AUTONEG_DISABLE;
> + phydev->speed = SPEED_100;
> + phydev->duplex = DUPLEX_FULL;
> +
> + return 0;
> +}
> +
> +static int tja1100_phy_config_aneg(struct phy_device *phydev)
> +{
> + if (phydev->autoneg == AUTONEG_ENABLE) {
> + phydev_err(phydev, "autonegotiation is not supported\n");
> + return -EINVAL;
> + }
> +
> + if (phydev->speed != SPEED_100 || phydev->duplex != DUPLEX_FULL) {
> + phydev_err(phydev, "only 100MBps Full Duplex allowed\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static struct phy_driver tja1100_phy_driver[] = {
> + {
> + .phy_id = 0x0180dc48,
> + .phy_id_mask = 0xfffffff0,
> + .name = "NXP TJA1100",
> +
> + /* TJA1100 has only 100BASE-BroadR-REACH ability specified
> + * at MII_ESTATUS register. Standard modes are not
> + * supported. Therefore BroadR-REACH allow only 100Mbps
> + * full duplex without autoneg.
> + */
> + .features = SUPPORTED_100baseT_Full | SUPPORTED_MII,
This is the second T1 driver we have had recently. It might make sense to add a
PHY_T1_FEATURES macro the include/linux/phy.h
Don't you also want SUPPORTED_TP?
Andrew
^ permalink raw reply
* Re: general protection fault in bpf_tcp_close
From: John Fastabend @ 2018-06-08 16:02 UTC (permalink / raw)
To: Dmitry Vyukov, Daniel Borkmann
Cc: syzbot, Alexei Starovoitov, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+bN1jHcqovkBu5szmUqNHe3WRS1doOi9v3N6VnxZS7z4g@mail.gmail.com>
On 06/07/2018 09:58 AM, Dmitry Vyukov wrote:
> On Mon, May 28, 2018 at 12:15 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> [ +John ]
>>
>> On 05/26/2018 11:13 AM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: fd0bfa8d6e04 Merge branch 'bpf-af-xdp-cleanups'
>>> git tree: bpf-next
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=11da9427800000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=0ce137753c78f7b6acc1
>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>
>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+0ce137753c78f7b6acc1@syzkaller.appspotmail.com
>>
>> Should be fixed by: https://patchwork.ozlabs.org/patch/920695/
>
> #syz fix: bpf: sockhash fix race with bpf_tcp_close and map delete
>
Hi, actually that patch was dropped because it needed an update. I
should have a new patch today/tomorrow though and will add the
correct fix tag then.
Thanks,
John
^ permalink raw reply
* Re: KASAN: use-after-free Write in bpf_tcp_close
From: John Fastabend @ 2018-06-08 16:03 UTC (permalink / raw)
To: Dmitry Vyukov, Daniel Borkmann
Cc: syzbot, Alexei Starovoitov, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+YqCF3mcjkJSZaJSpBHazQsucdZWdgksg=Cdi7AFQuEqQ@mail.gmail.com>
On 06/07/2018 09:58 AM, Dmitry Vyukov wrote:
> On Mon, May 28, 2018 at 12:15 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> [ +John ]
>>
>> On 05/27/2018 10:06 PM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: ff4fb475cea8 Merge branch 'btf-uapi-cleanups'
>>> git tree: bpf-next
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=12b3d577800000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=31025a5f3f7650081204
>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=109a2f37800000
>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=171a727b800000
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+31025a5f3f7650081204@syzkaller.appspotmail.com
>>
>> Should be fixed by: https://patchwork.ozlabs.org/patch/920695/
>
> #syz fix: bpf: sockhash fix race with bpf_tcp_close and map delete
>
Same here 'bpf: sockhash fix race with bpf_tcp_close and map delete"
was dropped and a new fix will be posted shortly.
Thanks!
John
^ permalink raw reply
* [PATCH bpf] bpf: implement dummy fops for bpf objects
From: Daniel Borkmann @ 2018-06-08 16:10 UTC (permalink / raw)
To: ast; +Cc: netdev, Daniel Borkmann
syzkaller was able to trigger the following warning in
do_dentry_open():
WARNING: CPU: 1 PID: 4508 at fs/open.c:778 do_dentry_open+0x4ad/0xe40 fs/open.c:778
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 4508 Comm: syz-executor867 Not tainted 4.17.0+ #90
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
[...]
vfs_open+0x139/0x230 fs/open.c:908
do_last fs/namei.c:3370 [inline]
path_openat+0x1717/0x4dc0 fs/namei.c:3511
do_filp_open+0x249/0x350 fs/namei.c:3545
do_sys_open+0x56f/0x740 fs/open.c:1101
__do_sys_openat fs/open.c:1128 [inline]
__se_sys_openat fs/open.c:1122 [inline]
__x64_sys_openat+0x9d/0x100 fs/open.c:1122
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Problem was that prog and map inodes in bpf fs did not
implement a dummy file open operation that would return an
error. The patch in do_dentry_open() checks whether f_ops
are present and if not bails out with an error. While this
may be fine, we really shouldn't be throwing a warning
though. Thus follow the model similar to bad_file_ops and
reject the request unconditionally with -EIO.
Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
Reported-by: syzbot+2e7fcab0f56fdbb330b8@syzkaller.appspotmail.com
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/inode.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
index ed13645..76efe9a 100644
--- a/kernel/bpf/inode.c
+++ b/kernel/bpf/inode.c
@@ -295,6 +295,15 @@ static const struct file_operations bpffs_map_fops = {
.release = bpffs_map_release,
};
+static int bpffs_obj_open(struct inode *inode, struct file *file)
+{
+ return -EIO;
+}
+
+static const struct file_operations bpffs_obj_fops = {
+ .open = bpffs_obj_open,
+};
+
static int bpf_mkobj_ops(struct dentry *dentry, umode_t mode, void *raw,
const struct inode_operations *iops,
const struct file_operations *fops)
@@ -314,7 +323,8 @@ static int bpf_mkobj_ops(struct dentry *dentry, umode_t mode, void *raw,
static int bpf_mkprog(struct dentry *dentry, umode_t mode, void *arg)
{
- return bpf_mkobj_ops(dentry, mode, arg, &bpf_prog_iops, NULL);
+ return bpf_mkobj_ops(dentry, mode, arg, &bpf_prog_iops,
+ &bpffs_obj_fops);
}
static int bpf_mkmap(struct dentry *dentry, umode_t mode, void *arg)
@@ -322,7 +332,7 @@ static int bpf_mkmap(struct dentry *dentry, umode_t mode, void *arg)
struct bpf_map *map = arg;
return bpf_mkobj_ops(dentry, mode, arg, &bpf_map_iops,
- map->btf ? &bpffs_map_fops : NULL);
+ map->btf ? &bpffs_map_fops : &bpffs_obj_fops);
}
static struct dentry *
--
2.9.5
^ permalink raw reply related
* [PATCH] Bluetooth: hci_bcm: Configure SCO routing automatically
From: attitokes @ 2018-06-08 16:20 UTC (permalink / raw)
Cc: Attila Tőkés, David S. Miller, Rob Herring,
Mark Rutland, Marcel Holtmann, Johan Hedberg, Artiom Vaskov,
netdev, devicetree, linux-kernel, linux-bluetooth
In-Reply-To: <280FCB2C-6DF1-4790-A89F-AF5BE3513AE5@holtmann.org>
From: Attila Tőkés <attitokes@gmail.com>
Added support to automatically configure the SCO packet routing at the device setup. The SCO packets are used with the HSP / HFP profiles, but in some devices (ex. CYW43438) they are routed to a PCM output by default. This change allows sending the vendor specific HCI command to configure the SCO routing. The parameters of the command are loaded from the device tree.
Signed-off-by: Attila Tőkés <attitokes@gmail.com>
---
.../bindings/net/broadcom-bluetooth.txt | 7 ++
drivers/bluetooth/hci_bcm.c | 72 +++++++++++++++++++
2 files changed, 79 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
index 4194ff7e..aea3a094 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
+++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
@@ -21,6 +21,12 @@ Optional properties:
- clocks: clock specifier if external clock provided to the controller
- clock-names: should be "extclk"
+ SCO routing parameters:
+ - sco-routing: 0-3 (PCM, Transport, Codec, I2S)
+ - pcm-interface-rate: 0-4 (128 Kbps - 2048 Kbps)
+ - pcm-frame-type: 0 (short), 1 (long)
+ - pcm-sync-mode: 0 (slave), 1 (master)
+ - pcm-clock-mode: 0 (slave), 1 (master)
Example:
@@ -31,5 +37,6 @@ Example:
bluetooth {
compatible = "brcm,bcm43438-bt";
max-speed = <921600>;
+ sco-routing = <1>; /* 1 = transport (UART) */
};
};
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index ddbd8c6a..0e729534 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -83,6 +83,16 @@
* @hu: pointer to HCI UART controller struct,
* used to disable flow control during runtime suspend and system sleep
* @is_suspended: whether flow control is currently disabled
+ *
+ * SCO routing parameters:
+ * used as the parameters for the bcm_set_pcm_int_params command
+ * @sco_routing:
+ * >= 255 (skip SCO routing configuration)
+ * 0-3 (PCM, Transport, Codec, I2S)
+ * @pcm_interface_rate: 0-4 (128 Kbps - 2048 Kbps)
+ * @pcm_frame_type: 0 (short), 1 (long)
+ * @pcm_sync_mode: 0 (slave), 1 (master)
+ * @pcm_clock_mode: 0 (slave), 1 (master)
*/
struct bcm_device {
/* Must be the first member, hci_serdev.c expects this. */
@@ -114,6 +124,13 @@ struct bcm_device {
struct hci_uart *hu;
bool is_suspended;
#endif
+
+ /* SCO routing parameters */
+ u8 sco_routing;
+ u8 pcm_interface_rate;
+ u8 pcm_frame_type;
+ u8 pcm_sync_mode;
+ u8 pcm_clock_mode;
};
/* generic bcm uart resources */
@@ -189,6 +206,40 @@ static int bcm_set_baudrate(struct hci_uart *hu, unsigned int speed)
return 0;
}
+static int bcm_configure_sco_routing(struct hci_uart *hu, struct bcm_device *bcm_dev)
+{
+ struct hci_dev *hdev = hu->hdev;
+ struct sk_buff *skb;
+ struct bcm_set_pcm_int_params params;
+
+ if (bcm_dev->sco_routing >= 0xff) {
+ /* SCO routing configuration should be skipped */
+ return 0;
+ }
+
+ bt_dev_dbg(hdev, "BCM: Configuring SCO routing (%d %d %d %d %d)",
+ bcm_dev->sco_routing, bcm_dev->pcm_interface_rate, bcm_dev->pcm_frame_type,
+ bcm_dev->pcm_sync_mode, bcm_dev->pcm_clock_mode);
+
+ params.routing = bcm_dev->sco_routing;
+ params.rate = bcm_dev->pcm_interface_rate;
+ params.frame_sync = bcm_dev->pcm_frame_type;
+ params.sync_mode = bcm_dev->pcm_sync_mode;
+ params.clock_mode = bcm_dev->pcm_clock_mode;
+
+ /* Send the SCO routing configuration command */
+ skb = __hci_cmd_sync(hdev, 0xfc1c, sizeof(params), ¶ms, HCI_CMD_TIMEOUT);
+ if (IS_ERR(skb)) {
+ int err = PTR_ERR(skb);
+ bt_dev_err(hdev, "BCM: failed to configure SCO routing (%d)", err);
+ return err;
+ }
+
+ kfree_skb(skb);
+
+ return 0;
+}
+
/* bcm_device_exists should be protected by bcm_device_lock */
static bool bcm_device_exists(struct bcm_device *device)
{
@@ -534,6 +585,9 @@ static int bcm_setup(struct hci_uart *hu)
host_set_baudrate(hu, speed);
}
+ /* Configure SCO routing if needed */
+ bcm_configure_sco_routing(hu, bcm->dev);
+
finalize:
release_firmware(fw);
@@ -1004,9 +1058,21 @@ static int bcm_acpi_probe(struct bcm_device *dev)
}
#endif /* CONFIG_ACPI */
+static void read_u8_device_property(struct device *device, const char *property, u8 *destination) {
+ u32 temp;
+ if (device_property_read_u32(device, property, &temp) == 0) {
+ *destination = temp & 0xff;
+ }
+}
+
static int bcm_of_probe(struct bcm_device *bdev)
{
device_property_read_u32(bdev->dev, "max-speed", &bdev->oper_speed);
+ read_u8_device_property(bdev->dev, "sco-routing", &bdev->sco_routing);
+ read_u8_device_property(bdev->dev, "pcm-interface-rate", &bdev->pcm_interface_rate);
+ read_u8_device_property(bdev->dev, "pcm-frame-type", &bdev->pcm_frame_type);
+ read_u8_device_property(bdev->dev, "pcm-sync-mode", &bdev->pcm_sync_mode);
+ read_u8_device_property(bdev->dev, "pcm-clock-mode", &bdev->pcm_clock_mode);
return 0;
}
@@ -1022,6 +1088,9 @@ static int bcm_probe(struct platform_device *pdev)
dev->dev = &pdev->dev;
dev->irq = platform_get_irq(pdev, 0);
+ /* SCO routing configuration is disabled by default */
+ dev->sco_routing = 0xff;
+
if (has_acpi_companion(&pdev->dev)) {
ret = bcm_acpi_probe(dev);
if (ret)
@@ -1281,6 +1350,9 @@ static int bcm_serdev_probe(struct serdev_device *serdev)
bcmdev->serdev_hu.serdev = serdev;
serdev_device_set_drvdata(serdev, bcmdev);
+ /* SCO routing configuration is disabled by default */
+ bcmdev->sco_routing = 0xff;
+
if (has_acpi_companion(&serdev->dev))
err = bcm_acpi_probe(bcmdev);
else
--
2.17.0
^ permalink raw reply related
* [PATCH net] KEYS: DNS: fix parsing multiple options
From: Eric Biggers @ 2018-06-08 16:20 UTC (permalink / raw)
To: netdev, David S . Miller; +Cc: keyrings, David Howells, Wang Lei, Eric Biggers
From: Eric Biggers <ebiggers@google.com>
My recent fix for dns_resolver_preparse() printing very long strings was
incomplete, as shown by syzbot which still managed to hit the
WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:
precision 50001 too large
WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0
The bug this time isn't just a printing bug, but also a logical error
when multiple options ("#"-separated strings) are given in the key
payload. Specifically, when separating an option string into name and
value, if there is no value then the name is incorrectly considered to
end at the end of the key payload, rather than the end of the current
option. This bypasses validation of the option length, and also means
that specifying multiple options is broken -- which presumably has gone
unnoticed as there is currently only one valid option anyway.
Fix it by correctly calculating the length of the option name.
Reproducer:
perl -e 'print "#A#", "\x00" x 50000' | keyctl padd dns_resolver desc @s
Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
net/dns_resolver/dns_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index 40c851693f77e..d448823d4d2ed 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -97,7 +97,7 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
return -EINVAL;
}
- eq = memchr(opt, '=', opt_len) ?: end;
+ eq = memchr(opt, '=', opt_len) ?: next_opt;
opt_nlen = eq - opt;
eq++;
opt_vlen = next_opt - eq; /* will be -1 if no value */
--
2.18.0.rc1.242.g61856ae69a-goog
^ permalink raw reply related
* Re: [PATCH net] kcm: fix races on sk_receive_queue
From: Paolo Abeni @ 2018-06-08 16:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, tom, ktkhai
In-Reply-To: <20180608.105311.1644703021787191738.davem@davemloft.net>
On Fri, 2018-06-08 at 10:53 -0400, David Miller wrote:
> From: Paolo Abeni <pabeni@redhat.com>
> Date: Wed, 6 Jun 2018 15:16:29 +0200
>
> > @@ -1126,7 +1132,7 @@ static int kcm_recvmsg(struct socket *sock, struct msghdr *msg,
> >
> > lock_sock(sk);
> >
> > - skb = kcm_wait_data(sk, flags, timeo, &err);
> > + skb = kcm_wait_data(sk, flags, peek, timeo, &err);
> > if (!skb)
> > goto out;
> >
>
> Because kcm_wait_data() potentially unlinks now, you will have to kfree the
> SKB in the error paths, for example if skb_copy_datagram_msg() fails.
>
> Otherwise we have an SKB leak.
Right. But now I fear the fix should be different: if we drop the skb
on skb_copy_datagram_msg() error, that will cause a behavior change. I
need to think more for a proper fix.
Thank you for the feedback.
Paolo
^ permalink raw reply
* Fw: [Bug 199995] New: Ramdomly sent TCP Reset from Kernel with bonding mode "brodcast"
From: Stephen Hemminger @ 2018-06-08 16:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
Begin forwarded message:
Date: Fri, 08 Jun 2018 16:06:40 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 199995] New: Ramdomly sent TCP Reset from Kernel with bonding mode "brodcast"
https://bugzilla.kernel.org/show_bug.cgi?id=199995
Bug ID: 199995
Summary: Ramdomly sent TCP Reset from Kernel with bonding mode
"brodcast"
Product: Networking
Version: 2.5
Kernel Version: since 4.15.0
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: l.bendel@portunity.de
Regression: No
Created attachment 276401
--> https://bugzilla.kernel.org/attachment.cgi?id=276401&action=edit
TCP Dump
Hi,
after a dist upgrade from Ubuntu 17.10 (Kernel 4.13.x) to Ubuntu 18.04 (Kernel
4.15.0) I suffer from ramdomly generated TCP RST packets sent (presumably) by
the Kernel
on a bonding device that uses bonding mode "brodcast" with 2 physical NICs.
With tcpdump/whireshark I can see that the kernel randomly sends TCP-RST
packets after the SYN/ACK/ACK packet is received (see attached PCAP).
This only happens if the kernel receives the initial SYN packet on both
physical NICs (and therefore seeing it twice), before the connection is
established by sending SYN/ACK.
It's not happening in 100% of all cases and only, if the system can use two or
more CPU cores/threads. With only one CPU available to the system, this
behaviour is not reproducable.
I can reproduce this on multiple physical servers with 2 bonded Intel NICs
connected over 2 seperate Switches and with virtual machines on a KVM Host
using 2 dedicated host bridges.
This also happens with a fresh installed Ubuntu 18.04 and Fedora 28 (kernel
4.16), so I decided to compile and boot with Kernel 4.17.0 on ubuntu, getting
the same result.
Only disabling/blocking the second network connection or reducing the amount of
CPU cores of the VM to one core solves the problem, so I think this could be a
race condition on systems with more than one CPU core and thread.
For my tests I used a very basic Ubuntu 18.04 (x86-64) running xinetd tcp-echo
service (port 7/TCP).
On the client I used the netcat-traditional packet with the following command:
while true; do echo $(date) | nc.traditional -q 1 ECHO-SERVER 7; sleep 0.1 ;
done
This gives the following output:
---------------------------------------
Fr 8. Jun 09:12:43 UTC 2018
Fr 8. Jun 09:12:43 UTC 2018
Fr 8. Jun 09:12:43 UTC 2018
Fr 8. Jun 09:12:43 UTC 2018
Fr 8. Jun 09:12:43 UTC 2018
Fr 8. Jun 09:12:43 UTC 2018
Fr 8. Jun 09:12:43 UTC 2018
Fr 8. Jun 09:12:43 UTC 2018
(UNKNOWN) [192.168.86.101] 7 (echo) : Connection reset by peer
(UNKNOWN) [192.168.86.101] 7 (echo) : Connection reset by peer
(UNKNOWN) [192.168.86.101] 7 (echo) : Connection reset by peer
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
Fr 8. Jun 09:12:44 UTC 2018
(UNKNOWN) [192.168.86.101] 7 (echo) : Connection reset by peer
(UNKNOWN) [192.168.86.101] 7 (echo) : Connection reset by peer
Fr 8. Jun 09:12:44 UTC 2018
---------------------------------------
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 2/2] iproute2: Remove leftover gated RT_PROT defines
From: Stephen Hemminger @ 2018-06-08 17:04 UTC (permalink / raw)
To: Donald Sharp; +Cc: netdev, dsahern
In-Reply-To: <20180608124638.4895-3-sharpd@cumulusnetworks.com>
On Fri, 8 Jun 2018 08:46:38 -0400
Donald Sharp <sharpd@cumulusnetworks.com> wrote:
> These values are not being used nor maintained, so remove.
>
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> etc/iproute2/rt_protos | 13 -------------
> 1 file changed, 13 deletions(-)
>
> diff --git a/etc/iproute2/rt_protos b/etc/iproute2/rt_protos
> index 3ffe8a6c..a965ad16 100644
> --- a/etc/iproute2/rt_protos
> +++ b/etc/iproute2/rt_protos
> @@ -21,16 +21,3 @@
> 188 ospf
> 189 rip
> 192 eigrp
> -
> -#
> -# Used by me for gated
> -#
> -254 gated/aggr
> -253 gated/bgp
> -252 gated/ospf
> -251 gated/ospfase
> -250 gated/rip
> -249 gated/static
> -248 gated/conn
> -247 gated/inet
> -246 gated/default
I already dropped these
^ permalink raw reply
* Re: [iproute2 1/1] tipc: TIPC_NLA_LINK_NAME value pass on nesting entry TIPC_NLA_LINK
From: Stephen Hemminger @ 2018-06-08 17:07 UTC (permalink / raw)
To: Hoang Le; +Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
In-Reply-To: <1528424368-3768-1-git-send-email-hoang.h.le@dektech.com.au>
On Fri, 8 Jun 2018 09:19:28 +0700
Hoang Le <hoang.h.le@dektech.com.au> wrote:
> In the commit 94f6a80 on next-net, TIPC_NLA_LINK_NAME attribute should be
> retrieved and validated via TIPC_NLA_LINK nesting entry in
> tipc_nl_node_get_link().
> According to that commit, TIPC_NLA_LINK_NAME value passing via
> tipc link get command must follow above hierachy.
>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Applied
^ permalink raw reply
* Re: [PATCH iproute2 v2 0/2] display netns name instead of nsid
From: Stephen Hemminger @ 2018-06-08 17:08 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev
In-Reply-To: <20180605130831.8175-1-nicolas.dichtel@6wind.com>
On Tue, 5 Jun 2018 15:08:29 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> After these patches, the iproute2 name of netns is displayed instead of
> the nsid. It's easier to read/understand.
>
> v1 -> v2:
> - open netns socket and init netns map only when needed
>
> ip/ip_common.h | 3 +++
> ip/ipaddress.c | 20 +++++++++++++++-----
> ip/iplink.c | 18 ++++++++++++++++--
> ip/ipnetns.c | 22 ++++++++++++++++++++--
> 4 files changed, 54 insertions(+), 9 deletions(-)
>
> Comments are welcomed,
> Regards,
> Nicolas
Applied
^ permalink raw reply
* [PATCH 0/3] net: bpfilter: clean-up build rules
From: Masahiro Yamada @ 2018-06-08 17:12 UTC (permalink / raw)
To: netdev, Alexei Starovoitov, David S . Miller
Cc: Arnd Bergmann, Geert Uytterhoeven, linux-kernel, Masahiro Yamada,
YueHaibing
I am unhappy with ugly hacks in this Makefile.
(I could understand what is the hand-crafted .bpfilter_umh.o.cmd
used for.)
Moreover, CONFIG_OUTPUT_FORMAT is causing build errors
because it is defined only for x86.
As far as I understood, what is happening here is
to embed the 'bpfilter_umh' as a blob.
Instead, we can use '.incbin' to include it into a *.S file.
Also, let's stop (ab)using host-program rules.
Only build test is done.
Masahiro Yamada (3):
bpfilter: add bpfilter_umh to .gitignore
bpfilter: include bpfilter_umh in assembly instead of using objcopy
bpfilter: do not (ab)use host-program build rule
net/bpfilter/.gitignore | 1 +
net/bpfilter/Makefile | 30 ++++++++++++------------------
net/bpfilter/bpfilter_kern.c | 11 +++++------
net/bpfilter/{main.c => bpfilter_umh.c} | 0
net/bpfilter/bpfilter_umh_blob.S | 7 +++++++
5 files changed, 25 insertions(+), 24 deletions(-)
create mode 100644 net/bpfilter/.gitignore
rename net/bpfilter/{main.c => bpfilter_umh.c} (100%)
create mode 100644 net/bpfilter/bpfilter_umh_blob.S
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] bpfilter: add bpfilter_umh to .gitignore
From: Masahiro Yamada @ 2018-06-08 17:12 UTC (permalink / raw)
To: netdev, Alexei Starovoitov, David S . Miller
Cc: Arnd Bergmann, Geert Uytterhoeven, linux-kernel, Masahiro Yamada
In-Reply-To: <1528477930-7342-1-git-send-email-yamada.masahiro@socionext.com>
bpfilter_umh is a generated file. It should be ignored by git.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
net/bpfilter/.gitignore | 1 +
1 file changed, 1 insertion(+)
create mode 100644 net/bpfilter/.gitignore
diff --git a/net/bpfilter/.gitignore b/net/bpfilter/.gitignore
new file mode 100644
index 0000000..e97084e
--- /dev/null
+++ b/net/bpfilter/.gitignore
@@ -0,0 +1 @@
+bpfilter_umh
--
2.7.4
^ 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