Re: [PATCH net 6/6] net: dsa: ksz: fix wrong read cast to u64

On Wed, Jan 13, 2021 at 01:45:22PM +0100, Gilles DOFFE wrote: > '(u64)*value' casts a u32 to a u64. So depending on endianness, > LSB or MSB is lost. > The pointer needs to be cast to read the full u64: > '*((u64 *)value)' > > Signed-off-by: Gilles DOFFE > --- Reviewed-by: Vladimir Oltean

[PATCH net 6/6] net: dsa: ksz: fix wrong read cast to u64

'(u64)*value' casts a u32 to a u64. So depending on endianness, LSB or MSB is lost. The pointer needs to be cast to read the full u64: '*((u64 *)value)' Signed-off-by: Gilles DOFFE --- drivers/net/dsa/microchip/ksz_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH net 6/6] rxrpc: Fix server keyring leak

If someone calls setsockopt() twice to set a server key keyring, the first keyring is leaked. Fix it to return an error instead if the server key keyring is already set. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: David

[PATCH net 6/7] afs: Don't use VL probe running state to make decisions outside probe code

Don't use the running state for VL server probes to make decisions about which server to use as the state is cleared at the start of a probe and intermediate values might also be misleading. Instead, add a separate 'latest known' rtt in the afs_vlserver struct and a flag to indicate if the server

[PATCH net 6/9] net: qede: fix PTP initialization on recovery

Currently PTP cyclecounter and timecounter are initialized only on the first probing and are cleaned up during removal. This means that PTP becomes non-functional after device recovery. Fix this by unconditional PTP initialization on probing and clearing Tx pending bit on exiting. Fixes:

[PATCH net 6/6] rxrpc: Fix call crypto state cleanup

Fix the cleanup of the crypto state on a call after the call has been disconnected. As the call has been disconnected, its connection ref has been discarded and so we can't go through that to get to the security ops table. Fix this by caching the security ops pointer in the rxrpc_call struct and

[PATCH net 6/8] net: stmmac: Do not stop PHY if WoL is enabled

If WoL is enabled we can't really stop the PHY, otherwise we will not receive the WoL packet. Fix this by telling phylink that only the MAC is down and only stop the PHY if WoL is not enabled. Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic") Signed-off-by: Jose

[PATCH net 6/7] rxrpc: Use the tx-phase skb flag to simplify tracing

Use the previously-added transmit-phase skbuff private flag to simplify the socket buffer tracing a bit. Which phase the skbuff comes from can now be divined from the skb rather than having to be guessed from the call state. We can also reduce the number of rxrpc_skb_trace values by eliminating

[PATCH net 6/9] rxrpc: Use the tx-phase skb flag to simplify tracing

Use the previously-added transmit-phase skbuff private flag to simplify the socket buffer tracing a bit. Which phase the skbuff comes from can now be divined from the skb rather than having to be guessed from the call state. We can also reduce the number of rxrpc_skb_trace values by eliminating

[PATCH net 6/6] rxrpc: remove unused static variables

From: Sebastian Andrzej Siewior The rxrpc_security_methods and rxrpc_security_sem user has been removed in 648af7fca159 ("rxrpc: Absorb the rxkad security module"). This was noticed by kbuild test robot for the -RT tree but is also true for !RT. Reported-by: kbuild test

[PATCH net 6/6] rxrpc: remove unused static variables

From: Sebastian Andrzej Siewior The rxrpc_security_methods and rxrpc_security_sem user has been removed in 648af7fca159 ("rxrpc: Absorb the rxkad security module"). This was noticed by kbuild test robot for the -RT tree but is also true for !RT. Reported-by: kbuild test robot Signed-off-by:

[PATCH net 6/9] net: hns3: Fix for rx priv buf allocation when DCB is not supported

When hdev doesn't support DCB, rx private buffer is not allocated, otherwise there is not enough buffer for rx shared buffer, causing buffer allocation process to fail. This patch fixes by checking the dcb capability in hclge_rx_buffer_calc. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration

[PATCH net 6/9] net: hns3: Fix for rx priv buf allocation when DCB is not supported

When hdev doesn't support DCB, rx private buffer is not allocated, otherwise there is not enough buffer for rx shared buffer, causing buffer allocation process to fail. This patch fixes by checking the dcb capability in hclge_rx_buffer_calc. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration

[PATCH net 6/7] net: hns3: set default vlan id to PF

From: Lipeng When there is no vlan id in the packets, hardware will treat the vlan id as 0 and look for the mac_vlan table. This patch set the default vlan id of PF as 0. Without this config, it will fail when look for mac_vlan table, and hardware will drop packets.

[PATCH net 6/7] net: hns3: set default vlan id to PF

From: Lipeng When there is no vlan id in the packets, hardware will treat the vlan id as 0 and look for the mac_vlan table. This patch set the default vlan id of PF as 0. Without this config, it will fail when look for mac_vlan table, and hardware will drop packets. Signed-off-by: Mingguang Qu

Re: [PATCH net 6/7] netvsc: Initialize 64-bit stats seqcount

On Tue, 1 Aug 2017 12:11:12 -0700 Florian Fainelli wrote: > On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a > lockdep splat indicating this seqcount is not correctly initialized, fix > that. In commit 6c80f3fc2398 ("netvsc: report per-channel stats

Re: [PATCH net 6/7] netvsc: Initialize 64-bit stats seqcount

On Tue, 1 Aug 2017 12:11:12 -0700 Florian Fainelli wrote: > On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a > lockdep splat indicating this seqcount is not correctly initialized, fix > that. In commit 6c80f3fc2398 ("netvsc: report per-channel stats in > ethtool

[PATCH net 6/7] netvsc: Initialize 64-bit stats seqcount

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. In commit 6c80f3fc2398 ("netvsc: report per-channel stats in ethtool statistics") netdev_alloc_pcpu_stats() was removed in favor of open-coding the

[PATCH net 6/7] netvsc: Initialize 64-bit stats seqcount

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. In commit 6c80f3fc2398 ("netvsc: report per-channel stats in ethtool statistics") netdev_alloc_pcpu_stats() was removed in favor of open-coding the

[PATCH net 6/7] netvsc: Initialize 64-bit stats seqcount

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. In commit 6c80f3fc2398 ("netvsc: report per-channel stats in ethtool statistics") netdev_alloc_pcpu_stats() was removed in favor of open-coding the

[PATCH net 6/7] netvsc: Initialize 64-bit stats seqcount

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. In commit 6c80f3fc2398 ("netvsc: report per-channel stats in ethtool statistics") netdev_alloc_pcpu_stats() was removed in favor of open-coding the

[PATCH net 6/8] net: bcmgenet: Power up the internal PHY before probing the MII

From: Doug Berger When using the internal PHY it must be powered up when the MII is probed or the PHY will not be detected. Since the PHY is powered up at reset this has not been a problem. However, when the kernel is restarted with kexec the PHY will likely be

[PATCH net 6/8] net: bcmgenet: Power up the internal PHY before probing the MII

From: Doug Berger When using the internal PHY it must be powered up when the MII is probed or the PHY will not be detected. Since the PHY is powered up at reset this has not been a problem. However, when the kernel is restarted with kexec the PHY will likely be powered down when the kernel

Re: [PATCH net 6/9] virtio-net: make rx buf size estimation works for XDP

On 16-12-23 06:37 AM, Jason Wang wrote: > We don't update ewma rx buf size in the case of XDP. This will lead > underestimation of rx buf size which causes host to produce more than > one buffers. This will greatly increase the possibility of XDP page > linearization. > > Cc: John Fastabend

Re: [PATCH net 6/9] virtio-net: make rx buf size estimation works for XDP

On 16-12-23 06:37 AM, Jason Wang wrote: > We don't update ewma rx buf size in the case of XDP. This will lead > underestimation of rx buf size which causes host to produce more than > one buffers. This will greatly increase the possibility of XDP page > linearization. > > Cc: John Fastabend >

[PATCH net 6/9] virtio-net: make rx buf size estimation works for XDP

We don't update ewma rx buf size in the case of XDP. This will lead underestimation of rx buf size which causes host to produce more than one buffers. This will greatly increase the possibility of XDP page linearization. Cc: John Fastabend Signed-off-by: Jason Wang

[PATCH net 6/9] virtio-net: make rx buf size estimation works for XDP

We don't update ewma rx buf size in the case of XDP. This will lead underestimation of rx buf size which causes host to produce more than one buffers. This will greatly increase the possibility of XDP page linearization. Cc: John Fastabend Signed-off-by: Jason Wang --- drivers/net/virtio_net.c

[PATCH net 6/7] net: ethernet: stmmac: platform: fix outdated function header

Fix the OF-helper function header to reflect that the function no longer has a platform-data parameter. Fixes: b0003ead75f3 ("stmmac: make stmmac_probe_config_dt return the platform data struct") Signed-off-by: Johan Hovold ---

[PATCH net 6/7] net: ethernet: stmmac: platform: fix outdated function header

Fix the OF-helper function header to reflect that the function no longer has a platform-data parameter. Fixes: b0003ead75f3 ("stmmac: make stmmac_probe_config_dt return the platform data struct") Signed-off-by: Johan Hovold --- drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 - 1 file

[PATCH net 6/7] net: ethernet: ti: cpsw: add missing sanity check

Make sure to check for allocation failures before dereferencing a NULL-pointer during probe. Fixes: 649a1688c960 ("net: ethernet: ti: cpsw: create common struct to hold shared driver data") Signed-off-by: Johan Hovold --- drivers/net/ethernet/ti/cpsw.c | 3 +++ 1 file changed,

[PATCH net 6/7] net: ethernet: ti: cpsw: add missing sanity check

Make sure to check for allocation failures before dereferencing a NULL-pointer during probe. Fixes: 649a1688c960 ("net: ethernet: ti: cpsw: create common struct to hold shared driver data") Signed-off-by: Johan Hovold --- drivers/net/ethernet/ti/cpsw.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH net 6/6] rxrpc: Free packets discarded in data_ready

Under certain conditions, the data_ready handler will discard a packet. These need to be freed. Signed-off-by: David Howells --- net/rxrpc/input.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c index

[PATCH net 6/6] rxrpc: Free packets discarded in data_ready

Under certain conditions, the data_ready handler will discard a packet. These need to be freed. Signed-off-by: David Howells --- net/rxrpc/input.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c index 789719031462..70bb77818dea 100644 ---

[PATCH net 6/7] net: hns: fix warning of passing zero to 'PTR_ERR'

From: Kejian Yan There is a misuse of PTR as shown below: ae_node = (void *)of_parse_phandle(dev->of_node, "ae-handle", 0); if (IS_ERR_OR_NULL(ae_node)) {

[PATCH net 6/7] net: hns: fix warning of passing zero to 'PTR_ERR'

From: Kejian Yan There is a misuse of PTR as shown below: ae_node = (void *)of_parse_phandle(dev->of_node, "ae-handle", 0); if (IS_ERR_OR_NULL(ae_node)) { ret =

[PATCH net 6/6] net: hns: bug fix of getting hilink status

from Lisheng There is some difference in hilink status defination between v1 and v2 chips. for v1 chip, all ports connected to the same hilink share the same hilink status register bit. but for v2, all ports have separately hilink status register bit. And the register addr

[PATCH net 6/6] net: hns: bug fix of getting hilink status

from Lisheng There is some difference in hilink status defination between v1 and v2 chips. for v1 chip, all ports connected to the same hilink share the same hilink status register bit. but for v2, all ports have separately hilink status register bit. And the register addr is also changed. So

[PATCH net 6/6] net: hns: bug fix of getting hilink status

from Lisheng There is some difference in hilink status defination between v1 and v2 chips. for v1 chip, all ports connected to the same hilink share the same hilink status register bit. but for v2, all ports have separately hilink status register bit. And the register addr

[PATCH net 6/6] net: hns: bug fix of getting hilink status

from Lisheng There is some difference in hilink status defination between v1 and v2 chips. for v1 chip, all ports connected to the same hilink share the same hilink status register bit. but for v2, all ports have separately hilink status register bit. And the register addr is also changed. So

[PATCH net 6/6] net: mvneta: Fix race condition during stopping

When stopping the port, the CPU notifier are still there whereas the mvneta_stop_dev function calls mvneta_percpu_disable() on each CPUs. It was possible to have a new CPU coming at this point which could be racy. This patch adds a flag preventing executing the code notifier for a new CPU when

[PATCH net 6/6] net: mvneta: Fix race condition during stopping

When stopping the port, the CPU notifier are still there whereas the mvneta_stop_dev function calls mvneta_percpu_disable() on each CPUs. It was possible to have a new CPU coming at this point which could be racy. This patch adds a flag preventing executing the code notifier for a new CPU when

Re: [PATCH net 6/7] openvswitch: Extend ct_state match field to 32 bits

On Tue, Sep 29, 2015 at 3:39 PM, Joe Stringer wrote: > The ct_state field was initially added as an 8-bit field, however six of > the bits are already being used and use cases are already starting to > appear that may push the limits of this field. This patch extends the > field to 32 bits while

Re: [PATCH net 6/7] openvswitch: Extend ct_state match field to 32 bits

On Tue, Sep 29, 2015 at 3:39 PM, Joe Stringer wrote: > The ct_state field was initially added as an 8-bit field, however six of > the bits are already being used and use cases are already starting to > appear that may push the limits of this field. This patch extends the >

[PATCH net 6/7] openvswitch: Extend ct_state match field to 32 bits

The ct_state field was initially added as an 8-bit field, however six of the bits are already being used and use cases are already starting to appear that may push the limits of this field. This patch extends the field to 32 bits while retaining the internal representation of 8 bits. This should

[PATCH net 6/7] openvswitch: Extend ct_state match field to 32 bits

The ct_state field was initially added as an 8-bit field, however six of the bits are already being used and use cases are already starting to appear that may push the limits of this field. This patch extends the field to 32 bits while retaining the internal representation of 8 bits. This should

Re: [PATCH] net #6

> > They are done this way to get good non SMP performance. Your changes would > > ruin that. > > Maybe macro "spin_lock_irqsave_on_smp()" would be good idea? These > ifdefs look ugly. Maybe local to driver, maybe even global. I had that argument with Linus about globally and ended up with

Re: [PATCH] net #6

Hi! > They are neccessary > > > @@ -643,9 +631,7 @@ > > eexp_hw_tx_pio(dev,data,length); > > } > > dev_kfree_skb(buf); > > -#ifdef CONFIG_SMP > > spin_unlock_irqrestore(>lock, flags); > > -#endif > > enable_irq(dev->irq); > > return 0; > > They are done this way

Re: [PATCH] net #6

They are done this way to get good non SMP performance. Your changes would ruin that. Maybe macro spin_lock_irqsave_on_smp() would be good idea? These ifdefs look ugly. Maybe local to driver, maybe even global. I had that argument with Linus about globally and ended up with ifdefs. I

Re: [PATCH] net #6

Hi! They are neccessary @@ -643,9 +631,7 @@ eexp_hw_tx_pio(dev,data,length); } dev_kfree_skb(buf); -#ifdef CONFIG_SMP spin_unlock_irqrestore(lp-lock, flags); -#endif enable_irq(dev-irq); return 0; They are done this way to get good non SMP

Re: [PATCH] net #6

> > > The following patch removes unnecessary #ifdefs from eexpress.c > > They are neccessary Yes, you are right. I was suggested by improper part of spinlock.h ... Forget this patch. > > @@ -643,9 +631,7 @@ > > eexp_hw_tx_pio(dev,data,length); > > } > >

Re: [PATCH] net #6

> The following patch removes unnecessary #ifdefs from eexpress.c They are neccessary > @@ -643,9 +631,7 @@ > eexp_hw_tx_pio(dev,data,length); > } > dev_kfree_skb(buf); > -#ifdef CONFIG_SMP > spin_unlock_irqrestore(>lock, flags); > -#endif >

Re: [PATCH] net #6

The following patch removes unnecessary #ifdefs from eexpress.c They are neccessary Yes, you are right. I was suggested by improper part of spinlock.h ... Forget this patch. @@ -643,9 +631,7 @@ eexp_hw_tx_pio(dev,data,length); } dev_kfree_skb(buf); -#ifdef

Re: [PATCH] net #6

The following patch removes unnecessary #ifdefs from eexpress.c They are neccessary @@ -643,9 +631,7 @@ eexp_hw_tx_pio(dev,data,length); } dev_kfree_skb(buf); -#ifdef CONFIG_SMP spin_unlock_irqrestore(lp-lock, flags); -#endif enable_irq(dev-irq);

[PATCH] net #6

The following patch removes unnecessary #ifdefs from eexpress.c Andrzej ** PATCH 6 *** diff -uNr linux-2.4.5-ac4/drivers/net/eexpress.c linux/drivers/net/eexpress.c --- linux-2.4.5-ac4/drivers/net/eexpress.c Wed May 30 01:08:54 2001 +++

[PATCH] net #6

The following patch removes unnecessary #ifdefs from eexpress.c Andrzej ** PATCH 6 *** diff -uNr linux-2.4.5-ac4/drivers/net/eexpress.c linux/drivers/net/eexpress.c --- linux-2.4.5-ac4/drivers/net/eexpress.c Wed May 30 01:08:54 2001 +++