Re: [PATCH net-next] __netif_receive_skb_core: don't untag vlan from skb on DSA master
From: Vladimir Oltean
Date: Sat, 12 Sep 2020 02:26:07 +0300
> A DSA master interface has upper network devices, each representing an
> Ethernet switch port attached to it. Demultiplexing the source ports and
> setting skb->dev accordingly is done through the catch-all ETH_P_XDSA
> packet_type handler. Catch-all because DSA vendors have various header
> implementations, which can be placed anywhere in the frame: before the
> DMAC, before the EtherType, before the FCS, etc. So, the ETH_P_XDSA
> handler acts like an rx_handler more than anything.
>
> It is unlikely for the DSA master interface to have any other upper than
> the DSA switch interfaces themselves. Only maybe a bridge upper*, but it
> is very likely that the DSA master will have no 8021q upper. So
> __netif_receive_skb_core() will try to untag the VLAN, despite the fact
> that the DSA switch interface might have an 8021q upper. So the skb will
> never reach that.
>
> So far, this hasn't been a problem because most of the possible
> placements of the DSA switch header mentioned in the first paragraph
> will displace the VLAN header when the DSA master receives the frame, so
> __netif_receive_skb_core() will not actually execute any VLAN-specific
> code for it. This only becomes a problem when the DSA switch header does
> not displace the VLAN header (for example with a tail tag).
>
> What the patch does is it bypasses the untagging of the skb when there
> is a DSA switch attached to this net device. So, DSA is the only
> packet_type handler which requires seeing the VLAN header. Once skb->dev
> will be changed, __netif_receive_skb_core() will be invoked again and
> untagging, or delivery to an 8021q upper, will happen in the RX of the
> DSA switch interface itself.
>
> *see commit 9eb8eff0cf2f ("net: bridge: allow enslaving some DSA master
> network devices". This is actually the reason why I prefer keeping DSA
> as a packet_type handler of ETH_P_XDSA rather than converting to an
> rx_handler. Currently the rx_handler code doesn't support chaining, and
> this is a problem because a DSA master might be bridged.
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Florian Fainelli
Applied, thanks.
Re: [PATCH net-next v5 0/6] net-next: dsa: mt7530: add support for MT7531
From: Landen Chao Date: Fri, 11 Sep 2020 21:48:50 +0800 > This patch series adds support for MT7531. > > MT7531 is the next generation of MT7530 which could be found on Mediatek > router platforms such as MT7622 or MT7629. > > It is also a 7-ports switch with 5 giga embedded phys, 2 cpu ports, and > the same MAC logic of MT7530. Cpu port 6 only supports SGMII interface. > Cpu port 5 supports either RGMII or SGMII in different HW SKU, but cannot > be muxed to PHY of port 0/4 like mt7530. Due to support for SGMII > interface, pll, and pad setting are different from MT7530. > > MT7531 SGMII interface can be configured in following mode: > - 'SGMII AN mode' with in-band negotiation capability > which is compatible with PHY_INTERFACE_MODE_SGMII. > - 'SGMII force mode' without in-band negotiation > which is compatible with 10B/8B encoding of > PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause. > - 2.5 times faster clocked 'SGMII force mode' without in-band negotiation > which is compatible with 10B/8B encoding of > PHY_INTERFACE_MODE_2500BASEX with fixed full-duplex and fixed pause. ... Series applied, thank you.
Re: [PATCH net] ipv4: Initialize flowi4_multipath_hash in data path
From: David Ahern
Date: Sun, 13 Sep 2020 12:43:39 -0600
> From: David Ahern
>
> flowi4_multipath_hash was added by the commit referenced below for
> tunnels. Unfortunately, the patch did not initialize the new field
> for several fast path lookups that do not initialize the entire flow
> struct to 0. Fix those locations. Currently, flowi4_multipath_hash
> is random garbage and affects the hash value computed by
> fib_multipath_hash for multipath selection.
>
> Fixes: 24ba14406c5c ("route: Add multipath_hash in flowi_common to make
> user-define hash")
> Signed-off-by: David Ahern
> Cc: wenxu
Applied and queued up for -stable, thanks David.
Re: [PATCH v2 0/4] net: lantiq: Fix bugs in NAPI handling
From: Hauke Mehrtens Date: Sat, 12 Sep 2020 21:36:25 +0200 > This fixes multiple bugs in the NAPI handling. > > Changes since: > v1: > - removed stable tag from "net: lantiq: use netif_tx_napi_add() for TX NAPI" > - Check the NAPI budged in "net: lantiq: Use napi_complete_done()" > - Add extra fix "net: lantiq: Disable IRQs only if NAPI gets scheduled" Series applied and queued up for -stable. Please answer Jakub's question about patch #4. Thanks.
Re: [PATCH net-next] drivers/net/wan/x25_asy: Remove an unnecessary x25_type_trans call
From: Xie He Date: Fri, 11 Sep 2020 19:18:07 -0700 > x25_type_trans only needs to be called before we call netif_rx to pass > the skb to upper layers. > > It does not need to be called before lapb_data_received. The LAPB module > does not need the fields that are set by calling it. > > In the other two X.25 drivers - lapbether and hdlc_x25. x25_type_trans > is only called before netif_rx and not before lapb_data_received. > > Cc: Martin Schiller > Signed-off-by: Xie He Applied to net-next, thanks.
Re: [PATCH] rndis_host: increase sleep time in the query-response loop
From: Olympia Giannou Date: Fri, 11 Sep 2020 14:17:24 + > Some WinCE devices face connectivity issues via the NDIS interface. They > fail to register, resulting in -110 timeout errors and failures during the > probe procedure. > > In this kind of WinCE devices, the Windows-side ndis driver needs quite > more time to be loaded and configured, so that the linux rndis host queries > to them fail to be responded correctly on time. > > More specifically, when INIT is called on the WinCE side - no other > requests can be served by the Client and this results in a failed QUERY > afterwards. > > The increase of the waiting time on the side of the linux rndis host in > the command-response loop leaves the INIT process to complete and respond > to a QUERY, which comes afterwards. The WinCE devices with this special > "feature" in their ndis driver are satisfied by this fix. > > Signed-off-by: Olympia Giannou Applied, thank you.
Re: [PATCH net-next v2] net: try to avoid unneeded backlog flush
From: Paolo Abeni Date: Thu, 10 Sep 2020 23:33:18 +0200 > flush_all_backlogs() may cause deadlock on systems > running processes with FIFO scheduling policy. > > The above is critical in -RT scenarios, where user-space > specifically ensure no network activity is scheduled on > the CPU running the mentioned FIFO process, but still get > stuck. > > This commit tries to address the problem checking the > backlog status on the remote CPUs before scheduling the > flush operation. If the backlog is empty, we can skip it. > > v1 -> v2: > - explicitly clear flushed cpu mask - Eric > > Signed-off-by: Paolo Abeni Applied, thank you.
Re: [PATCH net-next 5/8] bridge: Add SWITCHDEV_FDB_FLUSH_TO_BRIDGE notifier
From: Julian Wiedmann Date: Thu, 10 Sep 2020 19:23:48 +0200 > From: Alexandra Winter > > so the switchdev can notifiy the bridge to flush non-permanent fdb entries > for this port. This is useful whenever the hardware fdb of the switchdev > is reset, but the netdev and the bridgeport are not deleted. > > Note that this has the same effect as the IFLA_BRPORT_FLUSH attribute. > > CC: Jiri Pirko > CC: Ivan Vecera > CC: Roopa Prabhu > CC: Nikolay Aleksandrov > Signed-off-by: Alexandra Winter > Signed-off-by: Julian Wiedmann This still needs review by bridge experts. Thank you.
Re: [PATCH net-next 0/5] mlxsw: Derive SBIB from maximum port speed & MTU
From: Ido Schimmel Date: Sun, 13 Sep 2020 18:46:04 +0300 > From: Ido Schimmel > > Petr says: > > Internal buffer is a part of port headroom used for packets that are > mirrored due to triggers that the Spectrum ASIC considers "egress". Besides > ACL mirroring on port egresss this includes also packets mirrored due to > ECN marking. > > This patchset changes the way the internal mirroring buffer is reserved. > Currently the buffer reflects port MTU and speed accurately. In the future, > mlxsw should support dcbnl_setbuffer hook to allow the users to set buffer > sizes by hand. In that case, there might not be enough space for growth of > the internal mirroring buffer due to MTU and speed changes. While vetoing > MTU changes would be merely confusing, port speed changes cannot be vetoed, > and such change would simply lead to issues in packet mirroring. > > For these reasons, with these patches the internal mirroring buffer is > derived from maximum MTU and maximum speed achievable on the port. > > Patches #1 and #2 introduce a new callback to determine the maximum speed a > given port can achieve. > > With patches #3 and #4, the information about, respectively, maximum MTU > and maximum port speed, is kept in struct mlxsw_sp_port. > > In patch #5, maximum MTU and maximum speed are used to determine the size > of the internal buffer. MTU update and speed update hooks are dropped, > because they are no longer necessary. Series applied, thank you.
Re: [PATCH net-next v5 0/6] 8390: core cleanups
From: Armin Wolf Date: Mon, 14 Sep 2020 23:01:22 +0200 > The purpose of this patchset is to do some > cleanups in lib8390.c and 8390.c A lot of these changes are borderline beneficial, at best. You are adding include files to foo.c files that are already included by lib8390.c already (which the foo.c file includes). This is redundant and makes the compiler work harder. lib8390.c is designed to work like this. Your first patch mixes comment formatting with actual code changes (adding new curly braces and such). And so on and so forth... I honestly don't like this patch series at all. If you were about to add a big new feature to the 8390 code and wanted to clean it up first before doing so, maybe I'd be ok with these changes. But as a pure cleanup, sorry I'm not going to apply this stuff.
Re: [net-next v2 0/5][pull request] 40GbE Intel Wired LAN Driver Updates 2020-09-14
From: Tony Nguyen Date: Mon, 14 Sep 2020 10:32:19 -0700 > This series contains updates to i40e driver only. > > Li RongQing removes binding affinity mask to a fixed CPU and sets > prefetch of Rx buffer page to occur conditionally. > > Björn provides AF_XDP performance improvements by not prefetching HW > descriptors, using 16 byte descriptors, and moving buffer allocation > out of Rx processing loop. > > v2: Define prefetch_page_address in a common header for patch 2. > Dropped, previous, patch 5 as it is being reworked to be more > generalized. > > The following are changes since commit > e059c6f340f6fccadd3db9993f06d4cc51305804: > tulip: switch from 'pci_' to 'dma_' API > and are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE Looks good, pulled, thanks Tony.
Re: [PATCH net-next 0/5] rxrpc: Fixes for the connection manager rewrite
From: David Howells Date: Mon, 14 Sep 2020 16:30:46 +0100 > > Here are some fixes for the connection manager rewrite: > > (1) Fix a goto to the wrong place in error handling. > > (2) Fix a missing NULL pointer check. > > (3) The stored allocation error needs to be stored signed. > > (4) Fix a leak of connection bundle when clearing connections due to > net namespace exit. > > (5) Fix an overget of the bundle when setting up a new client conn. > > The patches are tagged here: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-next-20200914 Pulled, thanks David.
Re: [PATCH net-next] hinic: add vxlan segmentation and cs offload support
From: Luo bin Date: Mon, 14 Sep 2020 21:48:23 +0800 > Add NETIF_F_GSO_UDP_TUNNEL and NETIF_F_GSO_UDP_TUNNEL_CSUM features > to support vxlan segmentation and checksum offload. Ipip and ipv6 > tunnel packets are regarded as non-tunnel pkt for hw and as for other > type of tunnel pkts, checksum offload is disabled. > > Signed-off-by: Luo bin Applied, thank you.
Re: [PATCH net-next] net: pxa168_eth: remove unused variable 'retval' int pxa168_eth_change_mtu()
From: Zhang Changzhong Date: Mon, 14 Sep 2020 21:19:12 +0800 > Fixes the following W=1 kernel build warning(s): > > drivers/net/ethernet/marvell/pxa168_eth.c:1190:6: warning: > variable 'retval' set but not used [-Wunused-but-set-variable] > 1190 | int retval; > | ^~ > > Function pxa168_eth_change_mtu() always return zero, so variable 'retval' > is redundant, just remove it. > > Reported-by: Hulk Robot > Signed-off-by: Zhang Changzhong Applied.
Re: [PATCH net-next] net: qlcnic: remove unused variable 'val' in qlcnic_83xx_cam_unlock()
From: Zhang Changzhong
Date: Mon, 14 Sep 2020 21:24:39 +0800
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c:661:6: warning:
> variable 'val' set but not used [-Wunused-but-set-variable]
> 661 | u32 val;
> | ^~~
>
> After commit 7f9664525f9c ("qlcnic: 83xx memory map and HW access
> routines"), variable 'val' is never used in qlcnic_83xx_cam_unlock(), so
> removing it to avoid build warning.
>
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
Applied.
Re: [PATCH net-next] net: fec: ptp: remove unused variable 'ns' in fec_time_keep()
From: Zhang Changzhong
Date: Mon, 14 Sep 2020 21:14:24 +0800
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/ethernet/freescale/fec_ptp.c:523:6: warning:
> variable 'ns' set but not used [-Wunused-but-set-variable]
> 523 | u64 ns;
> | ^~
>
> After commit 6605b730c061 ("FEC: Add time stamping code and a PTP
> hardware clock"), variable 'ns' is never used in fec_time_keep(),
> so removing it to avoid build warning.
>
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
Applied.
Re: [PATCH net-next] net: dnet: remove unused variable 'tx_status 'in dnet_start_xmit()
From: Zhang Changzhong
Date: Mon, 14 Sep 2020 21:08:37 +0800
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/ethernet/dnet.c:510:6: warning:
> variable 'tx_status' set but not used [-Wunused-but-set-variable]
> u32 tx_status, irq_enable;
> ^
>
> After commit 4796417417a6 ("dnet: Dave DNET ethernet controller driver
> (updated)"), variable 'tx_status' is never used in dnet_start_xmit(),
> so removing it to avoid build warning.
>
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
Applied.
Re: [PATCH net-next] tcp: remove SOCK_QUEUE_SHRUNK
From: Eric Dumazet
Date: Mon, 14 Sep 2020 03:20:27 -0700
> SOCK_QUEUE_SHRUNK is currently used by TCP as a temporary state
> that remembers if some room has been made in the rtx queue
> by an incoming ACK packet.
>
> This is later used from tcp_check_space() before
> considering to send EPOLLOUT.
>
> Problem is: If we receive SACK packets, and no packet
> is removed from RTX queue, we can send fresh packets, thus
> moving them from write queue to rtx queue and eventually
> empty the write queue.
>
> This stall can happen if TCP_NOTSENT_LOWAT is used.
>
> With this fix, we no longer risk stalling sends while holes
> are repaired, and we can fully use socket sndbuf.
>
> This also removes a cache line dirtying for typical RPC
> workloads.
>
> Fixes: c9bee3b7fdec ("tcp: TCP_NOTSENT_LOWAT socket option")
> Signed-off-by: Eric Dumazet
Applied, thanks Eric.
Re: [PATCH net-next v2] net/packet: Fix a comment about hard_header_len and headroom allocation
From: Xie He
Date: Mon, 14 Sep 2020 00:41:54 -0700
> This comment is outdated and no longer reflects the actual implementation
> of af_packet.c.
>
> Reasons for the new comment:
>
> 1.
>
> In af_packet.c, the function packet_snd first reserves a headroom of
> length (dev->hard_header_len + dev->needed_headroom).
> Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header,
> which calls dev->header_ops->create, to create the link layer header.
> If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of
> length (dev->hard_header_len), and checks if the user has provided a
> header sized between (dev->min_header_len) and (dev->hard_header_len)
> (in dev_validate_header).
> This shows the developers of af_packet.c expect hard_header_len to
> be consistent with header_ops.
>
> 2.
>
> In af_packet.c, the function packet_sendmsg_spkt has a FIXME comment.
> That comment states that prepending an LL header internally in a driver
> is considered a bug. I believe this bug can be fixed by setting
> hard_header_len to 0, making the internal header completely invisible
> to af_packet.c (and requesting the headroom in needed_headroom instead).
>
> 3.
>
> There is a commit for a WiFi driver:
> commit 9454f7a895b8 ("mwifiex: set needed_headroom, not hard_header_len")
> According to the discussion about it at:
> https://patchwork.kernel.org/patch/11407493/
> The author tried to set the WiFi driver's hard_header_len to the Ethernet
> header length, and request additional header space internally needed by
> setting needed_headroom.
> This means this usage is already adopted by driver developers.
>
> Cc: Willem de Bruijn
> Cc: Eric Dumazet
> Cc: Brian Norris
> Cc: Cong Wang
> Signed-off-by: Xie He
Applied, thank you.
Re: [PATCH net-next v2 00/13] mptcp: introduce support for real multipath xmit
From: Paolo Abeni Date: Mon, 14 Sep 2020 10:01:06 +0200 > This series enable MPTCP socket to transmit data on multiple subflows > concurrently in a load balancing scenario. > > First the receive code path is refactored to better deal with out-of-order > data (patches 1-7). An RB-tree is introduced to queue MPTCP-level out-of-order > data, closely resembling the TCP level OoO handling. > > When data is sent on multiple subflows, the peer can easily see OoO - "future" > data at the MPTCP level, especially if speeds, delay, or jitter are not > symmetric. > > The other major change regards the netlink PM, which is extended to allow > creating non backup subflows in patches 9-11. > > There are a few smaller additions, like the introduction of OoO related mibs, > send buffer autotuning and better ack handling. > > Finally a bunch of new self-tests is introduced. The new feature is tested > ensuring that the B/W used by an MPTCP socket using multiple subflows matches > the link aggregated B/W - we use low B/W virtual links, to ensure the tests > are not CPU bounded. > > v1 -> v2: > - fix 32 bit build breakage > - fix a bunch of checkpatch issues Looks good, series applied, thanks Paolo.
Re: [RESEND net-next v2 00/12]drivers: net: convert tasklets to use new tasklet_setup() API
From: Allen Pais
Date: Mon, 14 Sep 2020 13:01:19 +0530
> From: Allen Pais
>
> ommit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the net/* drivers to use the new tasklet_setup() API
>
> This series is based on v5.9-rc5
I don't understand how this works, you're not passing the existing
parameter any more so won't that crash until the final parts of the
conversion?
This is like a half-transformation that will break bisection.
I'm not applying this series, sorry.
Re: [net-next v3 00/20] ethernet: convert tasklets to use new tasklet_setup API
From: Allen Pais
Date: Mon, 14 Sep 2020 12:59:19 +0530
> From: Allen Pais
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the crypto modules to use the new tasklet_setup() API
>
> This series is based on v5.9-rc5
>
> v3:
> fix subject prefix
> use backpointer instead of fragile priv to netdev.
>
> v2:
> fix kdoc reported by Jakub Kicinski.
Series applied to net-next, thank you.
Re: [PATCH] tulip: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sun, 13 Sep 2020 14:55:46 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'tulip_init_one()' GFP_KERNEL can be used > because it is a probe function and no lock is taken in the between. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] tulip: dmfe: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sun, 13 Sep 2020 14:38:34 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'dmfe_init_one()' GFP_KERNEL can be used > because it is a probe function and no lock is taken in the between. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] tulip: de2104x: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sun, 13 Sep 2020 14:44:53 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'de_alloc_rings()' GFP_KERNEL can be used > because it is only called from 'de_open()' which is a '.ndo_open' > function. Such functions are synchronized using the rtnl_lock() semaphore > and no lock is taken in the between. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] tulip: uli526x: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sun, 13 Sep 2020 14:30:42 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'uli526x_init_one()' GFP_KERNEL can be used > because it is a probe function and no lock is taken in the between. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH v2] net: fix uninit value error in __sys_sendmmsg
From: Anant Thazhemadam Date: Sun, 13 Sep 2020 16:33:13 +0530 > diff --git a/net/socket.c b/net/socket.c > index 0c0144604f81..1e6f9b54982c 100644 > --- a/net/socket.c > +++ b/net/socket.c > @@ -2398,6 +2398,7 @@ static int ___sys_sendmsg(struct socket *sock, struct > user_msghdr __user *msg, > struct iovec iovstack[UIO_FASTIOV], *iov = iovstack; > ssize_t err; > > + memset(iov, 0, UIO_FASTIOV); > msg_sys->msg_name = &address; Did you even test this? Seriously? UIO_FASTIOV is the number of entries in 'iovstack', it's not the size with would be "UIO_FASTIOV * sizeof (struct iovec)", or even "sizeof(iovstack)" So could you really explain to me how you tested this patch for correctness, and for any functional or performance regressions that may occur? Because, once you correct that size argument to memset() we will now have a huge memset() for _EVERY_ _SINGLE_ sendmsg() done by the system. And that will cause severe performance regressions for many workloads involving networking. This patch submission has been extremely careless on so many levels. I sincerely wish you would take your time with these changes and not be so lacking in the areas of testing and validation. It is always a reg flag when a submitter doesn't even notice an obvious compiler warning that reviewers like Greg and myself can see even without trying to build your code changes.
Re: [PATCH net-next] net: ethernet: mlx4: Avoid assigning a value to ring_cons but not used it anymore in mlx4_en_xmit()
From: Tariq Toukan
Date: Sun, 13 Sep 2020 13:12:05 +0300
>
>
> On 9/13/2020 4:22 AM, David Miller wrote:
>> From: Luo Jiaxing
>> Date: Sat, 12 Sep 2020 16:08:15 +0800
>>
>>> We found a set but not used variable 'ring_cons' in mlx4_en_xmit(), it
>>> will
>>> cause a warning when build the kernel. And after checking the commit
>>> record
>>> of this function, we found that it was introduced by a previous patch.
>>>
>>> So, We delete this redundant assignment code.
>>>
>>> Fixes: 488a9b48e398 ("net/mlx4_en: Wake TX queues only when there's
>>> enough room")
>>>
>>> Signed-off-by: Luo Jiaxing
>> Looks good, applied, thanks.
>>
>
> Hi Luo,
>
> I didn't get a chance to review it during the weekend.
Tariq, what are you even commenting on? Are you responding to this patch
which removes a %100 obviously unused variable set, or on the commit
mentioned in the Fixes: tag?
> The ring_cons local variable is used in line 903:
> https://elixir.bootlin.com/linux/v5.9-rc4/source/drivers/net/ethernet/mellanox/mlx4/en_tx.c#L903
He is removing an assignment to ring_cons much later in the function
and therefore has no effect on this line.
> 1. Your patch causes a degradation to the case when MLX4_EN_PERF_STAT
> is defined.
This is not true, see above.
Re: [PATCH V1 net-next 2/8] net: ena: Add device distinct log prefix to files
From: Shay Agroskin Date: Sun, 13 Sep 2020 11:16:34 +0300 > ENA logs are adjusted to display the full ENA representation to > distinct each ENA device in case of multiple interfaces. > Using dev_err/warn/info function family for logging provides uniform > printing with clear distinction of the driver and device. > > This patch changes all printing in ena_com files to use dev_* logging > messages. It also adds some log messages to make driver debugging > easier. > > Signed-off-by: Amit Bernstein > Signed-off-by: Shay Agroskin This device prefix is so much less useful than printing the actual networking adapter that the ena_com operations are for. So if you are going to do this, go all the way and pass the ena_adapter or the netdev down into these ena_com routines so that you can use the netdev_*() message helpers. Thank you.
Re: [Linux-kernel-mentees] [PATCH] net: fix uninit value error in __sys_sendmmsg
From: Anant Thazhemadam Date: Sun, 13 Sep 2020 11:50:52 +0530 > My apologies. I think I ended up overlooking the build warning. You "think" you overlooked the build warning? You don't actually know? If you aren't willing to even make sure the build is clean after your changes, why should we be willing to review and integrate your changes? This kind of carelessness costs other developers their valuable time, please treat it with more respect than you have. Thank you.
Re: [PATCH net-next] net: mvpp2: set SKBTX_IN_PROGRESS
From: Russell King Date: Sun, 13 Sep 2020 08:05:52 +0100 > Richard Cochran points out that SKBTX_IN_PROGRESS should be set when > the skbuff is queued for timestamping. Add this. > > Signed-off-by: Russell King Applied.
Re: [PATCH] tulip: windbond-840: Fix a debug message
From: Christophe JAILLET Date: Sun, 13 Sep 2020 09:01:07 +0200 > 'w89c840_open()' is incorrectly reported in a debug message. Use __func__ > instead. > > While at it, fix some style issue in the same function. > > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] tulip: windbond-840: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sun, 13 Sep 2020 08:57:11 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'alloc_ringdesc()' GFP_KERNEL can be used > because it is only called from 'netdev_open()' which is a '.ndo_open' > function. Such functions are synchronized using the rtnl_lock() semaphore > and no lock is taken in the between. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] net: dl2k: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sun, 13 Sep 2020 08:14:17 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'rio_probe1()' GFP_KERNEL can be used because > it is a probe function and no lock is taken in the between. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH V2] natsemi: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sun, 13 Sep 2020 07:46:28 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'alloc_ring()' (natsemi.c) GFP_KERNEL can be > used because it is only called from 'netdev_open()', which is a '.ndo_open' > function. Such function are synchronized with the rtnl_lock() semaphore. > > When memory is allocated in 'ns83820_init_one()' (ns83820.c) GFP_KERNEL can > be used because it is a probe function and no lock is taken in the between. ... > Signed-off-by: Christophe JAILLET > --- > If needed, see post from Christoph Hellwig on the kernel-janitors ML: >https://marc.info/?l=kernel-janitors&m=158745678307186&w=4 > > V2: fix description (duplicated comment and wrong file name) Applied, thank you.
Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"
From: Geert Uytterhoeven Date: Sat, 12 Sep 2020 14:33:59 +0200 > "dev" is not the bridge device, but the physical Ethernet interface, which > may already be suspended during s2ram. Hmmm, ok. Looking more deeply NETDEV_CHANGE causes br_port_carrier_check() to run which exits early if netif_running() is false, which is going to be true if netif_device_present() is false: *notified = false; if (!netif_running(br->dev)) return; The only other work the bridge notifier does is: if (event != NETDEV_UNREGISTER) br_vlan_port_event(p, event); and: /* Events that may cause spanning tree to refresh */ if (!notified && (event == NETDEV_CHANGEADDR || event == NETDEV_UP || event == NETDEV_CHANGE || event == NETDEV_DOWN)) br_ifinfo_notify(RTM_NEWLINK, NULL, p); So some vlan stuff, and emitting a netlink message to any available listeners. Should we really do all of this for a device which is not even present? This whole situation seems completely illogical. The device is useless, it logically has no link or other state that can be managed or used, while it is not present. So all of these bridge operations should only happen when the device transitions back to present again.
Re: [PATCH] rocker: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sat, 12 Sep 2020 13:44:18 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'rocker_dma_ring_create()' GFP_KERNEL can be > used because it is already used in the same function just a few lines > above. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] net: tehuti: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sat, 12 Sep 2020 16:12:32 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'bdx_fifo_init()' GFP_ATOMIC must be used > because it can be called from a '.ndo_set_rx_mode' function. Such functions > hold the 'netif_addr_lock' spinlock. > > .ndo_set_rx_mode (see struct net_device_ops) > --> bdx_change_mtu > --> bdx_open > --> bdx_rx_init > --> bdx_tx_init > --> bdx_fifo_init ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] sc92031: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sat, 12 Sep 2020 13:28:58 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'sc92031_open()' GFP_KERNEL can be used > because it is a '.ndo_open' function and no lock is taken in the between. > '.ndo_open' functions are synchronized with the rtnl_lock() semaphore. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] tlan: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sat, 12 Sep 2020 09:43:58 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'tlan_init()' GFP_KERNEL can be used because > it is only called from a probe function or a module_init function and no > lock is taken in the between. > The call chain is: > tlan_probe(module_init function) > --> tlan_eisa_probe > or > tlan_init_one (probe function) > > then in both cases: > --> tlan_probe1 > --> tlan_init > ... > Signed-off-by: Christophe JAILLET Applied.
Re: [Linux-kernel-mentees] [PATCH net] tipc: Fix memory leak in tipc_group_create_member()
From: Peilin Ye Date: Sat, 12 Sep 2020 06:22:30 -0400 > @@ -291,10 +291,11 @@ static void tipc_group_add_to_tree(struct tipc_group > *grp, > else if (key > nkey) > n = &(*n)->rb_right; > else > - return; > + return -1; Use a real error code like "-EEXIST", thank you.
Re: [PATCH net-next] net: ethernet: mlx4: Avoid assigning a value to ring_cons but not used it anymore in mlx4_en_xmit()
From: Luo Jiaxing
Date: Sat, 12 Sep 2020 16:08:15 +0800
> We found a set but not used variable 'ring_cons' in mlx4_en_xmit(), it will
> cause a warning when build the kernel. And after checking the commit record
> of this function, we found that it was introduced by a previous patch.
>
> So, We delete this redundant assignment code.
>
> Fixes: 488a9b48e398 ("net/mlx4_en: Wake TX queues only when there's enough
> room")
>
> Signed-off-by: Luo Jiaxing
Looks good, applied, thanks.
Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"
From: Geert Uytterhoeven Date: Fri, 11 Sep 2020 08:32:55 +0200 > Hi David, > > On Thu, Sep 10, 2020 at 9:20 PM David Miller wrote: >> From: Geert Uytterhoeven >> Date: Tue, 1 Sep 2020 17:02:37 +0200 >> >> > This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c. >> > >> > Inami-san reported that this commit breaks bridge support in a Xen >> > environment, and that reverting it fixes this. >> > >> > During system resume, bridge ports are no longer enabled, as that relies >> > on the receipt of the NETDEV_CHANGE notification. This notification is >> > not sent, as netdev_state_change() is no longer called. >> > >> > Note that the condition this commit intended to fix never existed >> > upstream, as the patch triggering it and referenced in the commit was >> > never applied upstream. Hence I can confirm s2ram on r8a73a4/ape6evm >> > and sh73a0/kzm9g works fine before/after this revert. >> > >> > Reported-by Gaku Inami >> > Signed-off-by: Geert Uytterhoeven >> >> Maybe you cannot reproduce it, but the problem is there and it still >> looks very real to me. >> >> netdev_state_change() does two things: >> >> 1) Emit the NETDEV_CHANGE notification >> >> 2) Emit an rtmsg_ifinfo() netlink message, which in turn tries to access >>the device statistics via ->ndo_get_stats*(). >> >> It is absolutely wrong to do #2 when netif_device_present() is false. >> >> So I cannot apply this patch as-is, sorry. > > Thanks a lot for looking into this! > > But doing #1 is still safe? That is the part that calls into the bridge > code. So would moving the netif_device_present() check from > linkwatch_do_dev() to netdev_state_change(), to prevent doing #2, be > acceptable? I have a better question. Why is a software device like the bridge, that wants to effectively exist and still receive netdev event notifications, marking itself as not present? That's seems like the real bug here.
Re: [PATCH v3 net-next] net: phy: mchp: Add support for LAN8814 QUAD PHY
From: Divya Koppera Date: Fri, 11 Sep 2020 18:48:44 +0530 > LAN8814 is a low-power, quad-port triple-speed (10BASE-T/100BASETX/1000BASE-T) > Ethernet physical layer transceiver (PHY). It supports transmission and > reception of data on standard CAT-5, as well as CAT-5e and CAT-6, unshielded > twisted pair (UTP) cables. > > LAN8814 supports industry-standard QSGMII (Quad Serial Gigabit Media > Independent Interface) and Q-USGMII (Quad Universal Serial Gigabit Media > Independent Interface) providing chip-to-chip connection to four Gigabit > Ethernet MACs using a single serialized link (differential pair) in each > direction. > > The LAN8814 SKU supports high-accuracy timestamping functions to > support IEEE-1588 solutions using Microchip Ethernet switches, as well as > customer solutions based on SoCs and FPGAs. > > The LAN8804 SKU has same features as that of LAN8814 SKU except that it does > not support 1588, SyncE, or Q-USGMII with PCH/MCH. > > This adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T, > QSGMII link with the MAC. > > Signed-off-by: Divya Koppera Applied, thanks.
Re: [PATCH net-next] net: hns: use IRQ_NOAUTOEN to avoid irq is enabled due to request_irq
From: Barry Song Date: Fri, 11 Sep 2020 13:55:10 +1200 > Rather than doing request_irq and then disabling the irq immediately, it > should be safer to use IRQ_NOAUTOEN flag for the irq. It removes any gap > between request_irq() and disable_irq(). > > Cc: Salil Mehta > Reviewed-by: Yunsheng Lin > Signed-off-by: Barry Song Applied.
Re: [PATCH] net: ethernet: ti: cpsw_new: fix suspend/resume
From: Grygorii Strashko
Date: Thu, 10 Sep 2020 23:52:29 +0300
> Add missed suspend/resume callbacks to properly restore networking after
> suspend/resume cycle.
>
> Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based
> driver part 1 - dual-emac")
> Signed-off-by: Grygorii Strashko
Applied and queued up for -stable, thanks.
Re: [PATCH net-next v3 0/9] net: ethernet: ti: ale: add static configuration
From: Grygorii Strashko Date: Thu, 10 Sep 2020 23:27:58 +0300 > As existing, as newly introduced CPSW ALE versions have differences in > supported features and ALE table formats. Especially it's actual for the > recent AM65x/J721E/J7200 and future AM64x SoCs, which supports more > features like: auto-aging, classifiers, Link aggregation, additional HW > filtering, etc. > > The existing ALE configuration interface is not practical in terms of > adding new features and requires consumers to program a lot static > parameters. And any attempt to add new features will case endless adding > and maintaining different combination of flags and options. Because CPSW > ALE configuration is static and fixed for SoC (or set of SoC), It is > reasonable to add support for static ALE configurations inside ALE module. > > This series introduces static ALE configuration table for different ALE > variants and provides option for consumers to select required ALE > configuration by providing ALE const char *dev_id identifier (Patch 2). > And all existing driver have been switched to use new approach (Patches 3-6). > > After this ALE HW auto-ageing feature can be enabled for AM65x CPSW ALE > variant (Patch 7). > > Finally, Patches 8-9 introduces tables to describe the ALE VLAN entries > fields as the ALE VLAN entries are too much differ between different TI > CPSW ALE versions. So, handling them using flags, defines and get/set > functions are became over-complicated. ... Series applied, thank you.
Re: [PATCH v2 net-next 0/4] DSA tag_8021q cleanup
From: Vladimir Oltean Date: Thu, 10 Sep 2020 19:48:53 +0300 > From: Vladimir Oltean > > This small series tries to consolidate the VLAN handling in DSA a little > bit. It reworks tag_8021q to be minimally invasive to the dsa_switch_ops > structure. This makes the rest of the code a bit easier to follow. Series applied, thank you.
Re: [PATCH net] net: ipa: fix u32_replace_bits by u32p_xxx version
From: Vadym Kochan
Date: Thu, 10 Sep 2020 18:41:52 +0300
> Looks like u32p_replace_bits() should be used instead of
> u32_replace_bits() which does not modifies the value but returns the
> modified version.
>
> Fixes: 2b9feef2b6c2 ("soc: qcom: ipa: filter and routing tables")
> Signed-off-by: Vadym Kochan
> Reviewed-by: Alex Elder
Applied and queued up for -stable, thank you.
Re: [net-next] crypto/chcr: move nic TLS functionality to drivers/net
From: Rohit Maheshwari Date: Thu, 10 Sep 2020 19:51:47 +0530 > This patch moves complete nic tls offload (kTLS) code from crypto > directory to drivers/net/ethernet/chelsio/inline_crypto/ch_ktls > directory. nic TLS is made a separate ULD of cxgb4. > > Signed-off-by: Rohit Maheshwari Applied, but... > diff --git a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/Makefile > b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/Makefile > new file mode 100644 > index ..aee3ee884799 > --- /dev/null > +++ b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/Makefile > @@ -0,0 +1,7 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +ccflags-y := -I $(srctree)/drivers/net/ethernet/chelsio/cxgb4 > + > +obj-$(CONFIG_CHELSIO_TLS_DEVICE) += ch_ktls.o > +ch_ktls-objs := chcr_ktls.o > + > + Please avoid empty trailing lines in files.
Re: [PATCH net v1] hinic: fix rewaking txq after netif_tx_disable
From: Luo bin
Date: Thu, 10 Sep 2020 22:04:40 +0800
> When calling hinic_close in hinic_set_channels, all queues are
> stopped after netif_tx_disable, but some queue may be rewaken in
> free_tx_poll by mistake while drv is handling tx irq. If one queue
> is rewaken core may call hinic_xmit_frame to send pkt after
> netif_tx_disable within a short time which may results in accessing
> memory that has been already freed in hinic_close. So we call
> napi_disable before netif_tx_disable in hinic_close to fix this bug.
>
> Fixes: 2eed5a8b614b ("hinic: add set_channels ethtool_ops support")
> Signed-off-by: Luo bin
> ---
> V0~V1:
> - call napi_disable before netif_tx_disable instead of judging whether
> the netdev is in down state before waking txq in free_tx_poll to fix
> this bug
Applied and queued up for -stable, thank you.
Re: [PATCH net v1] taprio: Fix allowing too small intervals
From: Vinicius Costa Gomes
Date: Wed, 9 Sep 2020 17:03:11 -0700
> It's possible that the user specifies an interval that couldn't allow
> any packet to be transmitted. This also avoids the issue of the
> hrtimer handler starving the other threads because it's running too
> often.
>
> The solution is to reject interval sizes that according to the current
> link speed wouldn't allow any packet to be transmitted.
>
> Reported-by: syzbot+8267241609ae8c23b...@syzkaller.appspotmail.com
> Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
> Signed-off-by: Vinicius Costa Gomes
Applied and queued up for -stable, thanks.
Re: [RESEND net 0/4][pull request] Intel Wired LAN Driver Updates 2020-09-09
From: Tony Nguyen Date: Fri, 11 Sep 2020 16:22:03 -0700 > This series contains updates to i40e and igc drivers. > > Stefan Assmann changes num_vlans to u16 to fix may be used uninitialized > error and propagates error in i40_set_vsi_promisc() for i40e. > > Vinicius corrects timestamping latency values for i225 devices and > accounts for TX timestamping delay for igc. > > The following are changes since commit > b87f9fe1ac9441b75656dfd95eba70ef9f0375e0: > hsr: avoid newline end of message in NL_SET_ERR_MSG_MOD > and are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue 40GbE Pulled, thank you.
Re: [PATCH v2 net-next 0/7] sfc: encap offloads on EF10
From: Jakub Kicinski Date: Fri, 11 Sep 2020 16:07:26 -0700 > On Fri, 11 Sep 2020 23:37:10 +0100 Edward Cree wrote: >> EF10 NICs from the 8000 series onwards support TX offloads (checksumming, >> TSO) on VXLAN- and NVGRE-encapsulated packets. This series adds driver >> support for these offloads. >> >> Changes from v1: >> * Fix 'no TXQ of type' error handling in patch #1 (and clear up the >>misleading comment that inspired the wrong version) >> * Add comment in patch #5 explaining what the deal with TSOv3 is > > Reviewed-by: Jakub Kicinski Series applied, thanks.
Re: [PATCH net-next] octeontx2-af: Constify npc_kpu_profile_{action,cam}
From: Rikard Falkeborn Date: Sat, 12 Sep 2020 00:00:15 +0200 > These are never modified, so constify them to allow the compiler to > place them in read-only memory. This moves about 25kB to read-only > memory as seen by the output of the size command. > > Before: >textdata bss dec hex filename > 296203 654641248 362915 589a3 > drivers/net/ethernet/marvell/octeontx2/af/octeontx2_af.ko > > After: >textdata bss dec hex filename > 321003 406641248 362915 589a3 > drivers/net/ethernet/marvell/octeontx2/af/octeontx2_af.ko > > Signed-off-by: Rikard Falkeborn Applied, thank you.
Re: [PATCH net-next 0/3] sfc: misc cleanups
From: Jakub Kicinski Date: Fri, 11 Sep 2020 14:00:38 -0700 > On Fri, 11 Sep 2020 19:43:26 +0100 Edward Cree wrote: >> Clean up a few nits I noticed while working on TXQ stuff. > > Reviewed-by: Jakub Kicinski Series applied.
Re: [PATCH net-next] bridge: mcast: Fix incomplete MDB dump
From: Ido Schimmel
Date: Fri, 11 Sep 2020 16:24:47 +0300
> From: Ido Schimmel
>
> Each MDB entry is encoded in a nested netlink attribute called
> 'MDBA_MDB_ENTRY'. In turn, this attribute contains another nested
> attributed called 'MDBA_MDB_ENTRY_INFO', which encodes a single port
> group entry within the MDB entry.
>
> The cited commit added the ability to restart a dump from a specific
> port group entry. However, on failure to add a port group entry to the
> dump the entire MDB entry (stored in 'nest2') is removed, resulting in
> missing port group entries.
>
> Fix this by finalizing the MDB entry with the partial list of already
> encoded port group entries.
>
> Fixes: 5205e919c9f0 ("net: bridge: mcast: add support for src list and filter
> mode dumping")
> Signed-off-by: Ido Schimmel
> Acked-by: Nikolay Aleksandrov
> Reviewed-by: Jiri Pirko
Applied, thank you.
Re: [PATCH] ipv6: remove redundant assignment to variable err
From: Colin King
Date: Fri, 11 Sep 2020 11:35:09 +0100
> From: Colin Ian King
>
> The variable err is being initialized with a value that is never read and
> it is being updated later with a new value. The initialization is redundant
> and can be removed. Also re-order variable declarations in reverse
> Christmas tree ordering.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Applied.
Re: [PATCH net] enetc: Fix mdio bus removal on PF probe bailout
From: Claudiu Manoil
Date: Fri, 11 Sep 2020 13:16:35 +0300
> This is the correct resolution for the conflict from
> merging the "net" tree fix:
> commit 26cb7085c898 ("enetc: Remove the mdio bus on PF probe bailout")
> with the "net-next" new work:
> commit 07095c025ac2 ("net: enetc: Use DT protocol information to set up the
> ports")
> that moved mdio bus allocation to an ealier stage of
> the PF probing routine.
>
> Fixes: a57066b1a019 ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net")
> Signed-off-by: Claudiu Manoil
Applied, thanks for catching this.
Re: [PATCH v1 0/2] ag71xx: add ethtool and flow control support
From: Oleksij Rempel Date: Fri, 11 Sep 2020 10:25:26 +0200 > The main target of this patches is to provide flow control support > for ag71xx driver. To be able to validate this functionality, I also > added ethtool support with HW counters. So, this patches was validated > with iperf3 and counters showing Pause frames send or received by this > NIC. Series applied, thank you.
Re: [PATCH net-next] drivers/net/wan/x25_asy: Remove an unused flag "SLF_OUTWAIT"
From: Xie He Date: Thu, 10 Sep 2020 23:35:03 -0700 > The "SLF_OUTWAIT" flag defined in x25_asy.h is not actually used. > It is only cleared at one place in x25_asy.c but is never read or set. > So we can remove it. > > Signed-off-by: Xie He Applied, it looks like this code wss based upon the slip.c code.
Re: [PATCH net-next] net/socket.c: Remove an unused header file
From: Xie He Date: Thu, 10 Sep 2020 23:07:20 -0700 > This header file is not actually used in this file. Let's remove it. How did you test this assertion? As Jakub showed, the dlci_ioctl_set() function needs to be declared because socket.c references it. All of your visual scanning of the code is wasted if you don't do something simple like an "allmodconfig" or "allyesconfig" build to test whether your change is correct or not. Don't leave that step for us, that's your responsibility.
Re: [PATCH net-next] net: dsa: b53: Configure VLANs while not filtering
From: Florian Fainelli Date: Fri, 11 Sep 2020 11:28:27 -0700 > > > On 9/10/2020 9:19 PM, Florian Fainelli wrote: >> Update the B53 driver to support VLANs while not filtering. This >> requires us to enable VLAN globally within the switch upon driver >> initial configuration (dev->vlan_enabled). >> We also need to remove the code that dealt with PVID re-configuration >> in >> b53_vlan_filtering() since that function worked under the assumption >> that it would only be called to make a bridge VLAN filtering, or not >> filtering, and we would attempt to move the port's PVID accordingly. >> Now that VLANs are programmed all the time, even in the case of a >> non-VLAN filtering bridge, we would be programming a default_pvid for >> the bridged switch ports. >> Signed-off-by: Florian Fainelli > > David, Jakub, please hold off applying this just yet, Vladimir has > submitted another patch for testing that would be IMHO a better way to > deal with DSA switches that have an egress tagged > default_pvid. Depending on the outcome of that patch, I will resubmit > this one or request that you apply it. Ok.
Re: [PATCH net-next] net: stmmac: set get_rx_header_len() as void for it didn't have any error code to return
From: Luo Jiaxing Date: Fri, 11 Sep 2020 11:55:58 +0800 > We found the following warning when using W=1 to build kernel: > > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3634:6: warning: variable > ‘ret’ set but not used [-Wunused-but-set-variable] > int ret, coe = priv->hw->rx_csum; > > When digging stmmac_get_rx_header_len(), dwmac4_get_rx_header_len() and > dwxgmac2_get_rx_header_len() return 0 only, without any error code to > report. Therefore, it's better to define get_rx_header_len() as void. > > Signed-off-by: Luo Jiaxing Applied, thank you.
Re: [PATCH net-next v4 0/8] Add GVE Features.
From: Jakub Kicinski Date: Fri, 11 Sep 2020 13:55:33 -0700 > On Fri, 11 Sep 2020 10:38:43 -0700 David Awogbemila wrote: >> Note: Patch 4 in v3 was dropped. >> >> Patch 4 (patch 5 in v3): Start/stop timer only when report stats is >> enabled/disabled. >> Patch 7 (patch 8 in v3): Use netdev_info, not dev_info, to log >> device link status. > > Acked-by: Jakub Kicinski Series applied, thanks everyone.
Re: pull-request: wireless-drivers-next-2020-09-11
From: Kalle Valo Date: Fri, 11 Sep 2020 15:27:13 + > here's a pull request to net-next tree, more info below. Please let me know if > there are any problems. Pulled, thanks a lot Kalle.
Re: [PATCH v2 01/20] ethernet: alteon: convert tasklets to use new tasklet_setup() API
From: Allen Date: Fri, 11 Sep 2020 15:30:41 +0530 >> Just add a backpointer to the netdev from the netdev_priv() if you >> absolutely have too. >> > > How does this look? Looks good.
Re: [PATCH 0/8] drivers: net: convert tasklets to use new tasklet_setup()
From: Allen Date: Fri, 11 Sep 2020 11:26:52 +0530 > Will you pick these up or should I send these out again when I > have fixed the two patches on the other thread. Always resend.
Re: [PATCH net] net: dec: de2104x: Increase receive ring size for Tulip
From: Lucy Yan Date: Thu, 10 Sep 2020 12:05:09 -0700 > Increase Rx ring size to address issue where hardware is reaching > the receive work limit. > > Before: > > [ 102.223342] de2104x :17:00.0 eth0: rx work limit reached > [ 102.245695] de2104x :17:00.0 eth0: rx work limit reached > [ 102.251387] de2104x :17:00.0 eth0: rx work limit reached > [ 102.267444] de2104x :17:00.0 eth0: rx work limit reached > > Signed-off-by: Lucy Yan Applied, thank you.
Re: [PATCH net-next] net: mvpp2: Initialize link in mvpp2_isr_handle_{xlg,gmac_internal}
From: Nathan Chancellor
Date: Thu, 10 Sep 2020 10:48:27 -0700
> Clang warns (trimmed for brevity):
>
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:3073:7: warning:
> variable 'link' is used uninitialized whenever 'if' condition is false
> [-Wsometimes-uninitialized]
> if (val & MVPP22_XLG_STATUS_LINK_UP)
> ^~~
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:3075:31: note:
> uninitialized use occurs here
> mvpp2_isr_handle_link(port, link);
> ^~~~
> ...
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:3090:8: warning:
> variable 'link' is used uninitialized whenever 'if' condition is false
> [-Wsometimes-uninitialized]
> if (val & MVPP2_GMAC_STATUS0_LINK_UP)
> ^~~~
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:3092:32: note:
> uninitialized use occurs here
> mvpp2_isr_handle_link(port, link);
> ^~~~
>
> Initialize link to false like it was before the refactoring that
> happened around link status so that a valid valid is always passed into
> mvpp2_isr_handle_link.
>
> Fixes: 36cfd3a6e52b ("net: mvpp2: restructure "link status" interrupt
> handling")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1151
> Signed-off-by: Nathan Chancellor
This got fixed via another change, a much mode simply one in fact,
changing the existing assignments to be unconditional and of the
form "link = (bits & MASK);"
Re: [PATCH net-next 00/10] net/smc: updates 2020-09-10
From: Karsten Graul Date: Thu, 10 Sep 2020 18:48:19 +0200 > Please apply the following patch series for smc to netdev's net-next tree. > > This patch series is a mix of various improvements and cleanups. > The patches 1 and 10 improve the handling of large parallel workloads. > Patch 8 corrects a kernel config default for config CCWGROUP on s390. > Patch 9 allows userspace tools to retrieve socket information for more > sockets. Series applied, thank you.
Re: [PATCH v3 0/8] nfc: s3fwrn5: Few cleanups
From: Krzysztof Kozlowski Date: Thu, 10 Sep 2020 18:12:11 +0200 > Changes since v2: > 1. Fix dtschema ID after rename (patch 1/8). > 2. Apply patch 9/9 (defconfig change). > > Changes since v1: > 1. Rename dtschema file and add additionalProperties:false, as Rob >suggested, > 2. Add Marek's tested-by, > 3. New patches: #4, #5, #6, #7 and #9. Seires applied to net-next, thanks.
Re: [PATCH net-next 0/6] Fix some kernel-doc warnings for hns
From: Wang Hai Date: Thu, 10 Sep 2020 22:56:14 +0800 > Fix some kernel-doc warnings for hns. Series applied to net-next, thanks.
Re: [PATCH] net: mvpp2: ptp: Fix unused variables
From: Alex Dewar
Date: Thu, 10 Sep 2020 14:49:10 +0100
> In the functions mvpp2_isr_handle_xlg() and
> mvpp2_isr_handle_gmac_internal(), the bool variable link is assigned a
> true value in the case that a given bit of val is set. However, if the
> bit is unset, no value is assigned to link and it is then passed to
> mvpp2_isr_handle_link() without being initialised. Fix by assigning to
> link the value of the bit test.
>
> Build-tested on x86.
>
> Fixes: 36cfd3a6e52b ("net: mvpp2: restructure "link status" interrupt
> handling")
> Signed-off-by: Alex Dewar
Applied to net-next.
Re: [PATCH net-next] net: cxgb3: Fix some kernel-doc warnings
From: Wang Hai Date: Thu, 10 Sep 2020 21:36:16 +0800 > Fixes the following W=1 kernel build warning(s): > > drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:2209: warning: Excess function > parameter 'adapter' description in 'clear_sge_ctxt' > drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:2975: warning: Excess function > parameter 'adapter' description in 't3_set_proto_sram' > > Reported-by: Hulk Robot > Signed-off-by: Wang Hai Applied.
Re: [PATCH net] netlink: fix doc about nlmsg_parse/nla_validate
From: Nicolas Dichtel
Date: Thu, 10 Sep 2020 15:34:39 +0200
> There is no @validate argument.
>
> CC: Johannes Berg
> Fixes: 3de644035446 ("netlink: re-add parse/validate functions in strict
> mode")
> Signed-off-by: Nicolas Dichtel
Applied, thank you.
Re: [PATCH V4 net-next 0/4] Enhance current features in ena driver
From: Date: Thu, 10 Sep 2020 13:07:09 + > From: Sameeh Jubran > > This series adds the following: > * Exposes new device stats using ethtool. > * Adds and exposes the stats of xdp TX queues through ethtool. > > V3: Fix indentation in patches #3 and #4 > V2: Drop the need for casting stat_offset > V1: Use unsigned long for pointer math instead of uintptr_t Series applied, thank you.
Re: [PATCH net] net: DCB: Validate DCB_ATTR_DCB_BUFFER argument
From: Petr Machata
Date: Thu, 10 Sep 2020 14:09:05 +0200
> The parameter passed via DCB_ATTR_DCB_BUFFER is a struct dcbnl_buffer. The
> field prio2buffer is an array of IEEE_8021Q_MAX_PRIORITIES bytes, where
> each value is a number of a buffer to direct that priority's traffic to.
> That value is however never validated to lie within the bounds set by
> DCBX_MAX_BUFFERS. The only driver that currently implements the callback is
> mlx5 (maintainers CCd), and that does not do any validation either, in
> particual allowing incorrect configuration if the prio2buffer value does
> not fit into 4 bits.
>
> Instead of offloading the need to validate the buffer index to drivers, do
> it right there in core, and bounce the request if the value is too large.
>
> CC: Parav Pandit
> CC: Saeed Mahameed
> Fixes: e549f6f9c098 ("net/dcb: Add dcbnl buffer attribute")
> Signed-off-by: Petr Machata
> Reviewed-by: Ido Schimmel
> Reviewed-by: Jiri Pirko
Applied and queued up for -stable, thank you.
Re: [PATCH net 0/2] net: Fix bridge enslavement failure
From: Ido Schimmel Date: Thu, 10 Sep 2020 14:01:25 +0300 > From: Ido Schimmel > > Patch #1 fixes an issue in which an upper netdev cannot be enslaved to a > bridge when it has multiple netdevs with different parent identifiers > beneath it. > > Patch #2 adds a test case using two netdevsim instances. Series applied and patch #1 queued up for -stable, thank you.
Re: [PATCH v2] macsec: Support 32bit PN netlink attribute for XPN links
From: Era Mayflower
Date: Thu, 10 Sep 2020 09:56:09 +
> - pn_len = secy->xpn ? MACSEC_XPN_PN_LEN : MACSEC_DEFAULT_PN_LEN;
> - if (nla_len(tb_sa[MACSEC_SA_ATTR_PN]) != pn_len) {
> - pr_notice("macsec: nl: upd_rxsa: bad pn length: %d !=
> %d\n",
> - nla_len(tb_sa[MACSEC_SA_ATTR_PN]), pn_len);
> + pr_notice("macsec: nl: upd_rxsa: pn length on non-xpn
> links must be %d\n",
> + MACSEC_DEFAULT_PN_LEN);
> + rtnl_unlock();
> + return -EINVAL;
> +
> + default:
> + pr_notice("macsec: nl: upd_rxsa: pn length must be %d
> or %d\n",
> + MACSEC_DEFAULT_PN_LEN, MACSEC_XPN_PN_LEN);
> rtnl_unlock();
Please do not spam the kernel log like this. Instead, report this
info via netlink extended ACKs.
Thank you.
Re: [PATCH net] net: mvneta: fix possible use-after-free in mvneta_xdp_put_buff
From: Lorenzo Bianconi
Date: Thu, 10 Sep 2020 11:08:01 +0200
> Release first buffer as last one since it contains references
> to subsequent fragments. This code will be optimized introducing
> multi-buffer bit in xdp_buff structure.
>
> Fixes: ca0e014609f05 ("net: mvneta: move skb build after descriptors
> processing")
> Signed-off-by: Lorenzo Bianconi
Applied, thank you.
Re: [PATCH v2] net: Correct the comment of dst_dev_put()
From: Miaohe Lin
Date: Thu, 10 Sep 2020 04:41:53 -0400
> Since commit 8d7017fd621d ("blackhole_netdev: use blackhole_netdev to
> invalidate dst entries"), we use blackhole_netdev to invalidate dst entries
> instead of loopback device anymore.
>
> Signed-off-by: Miaohe Lin
Applied, thanks.
Re: [PATCH net] s390/qeth: delay draining the TX buffers
From: Julian Wiedmann
Date: Thu, 10 Sep 2020 11:05:18 +0200
> Wait until the QDIO data connection is severed. Otherwise the device
> might still be processing the buffers, and end up accessing skb data
> that we already freed.
>
> Fixes: 8b5026bc1693 ("s390/qeth: fix qdio teardown after early init error")
> Signed-off-by: Julian Wiedmann
Applied.
Re: [PATCH] net: Fix broken NETIF_F_CSUM_MASK spell in netdev_features.h
From: Miaohe Lin Date: Thu, 10 Sep 2020 04:46:40 -0400 > Remove the weird space inside the NETIF_F_CSUM_MASK. > > Signed-off-by: Miaohe Lin Applied.
Re: [PATCH net-next 0/3] tcp: add tos reflection feature
From: Wei Wang Date: Wed, 9 Sep 2020 17:50:45 -0700 > This patch series adds a new tcp feature to reflect TOS value received in > SYN, and send it out in SYN-ACK, and eventually set the TOS value of the > established socket with this reflected TOS value. This provides a way to > set the traffic class/QoS level for all traffic in the same connection > to be the same as the incoming SYN. It could be useful for datacenters > to provide equivalent QoS according to the incoming request. > This feature is guarded by /proc/sys/net/ipv4/tcp_reflect_tos, and is by > default turned off. > > Wei Wang (3): > tcp: record received TOS value in the request socket > ip: pass tos into ip_build_and_send_pkt() > tcp: reflect tos value received in SYN to the socket This looks good, series applied, thanks.
Re: [PATCH net-next] net: mventa: drop mvneta_stats from mvneta_swbm_rx_frame signature
From: Lorenzo Bianconi Date: Wed, 9 Sep 2020 23:05:23 +0200 > Remove mvneta_stats from mvneta_swbm_rx_frame signature since now stats > are accounted in mvneta_run_xdp routine > > Signed-off-by: Lorenzo Bianconi Applied, thanks.
Re: [net-next v4 0/5] devlink flash update overwrite mask
From: Jacob Keller Date: Wed, 9 Sep 2020 15:26:48 -0700 > This series introduces support for a new attribute to the flash update > command: DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK. I think you really need to get rid of BIT() usage in the UAPI header as Jakub mentioned.
Re: [PATCH net-next 0/3] netpoll: make sure napi_list is safe for RCU traversal
From: Jakub Kicinski
Date: Wed, 9 Sep 2020 10:37:50 -0700
> This series is a follow-up to the fix in commit 96e97bc07e90 ("net:
> disable netpoll on fresh napis"). To avoid any latent race conditions
> convert dev->napi_list to a proper RCU list. We need minor restructuring
> because it looks like netif_napi_del() used to be idempotent, and
> it may be quite hard to track down everyone who depends on that.
Series applied, thanks Jakub.
Re: [PATCH v2 net] hdlc_ppp: add range checks in ppp_cp_parse_cr()
From: Dan Carpenter
Date: Wed, 9 Sep 2020 12:46:48 +0300
> There are a couple bugs here:
> 1) If opt[1] is zero then this results in a forever loop. If the value
>is less than 2 then it is invalid.
> 2) It assumes that "len" is more than sizeof(valid_accm) or 6 which can
>result in memory corruption.
>
> In the case of LCP_OPTION_ACCM, then we should check "opt[1]" instead
> of "len" because, if "opt[1]" is less than sizeof(valid_accm) then
> "nak_len" gets out of sync and it can lead to memory corruption in the
> next iterations through the loop. In case of LCP_OPTION_MAGIC, the
> only valid value for opt[1] is 6, but the code is trying to log invalid
> data so we should only discard the data when "len" is less than 6
> because that leads to a read overflow.
>
> Reported-by: ChenNan Of Chaitin Security Research Lab
> Fixes: e022c2f07ae5 ("WAN: new synchronous PPP implementation for generic
> HDLC.")
> Signed-off-by: Dan Carpenter
> Reviewed-by: Eric Dumazet
> Reviewed-by: Greg Kroah-Hartman
> ---
> v2: check opt[1] < 6 instead of len < 6 for the LCP_OPTION_ACCM case.
Applied and queued up for -stable, thanks Dan.
Re: [PATCH v2 RESEND] net: phy: call phy_disable_interrupts() in phy_attach_direct() instead
From: Yoshihiro Shimoda
Date: Wed, 9 Sep 2020 14:43:14 +0900
> Since the micrel phy driver calls phy_init_hw() as a workaround,
> the commit 9886a4dbd2aa ("net: phy: call phy_disable_interrupts()
> in phy_init_hw()") disables the interrupt unexpectedly. So,
> call phy_disable_interrupts() in phy_attach_direct() instead.
> Otherwise, the phy cannot link up after the ethernet cable was
> disconnected.
>
> Note that other drivers (like at803x.c) also calls phy_init_hw().
> So, perhaps, the driver caused a similar issue too.
>
> Fixes: 9886a4dbd2aa ("net: phy: call phy_disable_interrupts() in
> phy_init_hw()")
> Signed-off-by: Yoshihiro Shimoda
> ---
> Changes from v1:
> - Fix build failure. I used two PCs: PC 1) for testing, PC 2) for
>submitting patches. I tested on the PC 1. But, after that, I wrote
>a patch on the PC2 again, and it seemed I didn't do a compile...
>Today, I got some emails from kernel test bot. So, I realized
>I had submitted an awful patch. To avoid such failure, I'll use
>one PC only from now on.
>
Applied and queued up for -stable, thanks.
Re: [PATCH net 1/2] hv_netvsc: Switch the data path at the right time during hibernation
From: Dexuan Cui
Date: Tue, 8 Sep 2020 21:07:32 -0700
> When netvsc_resume() is called, the mlx5 VF NIC has not been resumed yet,
> so in the future the host might sliently fail the call netvsc_vf_changed()
> -> netvsc_switch_datapath() there, even if the call works now.
>
> Call netvsc_vf_changed() in the NETDEV_CHANGE event handler: at that time
> the mlx5 VF NIC has been resumed.
>
> Fixes: 19162fd4063a ("hv_netvsc: Fix hibernation for mlx5 VF driver")
> Signed-off-by: Dexuan Cui
Applied.
Re: [PATCH net 2/2] hv_netvsc: Cache the current data path to avoid duplicate call and message
From: Dexuan Cui Date: Tue, 8 Sep 2020 21:08:19 -0700 > The previous change "hv_netvsc: Switch the data path at the right time > during hibernation" adds the call of netvsc_vf_changed() upon > NETDEV_CHANGE, so it's necessary to avoid the duplicate call and message > when the VF is brought UP or DOWN. > > Signed-off-by: Dexuan Cui Applied.
Re: [PATCH net-next v2 0/2] mlx4: avoid devlink port type not set warnings
From: Jakub Kicinski Date: Tue, 8 Sep 2020 15:21:12 -0700 > This small set addresses the issue of mlx4 potentially not setting > devlink port type when Ethernet or IB driver is not built, but > port has that type. > > v2: > - add patch 1 Series applied, thank you.
Re: [PATCH net-next] net: mvneta: rely on MVNETA_MAX_RX_BUF_SIZE for pkt split in mvneta_swbm_rx_frame()
From: Lorenzo Bianconi Date: Tue, 8 Sep 2020 20:23:31 +0200 > In order to easily change the rx buffer size, rely on > MVNETA_MAX_RX_BUF_SIZE instead of PAGE_SIZE in mvneta_swbm_rx_frame > routine for rx buffer split. Currently this is not an issue since we set > MVNETA_MAX_RX_BUF_SIZE to PAGE_SIZE - MVNETA_SKB_PAD but it is a good to > have to configure a different rx buffer size. > > Signed-off-by: Lorenzo Bianconi Applied, thanks.
[PATCH] connector: Move maintainence under networking drivers umbrella.
Evgeniy does not have the time nor capacity to maintain the connector subsystem any longer, so just move it under networking as that is effectively what has been happening lately. Signed-off-by: David S. Miller --- MAINTAINERS | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 12be7ae4d989..2783a5f68d2c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4407,12 +4407,6 @@ T: git git://git.infradead.org/users/hch/configfs.git F: fs/configfs/ F: include/linux/configfs.h -CONNECTOR -M: Evgeniy Polyakov -L: netdev@vger.kernel.org -S: Maintained -F: drivers/connector/ - CONSOLE SUBSYSTEM M: Greg Kroah-Hartman S: Supported @@ -12046,6 +12040,7 @@ Q: http://patchwork.ozlabs.org/project/netdev/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git T: git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git F: Documentation/devicetree/bindings/net/ +F: drivers/connector/ F: drivers/net/ F: include/linux/etherdevice.h F: include/linux/fcdevice.h -- 2.26.2
Re: [PATCH v2 net] net: sch_generic: aviod concurrent reset and enqueue op for lockless qdisc
From: Yunsheng Lin
Date: Tue, 8 Sep 2020 19:02:34 +0800
> Currently there is concurrent reset and enqueue operation for the
> same lockless qdisc when there is no lock to synchronize the
> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
> qdisc_deactivate() called by dev_deactivate_queue(), which may cause
> out-of-bounds access for priv->ring[] in hns3 driver if user has
> requested a smaller queue num when __dev_xmit_skb() still enqueue a
> skb with a larger queue_mapping after the corresponding qdisc is
> reset, and call hns3_nic_net_xmit() with that skb later.
>
> Reused the existing synchronize_net() in dev_deactivate_many() to
> make sure skb with larger queue_mapping enqueued to old qdisc(which
> is saved in dev_queue->qdisc_sleeping) will always be reset when
> dev_reset_queue() is called.
>
> Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking")
> Signed-off-by: Yunsheng Lin
> ---
> ChangeLog V2:
> Reuse existing synchronize_net().
Applied and queued up for -stable, thank you.
Re: [PATCH v3] net: dsa: microchip: look for phy-mode in port nodes
From: Helmut Grohne Date: Tue, 8 Sep 2020 10:01:38 +0200 > Documentation/devicetree/bindings/net/dsa/dsa.txt says that the phy-mode > property should be specified on port nodes. However, the microchip > drivers read it from the switch node. > > Let the driver use the per-port property and fall back to the old > location with a warning. > > Fix in-tree users. > > Signed-off-by: Helmut Grohne > Link: https://lore.kernel.org/netdev/20200617082235.GA1523@laureti-dev/ > Acked-by: Alexandre Belloni Applied, thanks.
Re: [MPTCP][PATCH v2 net 0/2] mptcp: fix subflow's local_id/remote_id issues
From: Geliang Tang Date: Tue, 8 Sep 2020 10:49:37 +0800 > v2: > - add Fixes tags; > - simply with 'return addresses_equal'; > - use 'reversed Xmas tree' way. Series applied, thanks.
Re: [MPTCP][PATCH net] mptcp: fix kmalloc flag in mptcp_pm_nl_get_local_id
From: Geliang Tang
Date: Wed, 9 Sep 2020 11:01:24 +0800
> mptcp_pm_nl_get_local_id may be called in interrupt context, so we need to
> use GFP_ATOMIC flag to allocate memory to avoid sleeping in atomic context.
...
> Fixes: 01cacb00b35cb ("mptcp: add netlink-based PM")
> Signed-off-by: Geliang Tang
Applied.
Re: [PATCH net-next v2 0/3] Allow more than 255 IPv4 multicast interfaces
From: Paul Davey Date: Tue, 8 Sep 2020 10:04:05 +1200 > Currently it is not possible to use more than 255 multicast interfaces > for IPv4 due to the format of the igmpmsg header which only has 8 bits > available for the VIF ID. There is space available in the igmpmsg > header to store the full VIF ID in the form of an unused byte following > the VIF ID field. There is also enough space for the full VIF ID in > the Netlink cache notifications, however the value is currently taken > directly from the igmpmsg header and has thus already been truncated. > > Adding the high byte of the VIF ID into the unused3 byte of igmpmsg > allows use of more than 255 IPv4 multicast interfaces. The full VIF ID > is also available in the Netlink notification by assembling it from > both bytes from the igmpmsg. > > Additionally this reveals a deficiency in the Netlink cache report > notifications, they lack any means for differentiating cache reports > relating to different multicast routing tables. This is easily > resolved by adding the multicast route table ID to the cache reports. > > changes in v2: > - Added high byte of VIF ID to igmpmsg struct replacing unused3 >member. > - Assemble VIF ID in Netlink notification from both bytes in igmpmsg >header. Series applied, thank you.
