Re: mlx5 error when the skb linear space is empty

[Magnus Karlsson]

On Tue, Jan 5, 2021 at 9:51 PM Saeed Mahameed  wrote:
>
> On Mon, 2021-01-04 at 18:59 +0800, Xuan Zhuo wrote:
> > hi
> >
> > In the process of developing xdp socket, we tried to directly use
> > page to
> > construct skb directly, to avoid data copy. And the MAC information
> > is also in
> > the page, which caused the linear space of skb to be empty. In this
> > case, I
> > encountered a problem :
> >
> > mlx5_core :3b:00.1 eth1: Error cqe on cqn 0x817, ci 0x8, qn
> > 0x1dbb, opcode 0xd, syndrome 0x1, vendor syndrome 0x68
> > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0030: 00 00 00 00 60 10 68 01 0a 00 1d bb 00 0f 9f d2
> > WQE DUMP: WQ size 1024 WQ cur size 0, WQE index 0xf, len: 64
> > : 00 00 0f 0a 00 1d bb 03 00 00 00 08 00 00 00 00
> > 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0020: 00 00 00 2b 00 08 00 00 00 00 00 05 9e e3 08 00
> > 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > mlx5_core :3b:00.1 eth1: ERR CQE on SQ: 0x1dbb
> >
> >
> > And when I try to copy only the mac address into the linear space of
> > skb, the
> > other parts are still placed in the page. When constructing skb in
> > this way, I
> > found that although the data can be sent successfully, the sending
> > performance
> > is relatively poor!!
> >
>
> Hi,
>
> This is an expected behavior of ConnectX4-LX, ConnectX4-LX requires the
> driver to copy at least the L2 headers into the linear part, in some
> DCB/DSCP configuration it will require L3 headers.

Do I understand this correctly if I say whatever is calling
ndo_start_xmit has to make sure at least the L2 headers is in the
linear part of the skb? If Xuan does not do this, the ConnectX4 driver
crashes, but if he does, it works. So from an ndo_start_xmit interface
perspective, what is the requirement of an skb that is passed to it?
Do all users of ndo_start_xmit make sure the L2 header is in the
linear part, or are there users that do not make sure this is the
case? Judging from the ConnectX5 code it seems that the latter is
possible (since it has code to deal with this), but from the
ConnectX4, it seems like the former is true (since it does not copy
the L2 headers into the linear part as far as I can see). Sorry for my
confusion, but I think it is important to get some clarity here as it
will decide if Xuan's patch is a good idea or not in its current form.

Thank you.

> to check what the current configuration, you can check from the driver
> code:
> mlx5e_calc_min_inline() // Calculates the minimum required headers to
> copy to linear part per packet
>
> and sq->min_inline_mode; stores the minimum required by the FW.
>
> This "must copy" requirement doesn't exist for ConnectX5 and above ..

What is the

> > I would like to ask, is there any way to solve this problem?
> >
> > dev info:
> > driver: mlx5_core
> > version: 5.10.0+
> > firmware-version: 14.21.2328 (MT_2470112034)
> > expansion-rom-version:
> > bus-info: :3b:00.0
> > supports-statistics: yes
> > supports-test: yes
> > supports-eeprom-access: no
> > supports-register-dump: no
> > supports-priv-flags: yes
> >
> >
> >
> >
>

Re: [PATCH net] dt-bindings: net: dwmac: fix queue priority documentation

[Sebastien Laveze]

On Sat, 2021-01-09 at 19:16 -0800, Jakub Kicinski wrote:
> Hi Sebastien, looks like this no longer applies to net could you
> rebase?
Hi Jakub,
Sure, no problem.

Re: [PATCH] mt76: Fix queue ID variable types after mcu queue split

[Kalle Valo]

Lorenzo Bianconi  writes:

>> Clang warns in both mt7615 and mt7915:
>> 
>> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:271:9: warning: implicit
>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>> txq = MT_MCUQ_FWDL;
>> ~ ^~~~
>> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:278:9: warning: implicit
>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>> txq = MT_MCUQ_WA;
>> ~ ^~
>> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:282:9: warning: implicit
>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>> txq = MT_MCUQ_WM;
>> ~ ^~
>> 3 warnings generated.
>> 
>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:238:9: warning: implicit
>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>> qid = MT_MCUQ_WM;
>> ~ ^~
>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:240:9: warning: implicit
>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>> qid = MT_MCUQ_FWDL;
>> ~ ^~~~
>> 2 warnings generated.
>> 
>> Use the proper type for the queue ID variables to fix these warnings.
>> Additionally, rename the txq variable in mt7915_mcu_send_message to be
>> more neutral like mt7615_mcu_send_message.
>> 
>> Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array")
>> Link: https://github.com/ClangBuiltLinux/linux/issues/1229
>> Signed-off-by: Nathan Chancellor 
>
> Acked-by: Lorenzo Bianconi 

I see that Felix already applied this, but as this is a regression
starting from v5.11-rc1 I think it should be applied to
wireless-drivers. Felix, can you drop this from your tree so that I
could apply it to wireless-drivers?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v3 1/1] can: dev: add software tx timestamps

[Marc Kleine-Budde]

On 1/10/21 1:49 PM, Vincent Mailhol wrote:
> Call skb_tx_timestamp() within can_put_echo_skb() so that a software
> tx timestamp gets attached on the skb.
> 
> There two main reasons to include this call in can_put_echo_skb():
> 
>   * It easily allow to enable the tx timestamp on all devices with
> just one small change.
> 
>   * According to Documentation/networking/timestamping.rst, the tx
> timestamps should be generated in the device driver as close as
> possible, but always prior to passing the packet to the network
> interface. During the call to can_put_echo_skb(), the skb gets
> cloned meaning that the driver should not dereference the skb
> variable anymore after can_put_echo_skb() returns. This makes
> can_put_echo_skb() the very last place we can use the skb without
> having to access the echo_skb[] array.
> 
> Remarks:
> 
>   * By default, skb_tx_timestamp() does nothing. It needs to be
> activated by passing the SOF_TIMESTAMPING_TX_SOFTWARE flag either
> through socket options or control messages.
> 
>   * The hardware rx timestamp of a local loopback message is the
> hardware tx timestamp. This means that there are no needs to
> implement SOF_TIMESTAMPING_TX_HARDWARE for CAN sockets.
> 
> References:
> 
> Support for the error queue in CAN RAW sockets (which is needed for tx
> timestamps) was introduced in:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb88531bdbfaafb827192d1fc6c5a3fcc4fadd96
> 
> Put the call to skb_tx_timestamp() just before adding it to the array:
> https://lkml.org/lkml/2021/1/10/54
> 
> Signed-off-by: Vincent Mailhol 

Applied to linux-can-next/testing (ontop of my dev infrastructure cleanup).

regards,
Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] net: stmmac: retain PTP-clock at hwtstamp_set

[Holger Assmann]

On Thu, 17.12.20 um 02:13 Jakub Kicinski wrote:


Thanks for the patch, minor nits below.


Thanks for the Feedback! I will work it in for my v2.


+
+   if (!(priv->dma_cap.time_stamp || priv->dma_cap.atime_stamp))


!a && !b reads better IMHO


We've chosen this variant because it is already used this way in
stmmac_main (e.g. in stmmac_hwtstamp_set(), stmmac_hwtstamp_get(), or
stmmac_validate()).


@@ -5290,8 +5330,7 @@ int stmmac_resume(struct device *dev)
/* enable the clk previously disabled */
clk_prepare_enable(priv->plat->stmmac_clk);
clk_prepare_enable(priv->plat->pclk);
-   if (priv->plat->clk_ptp_ref)
-   clk_prepare_enable(priv->plat->clk_ptp_ref);
+   stmmac_init_hwtstamp(priv);


This was optional, now you always init?


This was not intended. Will be fixed in v2 to be optional again.

Regards,
Holger

[PATCH v1 net] dt-bindings: net: dwmac: fix queue priority documentation

[Sebastien Laveze]

From: Seb Laveze 

The priority field is not the queue priority (queue priority is fixed)
but a bitmask of priorities assigned to this queue.

In receive, priorities relate to tagged frames priorities.

In transmit, priorities relate to PFC frames.

Signed-off-by: Seb Laveze 
---
 Documentation/devicetree/bindings/net/snps,dwmac.yaml | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index b2f6083f556a..dfbf5fe4547a 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -161,7 +161,8 @@ properties:
 * snps,route-dcbcp, DCB Control Packets
 * snps,route-up, Untagged Packets
 * snps,route-multi-broad, Multicast & Broadcast Packets
-  * snps,priority, RX queue priority (Range 0x0 to 0xF)
+  * snps,priority, bitmask of the tagged frames priorities assigned to
+the queue
 
   snps,mtl-tx-config:
 $ref: /schemas/types.yaml#/definitions/phandle
@@ -188,7 +189,10 @@ properties:
 * snps,idle_slope, unlock on WoL
 * snps,high_credit, max write outstanding req. limit
 * snps,low_credit, max read outstanding req. limit
-  * snps,priority, TX queue priority (Range 0x0 to 0xF)
+  * snps,priority, bitmask of the priorities assigned to the queue.
+When a PFC frame is received with priorities matching the bitmask,
+the queue is blocked from transmitting for the pause time specified
+in the PFC frame.
 
   snps,reset-gpio:
 deprecated: true
-- 
2.25.1

[QUESTION] build errors and warnings when make M=samples/bpf

[Tiezhu Yang]

Hi all,

I found the following build errors and warnings when make M=samples/bpf
on the Loongson 3A3000 platform which belongs to MIPS arch.

Are theseknown issues? Should I submit patches to fix them? (1) fatal error: 
'asm/rwonce.h' file not found


CLANG-bpf samples/bpf/xdpsock_kern.o In file included from 
samples/bpf/xdpsock_kern.c:2: In file included from 
./include/linux/bpf.h:9: In file included from 
./include/linux/workqueue.h:9: In file included from 
./include/linux/timer.h:5: In file included from 
./include/linux/list.h:9: In file included from 
./include/linux/kernel.h:10: ./include/linux/compiler.h:246:10: fatal 
error: 'asm/rwonce.h' file not found #include  
^~ 1 error generated. HEAD is now at 7c53f6b... Linux 
5.11-rc3 [yangtiezhu@linux linux.git]$ find . -name rwonce.h 
./include/asm-generic/rwonce.h ./arch/arm64/include/asm/rwonce.h 
./arch/alpha/include/asm/rwonce.h The following changes can fix the 
above errors, is it right? [yangtiezhu@linux linux.git]$ vim 
include/linux/compiler.h [yangtiezhu@linux linux.git]$ git diff diff 
--git a/include/linux/compiler.h b/include/linux/compiler.h index 
b8fe0c2..b73b18c 100644 --- a/include/linux/compiler.h +++ 
b/include/linux/compiler.h @@ -243,6 +243,8 @@ static inline void 
*offset_to_ptr(const int *off) */ #define 
prevent_tail_call_optimization() mb() +#ifdef CONFIG_ARM64 || 
CONFIG_ALPHA #include  +#endif #endif /* 
__LINUX_COMPILER_H */ (2) printf format warnings


  CC  samples/bpf/ibumad_user.o
samples/bpf/ibumad_user.c: In function ‘dump_counts’:
samples/bpf/ibumad_user.c:46:24: warning: format ‘%llu’ expects argument of 
type ‘long long unsigned int’, but argument 3 has type ‘__u64’ {aka ‘long 
unsigned int’} [-Wformat=]
printf("0x%02x : %llu\n", key, value);
 ~~~^  ~
 %lu
  CC  samples/bpf/lathist_user.o
  CC  samples/bpf/lwt_len_hist_user.o
  CC  samples/bpf/map_perf_test_user.o
  CC  samples/bpf/offwaketime_user.o
samples/bpf/offwaketime_user.c: In function ‘print_ksym’:
samples/bpf/offwaketime_user.c:34:17: warning: format ‘%llx’ expects argument 
of type ‘long long unsigned int’, but argument 3 has type ‘__u64’ {aka ‘long 
unsigned int’} [-Wformat=]
   printf("%s/%llx;", sym->name, addr);
  ~~~^   
  %lx
samples/bpf/offwaketime_user.c: In function ‘print_stack’:
samples/bpf/offwaketime_user.c:68:17: warning: format ‘%lld’ expects argument 
of type ‘long long int’, but argument 3 has type ‘__u64’ {aka ‘long unsigned 
int’} [-Wformat=]
  printf(";%s %lld\n", key->waker, count);
  ~~~^ ~
  %ld
  CC  samples/bpf/sampleip_user.o
samples/bpf/sampleip_user.c: In function ‘print_ip_map’:
samples/bpf/sampleip_user.c:118:20: warning: format ‘%llx’ expects argument of 
type ‘long long unsigned int’, but argument 2 has type ‘__u64’ {aka ‘long 
unsigned int’} [-Wformat=]
printf("0x%-17llx %-32s %u\n", counts[i].ip, sym->name,
  ~~^  
  %-17lx
samples/bpf/sampleip_user.c:121:20: warning: format ‘%llx’ expects argument of 
type ‘long long unsigned int’, but argument 2 has type ‘__u64’ {aka ‘long 
unsigned int’} [-Wformat=]
printf("0x%-17llx %-32s %u\n", counts[i].ip, "(user)",
  ~~^  
  %-17lx
  CC  samples/bpf/sockex1_user.o
  CC  samples/bpf/sockex2_user.o
samples/bpf/sockex2_user.c: In function ‘main’:
samples/bpf/sockex2_user.c:47:27: warning: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 3 has type ‘__u64’ {aka ‘long unsigned int’} 
[-Wformat=]
printf("ip %s bytes %lld packets %lld\n",
~~~^
%ld
samples/bpf/sockex2_user.c:49:11:
   value.bytes, value.packets);
   ~~~
samples/bpf/sockex2_user.c:47:40: warning: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 4 has type ‘__u64’ {aka ‘long unsigned int’} 
[-Wformat=]
printf("ip %s bytes %lld packets %lld\n",
 ~~~^
 %ld
samples/bpf/sockex2_user.c:49:24:
   value.bytes, value.packets);
~
  CC  samples/bpf/sockex3_user.o
samples/bpf/sockex3_user.c: In function ‘main’:
samples/bpf/sockex3_user.c:91:36: warning: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 6 has type ‘__u64’ {aka ‘long unsigned int’} 
[-Wformat=]
printf("%s.%05d -> %s.%05d %12lld %12lld\n",
   ~^
   %12ld
samples/bpf/sockex3_user.c:96:11:
   value.bytes, value.packets);
   ~~~
samples/bpf/sockex3_user.c:91:43: warning: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 7 has type ‘__u64’ {aka ‘long unsigned int’} 
[-Wformat=]
printf("%s.%05d -> %s.%05d %12lld %12lld\n",
   

Re: [PATCH ipsec-next] xfrm: interface: enable TSO on xfrm interfaces

[Steffen Klassert]

On Wed, Jan 06, 2021 at 08:10:46AM +0200, Eyal Birger wrote:
> Underlying xfrm output supports gso packets.
> Declare support in hw_features and adapt the xmit MTU check to pass GSO
> packets.
> 
> Signed-off-by: Eyal Birger 

Applied, thanks a lot Eyal!

Re: [PATCH net v2 3/3] esp: avoid unneeded kmap_atomic call

[Steffen Klassert]

On Sat, Jan 09, 2021 at 05:18:34PM -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn 
> 
> esp(6)_output_head uses skb_page_frag_refill to allocate a buffer for
> the esp trailer.
> 
> It accesses the page with kmap_atomic to handle highmem. But
> skb_page_frag_refill can return compound pages, of which
> kmap_atomic only maps the first underlying page.
> 
> skb_page_frag_refill does not return highmem, because flag
> __GFP_HIGHMEM is not set. ESP uses it in the same manner as TCP.
> That also does not call kmap_atomic, but directly uses page_address,
> in skb_copy_to_page_nocache. Do the same for ESP.
> 
> This issue has become easier to trigger with recent kmap local
> debugging feature CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP.
> 
> Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
> Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
> Signed-off-by: Willem de Bruijn 
> Cc: Steffen Klassert 

As this patchset goes through the net tree:

Acked-by: Steffen Klassert 

Thanks!

Re: [RFC PATCH net] udp: check sk for UDP GRO fraglist

[Steffen Klassert]

On Mon, Jan 11, 2021 at 11:02:42AM +0900, Dongseok Yi wrote:
> On 2021-01-08 22:35, Steffen Klassert wrote:
> > On Fri, Jan 08, 2021 at 09:52:28PM +0900, Dongseok Yi wrote:
> > > It is a workaround patch.
> > >
> > > UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
> > > forwarding. Only the header of head_skb from ip_finish_output_gso ->
> > > skb_gso_segment is updated but following frag_skbs are not updated.
> > >
> > > A call path skb_mac_gso_segment -> inet_gso_segment ->
> > > udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list
> > > does not try to update any UDP/IP header of the segment list.
> > >
> > > It might make sense because each skb of frag_skbs is converted to a
> > > list of regular packets. Header update with checksum calculation may
> > > be not needed for UDP GROed frag_skbs.
> > >
> > > But UDP GRO frag_list is started from udp_gro_receive, we don't know
> > > whether the skb will be NAT forwarded at that time. For workaround,
> > > try to get sock always when call udp4_gro_receive -> udp_gro_receive
> > > to check if the skb is for local.
> > >
> > > I'm still not sure if UDP GRO frag_list is really designed for local
> > > session only. Can kernel support NAT forward for UDP GRO frag_list?
> > > What am I missing?
> > 
> > The initial idea when I implemented this was to have a fast
> > forwarding path for UDP. So forwarding is a usecase, but NAT
> > is a problem, indeed. A quick fix could be to segment the
> > skb before it gets NAT forwarded. Alternatively we could
> > check for a header change in __udp_gso_segment_list and
> > update the header of the frag_skbs accordingly in that case.
> 
> Thank you for explaining.
> Can I think of it as a known issue?

No, it was not known before you reported it.

> I think we should have a fix
> because NAT can be triggered by user. Can I check the current status?
> Already planning a patch or a new patch should be written?

We have to do a new patch to fix that issue. If you want do
do so, go ahead.

[PATCH] net: phy: smsc: fix clk error handling

[Marco Felsch]

Commit bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in
support") added the phy clk support. The commit already checks if
clk_get_optional() throw an error but instead of returning the error it
ignores it.

Fixes: bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in support")
Suggested-by: Jakub Kicinski 
Signed-off-by: Marco Felsch 
---
 drivers/net/phy/smsc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 0fc39ac5ca88..10722fed666d 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -284,7 +284,8 @@ static int smsc_phy_probe(struct phy_device *phydev)
/* Make clk optional to keep DTB backward compatibility. */
priv->refclk = clk_get_optional(dev, NULL);
if (IS_ERR(priv->refclk))
-   dev_err_probe(dev, PTR_ERR(priv->refclk), "Failed to request 
clock\n");
+   return dev_err_probe(dev, PTR_ERR(priv->refclk),
+"Failed to request clock\n");
 
ret = clk_prepare_enable(priv->refclk);
if (ret)
-- 
2.20.1

[PATCH net-next] fsl/fman: Add MII mode support.

[Maxim Kochetkov]

Set proper value to IF_MODE register for MII mode.

Signed-off-by: Maxim Kochetkov 
---
 drivers/net/ethernet/freescale/fman/fman_memac.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fman/fman_memac.c 
b/drivers/net/ethernet/freescale/fman/fman_memac.c
index bb9887f98841..62f42921933d 100644
--- a/drivers/net/ethernet/freescale/fman/fman_memac.c
+++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
@@ -111,6 +111,7 @@ do {
\
 
 #define IF_MODE_MASK   0x0003 /* 30-31 Mask on i/f mode bits */
 #define IF_MODE_10G0x /* 30-31 10G interface */
+#define IF_MODE_MII0x0001 /* 30-31 MII interface */
 #define IF_MODE_GMII   0x0002 /* 30-31 GMII (1G) interface */
 #define IF_MODE_RGMII  0x0004
 #define IF_MODE_RGMII_AUTO 0x8000
@@ -442,6 +443,9 @@ static int init(struct memac_regs __iomem *regs, struct 
memac_cfg *cfg,
case PHY_INTERFACE_MODE_XGMII:
tmp |= IF_MODE_10G;
break;
+   case PHY_INTERFACE_MODE_MII:
+   tmp |= IF_MODE_MII;
+   break;
default:
tmp |= IF_MODE_GMII;
if (phy_if == PHY_INTERFACE_MODE_RGMII ||
-- 
2.29.2

[PATCH] rtw88: debug: style: Simplify bool comparison

[YANG LI]

Fix the following coccicheck warning:
 ./drivers/net/wireless/realtek/rtw88/debug.c:800:17-23: WARNING:
Comparison of 0/1 to bool variable

Signed-off-by: YANG LI 
Reported-by: Abaci Robot
---
 drivers/net/wireless/realtek/rtw88/debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw88/debug.c 
b/drivers/net/wireless/realtek/rtw88/debug.c
index 19fc2d8..948cb79 100644
--- a/drivers/net/wireless/realtek/rtw88/debug.c
+++ b/drivers/net/wireless/realtek/rtw88/debug.c
@@ -800,7 +800,7 @@ static ssize_t rtw_debugfs_set_coex_enable(struct file 
*filp,
}
 
mutex_lock(&rtwdev->mutex);
-   coex->manual_control = enable == 0;
+   coex->manual_control = !enable;
mutex_unlock(&rtwdev->mutex);
 
return count;
-- 
1.8.3.1

[PATCH] hci: llc_shdlc: style: Simplify bool comparison

[YANG LI]

Fix the following coccicheck warning:
./net/nfc/hci/llc_shdlc.c:239:5-21: WARNING: Comparison to bool

Signed-off-by: YANG LI 
Reported-by: Abaci Robot
---
 net/nfc/hci/llc_shdlc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/nfc/hci/llc_shdlc.c b/net/nfc/hci/llc_shdlc.c
index 0eb4ddc..c0c8fea 100644
--- a/net/nfc/hci/llc_shdlc.c
+++ b/net/nfc/hci/llc_shdlc.c
@@ -236,7 +236,7 @@ static void llc_shdlc_rcv_i_frame(struct llc_shdlc *shdlc,
goto exit;
}
 
-   if (shdlc->t1_active == false) {
+   if (!shdlc->t1_active) {
shdlc->t1_active = true;
mod_timer(&shdlc->t1_timer, jiffies +
  msecs_to_jiffies(SHDLC_T1_VALUE_MS(shdlc->w)));
-- 
1.8.3.1

[PATCH net 0/2] bnxt_en: Bug fixes.

[Michael Chan]

This series has 2 fixes.  The first one fixes a resource accounting error
with the RDMA driver loaded and the second one fixes the firmware
flashing sequence after defragmentation.

Please queue the 1st one for -stable.  Thanks.

Michael Chan (1):
  bnxt_en: Improve stats context resource accounting with RDMA driver
loaded.

Pavan Chebbi (1):
  bnxt_en: Clear DEFRAG flag in firmware message when retry flashing.

 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 3 ++-
 drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c | 8 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.18.1

[PATCH net 2/2] bnxt_en: Clear DEFRAG flag in firmware message when retry flashing.

[Michael Chan]

From: Pavan Chebbi 

When the FW tells the driver to retry the INSTALL_UPDATE command after
it has cleared the NVM area, the driver is not clearing the previously
used ALLOWED_TO_DEFRAG flag. As a result the FW tries to defrag the NVM
area a second time in a loop and can fail the request.

Fixes: 1432c3f6a6ca ("bnxt_en: Retry installing FW package under NO_SPACE error 
condition.")
Signed-off-by: Pavan Chebbi 
Signed-off-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index 9ff79d5d14c4..2f8b193a772d 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -2532,7 +2532,7 @@ int bnxt_flash_package_from_fw_obj(struct net_device 
*dev, const struct firmware
 
if (rc && ((struct hwrm_err_output *)&resp)->cmd_err ==
NVM_INSTALL_UPDATE_CMD_ERR_CODE_FRAG_ERR) {
-   install.flags |=
+   install.flags =

cpu_to_le16(NVM_INSTALL_UPDATE_REQ_FLAGS_ALLOWED_TO_DEFRAG);
 
rc = _hwrm_send_message_silent(bp, &install,
@@ -2546,6 +2546,7 @@ int bnxt_flash_package_from_fw_obj(struct net_device 
*dev, const struct firmware
 * UPDATE directory and try the flash again
 */
defrag_attempted = true;
+   install.flags = 0;
rc = __bnxt_flash_nvram(bp->dev,
BNX_DIR_TYPE_UPDATE,
BNX_DIR_ORDINAL_FIRST,
-- 
2.18.1

[PATCH net 1/2] bnxt_en: Improve stats context resource accounting with RDMA driver loaded.

[Michael Chan]

The function bnxt_get_ulp_stat_ctxs() does not count the stats contexts
used by the RDMA driver correctly when the RDMA driver is freeing the
MSIX vectors.  It assumes that if the RDMA driver is registered, the
additional stats contexts will be needed.  This is not true when the
RDMA driver is about to unregister and frees the MSIX vectors.

This slight error leads to over accouting of the stats contexts needed
after the RDMA driver has unloaded.  This will cause some firmware
warning and error messages in dmesg during subsequent config. changes
or ifdown/ifup.

Fix it by properly accouting for extra stats contexts only if the
RDMA driver is registered and MSIX vectors have been successfully
requested.

Fixes: c027c6b4e91f ("bnxt_en: get rid of num_stat_ctxs variable")
Reviewed-by: Yongping Zhang 
Reviewed-by: Pavan Chebbi 
Signed-off-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c
index 8c8368c2f335..64dbbb04b043 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c
@@ -222,8 +222,12 @@ int bnxt_get_ulp_msix_base(struct bnxt *bp)
 
 int bnxt_get_ulp_stat_ctxs(struct bnxt *bp)
 {
-   if (bnxt_ulp_registered(bp->edev, BNXT_ROCE_ULP))
-   return BNXT_MIN_ROCE_STAT_CTXS;
+   if (bnxt_ulp_registered(bp->edev, BNXT_ROCE_ULP)) {
+   struct bnxt_en_dev *edev = bp->edev;
+
+   if (edev->ulp_tbl[BNXT_ROCE_ULP].msix_requested)
+   return BNXT_MIN_ROCE_STAT_CTXS;
+   }
 
return 0;
 }
-- 
2.18.1

[PATCH] scsi: qedf: style: Simplify bool comparison

[YANG LI]

Fix the following coccicheck warning:
./drivers/scsi/qedf/qedf_main.c:3716:5-31: WARNING: Comparison to bool

Signed-off-by: YANG LI 
Reported-by: Abaci Robot
---
 drivers/scsi/qedf/qedf_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
index 46d185c..cec27f2 100644
--- a/drivers/scsi/qedf/qedf_main.c
+++ b/drivers/scsi/qedf/qedf_main.c
@@ -3713,7 +3713,7 @@ static void __qedf_remove(struct pci_dev *pdev, int mode)
else
fc_fabric_logoff(qedf->lport);
 
-   if (qedf_wait_for_upload(qedf) == false)
+   if (!qedf_wait_for_upload(qedf))
QEDF_ERR(&qedf->dbg_ctx, "Could not upload all sessions.\n");
 
 #ifdef CONFIG_DEBUG_FS
-- 
1.8.3.1

RE: [EXT] [PATCH] scsi: qedf: style: Simplify bool comparison

[Saurav Kashyap]

Hi,
Thanks for a patch.

> -Original Message-
> From: YANG LI 
> Sent: Monday, January 11, 2021 2:59 PM
> To: j...@linux.ibm.com
> Cc: martin.peter...@oracle.com; Saurav Kashyap ;
> Javed Hasan ; GR-QLogic-Storage-Upstream  qlogic-storage-upstr...@marvell.com>; li...@armlinux.org.uk; linux-
> s...@vger.kernel.org; linux-ker...@vger.kernel.org; netdev@vger.kernel.org;
> YANG LI 
> Subject: [EXT] [PATCH] scsi: qedf: style: Simplify bool comparison
> 
> External Email
> 
> --
> Fix the following coccicheck warning:
> ./drivers/scsi/qedf/qedf_main.c:3716:5-31: WARNING: Comparison to bool
> 
> Signed-off-by: YANG LI 
> Reported-by: Abaci Robot
> ---
>  drivers/scsi/qedf/qedf_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
> index 46d185c..cec27f2 100644
> --- a/drivers/scsi/qedf/qedf_main.c
> +++ b/drivers/scsi/qedf/qedf_main.c
> @@ -3713,7 +3713,7 @@ static void __qedf_remove(struct pci_dev *pdev, int
> mode)
>   else
>   fc_fabric_logoff(qedf->lport);
> 
> - if (qedf_wait_for_upload(qedf) == false)
> + if (!qedf_wait_for_upload(qedf))
>   QEDF_ERR(&qedf->dbg_ctx, "Could not upload all sessions.\n");
> 
>  #ifdef CONFIG_DEBUG_FS
> --
> 1.8.3.1

Acked-by: Saurav Kashyap 

[PATCH net-next v2 1/2] net: vlan: Add parse protocol header ops

[Eran Ben Elisha]

Add parse protocol header ops for vlan device. Before this patch, vlan
tagged packet transmitted by af_packet had skb->protocol unset. Some
kernel methods (like __skb_flow_dissect()) rely on this missing information
for its packet processing.

Signed-off-by: Eran Ben Elisha 
Reviewed-by: Tariq Toukan 
---
 net/8021q/vlan_dev.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index ec8408d1638f..dc1a197792e6 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -510,9 +510,17 @@ static void vlan_dev_set_lockdep_class(struct net_device 
*dev)
netdev_for_each_tx_queue(dev, vlan_dev_set_lockdep_one, NULL);
 }
 
+static __be16 vlan_parse_protocol(const struct sk_buff *skb)
+{
+   struct vlan_ethhdr *veth = (struct vlan_ethhdr *)(skb->data);
+
+   return __vlan_get_protocol(skb, veth->h_vlan_proto, NULL);
+}
+
 static const struct header_ops vlan_header_ops = {
.create  = vlan_dev_hard_header,
.parse   = eth_header_parse,
+   .parse_protocol = vlan_parse_protocol,
 };
 
 static int vlan_passthru_hard_header(struct sk_buff *skb, struct net_device 
*dev,
@@ -532,6 +540,7 @@ static int vlan_passthru_hard_header(struct sk_buff *skb, 
struct net_device *dev
 static const struct header_ops vlan_passthru_header_ops = {
.create  = vlan_passthru_hard_header,
.parse   = eth_header_parse,
+   .parse_protocol = vlan_parse_protocol,
 };
 
 static struct device_type vlan_type = {
-- 
2.17.1

[PATCH net-next v2 0/2] Dissect PTP L2 packet header

[Eran Ben Elisha]

Hi Jakub, Dave,

This series adds support for dissecting PTP L2 packet
header (EtherType 0x88F7).

For packet header dissecting, skb->protocol is needed. Add protocol
parsing operation to vlan ops, to guarantee skb->protocol is set,
as EtherType 0x88F7 occasionally follows a vlan header.

Changelog:
v2:
- Add more people to CC list.

Eran Ben Elisha (2):
  net: vlan: Add parse protocol header ops
  net: flow_dissector: Parse PTP L2 packet header

 net/8021q/vlan_dev.c  |  9 +
 net/core/flow_dissector.c | 16 
 2 files changed, 25 insertions(+)

-- 
2.17.1

[PATCH net-next v2 2/2] net: flow_dissector: Parse PTP L2 packet header

[Eran Ben Elisha]

Add support for parsing PTP L2 packet header. Such packet consists
of an L2 header (with ethertype of ETH_P_1588), PTP header, body
and an optional suffix.

Signed-off-by: Eran Ben Elisha 
Reviewed-by: Tariq Toukan 
---
 net/core/flow_dissector.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 6f1adba6695f..fcaa223c7cdc 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1251,6 +1252,21 @@ bool __skb_flow_dissect(const struct net *net,
  &proto, &nhoff, hlen, flags);
break;
 
+   case htons(ETH_P_1588): {
+   struct ptp_header *hdr, _hdr;
+
+   hdr = __skb_header_pointer(skb, nhoff, sizeof(_hdr), data,
+  hlen, &_hdr);
+   if (!hdr || (hlen - nhoff) < sizeof(_hdr)) {
+   fdret = FLOW_DISSECT_RET_OUT_BAD;
+   break;
+   }
+
+   nhoff += ntohs(hdr->message_length);
+   fdret = FLOW_DISSECT_RET_OUT_GOOD;
+   break;
+   }
+
default:
fdret = FLOW_DISSECT_RET_OUT_BAD;
break;
-- 
2.17.1

Re: [RFC PATCH 0/1] net: arcnet: Fix RESET sequence

[Sebastian A. Siewior]

On 2020-12-22 10:03:37 [+0100], Ahmed S. Darwish wrote:
>   2) arcnet_close() contains a del_timer_sync(). If the irq handler
>  interrupts the to-be-deleted timer then call del_timer_sync(), it
>  will just loop forever.

del_timer_sync() will trigger a warning if invoked from interrupt
handler.

Sebastian

Re: [PATCH bpf-next 1/4] bpf: enable task local storage for tracing programs

[KP Singh]

On Sat, Jan 9, 2021 at 12:35 AM Song Liu  wrote:
>
> To access per-task data, BPF program typically creates a hash table with
> pid as the key. This is not ideal because:
>  1. The use need to estimate requires size of the hash table, with may be
> inaccurate;
>  2. Big hash tables are slow;
>  3. To clean up the data properly during task terminations, the user need
> to write code.
>
> Task local storage overcomes these issues and becomes a better option for
> these per-task data. Task local storage is only available to BPF_LSM. Now
> enable it for tracing programs.

Also mention here that you change the pointer from being a security blob to a
dedicated member in the task struct. I assume this is because you want to
use it without CONFIG_BPF_LSM?

>

Can you also mention the reasons for changing the
raw_spin_lock_bh to raw_spin_lock_irqsave in the commit log?


> Reported-by: kernel test robot 
> Signed-off-by: Song Liu 
> ---
>  include/linux/bpf.h|  7 +++
>  include/linux/bpf_lsm.h| 22 --
>  include/linux/bpf_types.h  |  2 +-
>  include/linux/sched.h  |  5 +
>  kernel/bpf/Makefile|  3 +--
>  kernel/bpf/bpf_local_storage.c | 28 +---
>  kernel/bpf/bpf_lsm.c   |  4 
>  kernel/bpf/bpf_task_storage.c  | 26 ++
>  kernel/fork.c  |  5 +
>  kernel/trace/bpf_trace.c   |  4 
>  10 files changed, 46 insertions(+), 60 deletions(-)
>

[...]

Re: [patch 02/30] genirq: Move status flag checks to core

[Thomas Gleixner]

On Sun, Dec 27 2020 at 11:20, Guenter Roeck wrote:
> On Thu, Dec 10, 2020 at 08:25:38PM +0100, Thomas Gleixner wrote:
> Yes, but that means that irq_check_status_bit() may be called from modules,
> but it is not exported, resulting in build errors such as the following.
>
> arm64:allmodconfig:
>
> ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] 
> undefined!

Duh. Yes, that lacks an export obviously.

Thanks,

tglx

Re: [PATCH net-next 2/2] virtio_net: Implement XDP_FLAGS_NO_TX support

[Shay Agroskin]

Charlie Somerville  writes:


On Mon, Jan 11, 2021, at 04:31, Shay Agroskin wrote:

Is this addition needed ? Seems like we don't set VIRTIO_XDP_TX 
bit in case of virtnet_xdp_xmit() failure, so the surrounding 
'if' 
won't be taken.


Good catch, it looks like you're right. I'm happy to remove that 
extra branch although I would like to add a comment explaining 
that assumption:


diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ed08998765e0..3ae7cd2f1e72 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1472,8 +1472,10 @@ static int virtnet_poll(struct 
napi_struct *napi, int budget)

xdp_do_flush();

if (xdp_xmit & VIRTIO_XDP_TX) {
+   /* VIRTIO_XDP_TX only set on successful 
virtnet_xdp_xmit,

+* implies sq != NULL */
sq = virtnet_xdp_sq(vi);
-   if (sq && virtqueue_kick_prepare(sq->vq) && 
virtqueue_notify(sq->vq)) {
+   if (virtqueue_kick_prepare(sq->vq) && 
virtqueue_notify(sq->vq)) {

u64_stats_update_begin(&sq->stats.syncp);
sq->stats.kicks++;
u64_stats_update_end(&sq->stats.syncp);


The comment itself looks good. Note that the code style dictates 
that multi-line comments should end up with a line containing '*/' 
alone.
See 
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting 
for more information


Also you'd probably need to send a new email containing the new 
patchset (see V# tag on emails in the mailing list)


Shay

Re: [PATCH bpf-next 1/4] bpf: enable task local storage for tracing programs

[KP Singh]

On Mon, Jan 11, 2021 at 7:27 AM Yonghong Song  wrote:
>
>
>
> On 1/8/21 3:19 PM, Song Liu wrote:
> > To access per-task data, BPF program typically creates a hash table with
> > pid as the key. This is not ideal because:
> >   1. The use need to estimate requires size of the hash table, with may be
> >  inaccurate;
> >   2. Big hash tables are slow;
> >   3. To clean up the data properly during task terminations, the user need
> >  to write code.
> >
> > Task local storage overcomes these issues and becomes a better option for
> > these per-task data. Task local storage is only available to BPF_LSM. Now
> > enable it for tracing programs.
> >
> > Reported-by: kernel test robot 
> > Signed-off-by: Song Liu 
> > ---

[...]

> >   struct cfs_rq;
> >   struct fs_struct;
> > @@ -1348,6 +1349,10 @@ struct task_struct {
> >   /* Used by LSM modules for access restriction: */
> >   void*security;
> >   #endif
> > +#ifdef CONFIG_BPF_SYSCALL
> > + /* Used by BPF task local storage */
> > + struct bpf_local_storage*bpf_storage;
> > +#endif
>
> I remembered there is a discussion where KP initially wanted to put
> bpf_local_storage in task_struct, but later on changed to
> use in lsm as his use case mostly for lsm. Did anybody
> remember the details of the discussion? Just want to be
> sure what is the concern people has with putting bpf_local_storage
> in task_struct and whether the use case presented by
> Song will justify it.
>

If I recall correctly, the discussion was about inode local storage and
it was decided to use the security blob since the use-case was only LSM
programs. Since we now plan to use it in tracing,
detangling the dependency from CONFIG_BPF_LSM
sounds logical to me.


> >
> >   #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> >   unsigned long   lowest_stack;
> > diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
> > index d1249340fd6ba..ca995fdfa45e7 100644
> > --- a/kernel/bpf/Makefile
> > +++ b/kernel/bpf/Makefile
> > @@ -8,9 +8,8 @@ CFLAGS_core.o += $(call cc-disable-warning, override-init) 
> > $(cflags-nogcse-yy)
> >
> >   obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o 
> > tnum.o bpf_iter.o map_iter.o task_iter.o prog_iter.o
> >   obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o 
> > bpf_lru_list.o lpm_trie.o map_in_map.o
> > -obj-$(CONFIG_BPF_SYSCALL) += local_storage.o queue_stack_maps.o ringbuf.o
> > +obj-$(CONFIG_BPF_SYSCALL) += local_storage.o queue_stack_maps.o ringbuf.o 
> > bpf_task_storage.o
> >   obj-${CONFIG_BPF_LSM} += bpf_inode_storage.o
> > -obj-${CONFIG_BPF_LSM}  += bpf_task_storage.o
> >   obj-$(CONFIG_BPF_SYSCALL) += disasm.o
> >   obj-$(CONFIG_BPF_JIT) += trampoline.o
> >   obj-$(CONFIG_BPF_SYSCALL) += btf.o
> [...]

KASAN: use-after-free Read in hci_dev_do_open

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:71c061d2 Merge tag 'for-5.11-rc2-tag' of git://git.kernel...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1612b248d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
dashboard link: https://syzkaller.appspot.com/bug?extid=8bf62d95824d213104fa
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8bf62d95824d21310...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in instrument_atomic_read 
include/linux/instrumented.h:71 [inline]
BUG: KASAN: use-after-free in atomic_read 
include/asm-generic/atomic-instrumented.h:27 [inline]
BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:147 
[inline]
BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:1051 [inline]
BUG: KASAN: use-after-free in kfree_skb+0x2e/0x3f0 net/core/skbuff.c:697
Read of size 4 at addr 888022dacc1c by task syz-executor.2/13757

CPU: 0 PID: 13757 Comm: syz-executor.2 Not tainted 5.11.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230
 __kasan_report mm/kasan/report.c:396 [inline]
 kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
 check_memory_region_inline mm/kasan/generic.c:179 [inline]
 check_memory_region+0x13d/0x180 mm/kasan/generic.c:185
 instrument_atomic_read include/linux/instrumented.h:71 [inline]
 atomic_read include/asm-generic/atomic-instrumented.h:27 [inline]
 refcount_read include/linux/refcount.h:147 [inline]
 skb_unref include/linux/skbuff.h:1051 [inline]
 kfree_skb+0x2e/0x3f0 net/core/skbuff.c:697
 hci_dev_do_open+0xa4a/0x1a00 net/bluetooth/hci_core.c:1619
 hci_dev_open+0x132/0x300 net/bluetooth/hci_core.c:1685
 hci_sock_ioctl+0x5b6/0x840 net/bluetooth/hci_sock.c:1025
 sock_do_ioctl+0xcb/0x2d0 net/socket.c:1037
 sock_ioctl+0x477/0x6a0 net/socket.c:1177
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45e087
Code: 48 83 c4 08 48 89 d8 5b 5d c3 66 0f 1f 84 00 00 00 00 00 48 89 e8 48 f7 
d8 48 39 c3 0f 92 c0 eb 92 66 90 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 
6d b5 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fffdcd39c88 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 0003 RCX: 0045e087
RDX: 0002 RSI: 400448c9 RDI: 0003
RBP: 7fffdcd39ca0 R08:  R09: 7f60a0a24700
R10: 7f60a0a249d0 R11: 0246 R12: 0310e914
R13: 0004 R14:  R15: 

Allocated by task 8498:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
 kasan_set_track mm/kasan/common.c:46 [inline]
 set_alloc_info mm/kasan/common.c:401 [inline]
 kasan_kmalloc.constprop.0+0x82/0xa0 mm/kasan/common.c:429
 kasan_slab_alloc include/linux/kasan.h:205 [inline]
 slab_post_alloc_hook mm/slab.h:512 [inline]
 slab_alloc_node mm/slub.c:2891 [inline]
 slab_alloc mm/slub.c:2899 [inline]
 kmem_cache_alloc+0x1c6/0x440 mm/slub.c:2904
 skb_clone+0x14f/0x3c0 net/core/skbuff.c:1449
 hci_cmd_work+0x18f/0x390 net/bluetooth/hci_core.c:5007
 process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
 kthread+0x3b1/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296

Freed by task 2042:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:356
 kasan_slab_free+0xe1/0x110 mm/kasan/common.c:362
 kasan_slab_free include/linux/kasan.h:188 [inline]
 slab_free_hook mm/slub.c:1547 [inline]
 slab_free_freelist_hook+0x5d/0x150 mm/slub.c:1580
 slab_free mm/slub.c:3142 [inline]
 kmem_cache_free+0x82/0x350 mm/slub.c:3158
 kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:627
 __kfree_skb net/core/skbuff.c:684 [inline]
 kfree_skb net/core/skbuff.c:701 [inline]
 kfree_skb+0x140/0x3f0 net/core/skbuff.c:695
 hci_cmd_work+0x182/0x390 net/bluetooth/hci_core.c:5005
 process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
 kthread+0x3b1/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296

The buggy address belongs to the object at 888022dacb40
 which belongs to the cache skbuff_head_cache of size 232
The buggy address is located 220 bytes inside of
 232-byte region [888022da

Re: [PATCH net v3] ppp: fix refcount underflow on channel unbridge

[Tom Parkin]

On  Fri, Jan 08, 2021 at 21:57:50 +0100, Guillaume Nault wrote:
> On Thu, Jan 07, 2021 at 06:13:15PM +, Tom Parkin wrote:
> > When setting up a channel bridge, ppp_bridge_channels sets the
> > pch->bridge field before taking the associated reference on the bridge
> > file instance.
> > 
> > This opens up a refcount underflow bug if ppp_bridge_channels called
> > via. iotcl runs concurrently with ppp_unbridge_channels executing via.
> > file release.
> > 
> > The bug is triggered by ppp_bridge_channels taking the error path
> > through the 'err_unset' label.  In this scenario, pch->bridge is set,
> > but the reference on the bridged channel will not be taken because
> > the function errors out.  If ppp_unbridge_channels observes pch->bridge
> > before it is unset by the error path, it will erroneously drop the
> > reference on the bridged channel and cause a refcount underflow.
> > 
> > To avoid this, ensure that ppp_bridge_channels holds a reference on
> > each channel in advance of setting the bridge pointers.
> 
> Thanks for following up on this!
> 
> Acked-by: Guillaume Nault 

Thanks again for reviewing, Guillaume.


signature.asc
Description: PGP signature

Re: [PATCH v7 net-next 2/2] net: dsa: qca: ar9331: export stats64

[Oleksij Rempel]

On Sat, Jan 09, 2021 at 02:21:43AM +0200, Vladimir Oltean wrote:
> On Fri, Jan 08, 2021 at 06:32:28AM +0100, Oleksij Rempel wrote:
> > May be the "net: dsa: add optional stats64 support" can already be
> > taken?
> 
> I'm not sure that I see the point. David and Jakub won't cherry-pick
> partial series, and if you resend just patch 1/2, they won't accept new
> code that doesn't have any callers.
> 
> You don't have to wait for my series if you don't want to. If you're
> going to conflict with it anyway (it changes the prototype of
> ndo_get_stats64), you might as well not wait. I don't know when, or if,
> it's going to be over with it. It is going to take at least one more
> respin since it now conflicts with net.git commit 9f9d41f03bb0 ("docs:
> net: fix documentation on .ndo_get_stats") merged a few hours ago into
> net-next. So just say which way it is that you prefer.

Ok, thx. If no one is against it, i'll prefer to push this patches now.

Regards,
Oleksij
-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [RFC PATCH 2/3] chelsio: cxgb: Move slow interrupt handling to threaded irqs

[Sebastian A. Siewior]

On 2020-12-24 14:11:47 [+0100], Ahmed S. Darwish wrote:
> --- a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
> +++ b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
> @@ -211,9 +211,9 @@ static int cxgb_up(struct adapter *adapter)
>   t1_interrupts_clear(adapter);
>  
>   adapter->params.has_msi = !disable_msi && 
> !pci_enable_msi(adapter->pdev);
> - err = request_irq(adapter->pdev->irq, t1_interrupt,
> -   adapter->params.has_msi ? 0 : IRQF_SHARED,
> -   adapter->name, adapter);
> + err = request_threaded_irq(adapter->pdev->irq, t1_irq, t1_irq_thread,
> +adapter->params.has_msi ? 0 : IRQF_SHARED,
> +adapter->name, adapter);
>   if (err) {
>   if (adapter->params.has_msi)
>   pci_disable_msi(adapter->pdev);
> diff --git a/drivers/net/ethernet/chelsio/cxgb/sge.c 
> b/drivers/net/ethernet/chelsio/cxgb/sge.c
> index d6df1a87db0b..f1c402f6b889 100644
> --- a/drivers/net/ethernet/chelsio/cxgb/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb/sge.c
> @@ -1626,11 +1626,10 @@ int t1_poll(struct napi_struct *napi, int budget)
>   return work_done;
>  }
>  
> -irqreturn_t t1_interrupt(int irq, void *data)
> +irqreturn_t t1_irq(int irq, void *data)
>  {
>   struct adapter *adapter = data;
>   struct sge *sge = adapter->sge;
> - int handled;
>  
>   if (likely(responses_pending(adapter))) {
>   writel(F_PL_INTR_SGE_DATA, adapter->regs + A_PL_CAUSE);
> @@ -1645,9 +1644,19 @@ irqreturn_t t1_interrupt(int irq, void *data)
>   napi_enable(&adapter->napi);
>   }
>   }
> +
>   return IRQ_HANDLED;
>   }
>  
> + return IRQ_WAKE_THREAD;
> +}
> +
> +irqreturn_t t1_irq_thread(int irq, void *data)
> +{
> + struct adapter *adapter = data;
> + struct sge *sge = adapter->sge;
> + int handled;
> +
>   spin_lock(&adapter->async_lock);
>   handled = t1_slow_intr_handler(adapter);
>   spin_unlock(&adapter->async_lock);

This does not work in general, it might work in the MSI case but does
not work for the LEVEL interrupt case: The interrupt remains active
because it has not been ACKed. Chances are that the threaded handler
never gets scheduled because interrupt is still pending and t1_irq()
gets invoked right away.
For that reason, the primary must either mask the interrupt source or
use IRQF_ONESHOT to mask the interrupt line until the threaded handler
is done.

If you look at t1_elmer0_ext_intr() it disables F_PL_INTR_EXT before the
worker scheduled so the interrupt does not trigger again.
The worker then does what ever is needed (t1_elmer0_ext_intr_handler)
and then ACKs F_PL_INTR_EXT and enables F_PL_INTR_EXT again so it may
trigger an interrupt again.

Sebastian

[PATCH net-next] net: core: use eth_type_vlan in __netif_receive_skb_core

[menglong8 . dong]

From: Menglong Dong 

Replace the check for ETH_P_8021Q and ETH_P_8021AD in
__netif_receive_skb_core with eth_type_vlan.

Signed-off-by: Menglong Dong 
---
 net/core/dev.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index e4d77c8abe76..267c4a8daa55 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5151,8 +5151,7 @@ static int __netif_receive_skb_core(struct sk_buff 
**pskb, bool pfmemalloc,
skb_reset_mac_len(skb);
}
 
-   if (skb->protocol == cpu_to_be16(ETH_P_8021Q) ||
-   skb->protocol == cpu_to_be16(ETH_P_8021AD)) {
+   if (eth_type_vlan(skb->protocol)) {
skb = skb_vlan_untag(skb);
if (unlikely(!skb))
goto out;
@@ -5236,8 +5235,7 @@ static int __netif_receive_skb_core(struct sk_buff 
**pskb, bool pfmemalloc,
 * find vlan device.
 */
skb->pkt_type = PACKET_OTHERHOST;
-   } else if (skb->protocol == cpu_to_be16(ETH_P_8021Q) ||
-  skb->protocol == cpu_to_be16(ETH_P_8021AD)) {
+   } else if (eth_type_vlan(skb->protocol)) {
/* Outer header is 802.1P with vlan 0, inner header is
 * 802.1Q or 802.1AD and vlan_do_receive() above could
 * not find vlan dev for vlan id 0.
-- 
2.17.1

[PATCH net-next v8 0/2] net: dsa: add stats64 support

[Oleksij Rempel]

changes v8:
- stats.no_handler should not be assigned from HW stats

changes v7:
- move raw.filtered from rx_errors to rx_dropped counter 

changes v6:
- move stats64 callback to ethtool section
- ar9331: diff. fixes
- ar9331: move stats calculation to the worker
- ar9331: extend rx/tx error counters
- use spin lock instead of u64_stats*

changes v5:
- read all stats in one regmap_bulk_read() request
- protect stats with u64_stats* helpers.

changes v4:
- do no read MIBs withing stats64 call
- change polling frequency to 0.3Hz

changes v3:
- fix wrong multiplication
- cancel port workers on remove

changes v2:
- use stats64 instead of get_ethtool_stats
- add worked to poll for the stats

Oleksij Rempel (2):
  net: dsa: add optional stats64 support
  net: dsa: qca: ar9331: export stats64

 drivers/net/dsa/qca/ar9331.c | 163 ++-
 include/net/dsa.h|   4 +-
 net/dsa/slave.c  |  14 ++-
 3 files changed, 178 insertions(+), 3 deletions(-)

-- 
2.30.0

[PATCH net-next v8 1/2] net: dsa: add optional stats64 support

[Oleksij Rempel]

Allow DSA drivers to export stats64

Signed-off-by: Oleksij Rempel 
Reviewed-by: Vladimir Oltean 
---
 include/net/dsa.h |  4 +++-
 net/dsa/slave.c   | 14 +-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 4e60d2610f20..c50abb295fb6 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -477,7 +477,7 @@ struct dsa_switch_ops {
void(*phylink_fixed_state)(struct dsa_switch *ds, int port,
   struct phylink_link_state *state);
/*
-* ethtool hardware statistics.
+* Port statistics counters.
 */
void(*get_strings)(struct dsa_switch *ds, int port,
   u32 stringset, uint8_t *data);
@@ -486,6 +486,8 @@ struct dsa_switch_ops {
int (*get_sset_count)(struct dsa_switch *ds, int port, int sset);
void(*get_ethtool_phy_stats)(struct dsa_switch *ds,
 int port, uint64_t *data);
+   void(*get_stats64)(struct dsa_switch *ds, int port,
+  struct rtnl_link_stats64 *s);
 
/*
 * ethtool Wake-on-LAN
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 4a0498bf6c65..1fb823d3c7d7 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1602,6 +1602,18 @@ static struct devlink_port 
*dsa_slave_get_devlink_port(struct net_device *dev)
return dp->ds->devlink ? &dp->devlink_port : NULL;
 }
 
+static void dsa_slave_get_stats64(struct net_device *dev,
+ struct rtnl_link_stats64 *s)
+{
+   struct dsa_port *dp = dsa_slave_to_port(dev);
+   struct dsa_switch *ds = dp->ds;
+
+   if (ds->ops->get_stats64)
+   ds->ops->get_stats64(ds, dp->index, s);
+   else
+   dev_get_tstats64(dev, s);
+}
+
 static const struct net_device_ops dsa_slave_netdev_ops = {
.ndo_open   = dsa_slave_open,
.ndo_stop   = dsa_slave_close,
@@ -1621,7 +1633,7 @@ static const struct net_device_ops dsa_slave_netdev_ops = 
{
 #endif
.ndo_get_phys_port_name = dsa_slave_get_phys_port_name,
.ndo_setup_tc   = dsa_slave_setup_tc,
-   .ndo_get_stats64= dev_get_tstats64,
+   .ndo_get_stats64= dsa_slave_get_stats64,
.ndo_get_port_parent_id = dsa_slave_get_port_parent_id,
.ndo_vlan_rx_add_vid= dsa_slave_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid   = dsa_slave_vlan_rx_kill_vid,
-- 
2.30.0

[PATCH net-next v8 2/2] net: dsa: qca: ar9331: export stats64

[Oleksij Rempel]

Add stats support for the ar9331 switch.

Signed-off-by: Oleksij Rempel 
---
 drivers/net/dsa/qca/ar9331.c | 163 ++-
 1 file changed, 162 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index 4d49c5f2b790..1e3706054ae1 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -101,6 +101,9 @@
 AR9331_SW_PORT_STATUS_RX_FLOW_EN | AR9331_SW_PORT_STATUS_TX_FLOW_EN | \
 AR9331_SW_PORT_STATUS_SPEED_M)
 
+/* MIB registers */
+#define AR9331_MIB_COUNTER(x)  (0x2 + ((x) * 0x100))
+
 /* Phy bypass mode
  * 
  * Bit:   | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |10 |11 |12 |13 |14 |15 |
@@ -154,6 +157,66 @@
 #define AR9331_SW_MDIO_POLL_SLEEP_US   1
 #define AR9331_SW_MDIO_POLL_TIMEOUT_US 20
 
+/* The interval should be small enough to avoid overflow of 32bit MIBs */
+/*
+ * FIXME: until we can read MIBs from stats64 call directly (i.e. sleep
+ * there), we have to poll stats more frequently then it is actually needed.
+ * For overflow protection, normally, 100 sec interval should have been OK.
+ */
+#define STATS_INTERVAL_JIFFIES (3 * HZ)
+
+struct ar9331_sw_stats_raw {
+   u32 rxbroad;/* 0x00 */
+   u32 rxpause;/* 0x04 */
+   u32 rxmulti;/* 0x08 */
+   u32 rxfcserr;   /* 0x0c */
+   u32 rxalignerr; /* 0x10 */
+   u32 rxrunt; /* 0x14 */
+   u32 rxfragment; /* 0x18 */
+   u32 rx64byte;   /* 0x1c */
+   u32 rx128byte;  /* 0x20 */
+   u32 rx256byte;  /* 0x24 */
+   u32 rx512byte;  /* 0x28 */
+   u32 rx1024byte; /* 0x2c */
+   u32 rx1518byte; /* 0x30 */
+   u32 rxmaxbyte;  /* 0x34 */
+   u32 rxtoolong;  /* 0x38 */
+   u32 rxgoodbyte; /* 0x3c */
+   u32 rxgoodbyte_hi;
+   u32 rxbadbyte;  /* 0x44 */
+   u32 rxbadbyte_hi;
+   u32 rxoverflow; /* 0x4c */
+   u32 filtered;   /* 0x50 */
+   u32 txbroad;/* 0x54 */
+   u32 txpause;/* 0x58 */
+   u32 txmulti;/* 0x5c */
+   u32 txunderrun; /* 0x60 */
+   u32 tx64byte;   /* 0x64 */
+   u32 tx128byte;  /* 0x68 */
+   u32 tx256byte;  /* 0x6c */
+   u32 tx512byte;  /* 0x70 */
+   u32 tx1024byte; /* 0x74 */
+   u32 tx1518byte; /* 0x78 */
+   u32 txmaxbyte;  /* 0x7c */
+   u32 txoversize; /* 0x80 */
+   u32 txbyte; /* 0x84 */
+   u32 txbyte_hi;
+   u32 txcollision;/* 0x8c */
+   u32 txabortcol; /* 0x90 */
+   u32 txmulticol; /* 0x94 */
+   u32 txsinglecol;/* 0x98 */
+   u32 txexcdefer; /* 0x9c */
+   u32 txdefer;/* 0xa0 */
+   u32 txlatecol;  /* 0xa4 */
+};
+
+struct ar9331_sw_port {
+   int idx;
+   struct delayed_work mib_read;
+   struct rtnl_link_stats64 stats;
+   struct spinlock stats_lock;
+};
+
 struct ar9331_sw_priv {
struct device *dev;
struct dsa_switch ds;
@@ -165,8 +228,17 @@ struct ar9331_sw_priv {
struct mii_bus *sbus; /* mdio slave */
struct regmap *regmap;
struct reset_control *sw_reset;
+   struct ar9331_sw_port port[AR9331_SW_PORTS];
 };
 
+static struct ar9331_sw_priv *ar9331_sw_port_to_priv(struct ar9331_sw_port 
*port)
+{
+   struct ar9331_sw_port *p = port - port->idx;
+
+   return (struct ar9331_sw_priv *)((void *)p -
+offsetof(struct ar9331_sw_priv, port));
+}
+
 /* Warning: switch reset will reset last AR9331_SW_MDIO_PHY_MODE_PAGE request
  * If some kind of optimization is used, the request should be repeated.
  */
@@ -424,6 +496,7 @@ static void ar9331_sw_phylink_mac_link_down(struct 
dsa_switch *ds, int port,
phy_interface_t interface)
 {
struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+   struct ar9331_sw_port *p = &priv->port[port];
struct regmap *regmap = priv->regmap;
int ret;
 
@@ -431,6 +504,8 @@ static void ar9331_sw_phylink_mac_link_down(struct 
dsa_switch *ds, int port,
 AR9331_SW_PORT_STATUS_MAC_MASK, 0);
if (ret)
dev_err_ratelimited(priv->dev, "%s: %i\n", __func__, ret);
+
+   cancel_delayed_work_sync(&p->mib_read);
 }
 
 static void ar9331_sw

Re: [PATCH v5 net-next 11/16] net: propagate errors from dev_get_stats

[Dan Carpenter]

Hi Vladimir,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Make-ndo_get_stats64-sleepable/20210109-003617
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
58334e7537278793c86baa88b70c48b0d50b00ae
config: i386-randconfig-m021-20210108 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

New smatch warnings:
net/core/rtnetlink.c:1821 rtnl_fill_ifinfo() warn: missing error code 'err'

vim +/err +1821 net/core/rtnetlink.c

79e1ad148c844f5c Jiri Benc2017-11-02  1704  static int 
rtnl_fill_ifinfo(struct sk_buff *skb,
79e1ad148c844f5c Jiri Benc2017-11-02  1705  
struct net_device *dev, struct net *src_net,
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1706  
int type, u32 pid, u32 seq, u32 change,
3d3ea5af5c0b382b Vlad Yasevich2017-05-27  1707  
unsigned int flags, u32 ext_filter_mask,
38e01b30563a5b5a Nicolas Dichtel  2018-01-25  1708  
u32 event, int *new_nsid, int new_ifindex,
d4e4fdf9e4a27c87 Guillaume Nault  2019-10-23  1709  
int tgt_netnsid, gfp_t gfp)
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1710  {
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1711  struct 
ifinfomsg *ifm;
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1712  struct nlmsghdr 
*nlh;
5d346342f59ffa31 Vladimir Oltean  2021-01-08  1713  int err = 
-EMSGSIZE;
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1714  
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1715  ASSERT_RTNL();
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1716  nlh = 
nlmsg_put(skb, pid, seq, type, sizeof(*ifm), flags);
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1717  if (nlh == NULL)
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1718  return 
-EMSGSIZE;
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1719  
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1720  ifm = 
nlmsg_data(nlh);
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1721  ifm->ifi_family 
= AF_UNSPEC;
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1722  ifm->__ifi_pad 
= 0;
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1723  ifm->ifi_type = 
dev->type;
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1724  ifm->ifi_index 
= dev->ifindex;
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1725  ifm->ifi_flags 
= dev_get_flags(dev);
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1726  ifm->ifi_change 
= change;
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1727  
7e4a8d5a93f649a1 Christian Brauner2018-09-04  1728  if (tgt_netnsid 
>= 0 && nla_put_s32(skb, IFLA_TARGET_NETNSID, tgt_netnsid))
79e1ad148c844f5c Jiri Benc2017-11-02  1729  goto 
nla_put_failure;
79e1ad148c844f5c Jiri Benc2017-11-02  1730  
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1731  if 
(nla_put_string(skb, IFLA_IFNAME, dev->name) ||
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1732  
nla_put_u32(skb, IFLA_TXQLEN, dev->tx_queue_len) ||
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1733  
nla_put_u8(skb, IFLA_OPERSTATE,
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1734 
netif_running(dev) ? dev->operstate : IF_OPER_DOWN) ||
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1735  
nla_put_u8(skb, IFLA_LINKMODE, dev->link_mode) ||
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1736  
nla_put_u32(skb, IFLA_MTU, dev->mtu) ||
3e7a50ceb11ea75c Stephen Hemminger2018-07-27  1737  
nla_put_u32(skb, IFLA_MIN_MTU, dev->min_mtu) ||
3e7a50ceb11ea75c Stephen Hemminger2018-07-27  1738  
nla_put_u32(skb, IFLA_MAX_MTU, dev->max_mtu) ||
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1739  
nla_put_u32(skb, IFLA_GROUP, dev->group) ||
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1740  
nla_put_u32(skb, IFLA_PROMISCUITY, dev->promiscuity) ||
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1741  
nla_put_u32(skb, IFLA_NUM_TX_QUEUES, dev->num_tx_queues) ||
c70ce028e834f8e5 Eric Dumazet 2016-03-21  1742  
nla_put_u32(skb, IFLA_GSO_MAX_SEGS, dev->gso_max_segs) ||
c70ce028e834f8e5 Eric Dumazet 2016-03-21  1743  
nla_put_u32(skb, IFLA_GSO_MAX_SIZE, dev->gso_max_size) ||
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1744  #ifdef CONFIG_RPS
b22b941b2c253a20 Hannes Frederic Sowa 2015-11-17  1745  
nla_put_u32(skb, IFLA_NUM_RX_QUEUES, dev->num_rx_queues) ||
b22b94

Re: [PATCH iproute2] tc: flower: fix json output with mpls lse

[Guillaume Nault]

On Thu, Jan 07, 2021 at 10:39:03AM -0700, David Ahern wrote:
> On 1/7/21 10:13 AM, Jakub Kicinski wrote:
> > On Thu, 7 Jan 2021 17:48:56 +0100 Guillaume Nault wrote:
> >> On Fri, Dec 18, 2020 at 11:25:32PM +0100, Guillaume Nault wrote:
> >>> The json output of the TCA_FLOWER_KEY_MPLS_OPTS attribute was invalid.
> >>>
> >>> Example:
> >>>
> >>>   $ tc filter add dev eth0 ingress protocol mpls_uc flower mpls \
> >>>   lse depth 1 label 100 \
> >>>   lse depth 2 label 200
> >>>
> >>>   $ tc -json filter show dev eth0 ingress
> >>> ...{"eth_type":"8847",
> >>> "  mpls":["lse":["depth":1,"label":100],
> >>>   "lse":["depth":2,"label":200]]}...  
> >>
> >> Is there any problem with this patch?
> >> It's archived in patchwork, but still in state "new". Therefore I guess
> >> it was dropped before being considered for review.
> > 
> > Erm, that's weird. I think Alexei mentioned that auto-archiving is
> > turned on in the new netdevbpf patchwork instance. My guess is it got
> > auto archived :S
> > 
> > Here is the list of all patches that are Archived as New:
> > 
> > https://patchwork.kernel.org/project/netdevbpf/list/?state=1&archive=true
> > 
> > Should any of these have been reviewed?
> > 
> 
> 
> Interesting. I thought some patches had magically disappeared - and some
> of those are in that list.

Okay, but, in the end, should I repost this patch?

Re: [PATCH v5 net-next 11/16] net: propagate errors from dev_get_stats

[Vladimir Oltean]

Hi Dan,

On Mon, Jan 11, 2021 at 01:55:16PM +0300, Dan Carpenter wrote:
> Hi Vladimir,
>
> New smatch warnings:
> net/core/rtnetlink.c:1821 rtnl_fill_ifinfo() warn: missing error code 'err'
>
> vim +/err +1821 net/core/rtnetlink.c
>
> static int rtnl_fill_ifinfo(struct sk_buff *skb,
>   struct net_device *dev, struct net *src_net,
>   int type, u32 pid, u32 seq, u32 change,
>   unsigned int flags, u32 ext_filter_mask,
>   u32 event, int *new_nsid, int new_ifindex,
>   int tgt_netnsid, gfp_t gfp)
> {
>   struct ifinfomsg *ifm;
>   struct nlmsghdr *nlh;
>   int err = -EMSGSIZE;
>
...
>
>   err = rtnl_fill_stats(skb, dev);
>   if (err)
>   goto nla_put_failure;
>
>   if (rtnl_fill_vf(skb, dev, ext_filter_mask))
>   goto nla_put_failure;
>
> No error codes any more on the rest of the gotos in this function.
>
>
>   if (rtnl_port_fill(skb, dev, ext_filter_mask))
>   goto nla_put_failure;
>
>   if (rtnl_xdp_fill(skb, dev))
>   goto nla_put_failure;
>
...
>
>   nlmsg_end(skb, nlh);
>   return 0;
>
> nla_put_failure_rcu:
>   rcu_read_unlock();
> nla_put_failure:
>   nlmsg_cancel(skb, nlh);
>   return err;
> }

Thank you for this report. It is a valid issue. It has also been fixed
in v6:
https://patchwork.kernel.org/project/netdevbpf/patch/20210109172624.2028156-12-olte...@gmail.com/
>From the changelog:

Changes in v6:
- Fixed rtnetlink incorrectly returning 0 in rtnl_fill_ifinfo on
  nla_put_failure and causing "ip a" to not show any interfaces.

Re: [PATCH net-next 2/2] drivers: net: dsa: mt7530: MT7530 optional GPIO support

[Russell King - ARM Linux admin]

On Mon, Jan 11, 2021 at 01:44:28PM +0800, DENG Qingfang wrote:
> +static int
> +mt7530_gpio_direction_output(struct gpio_chip *gc, unsigned int offset, int 
> value)
> +{
> + struct mt7530_priv *priv = gpiochip_get_data(gc);
> + u32 bit = mt7530_gpio_to_bit(offset);
> +
> + mt7530_set(priv, MT7530_LED_GPIO_DIR, bit);
> + mt7530_set(priv, MT7530_LED_GPIO_OE, bit);
> + mt7530_gpio_set(gc, offset, value);

FYI, Documentation/driver-api/gpio/consumer.rst says:

  For output GPIOs, the value provided becomes the initial output value.
  This helps avoid signal glitching during system startup.

Setting the pin to be an output, and then setting its initial value
does not avoid the glitch. You may wish to investigate whether you
can set the value before setting the pin as an output to avoid this
issue.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next 0/2] Introduce XDP_FLAGS_NO_TX flag

[Toke Høiland-Jørgensen]

Charlie Somerville  writes:

> This patch series introduces a new flag XDP_FLAGS_NO_TX which prevents
> the allocation of additional send queues for XDP programs.
>
> Included in this patch series is an implementation of XDP_FLAGS_NO_TX
> for the virtio_net driver. This flag is intended to be advisory - not
> all drivers must implement support for it.
>
> Many virtualised environments only provide enough virtio_net send queues
> for the number of processors allocated to the VM:
>
> # nproc
> 8
> # ethtool --show-channels ens3
> Channel parameters for ens3:
> Pre-set maximums:
> RX: 0
> TX: 0
> Other:  0
> Combined:   8
>
> In this configuration XDP is unusable because the virtio_net driver
> always tries to allocate an extra send queue for each processor - even
> if the XDP the program never uses the XDP_TX functionality.
>
> While XDP_TX is still unavailable in these environments, this new flag
> expands the set of XDP programs that can be used.

I don't think adding a new flag is a good idea. Why can't you just fix
the driver?

-Toke

Re: [PATCH net ] net: mvpp2: Remove Pause and Asym_Pause support

[Marcin Wojtas]

niedz., 10 sty 2021 o 20:25  napisał(a):
>
> From: Stefan Chulski 
>
> Packet Processor hardware not connected to MAC flow control unit and
> cannot support TX flow control.
> This patch disable flow control support.
>
> Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network 
> unit")
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 82c6bef..d04171d 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -5861,8 +5861,6 @@ static void mvpp2_phylink_validate(struct 
> phylink_config *config,
>
> phylink_set(mask, Autoneg);
> phylink_set_port_modes(mask);
> -   phylink_set(mask, Pause);
> -   phylink_set(mask, Asym_Pause);
>
> switch (state->interface) {
> case PHY_INTERFACE_MODE_10GBASER:
> --
> 1.9.1
>

Acked-by: Marcin Wojtas 

Thanks!

[PATCH] octeontx2-pf: Add flow classification using IP next level protocol

[Naveen Mamindlapalli]

This patch adds support to install flow rules using ipv4 proto or
ipv6 next header field to distinguish between tcp/udp/sctp/esp/ah
flows when user doesn't specify the other match creteria related to
the flow such as tcp/udp/sctp source port and destination port, ah/esp
spi value. This is achieved by matching the layer type extracted by
NPC HW into the search key. Modified the driver to use Ethertype as
match criteria when user doesn't specify source IP address and dest
IP address. The esp/ah flow rule matching using security parameter
index (spi) is not supported as of now since the field is not extracted
into MCAM search key. Modified npc_check_field function to return bool.

Signed-off-by: Naveen Mamindlapalli 
Signed-off-by: Sunil Goutham 
---
 drivers/net/ethernet/marvell/octeontx2/af/npc.h|   5 +
 .../ethernet/marvell/octeontx2/af/rvu_debugfs.c|   1 +
 .../net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c |  52 ++---
 .../ethernet/marvell/octeontx2/nic/otx2_flows.c| 116 +++--
 4 files changed, 153 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/npc.h 
b/drivers/net/ethernet/marvell/octeontx2/af/npc.h
index a1f79445db71..3c640f6aba92 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/npc.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/npc.h
@@ -162,6 +162,11 @@ enum key_fields {
NPC_DIP_IPV4,
NPC_SIP_IPV6,
NPC_DIP_IPV6,
+   NPC_IPPROTO_TCP,
+   NPC_IPPROTO_UDP,
+   NPC_IPPROTO_SCTP,
+   NPC_IPPROTO_AH,
+   NPC_IPPROTO_ESP,
NPC_SPORT_TCP,
NPC_DPORT_TCP,
NPC_SPORT_UDP,
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c 
b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
index d27543c1a166..0c6882e84d42 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
@@ -1757,6 +1757,7 @@ static void rvu_dbg_npc_mcam_show_flows(struct seq_file 
*s,
seq_printf(s, "mask 0x%x\n", ntohs(rule->mask.dport));
break;
default:
+   seq_puts(s, "\n");
break;
}
}
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c 
b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
index 14832b66d1fe..7572321cea79 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
@@ -26,6 +26,11 @@ static const char * const npc_flow_names[] = {
[NPC_DIP_IPV4]  = "ipv4 destination ip",
[NPC_SIP_IPV6]  = "ipv6 source ip",
[NPC_DIP_IPV6]  = "ipv6 destination ip",
+   [NPC_IPPROTO_TCP] = "ip proto tcp",
+   [NPC_IPPROTO_UDP] = "ip proto udp",
+   [NPC_IPPROTO_SCTP] = "ip proto sctp",
+   [NPC_IPPROTO_AH] = "ip proto AH",
+   [NPC_IPPROTO_ESP] = "ip proto ESP",
[NPC_SPORT_TCP] = "tcp source port",
[NPC_DPORT_TCP] = "tcp destination port",
[NPC_SPORT_UDP] = "udp source port",
@@ -212,13 +217,13 @@ static bool npc_check_overlap(struct rvu *rvu, int 
blkaddr,
return false;
 }
 
-static int npc_check_field(struct rvu *rvu, int blkaddr, enum key_fields type,
-  u8 intf)
+static bool npc_check_field(struct rvu *rvu, int blkaddr, enum key_fields type,
+   u8 intf)
 {
if (!npc_is_field_present(rvu, type, intf) ||
npc_check_overlap(rvu, blkaddr, type, 0, intf))
-   return -EOPNOTSUPP;
-   return 0;
+   return false;
+   return true;
 }
 
 static void npc_scan_parse_result(struct npc_mcam *mcam, u8 bit_number,
@@ -448,14 +453,13 @@ static void npc_set_features(struct rvu *rvu, int 
blkaddr, u8 intf)
struct npc_mcam *mcam = &rvu->hw->mcam;
u64 *features = &mcam->rx_features;
u64 tcp_udp_sctp;
-   int err, hdr;
+   int hdr;
 
if (is_npc_intf_tx(intf))
features = &mcam->tx_features;
 
for (hdr = NPC_DMAC; hdr < NPC_HEADER_FIELDS_MAX; hdr++) {
-   err = npc_check_field(rvu, blkaddr, hdr, intf);
-   if (!err)
+   if (npc_check_field(rvu, blkaddr, hdr, intf))
*features |= BIT_ULL(hdr);
}
 
@@ -464,13 +468,26 @@ static void npc_set_features(struct rvu *rvu, int 
blkaddr, u8 intf)
   BIT_ULL(NPC_SPORT_SCTP) | BIT_ULL(NPC_DPORT_SCTP);
 
/* for tcp/udp/sctp corresponding layer type should be in the key */
-   if (*features & tcp_udp_sctp)
-   if (npc_check_field(rvu, blkaddr, NPC_LD, intf))
+   if (*features & tcp_udp_sctp) {
+   if (!npc_check_field(rvu, blkaddr, NPC_LD, intf))
*features &= ~tcp_udp_sctp;
+   else
+   *features |= BIT_ULL(NPC_IPPROTO_TCP) |
+BIT_UL

[PATCH 0/6] ethernet: fixes for stmmac driver

[Joakim Zhang]

Fixes for stmmac driver.

Joakim Zhang (6):
  ethernet: stmmac: remove redundant null check for ptp clock
  ethernet: stmmac: stop each tx channal independently
  ethernet: stmmac: fix watchdog timeout during suspend/resume stress
test
  ethernet: stmmac: fix dma physical address of descriptor when display
ring
  ethernet: stmmac: fix wrongly set buffer2 valid when sph unsupport
  ethernet: stmmac: re-init rx buffers when mac resume back

 .../ethernet/stmicro/stmmac/dwmac4_descs.c|  14 +-
 .../net/ethernet/stmicro/stmmac/dwmac4_lib.c  |   4 -
 .../ethernet/stmicro/stmmac/dwxgmac2_descs.c  |   2 +-
 .../net/ethernet/stmicro/stmmac/enh_desc.c|   5 +-
 drivers/net/ethernet/stmicro/stmmac/hwif.h|   5 +-
 .../net/ethernet/stmicro/stmmac/norm_desc.c   |   5 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 136 +++---
 7 files changed, 134 insertions(+), 37 deletions(-)

-- 
2.17.1

[PATCH 4/6] ethernet: stmmac: fix dma physical address of descriptor when display ring

[Joakim Zhang]

Driver uses dma_alloc_coherent to allocate dma memory for descriptors,
dma_alloc_coherent will return both the virtual address and physical
address. AFAIK, virt_to_phys could not convert virtual address to
physical address, for which memory is allocated by dma_alloc_coherent.

Signed-off-by: Joakim Zhang 
---
 .../ethernet/stmicro/stmmac/dwmac4_descs.c|  5 +-
 .../net/ethernet/stmicro/stmmac/enh_desc.c|  5 +-
 drivers/net/ethernet/stmicro/stmmac/hwif.h|  3 +-
 .../net/ethernet/stmicro/stmmac/norm_desc.c   |  5 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 50 ---
 5 files changed, 44 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index c6540b003b43..8e1ee33ba1e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -402,7 +402,8 @@ static void dwmac4_rd_set_tx_ic(struct dma_desc *p)
p->des2 |= cpu_to_le32(TDES2_INTERRUPT_ON_COMPLETION);
 }
 
-static void dwmac4_display_ring(void *head, unsigned int size, bool rx)
+static void dwmac4_display_ring(void *head, unsigned int size, bool rx,
+   unsigned int dma_rx_phy, unsigned int desc_size)
 {
struct dma_desc *p = (struct dma_desc *)head;
int i;
@@ -411,7 +412,7 @@ static void dwmac4_display_ring(void *head, unsigned int 
size, bool rx)
 
for (i = 0; i < size; i++) {
pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
-   i, (unsigned int)virt_to_phys(p),
+   i, (unsigned int)(dma_rx_phy + i * desc_size),
le32_to_cpu(p->des0), le32_to_cpu(p->des1),
le32_to_cpu(p->des2), le32_to_cpu(p->des3));
p++;
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c 
b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index d02cec296f51..a7324b9c1a02 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -417,7 +417,8 @@ static int enh_desc_get_rx_timestamp_status(void *desc, 
void *next_desc,
}
 }
 
-static void enh_desc_display_ring(void *head, unsigned int size, bool rx)
+static void enh_desc_display_ring(void *head, unsigned int size, bool rx,
+ unsigned int dma_rx_phy, unsigned int 
desc_size)
 {
struct dma_extended_desc *ep = (struct dma_extended_desc *)head;
int i;
@@ -429,7 +430,7 @@ static void enh_desc_display_ring(void *head, unsigned int 
size, bool rx)
 
x = *(u64 *)ep;
pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
-   i, (unsigned int)virt_to_phys(ep),
+   i, (unsigned int)(dma_rx_phy + i * desc_size),
(unsigned int)x, (unsigned int)(x >> 32),
ep->basic.des2, ep->basic.des3);
ep++;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h 
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index b40b2e0667bb..fc5260cf27ea 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -78,7 +78,8 @@ struct stmmac_desc_ops {
/* get rx timestamp status */
int (*get_rx_timestamp_status)(void *desc, void *next_desc, u32 ats);
/* Display ring */
-   void (*display_ring)(void *head, unsigned int size, bool rx);
+   void (*display_ring)(void *head, unsigned int size, bool rx,
+unsigned int dma_rx_phy, unsigned int desc_size);
/* set MSS via context descriptor */
void (*set_mss)(struct dma_desc *p, unsigned int mss);
/* get descriptor skbuff address */
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c 
b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index f083360e4ba6..c26544de0766 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -269,7 +269,8 @@ static int ndesc_get_rx_timestamp_status(void *desc, void 
*next_desc, u32 ats)
return 1;
 }
 
-static void ndesc_display_ring(void *head, unsigned int size, bool rx)
+static void ndesc_display_ring(void *head, unsigned int size, bool rx,
+  unsigned int dma_rx_phy, unsigned int desc_size)
 {
struct dma_desc *p = (struct dma_desc *)head;
int i;
@@ -281,7 +282,7 @@ static void ndesc_display_ring(void *head, unsigned int 
size, bool rx)
 
x = *(u64 *)p;
pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x",
-   i, (unsigned int)virt_to_phys(p),
+   i, (unsigned int)(dma_rx_phy + i * desc_size),
(unsigned int)x, (unsigned int)(x >> 32),
p->des2, p->des3);
p++;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/dr

[PATCH 2/6] ethernet: stmmac: stop each tx channal independently

[Joakim Zhang]

If clear GMAC_CONFIG_TE bit, it would stop all tx channals, but users
may only want to stop secific tx channel.

Fixes: 48863ce5940f ("stmmac: add DMA support for GMAC 4.xx")
Signed-off-by: Joakim Zhang 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
index 0b4ee2dbb691..71e50751ef2d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
@@ -53,10 +53,6 @@ void dwmac4_dma_stop_tx(void __iomem *ioaddr, u32 chan)
 
value &= ~DMA_CONTROL_ST;
writel(value, ioaddr + DMA_CHAN_TX_CONTROL(chan));
-
-   value = readl(ioaddr + GMAC_CONFIG);
-   value &= ~GMAC_CONFIG_TE;
-   writel(value, ioaddr + GMAC_CONFIG);
 }
 
 void dwmac4_dma_start_rx(void __iomem *ioaddr, u32 chan)
-- 
2.17.1

[PATCH 1/6] ethernet: stmmac: remove redundant null check for ptp clock

[Joakim Zhang]

Remove redundant null check for ptp clock.

Fixes: 1c35cc9cf6a0 ("net: stmmac: remove redundant null check before 
clk_disable_unprepare()")
Signed-off-by: Joakim Zhang 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5b1c12ff98c0..a0bd064a8421 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5290,8 +5290,7 @@ int stmmac_resume(struct device *dev)
/* enable the clk previously disabled */
clk_prepare_enable(priv->plat->stmmac_clk);
clk_prepare_enable(priv->plat->pclk);
-   if (priv->plat->clk_ptp_ref)
-   clk_prepare_enable(priv->plat->clk_ptp_ref);
+   clk_prepare_enable(priv->plat->clk_ptp_ref);
/* reset the phy so that it's ready */
if (priv->mii)
stmmac_mdio_reset(priv->mii);
-- 
2.17.1

[PATCH 5/6] ethernet: stmmac: fix wrongly set buffer2 valid when sph unsupport

[Joakim Zhang]

In current driver, buffer2 available only when hardware supports split
header. Wrongly set buffer2 valid in stmmac_rx_refill when refill buffer
address. You can see that desc3 is 0x8100 after initialization, but
turn out to be 0x8300 after refill.

Fixes: 67afd6d1cfdf ("net: stmmac: Add Split Header support and enable it in 
XGMAC cores")
Signed-off-by: Joakim Zhang 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c   | 9 +++--
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c | 2 +-
 drivers/net/ethernet/stmicro/stmmac/hwif.h   | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c| 8 ++--
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 8e1ee33ba1e6..aecba8b1302f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -500,10 +500,15 @@ static void dwmac4_get_rx_header_len(struct dma_desc *p, 
unsigned int *len)
*len = le32_to_cpu(p->des2) & RDES2_HL;
 }
 
-static void dwmac4_set_sec_addr(struct dma_desc *p, dma_addr_t addr)
+static void dwmac4_set_sec_addr(struct dma_desc *p, dma_addr_t addr, bool 
buf2_valid)
 {
p->des2 = cpu_to_le32(lower_32_bits(addr));
-   p->des3 = cpu_to_le32(upper_32_bits(addr) | RDES3_BUFFER2_VALID_ADDR);
+   p->des3 = cpu_to_le32(upper_32_bits(addr));
+
+   if (buf2_valid)
+   p->des3 |= RDES3_BUFFER2_VALID_ADDR;
+   else
+   p->des3 &= ~RDES3_BUFFER2_VALID_ADDR;
 }
 
 static void dwmac4_set_tbs(struct dma_edesc *p, u32 sec, u32 nsec)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c 
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
index 0aaf19ab5672..ccfb0102dde4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
@@ -292,7 +292,7 @@ static void dwxgmac2_get_rx_header_len(struct dma_desc *p, 
unsigned int *len)
*len = le32_to_cpu(p->des2) & XGMAC_RDES2_HL;
 }
 
-static void dwxgmac2_set_sec_addr(struct dma_desc *p, dma_addr_t addr)
+static void dwxgmac2_set_sec_addr(struct dma_desc *p, dma_addr_t addr, bool 
is_valid)
 {
p->des2 = cpu_to_le32(lower_32_bits(addr));
p->des3 = cpu_to_le32(upper_32_bits(addr));
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h 
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index fc5260cf27ea..6423dd5ef45a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -92,7 +92,7 @@ struct stmmac_desc_ops {
int (*get_rx_hash)(struct dma_desc *p, u32 *hash,
   enum pkt_hash_types *type);
void (*get_rx_header_len)(struct dma_desc *p, unsigned int *len);
-   void (*set_sec_addr)(struct dma_desc *p, dma_addr_t addr);
+   void (*set_sec_addr)(struct dma_desc *p, dma_addr_t addr, bool 
buf2_valid);
void (*set_sarc)(struct dma_desc *p, u32 sarc_type);
void (*set_vlan_tag)(struct dma_desc *p, u16 tag, u16 inner_tag,
 u32 inner_type);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ca24e268f49a..e30529b8f40a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1314,9 +1314,10 @@ static int stmmac_init_rx_buffers(struct stmmac_priv 
*priv, struct dma_desc *p,
return -ENOMEM;
 
buf->sec_addr = page_pool_get_dma_addr(buf->sec_page);
-   stmmac_set_desc_sec_addr(priv, p, buf->sec_addr);
+   stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, true);
} else {
buf->sec_page = NULL;
+   stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, false);
}
 
buf->addr = page_pool_get_dma_addr(buf->page);
@@ -3659,7 +3660,10 @@ static inline void stmmac_rx_refill(struct stmmac_priv 
*priv, u32 queue)
   DMA_FROM_DEVICE);
 
stmmac_set_desc_addr(priv, p, buf->addr);
-   stmmac_set_desc_sec_addr(priv, p, buf->sec_addr);
+   if (priv->sph)
+   stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, true);
+   else
+   stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, false);
stmmac_refill_desc3(priv, rx_q, p);
 
rx_q->rx_count_frames++;
-- 
2.17.1

[PATCH 3/6] ethernet: stmmac: fix watchdog timeout during suspend/resume stress test

[Joakim Zhang]

stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify tx timer to
do the transmission cleanup work. Imagine such a situation, stmmac enters
suspend immediately after tx timer modified, it's expire callback
stmmac_tx_clean() would not be invoked. This could affect BQL, since
netdev_tx_sent_queue() has been called, but netdev_tx_completed_queue()
have not been involved, as a result, dql_avail(&dev_queue->dql) finally always
return a negative value.

__dev_queue_xmit->__dev_xmit_skb->qdisc_run->__qdisc_run->qdisc_restart->dequeue_skb:
if ((q->flags & TCQ_F_ONETXQUEUE) &&
netif_xmit_frozen_or_stopped(txq)) // __QUEUE_STATE_STACK_XOFF 
is set

Net core will stop transmitting any more. Finillay, net watchdong would timeout.
To fix this issue, we should call netdev_tx_reset_queue() in stmmac_resume().

Fixes: 54139cf3bb33 ("net: stmmac: adding multiple buffers for rx")
Signed-off-by: Joakim Zhang 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a0bd064a8421..41d9a5a3cc9a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5256,6 +5256,8 @@ static void stmmac_reset_queues_param(struct stmmac_priv 
*priv)
tx_q->cur_tx = 0;
tx_q->dirty_tx = 0;
tx_q->mss = 0;
+
+   netdev_tx_reset_queue(netdev_get_tx_queue(priv->dev, queue));
}
 }
 
-- 
2.17.1

[PATCH 6/6] ethernet: stmmac: re-init rx buffers when mac resume back

[Joakim Zhang]

During suspend/resume stress test, we found descriptor write back by DMA
could exhibit unusual behavior, e.g.:
003 [0xc4310030]: 0x0 0x40 0x0 0xb5010040

We can see that desc3 write back is 0xb5010040, it is still ownd by DMA,
so application would not recycle this buffer. It will trigger fatal bus
error when DMA try to use this descriptor again. To fix this issue, we
should re-init all rx buffers when mac resume back.

Signed-off-by: Joakim Zhang 
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 73 ++-
 1 file changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e30529b8f40a..e02d798e605b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1328,6 +1328,77 @@ static int stmmac_init_rx_buffers(struct stmmac_priv 
*priv, struct dma_desc *p,
return 0;
 }
 
+/**
+ * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
+ * @priv: driver private structure
+ * Description: this function is called to re-allocate a receive buffer, 
perform
+ * the DMA mapping and init the descriptor.
+ */
+static int stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
+{
+   u32 rx_count = priv->plat->rx_queues_to_use;
+   u32 queue;
+   int i;
+
+   for (queue = 0; queue < rx_count; queue++) {
+   struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+
+   for (i = 0; i < priv->dma_rx_size; i++) {
+   struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+
+   if (buf->page) {
+   page_pool_recycle_direct(rx_q->page_pool, 
buf->page);
+   buf->page = NULL;
+   }
+
+   if (priv->sph && buf->sec_page) {
+   page_pool_recycle_direct(rx_q->page_pool, 
buf->sec_page);
+   buf->sec_page = NULL;
+   }
+   }
+   }
+
+   for (queue = 0; queue < rx_count; queue++) {
+   struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+
+   for (i = 0; i < priv->dma_rx_size; i++) {
+   struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+   struct dma_desc *p;
+
+   if (priv->extend_desc)
+   p = &((rx_q->dma_erx + i)->basic);
+   else
+   p = rx_q->dma_rx + i;
+
+   if (!buf->page) {
+   buf->page = 
page_pool_dev_alloc_pages(rx_q->page_pool);
+   if (!buf->page)
+   break;
+
+   buf->addr = page_pool_get_dma_addr(buf->page);
+   }
+
+   if (priv->sph && !buf->sec_page) {
+   buf->sec_page = 
page_pool_dev_alloc_pages(rx_q->page_pool);
+   if (!buf->sec_page)
+   break;
+
+   buf->sec_addr = 
page_pool_get_dma_addr(buf->sec_page);
+   }
+
+   stmmac_set_desc_addr(priv, p, buf->addr);
+   if (priv->sph)
+   stmmac_set_desc_sec_addr(priv, p, 
buf->sec_addr, true);
+   else
+   stmmac_set_desc_sec_addr(priv, p, 
buf->sec_addr, false);
+   if (priv->dma_buf_sz == BUF_SIZE_16KiB)
+   stmmac_init_desc3(priv, p);
+   }
+   }
+
+   return 0;
+}
+
 /**
  * stmmac_free_rx_buffer - free RX dma buffers
  * @priv: private structure
@@ -5338,7 +5409,7 @@ int stmmac_resume(struct device *dev)
mutex_lock(&priv->lock);
 
stmmac_reset_queues_param(priv);
-
+   stmmac_reinit_rx_buffers(priv);
stmmac_free_tx_skbufs(priv);
stmmac_clear_descriptors(priv);
 
-- 
2.17.1

[PATCH v3 0/2] net: sfp: add support for GPON RTL8672/RTL9601C and Ubiquiti U-Fiber

[Pali Rohár]

This is a third version of patches which add workarounds for
RTL8672/RTL9601C EEPROMs and Ubiquiti U-Fiber Instant SFP.

Russel's PATCH v2 2/3 was dropped from this patch series as
it is being handled separately.

Pali Rohár (2):
  net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips
  net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant

 drivers/net/phy/sfp-bus.c |  15 +
 drivers/net/phy/sfp.c | 117 ++
 2 files changed, 97 insertions(+), 35 deletions(-)

-- 
2.20.1

[PATCH v3 1/2] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips

[Pali Rohár]

Workaround for GPON SFP modules based on VSOL V2801F brand was added in
commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490
v2.0 workaround"). But it works only for ids explicitly added to the list.
As there are more rebraded VSOL V2801F modules and OEM vendors are putting
into vendor name random strings we cannot build workaround based on ids.

Moreover issue which that commit tried to workaround is generic not only to
VSOL based modules, but rather to all GPON modules based on Realtek RTL8672
and RTL9601C chips.

They can be found for example in following GPON modules:
* V-SOL V2801F
* C-Data FD511GX-RM0
* OPTON GP801R
* BAUDCOM BD-1234-SFM
* CPGOS03-0490 v2.0
* Ubiquiti U-Fiber Instant
* EXOT EGS1

Those Realtek chips have broken EEPROM emulator which for N-byte read
operation returns just one byte of EEPROM data followed by N-1 zeros.

So introduce a new function sfp_id_needs_byte_io() which detects SFP
modules with these Realtek chips which have broken EEPROM emulator based on
N-1 zeros and switch to 1 byte EEPROM reading operation which workaround
this issue.

Function sfp_i2c_read() now always use single byte reading when it is
required and when function sfp_hwmon_probe() detects single byte access
then it disable registration of hwmon device. As in this case we cannot
reliable and atomically read 2 bytes as it is required for retrieving some
values from diagnostic area.

These Realtek chips are broken in a way that violate SFP standards for
diagnostic interface. Kernel in this case cannot do anything, only skipping
registration of hwmon interface.

This patch fixes reading of EEPROM content from SFP modules based on
Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stay
broken and cannot be fixed.

Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 
workaround")
Co-developed-by: Russell King 
Signed-off-by: Russell King 
Signed-off-by: Pali Rohár 

---
Changes in v2:
* Add explanation why also for second address is used one byte read op
* Skip hwmon registration when eeprom does not support atomic 16bit read op

Changes in v3:
* Do not break longer info messages
* Do not read memory after the end of buffer in sfp_id_needs_byte_io()
* Add comments for default i2c_block_size and Nokia 3FE46541AA module
---
 drivers/net/phy/sfp.c | 100 --
 1 file changed, 67 insertions(+), 33 deletions(-)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 91d74c1a920a..f2b5e467a800 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -336,19 +336,11 @@ static int sfp_i2c_read(struct sfp *sfp, bool a2, u8 
dev_addr, void *buf,
size_t len)
 {
struct i2c_msg msgs[2];
-   size_t block_size;
+   u8 bus_addr = a2 ? 0x51 : 0x50;
+   size_t block_size = sfp->i2c_block_size;
size_t this_len;
-   u8 bus_addr;
int ret;
 
-   if (a2) {
-   block_size = 16;
-   bus_addr = 0x51;
-   } else {
-   block_size = sfp->i2c_block_size;
-   bus_addr = 0x50;
-   }
-
msgs[0].addr = bus_addr;
msgs[0].flags = 0;
msgs[0].len = 1;
@@ -1282,6 +1274,20 @@ static void sfp_hwmon_probe(struct work_struct *work)
struct sfp *sfp = container_of(work, struct sfp, hwmon_probe.work);
int err, i;
 
+   /* hwmon interface needs to access 16bit registers in atomic way to
+* guarantee coherency of the diagnostic monitoring data. If it is not
+* possible to guarantee coherency because EEPROM is broken in such way
+* that does not support atomic 16bit read operation then we have to
+* skip registration of hwmon device.
+*/
+   if (sfp->i2c_block_size < 2) {
+   dev_info(sfp->dev,
+"skipping hwmon device registration due to broken 
EEPROM\n");
+   dev_info(sfp->dev,
+"diagnostic EEPROM area cannot be read atomically to 
guarantee data coherency\n");
+   return;
+   }
+
err = sfp_read(sfp, true, 0, &sfp->diag, sizeof(sfp->diag));
if (err < 0) {
if (sfp->hwmon_tries--) {
@@ -1642,26 +1648,30 @@ static int sfp_sm_mod_hpower(struct sfp *sfp, bool 
enable)
return 0;
 }
 
-/* Some modules (Nokia 3FE46541AA) lock up if byte 0x51 is read as a
- * single read. Switch back to reading 16 byte blocks unless we have
- * a CarlitoxxPro module (rebranded VSOL V2801F). Even more annoyingly,
- * some VSOL V2801F have the vendor name changed to OEM.
+/* GPON modules based on Realtek RTL8672 and RTL9601C chips (e.g. V-SOL
+ * V2801F, CarlitoxxPro CPGOS03-0490, Ubiquiti U-Fiber Instant, ...) do
+ * not support multibyte reads from the EEPROM. Each multi-byte read
+ * operation returns just one byte of EEPROM followed by zeros. There is
+ * no way to identify which modules are using Realtek RTL8672 and RTL9601C
+ * chips.

[PATCH v3 2/2] net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant

[Pali Rohár]

SFP GPON module Ubiquiti U-Fiber Instant has in its EEPROM stored nonsense
information. It claims that support all transceiver types including 10G
Ethernet which is not truth. So clear all claimed modes and set only one
mode which module supports: 1000baseX_Full.

Also this module have set SFF phys_id in its EEPROM. Kernel SFP subsustem
currently does not allow to use SFP modules detected as SFF. Therefore add
and exception for this module so it can be detected as supported.

This change finally allows to detect and use SFP GPON module Ubiquiti
U-Fiber Instant on Linux system.

EEPROM content of this SFP module is (where XX is serial number):

00: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8?????.??
10: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20UBNT
20: 20 20 20 20 00 18 e8 29 55 46 2d 49 4e 53 54 41.??)UF-INSTA
30: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 36NT  4   ??.6
40: 00 06 00 00 55 42 4e 54 XX XX XX XX XX XX XX XX.?..UBNT
50: 20 20 20 20 31 34 30 31 32 33 20 20 60 80 02 41140123  `??A

Signed-off-by: Pali Rohár 

---
Changes in v2:
* add this module also into sfp_module_supported() function

Changes in v3:
* no change
---
 drivers/net/phy/sfp-bus.c | 15 +++
 drivers/net/phy/sfp.c | 17 +++--
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 20b91f5dfc6e..4cf874fb5c5b 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -44,6 +44,17 @@ static void sfp_quirk_2500basex(const struct sfp_eeprom_id 
*id,
phylink_set(modes, 2500baseX_Full);
 }
 
+static void sfp_quirk_ubnt_uf_instant(const struct sfp_eeprom_id *id,
+ unsigned long *modes)
+{
+   /* Ubiquiti U-Fiber Instant module claims that support all transceiver
+* types including 10G Ethernet which is not truth. So clear all claimed
+* modes and set only one mode which module supports: 1000baseX_Full.
+*/
+   phylink_zero(modes);
+   phylink_set(modes, 1000baseX_Full);
+}
+
 static const struct sfp_quirk sfp_quirks[] = {
{
// Alcatel Lucent G-010S-P can operate at 2500base-X, but
@@ -63,6 +74,10 @@ static const struct sfp_quirk sfp_quirks[] = {
.vendor = "HUAWEI",
.part = "MA5671A",
.modes = sfp_quirk_2500basex,
+   }, {
+   .vendor = "UBNT",
+   .part = "UF-INSTANT",
+   .modes = sfp_quirk_ubnt_uf_instant,
},
 };
 
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index f2b5e467a800..7a680b5177f5 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -273,8 +273,21 @@ static const struct sff_data sff_data = {
 
 static bool sfp_module_supported(const struct sfp_eeprom_id *id)
 {
-   return id->base.phys_id == SFF8024_ID_SFP &&
-  id->base.phys_ext_id == SFP_PHYS_EXT_ID_SFP;
+   if (id->base.phys_id == SFF8024_ID_SFP &&
+   id->base.phys_ext_id == SFP_PHYS_EXT_ID_SFP)
+   return true;
+
+   /* SFP GPON module Ubiquiti U-Fiber Instant has in its EEPROM stored
+* phys id SFF instead of SFP. Therefore mark this module explicitly
+* as supported based on vendor name and pn match.
+*/
+   if (id->base.phys_id == SFF8024_ID_SFF_8472 &&
+   id->base.phys_ext_id == SFP_PHYS_EXT_ID_SFP &&
+   !memcmp(id->base.vendor_name, "UBNT", 16) &&
+   !memcmp(id->base.vendor_pn, "UF-INSTANT  ", 16))
+   return true;
+
+   return false;
 }
 
 static const struct sff_data sfp_data = {
-- 
2.20.1

Re: [PATCH] mt76: fix enum conversion warning

[Kalle Valo]

Arnd Bergmann  writes:

> From: Arnd Bergmann 
>
> A recent patch changed some enum values, but not the type
> declaration for the assignment:
>
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:238:9: error: implicit 
> conversion from enumeration type 'enum mt76_mcuq_id' to different enumeration 
> type 'enum mt76_txq_id' [-Werror,-Wenum-conversion]
> qid = MT_MCUQ_WM;
> ~ ^~
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:240:9: error: implicit 
> conversion from enumeration type 'enum mt76_mcuq_id' to different enumeration 
> type 'enum mt76_txq_id' [-Werror,-Wenum-conversion]
> qid = MT_MCUQ_FWDL;
> ~ ^~~~
>
> Change the type to match again.
>
> Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array")
> Signed-off-by: Arnd Bergmann 

Nathan submitted a similar (but not identical) patch:

https://patchwork.kernel.org/project/linux-wireless/patch/20201229211548.1348077-1-natechancel...@gmail.com/

As Nathan was first we take that one.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 4/7] wil6210: select CONFIG_CRC32

[Kalle Valo]

Arnd Bergmann  writes:

> From: Arnd Bergmann 
>
> Without crc32, the driver fails to link:
>
> arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o: in function 
> `wil_fw_verify':
> fw.c:(.text+0x74c): undefined reference to `crc32_le'
> arm-linux-gnueabi-ld: 
> drivers/net/wireless/ath/wil6210/fw.o:fw.c:(.text+0x758): more undefined 
> references to `crc32_le' follow
>
> Fixes: 151a9706503f ("wil6210: firmware download")
> Signed-off-by: Arnd Bergmann 

I'll queue this to v5.11.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 2/3] usbnet: add method for reporting speed without MDIO

[Oliver Neukum]

Am Donnerstag, den 07.01.2021, 20:27 +0100 schrieb Andrew Lunn:
> On Thu, Jan 07, 2021 at 12:35:17PM +0100, Oliver Neukum wrote:
> 
> Hi Oliver
> 
> > +++ b/include/linux/usb/usbnet.h
> > @@ -53,6 +53,8 @@ struct usbnet {
> > u32 hard_mtu;   /* count any extra framing */
> > size_t  rx_urb_size;/* size for rx urbs */
> > struct mii_if_info  mii;
> > +   longrxspeed;/* if MII is not used */
> > +   longtxspeed;/* if MII is not used */
> 
> How generic is this really? I don't know USB networking, so i cannot
> say for myself.
> 
> I'm wondering if these should be added to cdc_ncm_ctx, and
> usbnet_get_link_ksettings_ncm function should be added?
> 
> Having said that, USB_CDC_NOTIFY_SPEED_CHANGE seems like it could also
> use this. Should the patch set also handle that notification and set
> usbnet->rxspeed and usbnet->txspeed? These would then be used in
> multiple places and that would justify it being in struct usbnet.

Hi,

yes, everything that gets notification in CDC style should use this
mechanism.

Regards
Oliver

Re: [RFC PATCH net] udp: check sk for UDP GRO fraglist

[Alexander Lobakin]

From: Steffen Klassert 
Date: Mon, 11 Jan 2021 09:43:22 +0100

> On Mon, Jan 11, 2021 at 11:02:42AM +0900, Dongseok Yi wrote:
>> On 2021-01-08 22:35, Steffen Klassert wrote:
>>> On Fri, Jan 08, 2021 at 09:52:28PM +0900, Dongseok Yi wrote:
 It is a workaround patch.

 UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
 forwarding. Only the header of head_skb from ip_finish_output_gso ->
 skb_gso_segment is updated but following frag_skbs are not updated.

 A call path skb_mac_gso_segment -> inet_gso_segment ->
 udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list
 does not try to update any UDP/IP header of the segment list.

 It might make sense because each skb of frag_skbs is converted to a
 list of regular packets. Header update with checksum calculation may
 be not needed for UDP GROed frag_skbs.

 But UDP GRO frag_list is started from udp_gro_receive, we don't know
 whether the skb will be NAT forwarded at that time. For workaround,
 try to get sock always when call udp4_gro_receive -> udp_gro_receive
 to check if the skb is for local.

 I'm still not sure if UDP GRO frag_list is really designed for local
 session only. Can kernel support NAT forward for UDP GRO frag_list?
 What am I missing?
>>>
>>> The initial idea when I implemented this was to have a fast
>>> forwarding path for UDP. So forwarding is a usecase, but NAT
>>> is a problem, indeed. A quick fix could be to segment the
>>> skb before it gets NAT forwarded. Alternatively we could
>>> check for a header change in __udp_gso_segment_list and
>>> update the header of the frag_skbs accordingly in that case.
>>
>> Thank you for explaining.
>> Can I think of it as a known issue?
>
> No, it was not known before you reported it.
>
>> I think we should have a fix
>> because NAT can be triggered by user. Can I check the current status?
>> Already planning a patch or a new patch should be written?
>
> We have to do a new patch to fix that issue. If you want do
> do so, go ahead.

This patch is incorrect. I do NAT UDP GRO Fraglists via nftables
(both with and without flow offload) with no issues since March'20.
Packet loss rates are always +/- 0, so I can say it works properly.
I can share any details / dump any runtime data if needed.

Thanks,
Al

Re: [PATCH 21/21] vdpasim: control virtqueue support

[Eli Cohen]

On Wed, Dec 16, 2020 at 02:48:18PM +0800, Jason Wang wrote:
> This patch introduces the control virtqueue support for vDPA
> simulator. This is a requirement for supporting advanced features like
> multiqueue.
> 
> A requirement for control virtqueue is to isolate its memory access
> from the rx/tx virtqueues. This is because when using vDPA device
> for VM, the control virqueue is not directly assigned to VM. Userspace
> (Qemu) will present a shadow control virtqueue to control for
> recording the device states.
> 
> The isolation is done via the virtqueue groups and ASID support in
> vDPA through vhost-vdpa. The simulator is extended to have:
> 
> 1) three virtqueues: RXVQ, TXVQ and CVQ (control virtqueue)
> 2) two virtqueue groups: group 0 contains RXVQ and TXVQ; group 1
>contains CVQ
> 3) two address spaces and the simulator simply implements the address
>spaces by mapping it 1:1 to IOTLB.
> 
> For the VM use cases, userspace(Qemu) may set AS 0 to group 0 and AS 1
> to group 1. So we have:
> 
> 1) The IOTLB for virtqueue group 0 contains the mappings of guest, so
>RX and TX can be assigned to guest directly.
> 2) The IOTLB for virtqueue group 1 contains the mappings of CVQ which
>is the buffers that allocated and managed by VMM only. So CVQ of
>vhost-vdpa is visible to VMM only. And Guest can not access the CVQ
>of vhost-vdpa.
> 
> For the other use cases, since AS 0 is associated to all virtqueue
> groups by default. All virtqueues share the same mapping by default.
> 
> To demonstrate the function, VIRITO_NET_F_CTRL_MACADDR is
> implemented in the simulator for the driver to set mac address.
> 

Hi Jason,

is there any version of qemu/libvirt available that I can see the
control virtqueue working in action?

> Signed-off-by: Jason Wang 
> ---
>  drivers/vdpa/vdpa_sim/vdpa_sim.c | 189 +++
>  1 file changed, 166 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c 
> b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> index fe90a783bde4..0fd06ac491cd 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> @@ -60,14 +60,18 @@ struct vdpasim_virtqueue {
>  #define VDPASIM_QUEUE_MAX 256
>  #define VDPASIM_DEVICE_ID 0x1
>  #define VDPASIM_VENDOR_ID 0
> -#define VDPASIM_VQ_NUM 0x2
> +#define VDPASIM_VQ_NUM 0x3
> +#define VDPASIM_AS_NUM 0x2
> +#define VDPASIM_GROUP_NUM 0x2
>  #define VDPASIM_NAME "vdpasim-netdev"
>  
>  static u64 vdpasim_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
> (1ULL << VIRTIO_F_VERSION_1)  |
> (1ULL << VIRTIO_F_ACCESS_PLATFORM) |
> +   (1ULL << VIRTIO_NET_F_MTU) |
> (1ULL << VIRTIO_NET_F_MAC) |
> -   (1ULL << VIRTIO_NET_F_MTU);
> +   (1ULL << VIRTIO_NET_F_CTRL_VQ) |
> +   (1ULL << VIRTIO_NET_F_CTRL_MAC_ADDR);
>  
>  /* State of each vdpasim device */
>  struct vdpasim {
> @@ -147,11 +151,17 @@ static void vdpasim_reset(struct vdpasim *vdpasim)
>  {
>   int i;
>  
> - for (i = 0; i < VDPASIM_VQ_NUM; i++)
> + spin_lock(&vdpasim->iommu_lock);
> +
> + for (i = 0; i < VDPASIM_VQ_NUM; i++) {
>   vdpasim_vq_reset(&vdpasim->vqs[i]);
> + vringh_set_iotlb(&vdpasim->vqs[i].vring,
> +  &vdpasim->iommu[0]);
> + }
>  
> - spin_lock(&vdpasim->iommu_lock);
> - vhost_iotlb_reset(vdpasim->iommu);
> + for (i = 0; i < VDPASIM_AS_NUM; i++) {
> + vhost_iotlb_reset(&vdpasim->iommu[i]);
> + }
>   spin_unlock(&vdpasim->iommu_lock);
>  
>   vdpasim->features = 0;
> @@ -191,6 +201,81 @@ static bool receive_filter(struct vdpasim *vdpasim, 
> size_t len)
>   return false;
>  }
>  
> +virtio_net_ctrl_ack vdpasim_handle_ctrl_mac(struct vdpasim *vdpasim,
> + u8 cmd)
> +{
> + struct vdpasim_virtqueue *cvq = &vdpasim->vqs[2];
> + virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
> + size_t read;
> +
> + switch (cmd) {
> + case VIRTIO_NET_CTRL_MAC_ADDR_SET:
> + read = vringh_iov_pull_iotlb(&cvq->vring, &cvq->in_iov,
> +  (void *)vdpasim->config.mac,
> +  ETH_ALEN);
> + if (read == ETH_ALEN)
> + status = VIRTIO_NET_OK;
> + break;
> + default:
> + break;
> + }
> +
> + return status;
> +}
> +
> +static void vdpasim_handle_cvq(struct vdpasim *vdpasim)
> +{
> + struct vdpasim_virtqueue *cvq = &vdpasim->vqs[2];
> + virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
> + struct virtio_net_ctrl_hdr ctrl;
> + size_t read, write;
> + int err;
> +
> + if (!(vdpasim->features & (1ULL << VIRTIO_NET_F_CTRL_VQ)))
> + return;
> +
> + if (!cvq->ready)
> + return;
> +
> + while (true) {
> +   

[PATCH net-next 0/2] net: enable udp v6 sockets receiving v4 packets with UDP GRO

[Xin Long]

Currently, udp v6 socket can not process v4 packets with UDP GRO, as
udp_encap_needed_key is not increased when udp_tunnel_encap_enable()
is called for v6 socket. This patchset is to increase it and remove
the unnecessary code in bareudp.

Xin Long (2):
  udp: call udp_encap_enable for v6 sockets when enabling encap
  Revert "bareudp: Fixed bareudp receive handling"

 drivers/net/bareudp.c| 6 --
 include/net/udp_tunnel.h | 3 +--
 net/ipv6/udp.c   | 4 +++-
 3 files changed, 4 insertions(+), 9 deletions(-)

-- 
2.1.0

[PATCH net-next 1/2] udp: call udp_encap_enable for v6 sockets when enabling encap

[Xin Long]

When enabling encap for a ipv6 socket without udp_encap_needed_key
increased, UDP GRO won't work for v4 mapped v6 address packets as
sk will be NULL in udp4_gro_receive().

This patch is to enable it by increasing udp_encap_needed_key for
v6 sockets in udp_tunnel_encap_enable(), and correspondingly
decrease udp_encap_needed_key in udpv6_destroy_sock().

Reported-by: Chen Yi 
Signed-off-by: Xin Long 
---
 include/net/udp_tunnel.h | 3 +--
 net/ipv6/udp.c   | 4 +++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
index 282d10e..afc7ce7 100644
--- a/include/net/udp_tunnel.h
+++ b/include/net/udp_tunnel.h
@@ -181,9 +181,8 @@ static inline void udp_tunnel_encap_enable(struct socket 
*sock)
 #if IS_ENABLED(CONFIG_IPV6)
if (sock->sk->sk_family == PF_INET6)
ipv6_stub->udpv6_encap_enable();
-   else
 #endif
-   udp_encap_enable();
+   udp_encap_enable();
 }
 
 #define UDP_TUNNEL_NIC_MAX_TABLES  4
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index b9f3dfd..265b6a0 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1608,8 +1608,10 @@ void udpv6_destroy_sock(struct sock *sk)
if (encap_destroy)
encap_destroy(sk);
}
-   if (up->encap_enabled)
+   if (up->encap_enabled) {
static_branch_dec(&udpv6_encap_needed_key);
+   static_branch_dec(&udp_encap_needed_key);
+   }
}
 
inet6_destroy_sock(sk);
-- 
2.1.0

[PATCH net-next 2/2] Revert "bareudp: Fixed bareudp receive handling"

[Xin Long]

As udp_encap_enable() is already called in udp_tunnel_encap_enable()
since the last patch, and we don't need it any more. So remove it by
reverting commit 81f954a44567567c7d74a97b1db78fb43afc253d.
---
 drivers/net/bareudp.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/bareudp.c b/drivers/net/bareudp.c
index 85de5f9..aed5049 100644
--- a/drivers/net/bareudp.c
+++ b/drivers/net/bareudp.c
@@ -240,12 +240,6 @@ static int bareudp_socket_create(struct bareudp_dev 
*bareudp, __be16 port)
tunnel_cfg.encap_destroy = NULL;
setup_udp_tunnel_sock(bareudp->net, sock, &tunnel_cfg);
 
-   /* As the setup_udp_tunnel_sock does not call udp_encap_enable if the
-* socket type is v6 an explicit call to udp_encap_enable is needed.
-*/
-   if (sock->sk->sk_family == AF_INET6)
-   udp_encap_enable();
-
rcu_assign_pointer(bareudp->sock, sock);
return 0;
 }
-- 
2.1.0

[PATCH net-next 1/2] net: move the hsize check to the else block in skb_segment

[Xin Long]

After commit 89319d3801d1 ("net: Add frag_list support to skb_segment"),
it goes to process frag_list when !hsize in skb_segment(). However, when
using skb frag_list, sg normally should not be set. In this case, hsize
will be set with len right before !hsize check, then it won't go to
frag_list processing code.

So the right thing to do is move the hsize check to the else block, so
that it won't affect the !hsize check for frag_list processing.

Signed-off-by: Xin Long 
---
 net/core/skbuff.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7626a33..ea79359 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3855,8 +3855,6 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
hsize = skb_headlen(head_skb) - offset;
if (hsize < 0)
hsize = 0;
-   if (hsize > len || !sg)
-   hsize = len;
 
if (!hsize && i >= nfrags && skb_headlen(list_skb) &&
(skb_headlen(list_skb) == len || sg)) {
@@ -3901,6 +3899,9 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
skb_release_head_state(nskb);
__skb_push(nskb, doffset);
} else {
+   if (hsize > len || !sg)
+   hsize = len;
+
nskb = __alloc_skb(hsize + doffset + headroom,
   GFP_ATOMIC, 
skb_alloc_rx_flag(head_skb),
   NUMA_NO_NODE);
-- 
2.1.0

[PATCH net-next 0/2] net: fix the features flag in sctp_gso_segment

[Xin Long]

Patch 1/2 is to improve the code in skb_segment(), and it is needed
by Patch 2/2.

Xin Long (2):
  net: move the hsize check to the else block in skb_segment
  sctp: remove the NETIF_F_SG flag before calling skb_segment

 net/core/skbuff.c  | 5 +++--
 net/sctp/offload.c | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
2.1.0

[PATCH net-next 2/2] sctp: remove the NETIF_F_SG flag before calling skb_segment

[Xin Long]

It makes more sense to clear NETIF_F_SG instead of set it when
calling skb_segment() in sctp_gso_segment(), since SCTP GSO is
using head_skb's fraglist, of which all frags are linear skbs.

This will make SCTP GSO code more understandable.

Suggested-by: Alexander Duyck 
Signed-off-by: Xin Long 
---
 net/sctp/offload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sctp/offload.c b/net/sctp/offload.c
index ce281a9..eb874e3 100644
--- a/net/sctp/offload.c
+++ b/net/sctp/offload.c
@@ -68,7 +68,7 @@ static struct sk_buff *sctp_gso_segment(struct sk_buff *skb,
goto out;
}
 
-   segs = skb_segment(skb, features | NETIF_F_HW_CSUM | NETIF_F_SG);
+   segs = skb_segment(skb, (features | NETIF_F_HW_CSUM) & ~NETIF_F_SG);
if (IS_ERR(segs))
goto out;
 
-- 
2.1.0

[PATCH net-next] net: ks8851: Select PHYLIB and MICREL_PHY in Kconfig

[Marek Vasut]

The PHYLIB must be selected to provide mdiobus_*() functions, and the
MICREL_PHY is necessary too, as that is the only possible PHY attached
to the KS8851 (it is the internal PHY).

Fixes: ef3631220d2b ("net: ks8851: Register MDIO bus and the internal PHY")
Signed-off-by: Marek Vasut 
Cc: Andrew Lunn 
Cc: Heiner Kallweit 
Cc: Lukas Wunner 
---
 drivers/net/ethernet/micrel/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/micrel/Kconfig 
b/drivers/net/ethernet/micrel/Kconfig
index 42bc014136fe..93df3049cdc0 100644
--- a/drivers/net/ethernet/micrel/Kconfig
+++ b/drivers/net/ethernet/micrel/Kconfig
@@ -31,6 +31,8 @@ config KS8851
select MII
select CRC32
select EEPROM_93CX6
+   select PHYLIB
+   select MICREL_PHY
help
  SPI driver for Micrel KS8851 SPI attached network chip.
 
@@ -40,6 +42,8 @@ config KS8851_MLL
select MII
select CRC32
select EEPROM_93CX6
+   select PHYLIB
+   select MICREL_PHY
help
  This platform driver is for Micrel KS8851 Address/data bus
  multiplexed network chip.
-- 
2.29.2

[PATCH net-next] net: ks8851: Connect and start/stop the internal PHY

[Marek Vasut]

Unless the internal PHY is connected and started, the phylib will not
poll the PHY for state and produce state updates. Connect the PHY and
start/stop it.

Signed-off-by: Marek Vasut 
Cc: Andrew Lunn 
Cc: Heiner Kallweit 
Cc: Lukas Wunner 
---
 drivers/net/ethernet/micrel/ks8851.h|  2 ++
 drivers/net/ethernet/micrel/ks8851_common.c | 28 +
 2 files changed, 30 insertions(+)

diff --git a/drivers/net/ethernet/micrel/ks8851.h 
b/drivers/net/ethernet/micrel/ks8851.h
index e2eb0caeac82..ef13929036cf 100644
--- a/drivers/net/ethernet/micrel/ks8851.h
+++ b/drivers/net/ethernet/micrel/ks8851.h
@@ -359,6 +359,7 @@ union ks8851_tx_hdr {
  * @vdd_io: Optional digital power supply for IO
  * @gpio: Optional reset_n gpio
  * @mii_bus: Pointer to MII bus structure
+ * @phy_dev: Pointer to PHY device structure
  * @lock: Bus access lock callback
  * @unlock: Bus access unlock callback
  * @rdreg16: 16bit register read callback
@@ -405,6 +406,7 @@ struct ks8851_net {
struct regulator*vdd_io;
int gpio;
struct mii_bus  *mii_bus;
+   struct phy_device   *phy_dev;
 
void(*lock)(struct ks8851_net *ks,
unsigned long *flags);
diff --git a/drivers/net/ethernet/micrel/ks8851_common.c 
b/drivers/net/ethernet/micrel/ks8851_common.c
index 058fd99bd483..a3716fd2d858 100644
--- a/drivers/net/ethernet/micrel/ks8851_common.c
+++ b/drivers/net/ethernet/micrel/ks8851_common.c
@@ -432,6 +432,11 @@ static void ks8851_flush_tx_work(struct ks8851_net *ks)
ks->flush_tx_work(ks);
 }
 
+static void ks8851_handle_link_change(struct net_device *net)
+{
+   phy_print_status(net->phydev);
+}
+
 /**
  * ks8851_net_open - open network device
  * @dev: The network device being opened.
@@ -445,11 +450,22 @@ static int ks8851_net_open(struct net_device *dev)
unsigned long flags;
int ret;
 
+   ret = phy_connect_direct(ks->netdev, ks->phy_dev,
+&ks8851_handle_link_change,
+PHY_INTERFACE_MODE_INTERNAL);
+   if (ret) {
+   netdev_err(dev, "failed to attach PHY\n");
+   return ret;
+   }
+
+   phy_attached_info(ks->phy_dev);
+
ret = request_threaded_irq(dev->irq, NULL, ks8851_irq,
   IRQF_TRIGGER_LOW | IRQF_ONESHOT,
   dev->name, ks);
if (ret < 0) {
netdev_err(dev, "failed to get irq\n");
+   phy_disconnect(ks->phy_dev);
return ret;
}
 
@@ -507,6 +523,7 @@ static int ks8851_net_open(struct net_device *dev)
netif_dbg(ks, ifup, ks->netdev, "network device up\n");
 
ks8851_unlock(ks, &flags);
+   phy_start(ks->phy_dev);
mii_check_link(&ks->mii);
return 0;
 }
@@ -528,6 +545,9 @@ static int ks8851_net_stop(struct net_device *dev)
 
netif_stop_queue(dev);
 
+   phy_stop(ks->phy_dev);
+   phy_disconnect(ks->phy_dev);
+
ks8851_lock(ks, &flags);
/* turn off the IRQs and ack any outstanding */
ks8851_wrreg16(ks, KS_IER, 0x);
@@ -1084,6 +1104,7 @@ int ks8851_resume(struct device *dev)
 
 static int ks8851_register_mdiobus(struct ks8851_net *ks, struct device *dev)
 {
+   struct phy_device *phy_dev;
struct mii_bus *mii_bus;
int ret;
 
@@ -1103,10 +1124,17 @@ static int ks8851_register_mdiobus(struct ks8851_net 
*ks, struct device *dev)
if (ret)
goto err_mdiobus_register;
 
+   phy_dev = phy_find_first(mii_bus);
+   if (!phy_dev)
+   goto err_find_phy;
+
ks->mii_bus = mii_bus;
+   ks->phy_dev = phy_dev;
 
return 0;
 
+err_find_phy:
+   mdiobus_unregister(mii_bus);
 err_mdiobus_register:
mdiobus_free(mii_bus);
return ret;
-- 
2.29.2

[PATCH 4.4 12/38] net: sched: prevent invalid Scell_log shift count

[Greg Kroah-Hartman]

From: Randy Dunlap 

[ Upstream commit bd1248f1ddbc48b0c30565fce897a3b6423313b8 ]

Check Scell_log shift size in red_check_params() and modify all callers
of red_check_params() to pass Scell_log.

This prevents a shift out-of-bounds as detected by UBSAN:
  UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
  shift exponent 72 is too large for 32-bit type 'int'

Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
Signed-off-by: Randy Dunlap 
Reported-by: syzbot+97c5bd9cc81eca63d...@syzkaller.appspotmail.com
Cc: Nogah Frankel 
Cc: Jamal Hadi Salim 
Cc: Cong Wang 
Cc: Jiri Pirko 
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 include/net/red.h |4 +++-
 net/sched/sch_choke.c |2 +-
 net/sched/sch_gred.c  |2 +-
 net/sched/sch_red.c   |2 +-
 net/sched/sch_sfq.c   |2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

--- a/include/net/red.h
+++ b/include/net/red.h
@@ -167,12 +167,14 @@ static inline void red_set_vars(struct r
v->qcount   = -1;
 }
 
-static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog)
+static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog, u8 
Scell_log)
 {
if (fls(qth_min) + Wlog > 32)
return false;
if (fls(qth_max) + Wlog > 32)
return false;
+   if (Scell_log >= 32)
+   return false;
if (qth_max < qth_min)
return false;
return true;
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -439,7 +439,7 @@ static int choke_change(struct Qdisc *sc
 
ctl = nla_data(tb[TCA_CHOKE_PARMS]);
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > CHOKE_MAX_QUEUE)
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -389,7 +389,7 @@ static inline int gred_change_vq(struct
struct gred_sched *table = qdisc_priv(sch);
struct gred_sched_data *q = table->tab[dp];
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (!q) {
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -203,7 +203,7 @@ static int red_change(struct Qdisc *sch,
max_P = tb[TCA_RED_MAX_P] ? nla_get_u32(tb[TCA_RED_MAX_P]) : 0;
 
ctl = nla_data(tb[TCA_RED_PARMS]);
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > 0) {
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -645,7 +645,7 @@ static int sfq_change(struct Qdisc *sch,
}
 
if (ctl_v1 && !red_check_params(ctl_v1->qth_min, ctl_v1->qth_max,
-   ctl_v1->Wlog))
+   ctl_v1->Wlog, ctl_v1->Scell_log))
return -EINVAL;
if (ctl_v1 && ctl_v1->qth_min) {
p = kmalloc(sizeof(*p), GFP_KERNEL);

[PATCH 4.14 23/57] net: sched: prevent invalid Scell_log shift count

[Greg Kroah-Hartman]

From: Randy Dunlap 

[ Upstream commit bd1248f1ddbc48b0c30565fce897a3b6423313b8 ]

Check Scell_log shift size in red_check_params() and modify all callers
of red_check_params() to pass Scell_log.

This prevents a shift out-of-bounds as detected by UBSAN:
  UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
  shift exponent 72 is too large for 32-bit type 'int'

Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
Signed-off-by: Randy Dunlap 
Reported-by: syzbot+97c5bd9cc81eca63d...@syzkaller.appspotmail.com
Cc: Nogah Frankel 
Cc: Jamal Hadi Salim 
Cc: Cong Wang 
Cc: Jiri Pirko 
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 include/net/red.h |4 +++-
 net/sched/sch_choke.c |2 +-
 net/sched/sch_gred.c  |2 +-
 net/sched/sch_red.c   |2 +-
 net/sched/sch_sfq.c   |2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

--- a/include/net/red.h
+++ b/include/net/red.h
@@ -168,12 +168,14 @@ static inline void red_set_vars(struct r
v->qcount   = -1;
 }
 
-static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog)
+static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog, u8 
Scell_log)
 {
if (fls(qth_min) + Wlog > 32)
return false;
if (fls(qth_max) + Wlog > 32)
return false;
+   if (Scell_log >= 32)
+   return false;
if (qth_max < qth_min)
return false;
return true;
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -370,7 +370,7 @@ static int choke_change(struct Qdisc *sc
 
ctl = nla_data(tb[TCA_CHOKE_PARMS]);
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > CHOKE_MAX_QUEUE)
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -356,7 +356,7 @@ static inline int gred_change_vq(struct
struct gred_sched *table = qdisc_priv(sch);
struct gred_sched_data *q = table->tab[dp];
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (!q) {
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -184,7 +184,7 @@ static int red_change(struct Qdisc *sch,
max_P = tb[TCA_RED_MAX_P] ? nla_get_u32(tb[TCA_RED_MAX_P]) : 0;
 
ctl = nla_data(tb[TCA_RED_PARMS]);
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > 0) {
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -649,7 +649,7 @@ static int sfq_change(struct Qdisc *sch,
}
 
if (ctl_v1 && !red_check_params(ctl_v1->qth_min, ctl_v1->qth_max,
-   ctl_v1->Wlog))
+   ctl_v1->Wlog, ctl_v1->Scell_log))
return -EINVAL;
if (ctl_v1 && ctl_v1->qth_min) {
p = kmalloc(sizeof(*p), GFP_KERNEL);

[PATCHv2 net-next] ip_gre: remove CRC flag from dev features in gre_gso_segment

[Xin Long]

This patch is to let it always do CRC checksum in sctp_gso_segment()
by removing CRC flag from the dev features in gre_gso_segment() for
SCTP over GRE, just as it does in Commit 527beb8ef9c0 ("udp: support
sctp over udp in skb_udp_tunnel_segment") for SCTP over UDP.

It could set csum/csum_start in GSO CB properly in sctp_gso_segment()
after that commit, so it would do checksum with gso_make_checksum()
in gre_gso_segment(), and Commit 622e32b7d4a6 ("net: gre: recompute
gre csum for sctp over gre tunnels") can be reverted now.

Note that the current HWs like igb NIC can only handle the SCTP CRC
when it's in the outer packet, not in the inner packet like in this
case, so here it removes CRC flag from the dev features even when
need_csum is false.

v1->v2:
  - improve the changelog.
  - fix "rev xmas tree" in varibles declaration.

Signed-off-by: Xin Long 
---
 net/ipv4/gre_offload.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index e0a2465..a681306 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -15,10 +15,10 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
   netdev_features_t features)
 {
int tnl_hlen = skb_inner_mac_header(skb) - skb_transport_header(skb);
-   bool need_csum, need_recompute_csum, gso_partial;
struct sk_buff *segs = ERR_PTR(-EINVAL);
u16 mac_offset = skb->mac_header;
__be16 protocol = skb->protocol;
+   bool need_csum, gso_partial;
u16 mac_len = skb->mac_len;
int gre_offset, outer_hlen;
 
@@ -41,10 +41,11 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
skb->protocol = skb->inner_protocol;
 
need_csum = !!(skb_shinfo(skb)->gso_type & SKB_GSO_GRE_CSUM);
-   need_recompute_csum = skb->csum_not_inet;
skb->encap_hdr_csum = need_csum;
 
features &= skb->dev->hw_enc_features;
+   /* CRC checksum can't be handled by HW when SCTP is the inner proto. */
+   features &= ~NETIF_F_SCTP_CRC;
 
/* segment inner packet. */
segs = skb_mac_gso_segment(skb, features);
@@ -99,15 +100,7 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
}
 
*(pcsum + 1) = 0;
-   if (need_recompute_csum && !skb_is_gso(skb)) {
-   __wsum csum;
-
-   csum = skb_checksum(skb, gre_offset,
-   skb->len - gre_offset, 0);
-   *pcsum = csum_fold(csum);
-   } else {
-   *pcsum = gso_make_checksum(skb, 0);
-   }
+   *pcsum = gso_make_checksum(skb, 0);
} while ((skb = skb->next));
 out:
return segs;
-- 
2.1.0

Re: [PATCH v4 net-next 1/2] ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls

[Simon Chopin]

Hello,

Le 10/12/2020 à 16:50, Tom Parkin a écrit :
> This new ioctl pair allows two ppp channels to be bridged together:
> frames arriving in one channel are transmitted in the other channel
> and vice versa.
> 
> The practical use for this is primarily to support the L2TP Access
> Concentrator use-case.  The end-user session is presented as a ppp
> channel (typically PPPoE, although it could be e.g. PPPoA, or even PPP
> over a serial link) and is switched into a PPPoL2TP session for
> transmission to the LNS.  At the LNS the PPP session is terminated in
> the ISP's network.
> 
> When a PPP channel is bridged to another it takes a reference on the
> other's struct ppp_file.  This reference is dropped when the channels
> are unbridged, which can occur either explicitly on userspace calling
> the PPPIOCUNBRIDGECHAN ioctl, or implicitly when either channel in the
> bridge is unregistered.
> 
> In order to implement the channel bridge, struct channel is extended
> with a new field, 'bridge', which points to the other struct channel
> making up the bridge.
> 
> This pointer is RCU protected to avoid adding another lock to the data
> path.
> 
> To guard against concurrent writes to the pointer, the existing struct
> channel lock 'upl' coverage is extended rather than adding a new lock.
> 
> The 'upl' lock is used to protect the existing unit pointer.  Since the
> bridge effectively replaces the unit (they're mutually exclusive for a
> channel) it makes coding easier to use the same lock to cover them
> both.
> 
> Signed-off-by: Tom Parkin 
> ---
>  drivers/net/ppp/ppp_generic.c  | 152 -
>  include/uapi/linux/ppp-ioctl.h |   2 +
>  2 files changed, 151 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> index 7d005896a0f9..09c27f7773f9 100644
> --- a/drivers/net/ppp/ppp_generic.c
> +++ b/drivers/net/ppp/ppp_generic.c
> @@ -174,7 +174,8 @@ struct channel {
>   struct ppp  *ppp;   /* ppp unit we're connected to */
>   struct net  *chan_net;  /* the net channel belongs to */
>   struct list_head clist; /* link in list of channels per unit */
> - rwlock_tupl;/* protects `ppp' */
> + rwlock_tupl;/* protects `ppp' and 'bridge' */
> + struct channel __rcu *bridge;   /* "bridged" ppp channel */
>  #ifdef CONFIG_PPP_MULTILINK
>   u8  avail;  /* flag used in multilink stuff */
>   u8  had_frag;   /* >= 1 fragments have been sent */
> @@ -606,6 +607,83 @@ static struct bpf_prog *compat_ppp_get_filter(struct 
> sock_fprog32 __user *p)
>  #endif
>  #endif
>  
> +/* Bridge one PPP channel to another.
> + * When two channels are bridged, ppp_input on one channel is redirected to
> + * the other's ops->start_xmit handler.
> + * In order to safely bridge channels we must reject channels which are 
> already
> + * part of a bridge instance, or which form part of an existing unit.
> + * Once successfully bridged, each channel holds a reference on the other
> + * to prevent it being freed while the bridge is extant.
> + */
> +static int ppp_bridge_channels(struct channel *pch, struct channel *pchb)
> +{
> + write_lock_bh(&pch->upl);
> + if (pch->ppp ||
> + rcu_dereference_protected(pch->bridge, lockdep_is_held(&pch->upl))) 
> {
> + write_unlock_bh(&pch->upl);
> + return -EALREADY;
> + }
> + rcu_assign_pointer(pch->bridge, pchb);
> + write_unlock_bh(&pch->upl);
> +
This is mostly for my own education:

I might be misunderstanding something, but is there anything
that would prevent a packet from being forwarded from pch to pchb at this
precise moment? If not, then it might be theoretically possible to have
any answer to said packet (say, a LCP ACK) to be received before the 
pchb->bridge is set?


> + write_lock_bh(&pchb->upl);
> + if (pchb->ppp ||
> + rcu_dereference_protected(pchb->bridge, 
> lockdep_is_held(&pchb->upl))) {
> + write_unlock_bh(&pchb->upl);
> + goto err_unset;
> + }
> + rcu_assign_pointer(pchb->bridge, pch);
> + write_unlock_bh(&pchb->upl);
> +
> + refcount_inc(&pch->file.refcnt);
> + refcount_inc(&pchb->file.refcnt);
> +
> + return 0;
> +
> +err_unset:
> + write_lock_bh(&pch->upl);
> + RCU_INIT_POINTER(pch->bridge, NULL);
> + write_unlock_bh(&pch->upl);
> + synchronize_rcu();
> + return -EALREADY;
> +}

Re: [PATCH net-next] net: ks8851: Connect and start/stop the internal PHY

[Heiner Kallweit]

On 11.01.2021 13:53, Marek Vasut wrote:
> Unless the internal PHY is connected and started, the phylib will not
> poll the PHY for state and produce state updates. Connect the PHY and
> start/stop it.
> 
> Signed-off-by: Marek Vasut 
> Cc: Andrew Lunn 
> Cc: Heiner Kallweit 
> Cc: Lukas Wunner 
> ---
>  drivers/net/ethernet/micrel/ks8851.h|  2 ++
>  drivers/net/ethernet/micrel/ks8851_common.c | 28 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/net/ethernet/micrel/ks8851.h 
> b/drivers/net/ethernet/micrel/ks8851.h
> index e2eb0caeac82..ef13929036cf 100644
> --- a/drivers/net/ethernet/micrel/ks8851.h
> +++ b/drivers/net/ethernet/micrel/ks8851.h
> @@ -359,6 +359,7 @@ union ks8851_tx_hdr {
>   * @vdd_io: Optional digital power supply for IO
>   * @gpio: Optional reset_n gpio
>   * @mii_bus: Pointer to MII bus structure
> + * @phy_dev: Pointer to PHY device structure
>   * @lock: Bus access lock callback
>   * @unlock: Bus access unlock callback
>   * @rdreg16: 16bit register read callback
> @@ -405,6 +406,7 @@ struct ks8851_net {
>   struct regulator*vdd_io;
>   int gpio;
>   struct mii_bus  *mii_bus;
> + struct phy_device   *phy_dev;
>  
>   void(*lock)(struct ks8851_net *ks,
>   unsigned long *flags);
> diff --git a/drivers/net/ethernet/micrel/ks8851_common.c 
> b/drivers/net/ethernet/micrel/ks8851_common.c
> index 058fd99bd483..a3716fd2d858 100644
> --- a/drivers/net/ethernet/micrel/ks8851_common.c
> +++ b/drivers/net/ethernet/micrel/ks8851_common.c
> @@ -432,6 +432,11 @@ static void ks8851_flush_tx_work(struct ks8851_net *ks)
>   ks->flush_tx_work(ks);
>  }
>  
> +static void ks8851_handle_link_change(struct net_device *net)
> +{
> + phy_print_status(net->phydev);
> +}
> +
>  /**
>   * ks8851_net_open - open network device
>   * @dev: The network device being opened.
> @@ -445,11 +450,22 @@ static int ks8851_net_open(struct net_device *dev)
>   unsigned long flags;
>   int ret;
>  
> + ret = phy_connect_direct(ks->netdev, ks->phy_dev,
> +  &ks8851_handle_link_change,
> +  PHY_INTERFACE_MODE_INTERNAL);
> + if (ret) {
> + netdev_err(dev, "failed to attach PHY\n");
> + return ret;
> + }
> +
> + phy_attached_info(ks->phy_dev);
> +
>   ret = request_threaded_irq(dev->irq, NULL, ks8851_irq,
>  IRQF_TRIGGER_LOW | IRQF_ONESHOT,
>  dev->name, ks);
>   if (ret < 0) {
>   netdev_err(dev, "failed to get irq\n");
> + phy_disconnect(ks->phy_dev);
>   return ret;
>   }
>  
> @@ -507,6 +523,7 @@ static int ks8851_net_open(struct net_device *dev)
>   netif_dbg(ks, ifup, ks->netdev, "network device up\n");
>  
>   ks8851_unlock(ks, &flags);
> + phy_start(ks->phy_dev);
>   mii_check_link(&ks->mii);
>   return 0;
>  }
> @@ -528,6 +545,9 @@ static int ks8851_net_stop(struct net_device *dev)
>  
>   netif_stop_queue(dev);
>  
> + phy_stop(ks->phy_dev);
> + phy_disconnect(ks->phy_dev);
> +
>   ks8851_lock(ks, &flags);
>   /* turn off the IRQs and ack any outstanding */
>   ks8851_wrreg16(ks, KS_IER, 0x);
> @@ -1084,6 +1104,7 @@ int ks8851_resume(struct device *dev)
>  
>  static int ks8851_register_mdiobus(struct ks8851_net *ks, struct device *dev)
>  {
> + struct phy_device *phy_dev;
>   struct mii_bus *mii_bus;
>   int ret;
>  
> @@ -1103,10 +1124,17 @@ static int ks8851_register_mdiobus(struct ks8851_net 
> *ks, struct device *dev)
>   if (ret)
>   goto err_mdiobus_register;
>  
> + phy_dev = phy_find_first(mii_bus);
> + if (!phy_dev)
> + goto err_find_phy;
> +
>   ks->mii_bus = mii_bus;
> + ks->phy_dev = phy_dev;
>  
>   return 0;
>  
> +err_find_phy:
> + mdiobus_unregister(mii_bus);
>  err_mdiobus_register:
>   mdiobus_free(mii_bus);
>   return ret;
> 

LGTM. When having a brief look at the driver I stumbled across two things:

1. Do MAC/PHY support any pause mode? Then a call to
   phy_support_(a)sym_pause() would be missing.

2. Don't have the datasheet, but IRQ_LCI seems to be the link change
   interrupt. So far it's ignored by the driver. You could configure
   it and use phy_mac_interrupt() to operate the internal PHY in
   interrupt mode.

Re: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX

[Kirill A. Shutemov]

On Fri, Jan 08, 2021 at 03:31:56PM +, Radev, Martin wrote:
> Just noticed that Intel TDX already does the device filtering. Check: 
> https://github.com/intel/tdx/commit/6789eee52aab8985e49b362379fab73aa3eecde2
> 
> CC-ing Kirill and Kuppuswamy from Intel in case they want to be part of the 
> discussion.
> 
> From: Radev, Martin
> Sent: Friday, January 8, 2021 12:57 PM
> To: netdev@vger.kernel.org ; 
> intel-wired-...@lists.osuosl.org 
> Cc: dos...@vmware.com ; jesse.brandeb...@intel.com 
> ; anthony.l.ngu...@intel.com 
> ; Morbitzer, Mathias 
> ; Robert Buhren 
> ; f...@sect.tu-berlin.de 
> ; Banse, Christian 
> ; brijesh.si...@amd.com 
> ; thomas.lenda...@amd.com ; 
> pv-driv...@vmware.com ; martin.b.ra...@gmail.com 
> 
> Subject: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX
> 
> Hello everybody,
> 
> tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP
>  control to a malicious e100 / vmxnet3 device implementation. This is
>  an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2].
> 
> Felicitas and Robert have started a project on fuzzing device drivers which
> may have negative security impact on solutions like AMD SEV Secure
> Nested Paging and Intel Trusted Domain Extensions. These solutions protect
> a VM from a malicious Hypervisor in various way.
> 
> There are a couple of devices which carry security issues under the attacker
> models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and
> e100, because we have detailed PoCs for both.
> 
> Maintainers of both vmxnet3 and e100 were added in this email because the
> discussion will likely be the same. The issues were already sent to AMD PSIRT,
> and Tom Lendacky and Brijesh Singh have volunteered to be part of the email
> communication with the maintainers. Both have been working on AMD SEV.
> 
> Please check the two attached files: vmxnet3_report.txt and e100_report.txt.
> Both contain detailed information about what the issue is and how it can be
> exploited by a malicious HV or attacker who has access to the QEMU process.
> 
> Fix:
> In an earlier discussion with AMD, there was the idea of making a list of
> allowed devices with SEV and forbidding everything else. This would avoid
> issues with other drivers whose implementation has not been yet scrutinized
> under the threat model of SEV-SNP and Intel Trusted Domain Extensions.

+Andi.

Right. Our TDX guest enabling has white list of devices that allowed to be
used. For now it's only VirtIO, but I believe it also requires hardening.
We need to validate any VMM input.

It might be beneficial to have coordination between Intel and AMD on what
devices (and device drivers) considered to be safe for trusted computing.
I think we can share burden of code audit and fuzzing.

-- 
 Kirill A. Shutemov

[PATCH 5.10 035/145] net: sched: prevent invalid Scell_log shift count

[Greg Kroah-Hartman]

From: Randy Dunlap 

[ Upstream commit bd1248f1ddbc48b0c30565fce897a3b6423313b8 ]

Check Scell_log shift size in red_check_params() and modify all callers
of red_check_params() to pass Scell_log.

This prevents a shift out-of-bounds as detected by UBSAN:
  UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
  shift exponent 72 is too large for 32-bit type 'int'

Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
Signed-off-by: Randy Dunlap 
Reported-by: syzbot+97c5bd9cc81eca63d...@syzkaller.appspotmail.com
Cc: Nogah Frankel 
Cc: Jamal Hadi Salim 
Cc: Cong Wang 
Cc: Jiri Pirko 
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 include/net/red.h |4 +++-
 net/sched/sch_choke.c |2 +-
 net/sched/sch_gred.c  |2 +-
 net/sched/sch_red.c   |2 +-
 net/sched/sch_sfq.c   |2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

--- a/include/net/red.h
+++ b/include/net/red.h
@@ -168,12 +168,14 @@ static inline void red_set_vars(struct r
v->qcount   = -1;
 }
 
-static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog)
+static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog, u8 
Scell_log)
 {
if (fls(qth_min) + Wlog > 32)
return false;
if (fls(qth_max) + Wlog > 32)
return false;
+   if (Scell_log >= 32)
+   return false;
if (qth_max < qth_min)
return false;
return true;
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -362,7 +362,7 @@ static int choke_change(struct Qdisc *sc
 
ctl = nla_data(tb[TCA_CHOKE_PARMS]);
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > CHOKE_MAX_QUEUE)
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -480,7 +480,7 @@ static inline int gred_change_vq(struct
struct gred_sched *table = qdisc_priv(sch);
struct gred_sched_data *q = table->tab[dp];
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog)) {
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log)) {
NL_SET_ERR_MSG_MOD(extack, "invalid RED parameters");
return -EINVAL;
}
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -250,7 +250,7 @@ static int __red_change(struct Qdisc *sc
max_P = tb[TCA_RED_MAX_P] ? nla_get_u32(tb[TCA_RED_MAX_P]) : 0;
 
ctl = nla_data(tb[TCA_RED_PARMS]);
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
err = red_get_flags(ctl->flags, TC_RED_HISTORIC_FLAGS,
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -647,7 +647,7 @@ static int sfq_change(struct Qdisc *sch,
}
 
if (ctl_v1 && !red_check_params(ctl_v1->qth_min, ctl_v1->qth_max,
-   ctl_v1->Wlog))
+   ctl_v1->Wlog, ctl_v1->Scell_log))
return -EINVAL;
if (ctl_v1 && ctl_v1->qth_min) {
p = kmalloc(sizeof(*p), GFP_KERNEL);

Re: [PATCH net-next] net: ks8851: Connect and start/stop the internal PHY

[Marek Vasut]

On 1/11/21 2:26 PM, Heiner Kallweit wrote:
[...]


LGTM. When having a brief look at the driver I stumbled across two things:

1. Do MAC/PHY support any pause mode? Then a call to
phy_support_(a)sym_pause() would be missing.


https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8851-16MLL-Single-Port-Ethernet-MAC-Controller-with-8-Bit-or-16-Bit-Non-PCI-Interface-DS2357B.pdf
page 64

https://www.mouser.com/datasheet/2/268/ksz8851-16mll_ds-776208.pdf
page 65

The later is more complete.

Apparently it does support pause.


2. Don't have the datasheet, but IRQ_LCI seems to be the link change
interrupt. So far it's ignored by the driver. You could configure
it and use phy_mac_interrupt() to operate the internal PHY in
interrupt mode.


That's only for link state change, shouldn't the PHY interrupt trigger 
on other things as well ?

Re: [PATCH net-next 2/2] drivers: net: dsa: mt7530: MT7530 optional GPIO support

[DENG Qingfang]

On Mon, Jan 11, 2021 at 7:04 PM Russell King - ARM Linux admin
 wrote:
>
> FYI, Documentation/driver-api/gpio/consumer.rst says:
>
>   For output GPIOs, the value provided becomes the initial output value.
>   This helps avoid signal glitching during system startup.
>
> Setting the pin to be an output, and then setting its initial value
> does not avoid the glitch. You may wish to investigate whether you
> can set the value before setting the pin as an output to avoid this
> issue.
>

So, setting the Output Enable bit _after_ setting the direction and
initial value should avoid this issue. Right?

[PATCH 5.4 34/92] net: sched: prevent invalid Scell_log shift count

[Greg Kroah-Hartman]

From: Randy Dunlap 

[ Upstream commit bd1248f1ddbc48b0c30565fce897a3b6423313b8 ]

Check Scell_log shift size in red_check_params() and modify all callers
of red_check_params() to pass Scell_log.

This prevents a shift out-of-bounds as detected by UBSAN:
  UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
  shift exponent 72 is too large for 32-bit type 'int'

Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
Signed-off-by: Randy Dunlap 
Reported-by: syzbot+97c5bd9cc81eca63d...@syzkaller.appspotmail.com
Cc: Nogah Frankel 
Cc: Jamal Hadi Salim 
Cc: Cong Wang 
Cc: Jiri Pirko 
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 include/net/red.h |4 +++-
 net/sched/sch_choke.c |2 +-
 net/sched/sch_gred.c  |2 +-
 net/sched/sch_red.c   |2 +-
 net/sched/sch_sfq.c   |2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

--- a/include/net/red.h
+++ b/include/net/red.h
@@ -168,12 +168,14 @@ static inline void red_set_vars(struct r
v->qcount   = -1;
 }
 
-static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog)
+static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog, u8 
Scell_log)
 {
if (fls(qth_min) + Wlog > 32)
return false;
if (fls(qth_max) + Wlog > 32)
return false;
+   if (Scell_log >= 32)
+   return false;
if (qth_max < qth_min)
return false;
return true;
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -368,7 +368,7 @@ static int choke_change(struct Qdisc *sc
 
ctl = nla_data(tb[TCA_CHOKE_PARMS]);
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > CHOKE_MAX_QUEUE)
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -480,7 +480,7 @@ static inline int gred_change_vq(struct
struct gred_sched *table = qdisc_priv(sch);
struct gred_sched_data *q = table->tab[dp];
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog)) {
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log)) {
NL_SET_ERR_MSG_MOD(extack, "invalid RED parameters");
return -EINVAL;
}
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -213,7 +213,7 @@ static int red_change(struct Qdisc *sch,
max_P = tb[TCA_RED_MAX_P] ? nla_get_u32(tb[TCA_RED_MAX_P]) : 0;
 
ctl = nla_data(tb[TCA_RED_PARMS]);
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > 0) {
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -647,7 +647,7 @@ static int sfq_change(struct Qdisc *sch,
}
 
if (ctl_v1 && !red_check_params(ctl_v1->qth_min, ctl_v1->qth_max,
-   ctl_v1->Wlog))
+   ctl_v1->Wlog, ctl_v1->Scell_log))
return -EINVAL;
if (ctl_v1 && ctl_v1->qth_min) {
p = kmalloc(sizeof(*p), GFP_KERNEL);

Re: [PATCH net-next 0/2] dsa: add MT7530 GPIO support

[Vladimir Oltean]

On Mon, Jan 11, 2021 at 01:44:26PM +0800, DENG Qingfang wrote:
> MT7530's LED controller can be used as GPIO controller. Add support for
> it.
> 
> DENG Qingfang (2):
>   dt-bindings: net: dsa: add MT7530 GPIO controller binding
>   drivers: net: dsa: mt7530: MT7530 optional GPIO support
> 
>  .../devicetree/bindings/net/dsa/mt7530.txt|  6 ++
>  drivers/net/dsa/mt7530.c  | 96 +++
>  drivers/net/dsa/mt7530.h  | 20 
>  3 files changed, 122 insertions(+)
> 
> -- 
> 2.25.1

Adding GPIO and LED maintainers to also have a look.
https://patchwork.kernel.org/project/netdevbpf/cover/20210111054428.3273-1-dqf...@gmail.com/

Re: [PATCH net-next] net: ks8851: Connect and start/stop the internal PHY

[Heiner Kallweit]

On 11.01.2021 14:38, Marek Vasut wrote:
> On 1/11/21 2:26 PM, Heiner Kallweit wrote:
> [...]
> 
>> LGTM. When having a brief look at the driver I stumbled across two things:
>>
>> 1. Do MAC/PHY support any pause mode? Then a call to
>>     phy_support_(a)sym_pause() would be missing.
> 
> https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8851-16MLL-Single-Port-Ethernet-MAC-Controller-with-8-Bit-or-16-Bit-Non-PCI-Interface-DS2357B.pdf
> page 64
> 
> https://www.mouser.com/datasheet/2/268/ksz8851-16mll_ds-776208.pdf
> page 65
> 
> The later is more complete.
> 
> Apparently it does support pause.
> 
>> 2. Don't have the datasheet, but IRQ_LCI seems to be the link change
>>     interrupt. So far it's ignored by the driver. You could configure
>>     it and use phy_mac_interrupt() to operate the internal PHY in
>>     interrupt mode.
> 
> That's only for link state change, shouldn't the PHY interrupt trigger on 
> other things as well ?

No, it's sufficient if the interrupt can signal link state change.
In r8169 I have exactly that case.

[PATCH 4.19 35/77] net: sched: prevent invalid Scell_log shift count

[Greg Kroah-Hartman]

From: Randy Dunlap 

[ Upstream commit bd1248f1ddbc48b0c30565fce897a3b6423313b8 ]

Check Scell_log shift size in red_check_params() and modify all callers
of red_check_params() to pass Scell_log.

This prevents a shift out-of-bounds as detected by UBSAN:
  UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
  shift exponent 72 is too large for 32-bit type 'int'

Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
Signed-off-by: Randy Dunlap 
Reported-by: syzbot+97c5bd9cc81eca63d...@syzkaller.appspotmail.com
Cc: Nogah Frankel 
Cc: Jamal Hadi Salim 
Cc: Cong Wang 
Cc: Jiri Pirko 
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 include/net/red.h |4 +++-
 net/sched/sch_choke.c |2 +-
 net/sched/sch_gred.c  |2 +-
 net/sched/sch_red.c   |2 +-
 net/sched/sch_sfq.c   |2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

--- a/include/net/red.h
+++ b/include/net/red.h
@@ -168,12 +168,14 @@ static inline void red_set_vars(struct r
v->qcount   = -1;
 }
 
-static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog)
+static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog, u8 
Scell_log)
 {
if (fls(qth_min) + Wlog > 32)
return false;
if (fls(qth_max) + Wlog > 32)
return false;
+   if (Scell_log >= 32)
+   return false;
if (qth_max < qth_min)
return false;
return true;
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -371,7 +371,7 @@ static int choke_change(struct Qdisc *sc
 
ctl = nla_data(tb[TCA_CHOKE_PARMS]);
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > CHOKE_MAX_QUEUE)
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -357,7 +357,7 @@ static inline int gred_change_vq(struct
struct gred_sched *table = qdisc_priv(sch);
struct gred_sched_data *q = table->tab[dp];
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (!q) {
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -214,7 +214,7 @@ static int red_change(struct Qdisc *sch,
max_P = tb[TCA_RED_MAX_P] ? nla_get_u32(tb[TCA_RED_MAX_P]) : 0;
 
ctl = nla_data(tb[TCA_RED_PARMS]);
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > 0) {
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -651,7 +651,7 @@ static int sfq_change(struct Qdisc *sch,
}
 
if (ctl_v1 && !red_check_params(ctl_v1->qth_min, ctl_v1->qth_max,
-   ctl_v1->Wlog))
+   ctl_v1->Wlog, ctl_v1->Scell_log))
return -EINVAL;
if (ctl_v1 && ctl_v1->qth_min) {
p = kmalloc(sizeof(*p), GFP_KERNEL);

Re: [RFC PATCH 0/1] net: arcnet: Fix RESET sequence

[Ahmed S. Darwish]

Hi,

On Tue, Dec 22, 2020 at 10:03:37AM +0100, Ahmed S. Darwish wrote:
...
>
> Included is an RFC patch to fix the points above: if the RESET flag is
> encountered, a workqueue is scheduled to run the generic reset sequence.
>
...

Kind reminder.

Re: [PATCH net-next 2/2] drivers: net: dsa: mt7530: MT7530 optional GPIO support

[Russell King - ARM Linux admin]

On Mon, Jan 11, 2021 at 09:40:00PM +0800, DENG Qingfang wrote:
> On Mon, Jan 11, 2021 at 7:04 PM Russell King - ARM Linux admin
>  wrote:
> >
> > FYI, Documentation/driver-api/gpio/consumer.rst says:
> >
> >   For output GPIOs, the value provided becomes the initial output value.
> >   This helps avoid signal glitching during system startup.
> >
> > Setting the pin to be an output, and then setting its initial value
> > does not avoid the glitch. You may wish to investigate whether you
> > can set the value before setting the pin as an output to avoid this
> > issue.
> >
> 
> So, setting the Output Enable bit _after_ setting the direction and
> initial value should avoid this issue. Right?

It depends on the hardware. I don't know how your hardware works, so
I can't say whether doing anything will result in correct behaviour,
or even work.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

RE: [PATCH net-next repost v2 1/7] ethtool: Extend link modes settings uAPI with lanes

[Danielle Ratson]

> -Original Message-
> From: Jakub Kicinski 
> Sent: Friday, January 8, 2021 2:35 AM
> To: Danielle Ratson 
> Cc: netdev@vger.kernel.org; da...@davemloft.net; Jiri Pirko 
> ; and...@lunn.ch; f.faine...@gmail.com;
> mkube...@suse.cz; mlxsw ; Ido Schimmel ; 
> Danielle Ratson 
> Subject: Re: [PATCH net-next repost v2 1/7] ethtool: Extend link modes 
> settings uAPI with lanes
> 
> On Wed,  6 Jan 2021 15:06:16 +0200 Danielle Ratson wrote:
> > From: Danielle Ratson 
> >
> > Currently, when auto negotiation is on, the user can advertise all the
> > linkmodes which correspond to a specific speed, but does not have a
> > similar selector for the number of lanes. This is significant when a
> > specific speed can be achieved using different number of lanes.  For
> > example, 2x50 or 4x25.
> >
> > Add 'ETHTOOL_A_LINKMODES_LANES' attribute and expand 'struct
> > ethtool_link_settings' with lanes field in order to implement a new
> > lanes-selector that will enable the user to advertise a specific
> > number of lanes as well.
> >
> > When auto negotiation is off, lanes parameter can be forced only if
> > the driver supports it. Add a capability bit in 'struct ethtool_ops'
> > that allows ethtool know if the driver can handle the lanes parameter
> > when auto negotiation is off, so if it does not, an error message will
> > be returned when trying to set lanes.
> 
> > @@ -420,6 +423,7 @@ struct ethtool_pause_stats {
> >   * of the generic netdev features interface.
> >   */
> >  struct ethtool_ops {
> > +   u32 capabilities;
> 
> An appropriately named bitfield seems better. Alternatively maybe let the 
> driver specify which lane counts it can accept?

Not sure what did you mean, can you please explain?
Thanks!

> 
> And please remember to add the kdoc.
> 
> > u32 supported_coalesce_params;
> > void(*get_drvinfo)(struct net_device *, struct ethtool_drvinfo *);
> > int (*get_regs_len)(struct net_device *);
> 
> > @@ -274,16 +277,17 @@ const struct nla_policy ethnl_linkmodes_set_policy[] 
> > = {
> > [ETHTOOL_A_LINKMODES_SPEED] = { .type = NLA_U32 },
> > [ETHTOOL_A_LINKMODES_DUPLEX]= { .type = NLA_U8 },
> > [ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFG]  = { .type = NLA_U8 },
> > +   [ETHTOOL_A_LINKMODES_LANES] = { .type = NLA_U32 },
> 
> Please set the min and max for the policy, so userspace can at least see that 
> part.
> 
> > +static bool ethnl_validate_lanes_cfg(u32 cfg) {
> > +   switch (cfg) {
> > +   case 1:
> > +   case 2:
> > +   case 4:
> > +   case 8:
> > +   return true;
> 
> And with the policy checking min and max this can be turned into a simple 
> is_power_of_2() call.
> 
> > +   }
> > +
> > +   return false;
> > +}

Re: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX

[Robert Buhren]

On 1/11/21 2:26 PM, Kirill A. Shutemov wrote:
> On Fri, Jan 08, 2021 at 03:31:56PM +, Radev, Martin wrote:
>> Just noticed that Intel TDX already does the device filtering. Check: 
>> https://github.com/intel/tdx/commit/6789eee52aab8985e49b362379fab73aa3eecde2
>>
>> CC-ing Kirill and Kuppuswamy from Intel in case they want to be part of the 
>> discussion.
>> 
>> From: Radev, Martin
>> Sent: Friday, January 8, 2021 12:57 PM
>> To: netdev@vger.kernel.org ; 
>> intel-wired-...@lists.osuosl.org 
>> Cc: dos...@vmware.com ; jesse.brandeb...@intel.com 
>> ; anthony.l.ngu...@intel.com 
>> ; Morbitzer, Mathias 
>> ; Robert Buhren 
>> ; f...@sect.tu-berlin.de 
>> ; Banse, Christian 
>> ; brijesh.si...@amd.com 
>> ; thomas.lenda...@amd.com ; 
>> pv-driv...@vmware.com ; martin.b.ra...@gmail.com 
>> 
>> Subject: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX
>>
>> Hello everybody,
>>
>> tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP
>>  control to a malicious e100 / vmxnet3 device implementation. This is
>>  an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2].
>>
>> Felicitas and Robert have started a project on fuzzing device drivers which
>> may have negative security impact on solutions like AMD SEV Secure
>> Nested Paging and Intel Trusted Domain Extensions. These solutions protect
>> a VM from a malicious Hypervisor in various way.
>>
>> There are a couple of devices which carry security issues under the attacker
>> models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and
>> e100, because we have detailed PoCs for both.
>>
>> Maintainers of both vmxnet3 and e100 were added in this email because the
>> discussion will likely be the same. The issues were already sent to AMD 
>> PSIRT,
>> and Tom Lendacky and Brijesh Singh have volunteered to be part of the email
>> communication with the maintainers. Both have been working on AMD SEV.
>>
>> Please check the two attached files: vmxnet3_report.txt and e100_report.txt.
>> Both contain detailed information about what the issue is and how it can be
>> exploited by a malicious HV or attacker who has access to the QEMU process.
>>
>> Fix:
>> In an earlier discussion with AMD, there was the idea of making a list of
>> allowed devices with SEV and forbidding everything else. This would avoid
>> issues with other drivers whose implementation has not been yet scrutinized
>> under the threat model of SEV-SNP and Intel Trusted Domain Extensions.
> +Andi.
>
> Right. Our TDX guest enabling has white list of devices that allowed to be
> used. For now it's only VirtIO, but I believe it also requires hardening.
> We need to validate any VMM input.
>
> It might be beneficial to have coordination between Intel and AMD on what
> devices (and device drivers) considered to be safe for trusted computing.
> I think we can share burden of code audit and fuzzing.
Let us know if you are interested in our fuzzing/static analysis setup.
We're planning to submit a paper soon and we will publish the source
code along with the paper.

-- 
Robert Buhren 
Security in Telecommunications 
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 16 / D - 10587 Berlin, Germany
phone: +49 30 835358325

[PATCH 4.9 15/45] net: sched: prevent invalid Scell_log shift count

[Greg Kroah-Hartman]

From: Randy Dunlap 

[ Upstream commit bd1248f1ddbc48b0c30565fce897a3b6423313b8 ]

Check Scell_log shift size in red_check_params() and modify all callers
of red_check_params() to pass Scell_log.

This prevents a shift out-of-bounds as detected by UBSAN:
  UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
  shift exponent 72 is too large for 32-bit type 'int'

Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
Signed-off-by: Randy Dunlap 
Reported-by: syzbot+97c5bd9cc81eca63d...@syzkaller.appspotmail.com
Cc: Nogah Frankel 
Cc: Jamal Hadi Salim 
Cc: Cong Wang 
Cc: Jiri Pirko 
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 include/net/red.h |4 +++-
 net/sched/sch_choke.c |2 +-
 net/sched/sch_gred.c  |2 +-
 net/sched/sch_red.c   |2 +-
 net/sched/sch_sfq.c   |2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

--- a/include/net/red.h
+++ b/include/net/red.h
@@ -167,12 +167,14 @@ static inline void red_set_vars(struct r
v->qcount   = -1;
 }
 
-static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog)
+static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog, u8 
Scell_log)
 {
if (fls(qth_min) + Wlog > 32)
return false;
if (fls(qth_max) + Wlog > 32)
return false;
+   if (Scell_log >= 32)
+   return false;
if (qth_max < qth_min)
return false;
return true;
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -425,7 +425,7 @@ static int choke_change(struct Qdisc *sc
 
ctl = nla_data(tb[TCA_CHOKE_PARMS]);
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > CHOKE_MAX_QUEUE)
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -356,7 +356,7 @@ static inline int gred_change_vq(struct
struct gred_sched *table = qdisc_priv(sch);
struct gred_sched_data *q = table->tab[dp];
 
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (!q) {
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -184,7 +184,7 @@ static int red_change(struct Qdisc *sch,
max_P = tb[TCA_RED_MAX_P] ? nla_get_u32(tb[TCA_RED_MAX_P]) : 0;
 
ctl = nla_data(tb[TCA_RED_PARMS]);
-   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+   if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog, 
ctl->Scell_log))
return -EINVAL;
 
if (ctl->limit > 0) {
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -645,7 +645,7 @@ static int sfq_change(struct Qdisc *sch,
}
 
if (ctl_v1 && !red_check_params(ctl_v1->qth_min, ctl_v1->qth_max,
-   ctl_v1->Wlog))
+   ctl_v1->Wlog, ctl_v1->Scell_log))
return -EINVAL;
if (ctl_v1 && ctl_v1->qth_min) {
p = kmalloc(sizeof(*p), GFP_KERNEL);

Re: [PATCH net] net: ipa: modem: add missing SET_NETDEV_DEV() for proper sysfs links

[Alex Elder]

On 1/7/21 8:46 PM, Jakub Kicinski wrote:

On Wed,  6 Jan 2021 11:07:55 +0100 Stephan Gerhold wrote:

At the moment it is quite hard to identify the network interface
provided by IPA in userspace components: The network interface is
created as virtual device, without any link to the IPA device.
The interface name ("rmnet_ipa%d") is the only indication that the
network interface belongs to IPA, but this is not very reliable.

Add SET_NETDEV_DEV() to associate the network interface with the
IPA parent device. This allows userspace services like ModemManager
to properly identify that this network interface is provided by IPA
and belongs to the modem.

Cc: Alex Elder 
Fixes: a646d6ec9098 ("soc: qcom: ipa: modem and microcontroller")
Signed-off-by: Stephan Gerhold 


Alex, can we get an ack?


Too late, but this looks good.  Thank you for applying it.
I don't always spot messages not "To:" me.  I still need to
improve my mail filtering.  Sorry about that.

-Alex

Re: [PATCH net-next] net: ks8851: Connect and start/stop the internal PHY

[Marek Vasut]

On 1/11/21 2:50 PM, Heiner Kallweit wrote:

On 11.01.2021 14:38, Marek Vasut wrote:

On 1/11/21 2:26 PM, Heiner Kallweit wrote:
[...]


LGTM. When having a brief look at the driver I stumbled across two things:

1. Do MAC/PHY support any pause mode? Then a call to
     phy_support_(a)sym_pause() would be missing.


https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8851-16MLL-Single-Port-Ethernet-MAC-Controller-with-8-Bit-or-16-Bit-Non-PCI-Interface-DS2357B.pdf
page 64

https://www.mouser.com/datasheet/2/268/ksz8851-16mll_ds-776208.pdf
page 65

The later is more complete.

Apparently it does support pause.


Based on the datasheet, does it support sym or asym pause ?


2. Don't have the datasheet, but IRQ_LCI seems to be the link change
     interrupt. So far it's ignored by the driver. You could configure
     it and use phy_mac_interrupt() to operate the internal PHY in
     interrupt mode.


That's only for link state change, shouldn't the PHY interrupt trigger on other 
things as well ?


No, it's sufficient if the interrupt can signal link state change.
In r8169 I have exactly that case.


I'll do that in a subsequent patch, once I verify it works as it should.

Re: [PATCH] net: phy: smsc: fix clk error handling

[Andrew Lunn]

On Mon, Jan 11, 2021 at 09:59:32AM +0100, Marco Felsch wrote:
> Commit bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in
> support") added the phy clk support. The commit already checks if
> clk_get_optional() throw an error but instead of returning the error it
> ignores it.
> 
> Fixes: bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in support")
> Suggested-by: Jakub Kicinski 
> Signed-off-by: Marco Felsch 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH v1 0/2] Add 100 base-x mode

[Russell King - ARM Linux admin]

On Mon, Jan 11, 2021 at 02:06:55PM +0100, Bjarni Jonasson wrote:
> Adding support for 100 base-x in phylink.
> The Sparx5 switch supports 100 base-x pcs (IEEE 802.3 Clause 24) 4b5b encoded.
> These patches adds phylink support for that mode.
> 
> Tested in Sparx5, using sfp modules:
> Axcen 100fx AXFE-1314-0521 
> Cisco GLC-FE-100LX
> HP SFP 100FX J9054C
> Excom SFP-SX-M1002

For each of these modules, please send me:

ethtool -m ethx raw on > module.bin

so I can validate future changes with these modules. Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v1 1/2] net: phy: Add 100 base-x mode

[Russell King - ARM Linux admin]

On Mon, Jan 11, 2021 at 02:06:56PM +0100, Bjarni Jonasson wrote:
> Sparx-5 supports this mode and it is missing in the PHY core.
> 
> Signed-off-by: Bjarni Jonasson 

Looks good, thanks.

Reviewed-by: Russell King 

> ---
>  include/linux/phy.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 56563e5e0dc7..dce867222d58 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -111,6 +111,7 @@ extern const int phy_10gbit_features_array[1];
>   * @PHY_INTERFACE_MODE_10GBASER: 10G BaseR
>   * @PHY_INTERFACE_MODE_USXGMII:  Universal Serial 10GE MII
>   * @PHY_INTERFACE_MODE_10GKR: 10GBASE-KR - with Clause 73 AN
> + * @PHY_INTERFACE_MODE_100BASEX: 100 BaseX
>   * @PHY_INTERFACE_MODE_MAX: Book keeping
>   *
>   * Describes the interface between the MAC and PHY.
> @@ -144,6 +145,7 @@ typedef enum {
>   PHY_INTERFACE_MODE_USXGMII,
>   /* 10GBASE-KR - with Clause 73 AN */
>   PHY_INTERFACE_MODE_10GKR,
> + PHY_INTERFACE_MODE_100BASEX,
>   PHY_INTERFACE_MODE_MAX,
>  } phy_interface_t;
>  
> @@ -217,6 +219,8 @@ static inline const char *phy_modes(phy_interface_t 
> interface)
>   return "usxgmii";
>   case PHY_INTERFACE_MODE_10GKR:
>   return "10gbase-kr";
> + case PHY_INTERFACE_MODE_100BASEX:
> + return "100base-x";
>   default:
>   return "unknown";
>   }
> -- 
> 2.17.1
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v1 2/2] sfp: add support for 100 base-x SFPs

[Russell King - ARM Linux admin]

On Mon, Jan 11, 2021 at 02:06:57PM +0100, Bjarni Jonasson wrote:
> Add support for 100Base-FX, 100Base-LX, 100Base-PX and 100Base-BX10 modules
> This is needed for Sparx-5 switch.
> 
> Signed-off-by: Bjarni Jonasson 
> ---
>  drivers/net/phy/sfp-bus.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
> index 58014feedf6c..b2a9ee3dd28e 100644
> --- a/drivers/net/phy/sfp-bus.c
> +++ b/drivers/net/phy/sfp-bus.c
> @@ -265,6 +265,12 @@ void sfp_parse_support(struct sfp_bus *bus, const struct 
> sfp_eeprom_id *id,
>   br_min <= 1300 && br_max >= 1200)
>   phylink_set(modes, 1000baseX_Full);
>  
> + /* 100Base-FX, 100Base-LX, 100Base-PX, 100Base-BX10 */
> + if (id->base.e100_base_fx || id->base.e100_base_lx)
> + phylink_set(modes, 100baseFX_Full);
> + if ((id->base.e_base_px || id->base.e_base_bx10) && br_nom == 100)
> + phylink_set(modes, 100baseFX_Full);

Do you have any modules that identify as PX or BX10 modules? What if
their range of speeds covers 100M - you're only checking the nominal
speed here.

Note that this will likely conflict with changes I submitted over the
weekend, and it really needs to be done _before_ the comment about
"If we haven't discovered any modes", not below.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v1 1/2] net: phy: Add 100 base-x mode

[Andrew Lunn]

On Mon, Jan 11, 2021 at 02:06:56PM +0100, Bjarni Jonasson wrote:
> Sparx-5 supports this mode and it is missing in the PHY core.
> 
> Signed-off-by: Bjarni Jonasson 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH v4 net-next 1/2] ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls

[Guillaume Nault]

On Mon, Jan 11, 2021 at 02:17:13PM +0100, Simon Chopin wrote:
> Hello,
> 
> Le 10/12/2020 à 16:50, Tom Parkin a écrit :
> > This new ioctl pair allows two ppp channels to be bridged together:
> > frames arriving in one channel are transmitted in the other channel
> > and vice versa.
> > 
> > The practical use for this is primarily to support the L2TP Access
> > Concentrator use-case.  The end-user session is presented as a ppp
> > channel (typically PPPoE, although it could be e.g. PPPoA, or even PPP
> > over a serial link) and is switched into a PPPoL2TP session for
> > transmission to the LNS.  At the LNS the PPP session is terminated in
> > the ISP's network.
> > 
> > When a PPP channel is bridged to another it takes a reference on the
> > other's struct ppp_file.  This reference is dropped when the channels
> > are unbridged, which can occur either explicitly on userspace calling
> > the PPPIOCUNBRIDGECHAN ioctl, or implicitly when either channel in the
> > bridge is unregistered.
> > 
> > In order to implement the channel bridge, struct channel is extended
> > with a new field, 'bridge', which points to the other struct channel
> > making up the bridge.
> > 
> > This pointer is RCU protected to avoid adding another lock to the data
> > path.
> > 
> > To guard against concurrent writes to the pointer, the existing struct
> > channel lock 'upl' coverage is extended rather than adding a new lock.
> > 
> > The 'upl' lock is used to protect the existing unit pointer.  Since the
> > bridge effectively replaces the unit (they're mutually exclusive for a
> > channel) it makes coding easier to use the same lock to cover them
> > both.
> > 
> > Signed-off-by: Tom Parkin 
> > ---
> >  drivers/net/ppp/ppp_generic.c  | 152 -
> >  include/uapi/linux/ppp-ioctl.h |   2 +
> >  2 files changed, 151 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> > index 7d005896a0f9..09c27f7773f9 100644
> > --- a/drivers/net/ppp/ppp_generic.c
> > +++ b/drivers/net/ppp/ppp_generic.c
> > @@ -174,7 +174,8 @@ struct channel {
> > struct ppp  *ppp;   /* ppp unit we're connected to */
> > struct net  *chan_net;  /* the net channel belongs to */
> > struct list_head clist; /* link in list of channels per unit */
> > -   rwlock_tupl;/* protects `ppp' */
> > +   rwlock_tupl;/* protects `ppp' and 'bridge' */
> > +   struct channel __rcu *bridge;   /* "bridged" ppp channel */
> >  #ifdef CONFIG_PPP_MULTILINK
> > u8  avail;  /* flag used in multilink stuff */
> > u8  had_frag;   /* >= 1 fragments have been sent */
> > @@ -606,6 +607,83 @@ static struct bpf_prog *compat_ppp_get_filter(struct 
> > sock_fprog32 __user *p)
> >  #endif
> >  #endif
> >  
> > +/* Bridge one PPP channel to another.
> > + * When two channels are bridged, ppp_input on one channel is redirected to
> > + * the other's ops->start_xmit handler.
> > + * In order to safely bridge channels we must reject channels which are 
> > already
> > + * part of a bridge instance, or which form part of an existing unit.
> > + * Once successfully bridged, each channel holds a reference on the other
> > + * to prevent it being freed while the bridge is extant.
> > + */
> > +static int ppp_bridge_channels(struct channel *pch, struct channel *pchb)
> > +{
> > +   write_lock_bh(&pch->upl);
> > +   if (pch->ppp ||
> > +   rcu_dereference_protected(pch->bridge, lockdep_is_held(&pch->upl))) 
> > {
> > +   write_unlock_bh(&pch->upl);
> > +   return -EALREADY;
> > +   }
> > +   rcu_assign_pointer(pch->bridge, pchb);
> > +   write_unlock_bh(&pch->upl);
> > +
> This is mostly for my own education:
> 
> I might be misunderstanding something, but is there anything
> that would prevent a packet from being forwarded from pch to pchb at this
> precise moment? If not, then it might be theoretically possible to have
> any answer to said packet (say, a LCP ACK) to be received before the 
> pchb->bridge is set?

That's possible in theory. But I can't see any problem in practice,
because:

  * It's unlikely the round trip time would be small enough to trigger
this situation.

  * If this situation ever happens, the reply is passed to user space,
which is free to forward it to the other channel. If the user
space implementation isn't prepared for this situation and just
drops the packet, that's fine too. It's just a transient packet
drop, which PPP peers are supposed to handle just fine (this can
happen anywhere in the network after all).

  * Any use case I know for channel bridging involves a "live" channel
(where LCP and authentication protocols are running) and an "idle"
channel (where no protocol is running at all yet). So the problem
can be avoided entirely by calling the PPPIOCBRIDGECHAN ioctl on
the idle channel file descriptor

Re: [PATCH net-next] net: ks8851: Connect and start/stop the internal PHY

[Heiner Kallweit]

On 11.01.2021 15:10, Marek Vasut wrote:
> On 1/11/21 2:50 PM, Heiner Kallweit wrote:
>> On 11.01.2021 14:38, Marek Vasut wrote:
>>> On 1/11/21 2:26 PM, Heiner Kallweit wrote:
>>> [...]
>>>
 LGTM. When having a brief look at the driver I stumbled across two things:

 1. Do MAC/PHY support any pause mode? Then a call to
  phy_support_(a)sym_pause() would be missing.
>>>
>>> https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8851-16MLL-Single-Port-Ethernet-MAC-Controller-with-8-Bit-or-16-Bit-Non-PCI-Interface-DS2357B.pdf
>>> page 64
>>>
>>> https://www.mouser.com/datasheet/2/268/ksz8851-16mll_ds-776208.pdf
>>> page 65
>>>
>>> The later is more complete.
>>>
>>> Apparently it does support pause.
> 
> Based on the datasheet, does it support sym or asym pause ?
> 

According to the description of flow control on p.23 it can support asym pause.
However on the MAC side flow control doesn't seem to be always active, it's
controlled by these two bits:

p.49, TXCR, bit 3
p.50, RXCR1, bit 10

Default seems to be that flow control is disabled.

 2. Don't have the datasheet, but IRQ_LCI seems to be the link change
  interrupt. So far it's ignored by the driver. You could configure
  it and use phy_mac_interrupt() to operate the internal PHY in
  interrupt mode.
>>>
>>> That's only for link state change, shouldn't the PHY interrupt trigger on 
>>> other things as well ?
>>
>> No, it's sufficient if the interrupt can signal link state change.
>> In r8169 I have exactly that case.
> 
> I'll do that in a subsequent patch, once I verify it works as it should.

Re: [PATCH net-next] net: ks8851: Connect and start/stop the internal PHY

[Andrew Lunn]

On Mon, Jan 11, 2021 at 01:53:37PM +0100, Marek Vasut wrote:
> Unless the internal PHY is connected and started, the phylib will not
> poll the PHY for state and produce state updates. Connect the PHY and
> start/stop it.

Hi Marek

Please continue the conversion and remove all mii_calls.

ks8851_set_link_ksettings() calling mii_ethtool_set_link_ksettings()
is not good, phylib will not know about changes which we made to the
PHY etc.

Andrew

Re: [PATCH net-next] net: ks8851: Select PHYLIB and MICREL_PHY in Kconfig

[Andrew Lunn]

On Mon, Jan 11, 2021 at 01:50:46PM +0100, Marek Vasut wrote:
> The PHYLIB must be selected to provide mdiobus_*() functions, and the
> MICREL_PHY is necessary too, as that is the only possible PHY attached
> to the KS8851 (it is the internal PHY).
> 
> Fixes: ef3631220d2b ("net: ks8851: Register MDIO bus and the internal PHY")
> Signed-off-by: Marek Vasut 
> Cc: Andrew Lunn 
> Cc: Heiner Kallweit 
> Cc: Lukas Wunner 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH v3 1/2] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips

[Marek Behún]

Hi Pali,
I have rewritten the commit message a little:

The workaround for VSOL V2801F brand based GPON SFP modules added in
commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490
v2.0 workaround") works only for IDs added explicitly to the list.
Since there are rebranded modules where OEM vendors put different
strings into the vendor name field, we cannot base workaround on IDs
only.

Moreover the issue which the above mentioned commit tried to work
around is generic not only to VSOL based modules, but rather to all
GPON modules based on Realtek RTL8672 and RTL9601C chips.
 
These include at least the following GPON modules:
* V-SOL V2801F
* C-Data FD511GX-RM0
* OPTON GP801R
* BAUDCOM BD-1234-SFM
* CPGOS03-0490 v2.0
* Ubiquiti U-Fiber Instant
* EXOT EGS1

These Realtek chips have broken EEPROM emulator which for N-byte read
operation returns just the first byte of EEPROM data, followed by N-1 zeros.

Introduce a new function, sfp_id_needs_byte_io(), which detects SFP
modules with broken EEPROM emulator based on N-1 zeros and switch to 1
byte EEPROM reading operation.

Function sfp_i2c_read() now always uses single byte reading when it is
required and when function sfp_hwmon_probe() detects single byte access,
it disables registration of hwmon device, because in this case we
cannot reliably and atomically read 2 bytes as is required byt the
standard for retrieving values from diagnostic area.

(These Realtek chips are broken in a way that violates SFP standards for
 diagnostic interface. Kernel in this case simply cannot do anything
 less of skipping registration of the hwmon interface.)

This patch fixes reading of EEPROM content from SFP modules based on
Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays
broken and cannot be fixed.

KMSAN: uninit-value in __nla_validate_parse (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_..
git tree:   https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=153a38f750
kernel config:  https://syzkaller.appspot.com/x/.config?x=2cdf4151c9653e32
dashboard link: https://syzkaller.appspot.com/bug?extid=2624e3778b18fc497c92
compiler:   clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=17ef8c3f50
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12bee8f750

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2624e3778b18fc497...@syzkaller.appspotmail.com

netlink: 4 bytes leftover after parsing attributes in process `syz-executor224'.
=
BUG: KMSAN: uninit-value in nla_ok include/net/netlink.h:1159 [inline]
BUG: KMSAN: uninit-value in __nla_validate_parse+0x5fd/0x4e00 lib/nlattr.c:576
CPU: 0 PID: 8270 Comm: syz-executor224 Not tainted 5.10.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x21c/0x280 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197
 nla_ok include/net/netlink.h:1159 [inline]
 __nla_validate_parse+0x5fd/0x4e00 lib/nlattr.c:576
 __nla_parse+0x141/0x150 lib/nlattr.c:685
 nla_parse_nested include/net/netlink.h:1212 [inline]
 fl_set_erspan_opt+0x39a/0xe60 net/sched/cls_flower.c:1206
 fl_set_enc_opt net/sched/cls_flower.c:1365 [inline]
 fl_set_key+0x810d/0xbb60 net/sched/cls_flower.c:1642
 fl_set_parms net/sched/cls_flower.c:1880 [inline]
 fl_change+0x1226/0x7ae0 net/sched/cls_flower.c:1979
 tc_new_tfilter+0x37c1/0x58e0 net/sched/cls_api.c:2129
 rtnetlink_rcv_msg+0xe94/0x18b0 net/core/rtnetlink.c:5553
 netlink_rcv_skb+0x70a/0x820 net/netlink/af_netlink.c:2494
 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5580
 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
 netlink_unicast+0x11da/0x14b0 net/netlink/af_netlink.c:1330
 netlink_sendmsg+0x173c/0x1840 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg net/socket.c:671 [inline]
 sys_sendmsg+0xc7a/0x1240 net/socket.c:2353
 ___sys_sendmsg net/socket.c:2407 [inline]
 __sys_sendmmsg+0xa56/0x1060 net/socket.c:2497
 __do_sys_sendmmsg net/socket.c:2526 [inline]
 __se_sys_sendmmsg+0xbd/0xe0 net/socket.c:2523
 __x64_sys_sendmmsg+0x56/0x70 net/socket.c:2523
 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441739
Code: e8 5c ad 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
bb 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffca52cefc8 EFLAGS: 0246 ORIG_RAX: 0133
RAX: ffda RBX: 0003 RCX: 00441739
RDX: 010efe10675dec16 RSI: 2200 RDI: 0003
RBP: 7ffca52cefd0 R08: 000120080522 R09: 000120080522
R10:  R11: 0246 R12: 004a2a70
R13: 00402610 R14:  R15: 

Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline]
 kmsan_internal_poison_shadow+0x5c/0xf0 mm/kmsan/kmsan.c:104
 kmsan_slab_alloc+0x8d/0xe0 mm/kmsan/kmsan_hooks.c:76
 slab_alloc_node mm/slub.c:2906 [inline]
 __kmalloc_node_track_caller+0xc61/0x15f0 mm/slub.c:4512
 __kmalloc_reserve net/core/skbuff.c:142 [inline]
 __alloc_skb+0x309/0xae0 net/core/skbuff.c:210
 alloc_skb include/linux/skbuff.h:1094 [inline]
 netlink_alloc_large_skb net/netlink/af_netlink.c:1176 [inline]
 netlink_sendmsg+0xdb8/0x1840 net/netlink/af_netlink.c:1894
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg net/socket.c:671 [inline]
 sys_sendmsg+0xc7a/0x1240 net/socket.c:2353
 ___sys_sendmsg net/socket.c:2407 [inline]
 __sys_sendmmsg+0xa56/0x1060 net/socket.c:2497
 __do_sys_sendmmsg net/socket.c:2526 [inline]
 __se_sys_sendmmsg+0xbd/0xe0 net/socket.c:2523
 __x64_sys_sendmmsg+0x56/0x70 net/socket.c:2523
 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
=


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCH iproute2] tc: flower: fix json output with mpls lse

[David Ahern]

On 1/11/21 3:57 AM, Guillaume Nault wrote:
> Okay, but, in the end, should I repost this patch?

I think your patches are covered, but you should check the repo to make
sure.

[PATCH] Signed-off-by: giladreti

[giladreti]

Added support for pointer to mem register spilling, to allow the verifier
to track pointer to valid memory addresses. Such pointers are returned
for example by a successful call of the bpf_ringbuf_reserve helper.

This patch was suggested as a solution by Yonghong Song.
---
 kernel/bpf/verifier.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 17270b8404f1..36af69fac591 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2217,6 +2217,8 @@ static bool is_spillable_regtype(enum bpf_reg_type type)
case PTR_TO_RDWR_BUF:
case PTR_TO_RDWR_BUF_OR_NULL:
case PTR_TO_PERCPU_BTF_ID:
+   case PTR_TO_MEM:
+   case PTR_TO_MEM_OR_NULL:
return true;
default:
return false;
-- 
2.27.0

Re: [PATCH v3 2/2] net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant

[Marek Behún]

On Mon, 11 Jan 2021 12:39:09 +0100
Pali Rohár  wrote:

> SFP GPON module Ubiquiti U-Fiber Instant has in its EEPROM stored nonsense
> information. It claims that support all transceiver types including 10G
> Ethernet which is not truth. So clear all claimed modes and set only one
> mode which module supports: 1000baseX_Full.

The Ubiquiti U-Fiber Instant SFP GPON module has nonsensical
information stored in int EEPROM. It claims to support all transceiver
types including 10G Ethernet. Clear all claimed modes and set only
1000baseX_Full, which is the only one supported.

> Also this module have set SFF phys_id in its EEPROM. Kernel SFP subsustem
> currently does not allow to use SFP modules detected as SFF. Therefore add
> and exception for this module so it can be detected as supported.

This module has also phys_id set to SFF, and the SFP subsystem
currently does not allow to use SFP modules detected as SFFs. Add
exception for this module so it can be detected as supported.

> This change finally allows to detect and use SFP GPON module Ubiquiti
> U-Fiber Instant on Linux system.
>
> Original EEPROM content is as follows (where XX is serial number):
> 
> 00: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8?????.??
> 10: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20UBNT
> 20: 20 20 20 20 00 18 e8 29 55 46 2d 49 4e 53 54 41.??)UF-INSTA
> 30: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 36NT  4   ??.6
> 40: 00 06 00 00 55 42 4e 54 XX XX XX XX XX XX XX XX.?..UBNT
> 50: 20 20 20 20 31 34 30 31 32 33 20 20 60 80 02 41140123  `??A

Re: [net-next 15/19] can: tcan4x5x: rework SPI access

[Ahmad Fatoum]

Hello Jakub,

On 08.01.21 17:32, Jakub Kicinski wrote:
> On Fri, 8 Jan 2021 11:07:26 +0100 Ahmad Fatoum wrote:
> +struct __packed tcan4x5x_map_buf { 
> + struct tcan4x5x_buf_cmd cmd; 
> + u8 data[256 * sizeof(u32)]; 
> +} cacheline_aligned; 

 Due to the packing of the struct tcan4x5x_buf_cmd it should have a length 
 of 4
 bytes. Without __packed, will the "u8 data" come directly after the cmd?  
>>>
>>> Yup, u8 with no alignment attribute will follow the previous
>>> field with no holes.  
>>
>> __packed has a documentation benefit though. It documents that the author
>> considers the current layout to be the only correct one. (and thus extra
>> care should be taken when modifying it).
> 
> cacheline_aligned adds a big architecture dependent padding at the
> end of this struct, so the size of this structure is architecture
> dependent. Besides using packed forced the compiler to use byte by byte
> loads on architectures without unaligned access, so __packed is not
> free.

https://godbolt.org/z/j68x8n

seems to indicate that explicit alignment "overrules" packed's implicit
alignment of 1 as
 there isn't any byte-by-byte access generated for a struct
that is both packed and cacheline aligned. packed only structs are accessed
byte-by-byte however.

Did I get something wrong in my testcase?

I compiled with ARM gcc 8.2  -mno-unaligned-access -fno-strict-aliasing -O2

Cheers,
Ahmad
 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |