* [PATCH net-next 5/5] net: hns3: fix for multiple unmapping DMA problem
From: Yunsheng Lin @ 2018-10-16 11:58 UTC (permalink / raw)
To: davem
Cc: huangdaode, xuwei5, liguozhu, Yisen.Zhuang, john.garry, linuxarm,
yisen.zhuang, salil.mehta, lipeng321, netdev, linux-kernel
In-Reply-To: <1539691132-158455-1-git-send-email-linyunsheng@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
When sending a big fragment using multiple buffer descriptor,
hns3 does one maping, but do multiple unmapping when tx is done,
which may cause unmapping problem.
To fix it, this patch makes sure the value of desc_cb.length of
the non-first bd is zero. If desc_cb.length is zero, we do not
unmap the buffer.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 74e592d..76ce2f2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1051,6 +1051,8 @@ static int hns3_fill_desc(struct hns3_enet_ring *ring, void *priv,
return -ENOMEM;
}
+ desc_cb->length = size;
+
frag_buf_num = (size + HNS3_MAX_BD_SIZE - 1) / HNS3_MAX_BD_SIZE;
sizeoflast = size % HNS3_MAX_BD_SIZE;
sizeoflast = sizeoflast ? sizeoflast : HNS3_MAX_BD_SIZE;
@@ -1059,15 +1061,14 @@ static int hns3_fill_desc(struct hns3_enet_ring *ring, void *priv,
for (k = 0; k < frag_buf_num; k++) {
/* The txbd's baseinfo of DESC_TYPE_PAGE & DESC_TYPE_SKB */
desc_cb->priv = priv;
- desc_cb->length = (k == frag_buf_num - 1) ?
- sizeoflast : HNS3_MAX_BD_SIZE;
desc_cb->dma = dma + HNS3_MAX_BD_SIZE * k;
desc_cb->type = (type == DESC_TYPE_SKB && !k) ?
DESC_TYPE_SKB : DESC_TYPE_PAGE;
/* now, fill the descriptor */
desc->addr = cpu_to_le64(dma + HNS3_MAX_BD_SIZE * k);
- desc->tx.send_size = cpu_to_le16((u16)desc_cb->length);
+ desc->tx.send_size = cpu_to_le16((k == frag_buf_num - 1) ?
+ (u16)sizeoflast : (u16)HNS3_MAX_BD_SIZE);
hns3_set_txbd_baseinfo(&bdtp_fe_sc_vld_ra_ri,
frag_end && (k == frag_buf_num - 1) ?
1 : 0);
@@ -1150,12 +1151,14 @@ static void hns3_clear_desc(struct hns3_enet_ring *ring, int next_to_use_orig)
ring->desc_cb[ring->next_to_use].dma,
ring->desc_cb[ring->next_to_use].length,
DMA_TO_DEVICE);
- else
+ else if (ring->desc_cb[ring->next_to_use].length)
dma_unmap_page(dev,
ring->desc_cb[ring->next_to_use].dma,
ring->desc_cb[ring->next_to_use].length,
DMA_TO_DEVICE);
+ ring->desc_cb[ring->next_to_use].length = 0;
+
/* rollback one */
ring_ptr_move_bw(ring, next_to_use);
}
@@ -1874,7 +1877,7 @@ static void hns3_unmap_buffer(struct hns3_enet_ring *ring,
if (cb->type == DESC_TYPE_SKB)
dma_unmap_single(ring_to_dev(ring), cb->dma, cb->length,
ring_to_dma_dir(ring));
- else
+ else if (cb->length)
dma_unmap_page(ring_to_dev(ring), cb->dma, cb->length,
ring_to_dma_dir(ring));
}
--
1.9.1
^ permalink raw reply related
* crash in xt_policy due to skb_dst_drop() in nf_ct_frag6_gather()
From: Maciej Żenczykowski @ 2018-10-16 4:13 UTC (permalink / raw)
To: Lorenzo Colitti, Eric Dumazet, Florian Westphal, Linux NetDev,
Maciej Zenczykowski, Maciej Żenczykowski
I believe that:
commit ad8b1ffc3efae2f65080bdb11145c87d299b8f9a
Author: Florian Westphal <fw@strlen.de>
netfilter: ipv6: nf_defrag: drop skb dst before queueing
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -618,6 +618,8 @@ int nf_ct_frag6_gather(struct net *net, struct
sk_buff *skb, u32 user)
fq->q.meat == fq->q.len &&
nf_ct_frag6_reasm(fq, skb, dev))
ret = 0;
+ else
+ skb_dst_drop(skb);
out_unlock:
spin_unlock_bh(&fq->q.lock);
Is causing a crash on android after upgrading from 4.9.96 to 4.9.119
This is because clatd ipv4 to ipv6 translation user space daemon is
functionally equivalent to the syzkaller reproducer.
It will convert ipv4 frags it receives via tap into ipv6 frags which
it will write out via rawv6 sendmsg.
However we are also using xt_policy, after stripping cruft this is basically:
ip6tables -A OUTPUT -m policy --dir out --pol ipsec
Crash is:
match_policy_out()
const struct dst_entry *dst = skb_dst(skb); // returns NULL
if (dst->xfrm == NULL) <-- dst == NULL -> panic
[ 1136.606948] c1 2675 [<ffffff9ec38b4098>] policy_mt+0x34/0x18c
[ 1136.606954] c1 2675 [<ffffff9ec39e6af8>] ip6t_do_table+0x280/0x684
[ 1136.606961] c1 2675 [<ffffff9ec39e7250>] ip6table_filter_hook+0x20/0x28
[ 1136.606969] c1 2675 [<ffffff9ec386ecc8>] nf_hook_slow+0x98/0x154
[ 1136.606977] c1 2675 [<ffffff9ec39b9b10>] rawv6_sendmsg+0xd14/0x1520
[ 1136.606985] c1 2675 [<ffffff9ec39191fc>] inet_sendmsg+0x100/0x1b0
[ 1136.606993] c1 2675 [<ffffff9ec37d3720>] ___sys_sendmsg+0x2a0/0x414
[ 1136.606999] c1 2675 [<ffffff9ec37d3d48>] SyS_sendmsg+0x94/0xe4
Just checking for NULL in xt_policy.c:match_policy_out() and returning
0 or 1 unconditionally seems to be the wrong thing to do,
since after all prior to skb_dst_drop() the skb->dst->xfrm might not
have been NULL.
Maciej Żenczykowski, Kernel Networking Developer @ Google
^ permalink raw reply
* Re: [PATCH] ethtool: fix a privilege escalation bug
From: David Miller @ 2018-10-16 4:39 UTC (permalink / raw)
To: wang6495
Cc: kjlu, f.fainelli, keescook, andrew, ecree, ilyal, ynorov,
alan.brady, stephen, netdev, linux-kernel
In-Reply-To: <1539013777-1625-1-git-send-email-wang6495@umn.edu>
From: Wenwen Wang <wang6495@umn.edu>
Date: Mon, 8 Oct 2018 10:49:35 -0500
> In dev_ethtool(), the eth command 'ethcmd' is firstly copied from the
> use-space buffer 'useraddr' and checked to see whether it is
> ETHTOOL_PERQUEUE. If yes, the sub-command 'sub_cmd' is further copied from
> the user space. Otherwise, 'sub_cmd' is the same as 'ethcmd'. Next,
> according to 'sub_cmd', a permission check is enforced through the function
> ns_capable(). For example, the permission check is required if 'sub_cmd' is
> ETHTOOL_SCOALESCE, but it is not necessary if 'sub_cmd' is
> ETHTOOL_GCOALESCE, as suggested in the comment "Allow some commands to be
> done by anyone". The following execution invokes different handlers
> according to 'ethcmd'. Specifically, if 'ethcmd' is ETHTOOL_PERQUEUE,
> ethtool_set_per_queue() is called. In ethtool_set_per_queue(), the kernel
> object 'per_queue_opt' is copied again from the user-space buffer
> 'useraddr' and 'per_queue_opt.sub_command' is used to determine which
> operation should be performed. Given that the buffer 'useraddr' is in the
> user space, a malicious user can race to change the sub-command between the
> two copies. In particular, the attacker can supply ETHTOOL_PERQUEUE and
> ETHTOOL_GCOALESCE to bypass the permission check in dev_ethtool(). Then
> before ethtool_set_per_queue() is called, the attacker changes
> ETHTOOL_GCOALESCE to ETHTOOL_SCOALESCE. In this way, the attacker can
> bypass the permission check and execute ETHTOOL_SCOALESCE.
>
> This patch enforces a check in ethtool_set_per_queue() after the second
> copy from 'useraddr'. If the sub-command is different from the one obtained
> in the first copy in dev_ethtool(), an error code EINVAL will be returned.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] tun: Consistently configure generic netdev params via rtnetlink
From: David Miller @ 2018-10-16 4:41 UTC (permalink / raw)
To: serhe.popovych; +Cc: netdev, ebiederm
In-Reply-To: <1539109261-8414-1-git-send-email-serhe.popovych@gmail.com>
From: Serhey Popovych <serhe.popovych@gmail.com>
Date: Tue, 9 Oct 2018 21:21:01 +0300
> Configuring generic network device parameters on tun will fail in
> presence of IFLA_INFO_KIND attribute in IFLA_LINKINFO nested attribute
> since tun_validate() always return failure.
>
> This can be visualized with following ip-link(8) command sequences:
>
> # ip link set dev tun0 group 100
> # ip link set dev tun0 group 100 type tun
> RTNETLINK answers: Invalid argument
>
> with contrast to dummy and veth drivers:
>
> # ip link set dev dummy0 group 100
> # ip link set dev dummy0 type dummy
>
> # ip link set dev veth0 group 100
> # ip link set dev veth0 group 100 type veth
>
> Fix by returning zero in tun_validate() when @data is NULL that is
> always in case since rtnl_link_ops->maxtype is zero in tun driver.
>
> Fixes: f019a7a594d9 ("tun: Implement ip link del tunXXX")
> Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/3] ip_tunnel: specify tunnel type via template
From: David Miller @ 2018-10-16 4:43 UTC (permalink / raw)
To: pablo
Cc: netfilter-devel, netdev, roopa, amir, pshelar, u9012063, daniel,
jakub.kicinski
In-Reply-To: <20181009222439.29399-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 10 Oct 2018 00:24:36 +0200
> The following patchset adds a new field to the tunnel metadata template.
> This new field allows us to restrict the configuration to a given tunnel
> driver in order to catch incorrect configuration that may result in
> packets going to the wrong tunnel driver.
>
> Changes with regards to initial RFC [1] are:
>
> 1) Explicit tunnel type initialization to TUNNEL_TYPE_UNSPEC in existing
> clients for this code, as requested by Daniel.
>
> 2) Add TUNNEL_TYPE_* definition through enum tunnel_type in
> uapi/linux/if_tunnel.h, so we don't need to redefine this in every
> client of this infrastructure.
>
> 3) Add TUNNEL_TYPE_IPIP, TUNNEL_TYPE_IPIP6 and TUNNEL_TYPE_IP6IP6, which
> were missing in the original RFC.
>
> Let me know if you any more comments, thanks.
>
> [1] https://marc.info/?l=netfilter-devel&m=153861145204094&w=2
People don't need to update a core common UAPI header to add a new
ethernet driver.
They shouldn't have to do so to add a new tunneling driver either.
But that requirement is created by this patch set.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] FDDI: DEC FDDIcontroller 700 TURBOchannel adapter support
From: David Miller @ 2018-10-16 4:46 UTC (permalink / raw)
To: macro; +Cc: netdev
In-Reply-To: <alpine.LFD.2.21.1810090133440.15789@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Tue, 9 Oct 2018 23:57:36 +0100 (BST)
> Questions, comments? Otherwise, please apply.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net v3] net/sched: cls_api: add missing validation of netlink attributes
From: David Miller @ 2018-10-16 4:49 UTC (permalink / raw)
To: dcaratti; +Cc: dsahern, jhs, netdev
In-Reply-To: <d5fecfcf7edae6027598149f0b8c40ec2bef00cd.1539201552.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 10 Oct 2018 22:00:58 +0200
> Similarly to what has been done in 8b4c3cdd9dd8 ("net: sched: Add policy
> validation for tc attributes"), fix classifier code to add validation of
> TCA_CHAIN and TCA_KIND netlink attributes.
>
> tested with:
> # ./tdc.py -c filter
>
> v2: Let sch_api and cls_api share nla_policy they have in common, thanks
> to David Ahern.
> v3: Avoid EXPORT_SYMBOL(), as validation of those attributes is not done
> by TC modules, thanks to Cong Wang.
> While at it, restore the 'Delete / get qdisc' comment to its orginal
> position, just above tc_get_qdisc() function prototype.
>
> Fixes: 5bc1701881e39 ("net: sched: introduce multichain support for filters")
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [pull request][net-next 0/7] Mellanox, mlx5e and IPoIB netlink support fixes
From: David Miller @ 2018-10-16 4:50 UTC (permalink / raw)
To: saeedm; +Cc: netdev, jgg, linux-rdma
In-Reply-To: <20181011012444.28194-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 10 Oct 2018 18:24:37 -0700
> This series was meant to go to -rc but due to this late submission and the
> size/complexity of this patchset, I am submitting to net-next.
>
> This series came to fix a very serious regression in RDMA
> IPoIB netlink child creation API, the patcheset contains fixes to two
> components and they must come together:
> 1) IPoIB netllink implementation to allow allocation of the netdev to be done by
> the rtnl netdev code
> 2) mlx5e refactoring and changes to correctly initialize netdevices
> created by the rdma stack.
>
> For more details please see tag log below.
>
> Please pull and let me know if there's any problem.
Pulled, thanks.
^ permalink raw reply
* Re: [pull request][net 0/3] Mellanox, mlx5 fixes 2018-10-10
From: David Miller @ 2018-10-16 4:52 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20181011013244.29554-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 10 Oct 2018 18:32:41 -0700
> This pull request includes some fixes to mlx5 driver,
> Please pull and let me know if there's any problem.
Pulled.
> For -stable v4.11:
> ('net/mlx5: Take only bit 24-26 of wqe.pftype_wq for page fault type')
> For -stable v4.17:
> ('net/mlx5: Fix memory leak when setting fpga ipsec caps')
> For -stable v4.18:
> ('net/mlx5: WQ, fixes for fragmented WQ buffers API')
Queued up.
^ permalink raw reply
* Re: [net-next] tipc: support binding to specific ip address when activating UDP bearer
From: David Miller @ 2018-10-16 4:58 UTC (permalink / raw)
To: hoang.h.le; +Cc: jon.maloy, maloy, ying.xue, netdev, tipc-discussion
In-Reply-To: <20181011014308.6637-1-hoang.h.le@dektech.com.au>
From: Hoang Le <hoang.h.le@dektech.com.au>
Date: Thu, 11 Oct 2018 08:43:08 +0700
> INADDR_ANY is hard-coded when activating UDP bearer. So, we could not
> bind to a specific IP address even with replicast mode using - given
> remote ip address instead of using multicast ip address.
>
> In this commit, we fixed it by checking and switch to use appropriate
> local ip address.
>
> before:
> $netstat -plu
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address
> udp 0 0 **0.0.0.0:6118** 0.0.0.0:*
>
> after:
> $netstat -plu
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address
> udp 0 0 **10.0.0.2:6118** 0.0.0.0:*
>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/3] veth: XDP stats improvement
From: David Miller @ 2018-10-16 4:58 UTC (permalink / raw)
To: makita.toshiaki; +Cc: netdev, brouer
In-Reply-To: <1539250610-2557-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Thu, 11 Oct 2018 18:36:47 +0900
> ndo_xdp_xmit in veth did not update packet counters as described in [1].
> Also, current implementation only updates counters on tx side so rx side
> events like XDP_DROP were not collected.
> This series implements the missing accounting as well as support for
> ethtool per-queue stats in veth.
>
> Patch 1: Update drop counter in ndo_xdp_xmit.
> Patch 2: Update packet and byte counters for all XDP path, and drop
> counter on XDP_DROP.
> Patch 3: Support per-queue ethtool stats for XDP counters.
>
> Note that counters are maintained on per-queue basis for XDP but not
> otherwise (per-cpu and atomic as before). This is because 1) tx path in
> veth is essentially lockless so we cannot update per-queue stats on tx,
> and 2) rx path is net core routine (process_backlog) which cannot update
> per-queue based stats when XDP is disabled. On the other hand there are
> real rxqs and napi handlers for veth XDP, so update per-queue stats on
> rx for XDP packets, and use them to calculate tx counters as well,
> contrary to the existing non-XDP counters.
>
> [1] https://patchwork.ozlabs.org/cover/953071/#1967449
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: trigger state machine immediately in phy_start_machine
From: David Miller @ 2018-10-16 5:00 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <7bbeb020-0001-404c-4a0c-d4d8e9788db5@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 11 Oct 2018 19:31:47 +0200
> When starting the state machine there may be work to be done
> immediately, e.g. if the initial state is PHY_UP then the state
> machine may trigger an autonegotiation. Having said that I see no need
> to wait a second until the state machine is run first time.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v7] net/ncsi: Extend NC-SI Netlink interface to allow user space to send NC-SI command
From: David Miller @ 2018-10-16 5:01 UTC (permalink / raw)
To: Justin.Lee1
Cc: sam, joel, linux-aspeed, netdev, openbmc, amithash, christian,
vijaykhemka
In-Reply-To: <cd371b0265b74889a10241a6af7e4843@AUSX13MPS302.AMER.DELL.COM>
From: <Justin.Lee1@Dell.com>
Date: Thu, 11 Oct 2018 18:07:37 +0000
> The new command (NCSI_CMD_SEND_CMD) is added to allow user space application
> to send NC-SI command to the network card.
> Also, add a new attribute (NCSI_ATTR_DATA) for transferring request and response.
>
> The work flow is as below.
>
> Request:
> User space application
> -> Netlink interface (msg)
> -> new Netlink handler - ncsi_send_cmd_nl()
> -> ncsi_xmit_cmd()
>
> Response:
> Response received - ncsi_rcv_rsp()
> -> internal response handler - ncsi_rsp_handler_xxx()
> -> ncsi_rsp_handler_netlink()
> -> ncsi_send_netlink_rsp ()
> -> Netlink interface (msg)
> -> user space application
>
> Command timeout - ncsi_request_timeout()
> -> ncsi_send_netlink_timeout ()
> -> Netlink interface (msg with zero data length)
> -> user space application
>
> Error:
> Error detected
> -> ncsi_send_netlink_err ()
> -> Netlink interface (err msg)
> -> user space application
>
>
> Signed-off-by: Justin Lee <justin.lee1@dell.com>
Applied.
^ permalink raw reply
* Re: [Patch net] llc: set SOCK_RCU_FREE in llc_sap_add_socket()
From: David Miller @ 2018-10-16 5:02 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev
In-Reply-To: <20181011181513.20203-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 11 Oct 2018 11:15:13 -0700
> WHen an llc sock is added into the sk_laddr_hash of an llc_sap,
> it is not marked with SOCK_RCU_FREE.
>
> This causes that the sock could be freed while it is still being
> read by __llc_lookup_established() with RCU read lock. sock is
> refcounted, but with RCU read lock, nothing prevents the readers
> getting a zero refcnt.
>
> Fix it by setting SOCK_RCU_FREE in llc_sap_add_socket().
>
> Reported-by: syzbot+11e05f04c15e03be5254@syzkaller.appspotmail.com
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next v2] vxlan: support NTF_USE refresh of fdb entries
From: David Miller @ 2018-10-16 5:03 UTC (permalink / raw)
To: roopa; +Cc: netdev
In-Reply-To: <1539286513-26165-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Thu, 11 Oct 2018 12:35:13 -0700
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This makes use of NTF_USE in vxlan driver consistent
> with bridge driver.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Applied.
^ permalink raw reply
* Re: [net 1/1] tipc: initialize broadcast link stale counter correctly
From: David Miller @ 2018-10-16 5:04 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1539288149-24122-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 11 Oct 2018 22:02:29 +0200
> In the commit referred to below we added link tolerance as an additional
> criteria for declaring broadcast transmission "stale" and resetting the
> unicast links to the affected node.
>
> Unfortunately, this 'improvement' introduced two bugs, which each and
> one alone cause only limited problems, but combined lead to seemingly
> stochastic unicast link resets, depending on the amount of broadcast
> traffic transmitted.
>
> The first issue, a missing initialization of the 'tolerance' field of
> the receiver broadcast link, was recently fixed by commit 047491ea334a
> ("tipc: set link tolerance correctly in broadcast link").
>
> Ths second issue, where we omit to reset the 'stale_cnt' field of
> the same link after a 'stale' period is over, leads to this counter
> accumulating over time, and in the absence of the 'tolerance' criteria
> leads to the above described symptoms. This commit adds the missing
> initialization.
>
> Fixes: a4dc70d46cf1 ("tipc: extend link reset criteria for stale packet
> retransmission")
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
In the future, please always make your Fixes: tag one single line no
matter how long it is. And also do not separate it from other tags
like the signoff with empty lines. All of the tags should be
collected together without any empty lines in between.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: phy: improve and simplify state machine
From: David Miller @ 2018-10-16 5:07 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <a3f84d67-c7f1-82d5-1956-bd348ab2b5c0@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 11 Oct 2018 22:35:35 +0200
> Improve / simplify handling of states PHY_RUNNING and PHY_RESUMING in
> phylib state machine.
Series applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: rate-limit probes for neighbourless routes
From: David Miller @ 2018-10-16 5:20 UTC (permalink / raw)
To: sd; +Cc: netdev, sbrivio
In-Reply-To: <ae3154f520198f61e4cd51a082e0e6be6b8bd632.1539353746.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Fri, 12 Oct 2018 16:22:47 +0200
> When commit 270972554c91 ("[IPV6]: ROUTE: Add Router Reachability
> Probing (RFC4191).") introduced router probing, the rt6_probe() function
> required that a neighbour entry existed. This neighbour entry is used to
> record the timestamp of the last probe via the ->updated field.
>
> Later, commit 2152caea7196 ("ipv6: Do not depend on rt->n in rt6_probe().")
> removed the requirement for a neighbour entry. Neighbourless routes skip
> the interval check and are not rate-limited.
>
> This patch adds rate-limiting for neighbourless routes, by recording the
> timestamp of the last probe in the fib6_info itself.
>
> Fixes: 2152caea7196 ("ipv6: Do not depend on rt->n in rt6_probe().")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 0/6] dpaa2-eth: code cleanup
From: David Miller @ 2018-10-16 5:24 UTC (permalink / raw)
To: ioana.ciornei; +Cc: netdev, ruxandra.radulescu
In-Reply-To: <cover.1539361388.git.ioana.ciornei@nxp.com>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
Date: Fri, 12 Oct 2018 16:27:16 +0000
> There are no functional changes in this patch set, only some cleanup
> changes such as: unused parameters, uninitialized variables and
> unnecessary Kconfig dependencies.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] nfp: devlink port split support for 1x100G CXP NIC
From: David Miller @ 2018-10-16 5:31 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers, rgoodfel
In-Reply-To: <20181012180901.24119-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Fri, 12 Oct 2018 11:09:01 -0700
> From: Ryan C Goodfellow <rgoodfel@isi.edu>
>
> This commit makes it possible to use devlink to split the 100G CXP
> Netronome into two 40G interfaces. Currently when you ask for 2
> interfaces, the math in src/nfp_devlink.c:nfp_devlink_port_split
> calculates that you want 5 lanes per port because for some reason
> eth_port.port_lanes=10 (shouldn't this be 12 for CXP?). What we really
> want when asking for 2 breakout interfaces is 4 lanes per port. This
> commit makes that happen by calculating based on 8 lanes if 10 are
> present.
>
> Signed-off-by: Ryan C Goodfellow <rgoodfel@isi.edu>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Greg Weeks <greg.weeks@netronome.com>
Applied.
^ permalink raw reply
* Re: [net 1/1] tipc: fix unsafe rcu locking when accessing publication list
From: David Miller @ 2018-10-16 5:33 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1539377215-29145-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Fri, 12 Oct 2018 22:46:55 +0200
> From: Tung Nguyen <tung.q.nguyen@dektech.com.au>
>
> The binding table's 'cluster_scope' list is rcu protected to handle
> races between threads changing the list and those traversing the list at
> the same moment. We have now found that the function named_distribute()
> uses the regular list_for_each() macro to traverse the said list.
> Likewise, the function tipc_named_withdraw() is removing items from the
> same list using the regular list_del() call. When these two functions
> execute in parallel we see occasional crashes.
>
> This commit fixes this by adding the missing _rcu() suffixes.
>
> Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] r8169: simplify rtl8169_set_magic_reg
From: David Miller @ 2018-10-16 5:35 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <d1e53c97-9779-5a2a-9f3a-f823db41a54a@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 12 Oct 2018 23:23:57 +0200
> Simplify this function, no functional change intended.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: remove unneeded call to netif_stop_queue in rtl8169_net_suspend
From: David Miller @ 2018-10-16 5:35 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <0c2ef75a-3f4f-c81b-d5fc-cc1e523d61c7@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 12 Oct 2018 23:30:52 +0200
> netif_device_detach() stops all tx queues already, so we don't need
> this call.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] selftests: pmtu: Add test choice and captures
From: David Miller @ 2018-10-16 5:38 UTC (permalink / raw)
To: sbrivio; +Cc: sd, netdev
In-Reply-To: <cover.1539361090.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Fri, 12 Oct 2018 23:54:12 +0200
> This series adds a couple of features useful for debugging: 1/2
> allows selecting single tests and 2/2 adds optional traffic
> captures.
>
> Semantics for current invocation of test script are preserved.
M0AR SELF TESTS!
I love it.
Keep them coming.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv6: mcast: fix a use-after-free in inet6_mc_check
From: David Miller @ 2018-10-16 5:39 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20181013015853.133333-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 12 Oct 2018 18:58:53 -0700
> syzbot found a use-after-free in inet6_mc_check [1]
>
> The problem here is that inet6_mc_check() uses rcu
> and read_lock(&iml->sflock)
>
> So the fact that ip6_mc_leave_src() is called under RTNL
> and the socket lock does not help us, we need to acquire
> iml->sflock in write mode.
>
> In the future, we should convert all this stuff to RCU.
>
> [1]
> BUG: KASAN: use-after-free in ipv6_addr_equal include/net/ipv6.h:521 [inline]
> BUG: KASAN: use-after-free in inet6_mc_check+0xae7/0xb40 net/ipv6/mcast.c:649
> Read of size 8 at addr ffff8801ce7f2510 by task syz-executor0/22432
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox