Re: [PATCH net 2/2] docs: networking: packet_mmap: don't mention PACKET_MMAP
Hi Willem,
On Thu, Dec 17 2020, Willem de Bruijn wrote:
> On Thu, Dec 17, 2020 at 2:48 PM Jakub Kicinski wrote:
>>
>> On Tue, 15 Dec 2020 18:51:17 +0200 Baruch Siach wrote:
>> > Before commit 889b8f964f2f ("packet: Kill CONFIG_PACKET_MMAP.") there
>> > used to be a CONFIG_PACKET_MMAP config symbol that depended on
>> > CONFIG_PACKET. The text still refers to PACKET_MMAP as the name of this
>> > feature, implying that it can be disabled. Another naming variant is
>> > "Packet MMAP".
>> >
>> > Use "PACKET mmap()" everywhere to unify the terminology. Rephrase the
>> > text the implied mmap() feature disable option.
>>
>> Should we maybe say AF_PACKET mmap() ?
>
> I don't think that the feature name PACKET_MMAP implies
> CONFIG_PACKET_MMAP, or thus that the name is obsolete now that the
> latter is.
Current text says "if PACKET_MMAP is not enabled ...". This clearly
implies a CONFIG_ symbol. Besides, the PACKET_MMAP term is mentioned
nowhere else in the source tree. At the very least we need to clarify
what it means.
> If it needs a rename, the setsockopt is PACKET_[RT]X_RING. So, if this
> needs updating, perhaps PACKET_RING would be suitable. Or TPACKET,
> based on the version definitions.
So how would you rephrase text like "PACKET_MMAP provides a size
configurable circular buffer ..."?
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH net v2 1/3] ethernet: ucc_geth: set dev->max_mtu to 1518
On Fri, Dec 18, 2020 at 11:55:36AM +0100, Rasmus Villemoes wrote:
> All the buffers and registers are already set up appropriately for an
> MTU slightly above 1500, so we just need to expose this to the
> networking stack. AFAICT, there's no need to implement .ndo_change_mtu
> when the receive buffers are always set up to support the max_mtu.
>
> This fixes several warnings during boot on our mpc8309-board with an
> embedded mv88e6250 switch:
>
> mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
> ...
> mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
> ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA
> overhead
>
> The last line explains what the DSA stack tries to do: achieving an MTU
> of 1500 on-the-wire requires that the master netdevice connected to
> the CPU port supports an MTU of 1500+the tagging overhead.
>
> Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
> Cc: Vladimir Oltean
> Reviewed-by: Andrew Lunn
> Signed-off-by: Rasmus Villemoes
> ---
Reviewed-by: Vladimir Oltean
Re: [PATCH v4 bpf-next 0/2] introduce xdp_init_buff/xdp_prepare_buff
Lorenzo Bianconi writes: Introduce xdp_init_buff and xdp_prepare_buff utility routines to initialize xdp_buff data structure and remove duplicated code in all XDP capable drivers. Changes since v3: - use __always_inline instead of inline for xdp_init_buff/xdp_prepare_buff - add 'const bool meta_valid' to xdp_prepare_buff signature to avoid overwriting data_meta with xdp_set_data_meta_invalid() - introduce removed comment in bnxt driver Changes since v2: - precompute xdp->data as hard_start + headroom and save it in a local variable to reuse it for xdp->data_end and xdp->data_meta in xdp_prepare_buff() Changes since v1: - introduce xdp_prepare_buff utility routine Lorenzo Bianconi (2): net: xdp: introduce xdp_init_buff utility routine net: xdp: introduce xdp_prepare_buff utility routine Acked-by: Martin Habets Acked-by: Camelia Groza drivers/net/ethernet/amazon/ena/ena_netdev.c | 10 -- For changes in ena driver Acked-by: Shay Agroskin Also, wouldn't xdp_init_buff() change once the xdp_mb series is merged to take care of xdp.mb = 0 part ? Maybe this series should wait until the other one is merged ? drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c | 9 +++-- .../net/ethernet/cavium/thunder/nicvf_main.c | 12 ++-- .../net/ethernet/freescale/dpaa/dpaa_eth.c| 10 -- .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 14 +- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 18 +- drivers/net/ethernet/intel/ice/ice_txrx.c | 15 --- drivers/net/ethernet/intel/igb/igb_main.c | 18 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 19 +-- .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 19 +-- drivers/net/ethernet/marvell/mvneta.c | 10 +++--- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 14 +++--- drivers/net/ethernet/mellanox/mlx4/en_rx.c| 9 +++-- .../net/ethernet/mellanox/mlx5/core/en_rx.c | 8 ++-- .../ethernet/netronome/nfp/nfp_net_common.c | 12 ++-- drivers/net/ethernet/qlogic/qede/qede_fp.c| 9 +++-- drivers/net/ethernet/sfc/rx.c | 10 +++--- drivers/net/ethernet/socionext/netsec.c | 9 +++-- drivers/net/ethernet/ti/cpsw.c| 18 ++ drivers/net/ethernet/ti/cpsw_new.c| 18 ++ drivers/net/hyperv/netvsc_bpf.c | 8 ++-- drivers/net/tun.c | 12 drivers/net/veth.c| 14 +- drivers/net/virtio_net.c | 18 ++ drivers/net/xen-netfront.c| 10 -- include/net/xdp.h | 19 +++ net/bpf/test_run.c| 9 +++-- net/core/dev.c| 18 -- 28 files changed, 159 insertions(+), 210 deletions(-)
Re: [PATCH net] docs: netdev-FAQ: add missing underlines to questions
Hi Jakub,
On Thu, Dec 17 2020, Jakub Kicinski wrote:
> On Tue, 15 Dec 2020 19:18:19 +0200 Baruch Siach wrote:
>> Signed-off-by: Baruch Siach
>> ---
>> Documentation/networking/netdev-FAQ.rst | 18 +++---
>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/networking/netdev-FAQ.rst
>> b/Documentation/networking/netdev-FAQ.rst
>> index 4b9ed5874d5a..4ef90fe26640 100644
>> --- a/Documentation/networking/netdev-FAQ.rst
>> +++ b/Documentation/networking/netdev-FAQ.rst
>> @@ -82,6 +82,7 @@ focus for ``net`` is on stabilization and bug fixes.
>> Finally, the vX.Y gets released, and the whole cycle starts over.
>>
>> Q: So where are we now in this cycle?
>> +-
>>
>> Load the mainline (Linus) page here:
>>
>> @@ -108,6 +109,7 @@ with.
>> Q: I sent a patch and I'm wondering what happened to it?
>>
>> Q: How can I tell whether it got merged?
>> +
>
> I think this and the following fixes should be folded into a single
> line (unless it's possible in RST for header to span multiple lines):
>
> I sent a patch and I'm wondering what happened to it - how can I tell whether
> it got merged?
>
>
> To be honest I think we can also drop the Q: and A: prefixes now that
> we're using RST.
>
> And perhaps we can add an index of questions at the beginning of the
> the file?
Sphinx creates side bar index of the questions in the HTML version. See
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
Other formats provide other index methods.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] net: ethernet: mvneta: Fix error handling in mvneta_probe
When mvneta_port_power_up() fails, we should execute
cleanup functions after label err_netdev to avoid memleak.
Fixes: 41c2b6b4f0f80 ("net: ethernet: mvneta: Add back interface mode
validation")
Signed-off-by: Dinghao Liu
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 563ceac3060f..3369ec717a51 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -5255,7 +5255,7 @@ static int mvneta_probe(struct platform_device *pdev)
err = mvneta_port_power_up(pp, pp->phy_interface);
if (err < 0) {
dev_err(&pdev->dev, "can't power up port\n");
- return err;
+ goto err_netdev;
}
/* Armada3700 network controller does not support per-cpu
--
2.17.1
Re: [RFC PATCH net-next] net: dsa: mt7530: rename MT7621 compatible
On Sun, Dec 20, 2020 at 3:49 PM Vladimir Oltean wrote: > But still, what is at memory address 0x1e11, if the switch is > accessed over MDIO? It's "Ethernet GMAC", handled by mtk_eth_soc.
[PATCH v2] docs: netdev-FAQ: fix question headers formatting
Join adjacent questions to a single question line. This fixes the formatting of questions that were not part of the heading. Also, drop Q: and A: prefixes. We don't need them now that questions and answers are visually separated. Signed-off-by: Baruch Siach --- v2: Address comments from Jakub Kicinski: * Join adjacent questions * Drop Q:/A: prefixes --- Documentation/networking/netdev-FAQ.rst | 126 +++- 1 file changed, 59 insertions(+), 67 deletions(-) diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 4b9ed5874d5a..aa6fdb4fcae9 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -6,9 +6,9 @@ netdev FAQ == -Q: What is netdev? --- -A: It is a mailing list for all network-related Linux stuff. This +What is netdev? +--- +It is a mailing list for all network-related Linux stuff. This includes anything found under net/ (i.e. core code like IPv6) and drivers/net (i.e. hardware specific drivers) in the Linux source tree. @@ -25,9 +25,9 @@ Aside from subsystems like that mentioned above, all network-related Linux development (i.e. RFC, review, comments, etc.) takes place on netdev. -Q: How do the changes posted to netdev make their way into Linux? -- -A: There are always two trees (git repositories) in play. Both are +How do the changes posted to netdev make their way into Linux? +-- +There are always two trees (git repositories) in play. Both are driven by David Miller, the main network maintainer. There is the ``net`` tree, and the ``net-next`` tree. As you can probably guess from the names, the ``net`` tree is for fixes to existing code already in the @@ -37,9 +37,9 @@ for the future release. You can find the trees here: - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git -Q: How often do changes from these trees make it to the mainline Linus tree? - -A: To understand this, you need to know a bit of background information on +How often do changes from these trees make it to the mainline Linus tree? +- +To understand this, you need to know a bit of background information on the cadence of Linux development. Each new release starts off with a two week "merge window" where the main maintainers feed their new stuff to Linus for merging into the mainline tree. After the two weeks, the @@ -81,7 +81,8 @@ focus for ``net`` is on stabilization and bug fixes. Finally, the vX.Y gets released, and the whole cycle starts over. -Q: So where are we now in this cycle? +So where are we now in this cycle? +-- Load the mainline (Linus) page here: @@ -91,9 +92,9 @@ and note the top of the "tags" section. If it is rc1, it is early in the dev cycle. If it was tagged rc7 a week ago, then a release is probably imminent. -Q: How do I indicate which tree (net vs. net-next) my patch should be in? -- -A: Firstly, think whether you have a bug fix or new "next-like" content. +How do I indicate which tree (net vs. net-next) my patch should be in? +-- +Firstly, think whether you have a bug fix or new "next-like" content. Then once decided, assuming that you use git, use the prefix flag, i.e. :: @@ -105,48 +106,45 @@ in the above is just the subject text of the outgoing e-mail, and you can manually change it yourself with whatever MUA you are comfortable with. -Q: I sent a patch and I'm wondering what happened to it? - -Q: How can I tell whether it got merged? -A: Start by looking at the main patchworks queue for netdev: +I sent a patch and I'm wondering what happened to it - How can I tell whether it got merged? + +Start by looking at the main patchworks queue for netdev: https://patchwork.kernel.org/project/netdevbpf/list/ The "State" field will tell you exactly where things are at with your patch. -Q: The above only says "Under Review". How can I find out more? - -A: Generally speaking, the patches get triaged quickly (in less than +The above only says "Under Review". How can I find out more? +- +Generally speaking, the patches get triaged quickly (in less than 48h). So be patient. Asking the maintainer for status upd
Re: [RFC PATCH net-next] net: dsa: mt7530: rename MT7621 compatible
On Sun, Dec 20, 2020 at 04:36:27PM +0800, DENG Qingfang wrote: > On Sun, Dec 20, 2020 at 3:49 PM Vladimir Oltean wrote: > > But still, what is at memory address 0x1e11, if the switch is > > accessed over MDIO? > > It's "Ethernet GMAC", handled by mtk_eth_soc. I see. You have some work to do with that device tree.
Re: [RFC PATCH net-next] net: dsa: mt7530: rename MT7621 compatible
On Sun, Dec 20, 2020 at 12:21:53AM +0800, DENG Qingfang wrote: > MT7621 is a SoC, so using "mediatek,mt7621" as its compatible is ambiguous. > Rename it to "mediatek,mt7621-gsw". > > Signed-off-by: DENG Qingfang > --- I would say that you need to resolve the situation with the docs at Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt and with the bindings at drivers/staging/mt7621-dts/mt7621.dtsi first (or in the same series). And still then, it would be nice if you could preserve compatibility with the existing bindings at least for a while.
Re: INFO: rcu detected stall in tipc_release
syzbot suspects this issue was fixed by commit: commit cc00bcaa589914096edef7fb87ca5cee4a166b5c Author: Subash Abhinov Kasiviswanathan Date: Wed Nov 25 18:27:22 2020 + netfilter: x_tables: Switch synchronization to RCU bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1445cb3750 start commit: 7cc2a8ea Merge tag 'block-5.8-2020-07-01' of git://git.ker.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=7be693511b29b338 dashboard link: https://syzkaller.appspot.com/bug?extid=3654c027d861c6df4b06 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1294823310 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11344c0510 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: netfilter: x_tables: Switch synchronization to RCU For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH v4 bpf-next 0/2] introduce xdp_init_buff/xdp_prepare_buff
> > > Lorenzo Bianconi writes: > > > Introduce xdp_init_buff and xdp_prepare_buff utility routines to > > initialize > > xdp_buff data structure and remove duplicated code in all XDP > > capable > > drivers. > > > > Changes since v3: > > - use __always_inline instead of inline for > > xdp_init_buff/xdp_prepare_buff > > - add 'const bool meta_valid' to xdp_prepare_buff signature to > > avoid > > overwriting data_meta with xdp_set_data_meta_invalid() > > - introduce removed comment in bnxt driver > > > > Changes since v2: > > - precompute xdp->data as hard_start + headroom and save it in a > > local > > variable to reuse it for xdp->data_end and xdp->data_meta in > > xdp_prepare_buff() > > > > Changes since v1: > > - introduce xdp_prepare_buff utility routine > > > > Lorenzo Bianconi (2): > > net: xdp: introduce xdp_init_buff utility routine > > net: xdp: introduce xdp_prepare_buff utility routine > > > > Acked-by: Martin Habets > > Acked-by: Camelia Groza > > > > drivers/net/ethernet/amazon/ena/ena_netdev.c | 10 -- > > For changes in ena driver > > Acked-by: Shay Agroskin > > Also, wouldn't xdp_init_buff() change once the xdp_mb series is > merged to take care of xdp.mb = 0 part ? > Maybe this series should wait until the other one is merged ? > When this series is merged, I will rebase xdp multi-buff one on top of it and I will initialize xdp.mb = 0 in xdp_init_buff() without changing each driver. Regards, Lorenzo > > drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c | 9 +++-- > > .../net/ethernet/cavium/thunder/nicvf_main.c | 12 ++-- > > .../net/ethernet/freescale/dpaa/dpaa_eth.c| 10 -- > > .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 14 > > +- > > drivers/net/ethernet/intel/i40e/i40e_txrx.c | 18 > > +- > > drivers/net/ethernet/intel/ice/ice_txrx.c | 15 > > --- > > drivers/net/ethernet/intel/igb/igb_main.c | 18 > > +- > > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 19 > > +-- > > .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 19 > > +-- > > drivers/net/ethernet/marvell/mvneta.c | 10 +++--- > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 14 > > +++--- > > drivers/net/ethernet/mellanox/mlx4/en_rx.c| 9 +++-- > > .../net/ethernet/mellanox/mlx5/core/en_rx.c | 8 ++-- > > .../ethernet/netronome/nfp/nfp_net_common.c | 12 ++-- > > drivers/net/ethernet/qlogic/qede/qede_fp.c| 9 +++-- > > drivers/net/ethernet/sfc/rx.c | 10 +++--- > > drivers/net/ethernet/socionext/netsec.c | 9 +++-- > > drivers/net/ethernet/ti/cpsw.c| 18 > > ++ > > drivers/net/ethernet/ti/cpsw_new.c| 18 > > ++ > > drivers/net/hyperv/netvsc_bpf.c | 8 ++-- > > drivers/net/tun.c | 12 > > drivers/net/veth.c| 14 > > +- > > drivers/net/virtio_net.c | 18 > > ++ > > drivers/net/xen-netfront.c| 10 -- > > include/net/xdp.h | 19 > > +++ > > net/bpf/test_run.c| 9 +++-- > > net/core/dev.c| 18 > > -- > > 28 files changed, 159 insertions(+), 210 deletions(-) >
RE: [EXT] Re: [PATCH net v3] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations
> External Email > > -- > On Thu, 17 Dec 2020 14:37:28 +0200 stef...@marvell.com wrote: > > From: Stefan Chulski > > > > During GoP port 2 Networking Complex Control mode of operation > > configurations, also GoP port 3 mode of operation was wrongly set. > > Patch removes these configurations. > > GENCONF_CTRL0_PORTX naming also fixed. > > Testing the stable backport it looks like this addition change will be > problematic. Not to mention it goes against the "fixes should be minimal" > rule. > > Could you please send just a one liner which removes the offending ORing in > of the bad bit? > > We can do the rename soon after in net-next, the trees are merged pretty > much every week so it won't be a long wait. I would repost with single line change. Regards, Stefan.
[PATCH net v4] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations
From: Stefan Chulski
During GoP port 2 Networking Complex Control mode of operation configurations,
also GoP port 3 mode of operation was wrongly set.
Patch removes these configurations.
Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
Acked-by: Marcin Wojtas
Signed-off-by: Stefan Chulski
---
Changes in v4:
- Remove rename change.
Changes in v3:
- No changes.
Changes in v2:
- Added Fixes tag.
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d64dc12..82c6bef 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1231,7 +1231,7 @@ static void mvpp22_gop_init_rgmii(struct mvpp2_port *port)
regmap_read(priv->sysctrl_base, GENCONF_CTRL0, &val);
if (port->gop_id == 2)
- val |= GENCONF_CTRL0_PORT0_RGMII | GENCONF_CTRL0_PORT1_RGMII;
+ val |= GENCONF_CTRL0_PORT0_RGMII;
else if (port->gop_id == 3)
val |= GENCONF_CTRL0_PORT1_RGMII_MII;
regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
--
1.9.1
RE: [EXT] Re: [PATCH net-next] net: mvpp2: prs: improve ipv4 parse flow
> > -- > On Thu, 17 Dec 2020 18:07:58 +0200 stef...@marvell.com wrote: > > From: Stefan Chulski > > > > Patch didn't fix any issue, just improve parse flow and align ipv4 > > parse flow with ipv6 parse flow. > > > > Currently ipv4 kenguru parser first check IP protocol(TCP/UDP) and > > then destination IP address. > > Patch introduce reverse ipv4 parse, first destination IP address > > parsed and only then IP protocol. > > This would allow extend capability for packet L4 parsing and align > > ipv4 parsing flow with ipv6. > > > > Suggested-by: Liron Himi > > Signed-off-by: Stefan Chulski > > This one will need to wait until after the merge window > > -- > > # Form letter - net-next is closed > > We have already sent the networking pull request for 5.11 and therefore net- > next is closed for new drivers, features, code refactoring and optimizations. > We are currently accepting bug fixes only. > > Please repost when net-next reopens after 5.11-rc1 is cut. OK, Thanks. > Look out for the announcement on the mailing list or check: > https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_- > 7Edavem_net- > 2Dnext.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DDQ3dKwkTIxKAl > 6_Bs7GMx4zhJArrXKN2mDMOXGh7lg&m=2CcDqbEJMvxpx15rGBe2og6oh1eZ > hVee8xvK-mjfd0E&s=r1d6bSIPQmjwJqe- > mkU_s5wyqHOU82D18G6SkVuUg5A&e= > > RFC patches sent for review only are obviously welcome at any time. If I post RFC patches for review only, should I add some prefix or tag for this? And if all reviewers OK with change(or no comments at all), should I repost this patch again after net-next opened? Thanks, Stefan.
Re: [PATCH AUTOSEL 5.4 08/10] selftests/bpf: Fix array access with signed variable test
Hi,
On Sat, Dec 19, 2020 at 10:34:55PM -0500, Sasha Levin wrote:
> From: Jean-Philippe Brucker
>
> [ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
>
> The test fails because of a recent fix to the verifier, even though this
That fix is commit b02709587ea3 ("bpf: Fix propagation of 32-bit signed
bounds from 64-bit bounds.") upstream, which only needed backport to 5.9.
So although backporting this patch to 5.4 shouldn't break anything, I
wouldn't bother.
Thanks,
Jean
> program is valid. In details what happens is:
>
> 7: (61) r1 = *(u32 *)(r0 +0)
>
> Load a 32-bit value, with signed bounds [S32_MIN, S32_MAX]. The bounds
> of the 64-bit value are [0, U32_MAX]...
>
> 8: (65) if r1 s> 0x goto pc+1
>
> ... therefore this is always true (the operand is sign-extended).
>
> 10: (b4) w2 = 11
> 11: (6d) if r2 s> r1 goto pc+1
>
> When true, the 64-bit bounds become [0, 10]. The 32-bit bounds are still
> [S32_MIN, 10].
>
> 13: (64) w1 <<= 2
>
> Because this is a 32-bit operation, the verifier propagates the new
> 32-bit bounds to the 64-bit ones, and the knowledge gained from insn 11
> is lost.
>
> 14: (0f) r0 += r1
> 15: (7a) *(u64 *)(r0 +0) = 4
>
> Then the verifier considers r0 unbounded here, rejecting the test. To
> make the test work, change insn 8 to check the sign of the 32-bit value.
>
> Signed-off-by: Jean-Philippe Brucker
> Acked-by: John Fastabend
> Signed-off-by: Alexei Starovoitov
> Signed-off-by: Sasha Levin
> ---
> tools/testing/selftests/bpf/verifier/array_access.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/verifier/array_access.c
> b/tools/testing/selftests/bpf/verifier/array_access.c
> index f3c33e128709b..a80d806ead15f 100644
> --- a/tools/testing/selftests/bpf/verifier/array_access.c
> +++ b/tools/testing/selftests/bpf/verifier/array_access.c
> @@ -68,7 +68,7 @@
> BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
> BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 9),
> BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0),
> - BPF_JMP_IMM(BPF_JSGT, BPF_REG_1, 0x, 1),
> + BPF_JMP32_IMM(BPF_JSGT, BPF_REG_1, 0x, 1),
> BPF_MOV32_IMM(BPF_REG_1, 0),
> BPF_MOV32_IMM(BPF_REG_2, MAX_ENTRIES),
> BPF_JMP_REG(BPF_JSGT, BPF_REG_2, BPF_REG_1, 1),
> --
> 2.27.0
>
[PATCH] net/ncsi: Use real net-device for response handler
When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the net device registered to packet_type to fix it.
Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang
---
net/ncsi/ncsi-rsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index a94bb59793f0..60ae32682904 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -1120,7 +1120,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, struct net_device
*dev,
int payload, i, ret;
/* Find the NCSI device */
- nd = ncsi_find_dev(dev);
+ nd = ncsi_find_dev(pt->dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;
--
2.25.1
KASAN: global-out-of-bounds Read in smc_nl_get_sys_info
Hello, syzbot found the following issue on: HEAD commit:3db1a3fa Merge tag 'staging-5.11-rc1' of git://git.kernel... git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=121dc93750 kernel config: https://syzkaller.appspot.com/x/.config?x=2764fc28a92339f9 dashboard link: https://syzkaller.appspot.com/bug?extid=f4708c391121cfc58396 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1652228750 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1144680f50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f4708c391121cfc58...@syzkaller.appspotmail.com == BUG: KASAN: global-out-of-bounds in string_nocheck lib/vsprintf.c:611 [inline] BUG: KASAN: global-out-of-bounds in string+0x39c/0x3d0 lib/vsprintf.c:693 Read of size 1 at addr 8faea960 by task syz-executor646/8509 CPU: 0 PID: 8509 Comm: syz-executor646 Not tainted 5.10.0-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+0x5/0x4c8 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562 string_nocheck lib/vsprintf.c:611 [inline] string+0x39c/0x3d0 lib/vsprintf.c:693 vsnprintf+0x71b/0x14f0 lib/vsprintf.c:2618 snprintf+0xbb/0xf0 lib/vsprintf.c:2751 smc_nl_get_sys_info+0x493/0x880 net/smc/smc_core.c:249 genl_lock_dumpit+0x60/0x90 net/netlink/genetlink.c:623 netlink_dump+0x4b9/0xb70 net/netlink/af_netlink.c:2268 __netlink_dump_start+0x642/0x900 net/netlink/af_netlink.c:2373 genl_family_rcv_msg_dumpit+0x2af/0x310 net/netlink/genetlink.c:686 genl_family_rcv_msg net/netlink/genetlink.c:780 [inline] genl_rcv_msg+0x434/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2336 ___sys_sendmsg+0xf3/0x170 net/socket.c:2390 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2423 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x440299 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff4b943e58 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 004002c8 RCX: 00440299 RDX: RSI: 2180 RDI: 0003 RBP: 006ca018 R08: R09: 004002c8 R10: R11: 0246 R12: 00401aa0 R13: 00401b30 R14: R15: The buggy address belongs to the variable: smc_hostname+0x20/0x40 Memory state around the buggy address: 8faea800: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 8faea880: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 >8faea900: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ 8faea980: 04 f9 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 8faeaa00: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 == --- 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: general protection fault in j1939_netdev_notify (2)
Hello Oleksij,
I assume there is some ndev->ml_priv value set - but not from a CAN
netdevice.
What was the reason to fiddle with the 'priv' stuff in
j1939_netdev_notify() before checking if it was a CAN device?
Would this patch fix the issue then?
diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c
index bb914d8b4216..6940f98b81fb 100644
--- a/net/can/j1939/main.c
+++ b/net/can/j1939/main.c
@@ -348,26 +348,25 @@ static int j1939_netdev_notify(struct
notifier_block *nb,
unsigned long msg, void *data)
{
struct net_device *ndev = netdev_notifier_info_to_dev(data);
struct j1939_priv *priv;
+ if (ndev->type != ARPHRD_CAN)
+ goto notify_done;
+
priv = j1939_priv_get_by_ndev(ndev);
if (!priv)
goto notify_done;
- if (ndev->type != ARPHRD_CAN)
- goto notify_put;
-
switch (msg) {
case NETDEV_DOWN:
j1939_cancel_active_session(priv, NULL);
j1939_sk_netdev_event_netdown(priv);
j1939_ecu_unmap_all(priv);
break;
}
-notify_put:
j1939_priv_put(priv);
notify_done:
return NOTIFY_DONE;
}
If so, I can send a proper patch if you like.
Best regards,
Oliver
On 20.12.20 06:34, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:d635a69d Merge tag 'net-next-5.11' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1315f12350
kernel config: https://syzkaller.appspot.com/x/.config?x=c3556e4856b17a95
dashboard link: https://syzkaller.appspot.com/bug?extid=5138c4dd15a0401bec7b
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1295512350
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f2f30f50
The issue was bisected to:
commit 497a5757ce4e8f37219a3989ac6a561eb9a8e6c7
Author: Heiner Kallweit
Date: Sat Nov 7 20:50:56 2020 +
tun: switch to net core provided statistics counters
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=143b845b50
final oops: https://syzkaller.appspot.com/x/report.txt?x=163b845b50
console output: https://syzkaller.appspot.com/x/log.txt?x=123b845b50
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5138c4dd15a0401be...@syzkaller.appspotmail.com
Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters")
general protection fault, probably for non-canonical address
0xe80fe8c072f1: [#1] PREEMPT SMP KASAN
KASAN: probably user-memory-access in range
[0x607f46039788-0x607f4603978f]
CPU: 1 PID: 8472 Comm: syz-executor635 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:j1939_ndev_to_priv net/can/j1939/main.c:219 [inline]
RIP: 0010:j1939_priv_get_by_ndev_locked net/can/j1939/main.c:231 [inline]
RIP: 0010:j1939_priv_get_by_ndev net/can/j1939/main.c:243 [inline]
RIP: 0010:j1939_netdev_notify+0x115/0x320 net/can/j1939/main.c:353
Code: 00 74 08 48 89 df e8 ba 1e 48 f9 48 8b 1b 48 85 db 0f 84 f0 00 00 00 4c 89 64
24 08 48 81 c3 28 60 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df
e8 8c 1e 48 f9 4c 8b 23 4d 85 e4 0f
RSP: 0018:c9e9fd68 EFLAGS: 00010202
RAX: 0c0fe8c072f1 RBX: 607f46039788 RCX: 88801456d040
RDX: 88801456d040 RSI: 0118 RDI: 0118
RBP: 0118 R08: 8870585d R09: f520001d3fa5
R10: f520001d3fa5 R11: R12: 0010
R13: 11100293e848 R14: dc00 R15: 8880149f4244
FS: 01d13880() GS:8880b9d0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2080 CR3: 1402f000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
notifier_call_chain kernel/notifier.c:83 [inline]
raw_notifier_call_chain+0xe7/0x170 kernel/notifier.c:410
call_netdevice_notifiers_info net/core/dev.c:2022 [inline]
call_netdevice_notifiers_extack net/core/dev.c:2034 [inline]
call_netdevice_notifiers+0xeb/0x150 net/core/dev.c:2048
__tun_chr_ioctl+0x2337/0x4860 drivers/net/tun.c:3093
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440359
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 7b 13
fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fffd37b9c98 EFLAGS: 0246 ORIG_
Re: general protection fault in rose_send_frame
syzbot suspects this issue was fixed by commit: commit 3b3fd068c56e3fbea30090859216a368398e39bf Author: Anmol Karn Date: Thu Nov 19 19:10:43 2020 + rose: Fix Null pointer dereference in rose_send_frame() bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=139e2b9b50 start commit: 23ee3e4e Merge tag 'pci-v5.8-fixes-2' of git://git.kernel... git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267 dashboard link: https://syzkaller.appspot.com/bug?extid=7078ae989d857fe17988 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=157e896490 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10046c5490 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: rose: Fix Null pointer dereference in rose_send_frame() For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: general protection fault in j1939_netdev_notify (2)
Hello Oliver,
On Sun, Dec 20, 2020 at 02:18:27PM +0100, Oliver Hartkopp wrote:
> Hello Oleksij,
>
> I assume there is some ndev->ml_priv value set - but not from a CAN
> netdevice.
it is kind of CAN device :)
> What was the reason to fiddle with the 'priv' stuff in j1939_netdev_notify()
> before checking if it was a CAN device?
>
> Would this patch fix the issue then?
No, j1939_priv_get_by_ndev() already has an internal test for
ARPHRD_CAN. One of this tests can be removed, to make the code clear.
So, we get netdev with ARPHRD_CAN and ml_priv == something.
Right now I do not know how to fix it.
Ideas?
> diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c
> index bb914d8b4216..6940f98b81fb 100644
> --- a/net/can/j1939/main.c
> +++ b/net/can/j1939/main.c
> @@ -348,26 +348,25 @@ static int j1939_netdev_notify(struct notifier_block
> *nb,
> unsigned long msg, void *data)
> {
> struct net_device *ndev = netdev_notifier_info_to_dev(data);
> struct j1939_priv *priv;
>
> + if (ndev->type != ARPHRD_CAN)
> + goto notify_done;
> +
> priv = j1939_priv_get_by_ndev(ndev);
> if (!priv)
> goto notify_done;
>
> - if (ndev->type != ARPHRD_CAN)
> - goto notify_put;
> -
> switch (msg) {
> case NETDEV_DOWN:
> j1939_cancel_active_session(priv, NULL);
> j1939_sk_netdev_event_netdown(priv);
> j1939_ecu_unmap_all(priv);
> break;
> }
>
> -notify_put:
> j1939_priv_put(priv);
>
> notify_done:
> return NOTIFY_DONE;
> }
>
> If so, I can send a proper patch if you like.
>
> Best regards,
> Oliver
>
>
> On 20.12.20 06:34, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:d635a69d Merge tag 'net-next-5.11' of git://git.kernel.org..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1315f12350
> > kernel config: https://syzkaller.appspot.com/x/.config?x=c3556e4856b17a95
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5138c4dd15a0401bec7b
> > compiler: clang version 11.0.0
> > (https://github.com/llvm/llvm-project.git
> > ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1295512350
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f2f30f50
> >
> > The issue was bisected to:
> >
> > commit 497a5757ce4e8f37219a3989ac6a561eb9a8e6c7
> > Author: Heiner Kallweit
> > Date: Sat Nov 7 20:50:56 2020 +
> >
> > tun: switch to net core provided statistics counters
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=143b845b50
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=163b845b50
> > console output: https://syzkaller.appspot.com/x/log.txt?x=123b845b50
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+5138c4dd15a0401be...@syzkaller.appspotmail.com
> > Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters")
> >
> > general protection fault, probably for non-canonical address
> > 0xe80fe8c072f1: [#1] PREEMPT SMP KASAN
> > KASAN: probably user-memory-access in range
> > [0x607f46039788-0x607f4603978f]
> > CPU: 1 PID: 8472 Comm: syz-executor635 Not tainted 5.10.0-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:j1939_ndev_to_priv net/can/j1939/main.c:219 [inline]
> > RIP: 0010:j1939_priv_get_by_ndev_locked net/can/j1939/main.c:231 [inline]
> > RIP: 0010:j1939_priv_get_by_ndev net/can/j1939/main.c:243 [inline]
> > RIP: 0010:j1939_netdev_notify+0x115/0x320 net/can/j1939/main.c:353
> > Code: 00 74 08 48 89 df e8 ba 1e 48 f9 48 8b 1b 48 85 db 0f 84 f0 00 00 00
> > 4c 89 64 24 08 48 81 c3 28 60 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00
> > 74 08 48 89 df e8 8c 1e 48 f9 4c 8b 23 4d 85 e4 0f
> > RSP: 0018:c9e9fd68 EFLAGS: 00010202
> > RAX: 0c0fe8c072f1 RBX: 607f46039788 RCX: 88801456d040
> > RDX: 88801456d040 RSI: 0118 RDI: 0118
> > RBP: 0118 R08: 8870585d R09: f520001d3fa5
> > R10: f520001d3fa5 R11: R12: 0010
> > R13: 11100293e848 R14: dc00 R15: 8880149f4244
> > FS: 01d13880() GS:8880b9d0() knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 2080 CR3: 1402f000 CR4: 001506e0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> > notifier_call_chain kernel/notifier.c:83 [inline]
> > raw_notifier_call_chain+0xe7/0x170 kernel/notifier.c:410
> > call_netdevice_notifiers_info net/core/dev.c:2022 [inline]
> > call_net
Re: [PATCH net 2/2] docs: networking: packet_mmap: don't mention PACKET_MMAP
On Sun, Dec 20, 2020 at 3:00 AM Baruch Siach wrote:
>
> Hi Willem,
>
> On Thu, Dec 17 2020, Willem de Bruijn wrote:
> > On Thu, Dec 17, 2020 at 2:48 PM Jakub Kicinski wrote:
> >>
> >> On Tue, 15 Dec 2020 18:51:17 +0200 Baruch Siach wrote:
> >> > Before commit 889b8f964f2f ("packet: Kill CONFIG_PACKET_MMAP.") there
> >> > used to be a CONFIG_PACKET_MMAP config symbol that depended on
> >> > CONFIG_PACKET. The text still refers to PACKET_MMAP as the name of this
> >> > feature, implying that it can be disabled. Another naming variant is
> >> > "Packet MMAP".
> >> >
> >> > Use "PACKET mmap()" everywhere to unify the terminology. Rephrase the
> >> > text the implied mmap() feature disable option.
> >>
> >> Should we maybe say AF_PACKET mmap() ?
> >
> > I don't think that the feature name PACKET_MMAP implies
> > CONFIG_PACKET_MMAP, or thus that the name is obsolete now that the
> > latter is.
>
> Current text says "if PACKET_MMAP is not enabled ...". This clearly
> implies a CONFIG_ symbol. Besides, the PACKET_MMAP term is mentioned
> nowhere else in the source tree. At the very least we need to clarify
> what it means.
At this point I don't think renaming will simplify anything. It is by
now referred to by that name outside the kernel, a google search
shows. It is also even the name of the documentation file
(packet_mmap.rst).
The file starts with
PACKET_MMAP
Abstract
This file documents the mmap() facility available with the PACKET
socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for
That introduces the term well enough, I think.
Agreed that references to old kernel versions and the previous compile
time configurability of the feature are no longer relevant.
> > If it needs a rename, the setsockopt is PACKET_[RT]X_RING. So, if this
> > needs updating, perhaps PACKET_RING would be suitable. Or TPACKET,
> > based on the version definitions.
>
> So how would you rephrase text like "PACKET_MMAP provides a size
> configurable circular buffer ..."?
PACKET_RING provides a size configurable circular buffer would work,
but see previous comment.
Re: [PATCH] staging: qlge: Removed duplicate word in comment.
On Fri, Dec 18, 2020 at 05:48:29PM -0800, Daniel West wrote: > This patch fixes the checkpatch warning: > > WARNING: Possible repeated word: 'and' > > Signed-off-by: Daniel West > --- > drivers/staging/qlge/qlge_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/qlge/qlge_main.c > b/drivers/staging/qlge/qlge_main.c > index e6b7baa12cd6..22167eca7c50 100644 > --- a/drivers/staging/qlge/qlge_main.c > +++ b/drivers/staging/qlge/qlge_main.c > @@ -3186,7 +3186,7 @@ static void ql_enable_msix(struct ql_adapter *qdev) >"Running with legacy interrupts.\n"); > } > > -/* Each vector services 1 RSS ring and and 1 or more > +/* Each vector services 1 RSS ring and 1 or more > * TX completion rings. This function loops through > * the TX completion rings and assigns the vector that > * will service it. An example would be if there are Patch it self looks good. I nit pick a little bit because this is staging and were here to learn mostly. You should use imperative mood in subject line. So Removed -> Remove. Also no period in subject line. I'm also confused by your email. Other patch which you send has sign of is with daniel.s.west.dev and another is daniel.west.dev. So do you use both? I also think that you made this email becouse you want to get all lkml mails. That is perfectly fine and many does this. But many does it just for reading. That way if someone needs to send you email it wont be lost because you do not read that email anymore. Many does that they still send messages from they real email so that email do get so many emails. This is ofcourse your decission I'm just telling you options. -- Kari Argillander
UBSAN: object-size-mismatch in wg_xmit
Hello, syzbot found the following issue on: HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12b12c1350 kernel config: https://syzkaller.appspot.com/x/.config?x=267a60b188ded8ed dashboard link: https://syzkaller.appspot.com/bug?extid=8f90d005ab2d22342b6d compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git ca2dcbd030eadbf0aa9b660efe864ff08af6e18b) 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+8f90d005ab2d22342...@syzkaller.appspotmail.com UBSAN: object-size-mismatch in ./include/linux/skbuff.h:2021:28 member access within address 85889cc2 with insufficient space for an object of type 'struct sk_buff' CPU: 1 PID: 2998 Comm: kworker/1:2 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: ipv6_addrconf addrconf_dad_work Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x137/0x1be lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] handle_object_size_mismatch lib/ubsan.c:297 [inline] ubsan_type_mismatch_common+0x1e2/0x390 lib/ubsan.c:310 __ubsan_handle_type_mismatch_v1+0x41/0x50 lib/ubsan.c:339 __skb_queue_before include/linux/skbuff.h:2021 [inline] __skb_queue_tail include/linux/skbuff.h:2054 [inline] wg_xmit+0x45d/0xdf0 drivers/net/wireguard/device.c:182 __netdev_start_xmit include/linux/netdevice.h:4775 [inline] netdev_start_xmit+0x7b/0x140 include/linux/netdevice.h:4789 xmit_one net/core/dev.c:3556 [inline] dev_hard_start_xmit+0x182/0x2e0 net/core/dev.c:3572 __dev_queue_xmit+0x1229/0x1e60 net/core/dev.c:4133 neigh_output include/net/neighbour.h:510 [inline] ip6_finish_output2+0xe8d/0x11e0 net/ipv6/ip6_output.c:117 dst_output include/net/dst.h:441 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ndisc_send_skb+0x85b/0xc70 net/ipv6/ndisc.c:508 addrconf_dad_completed+0x5ef/0x990 net/ipv6/addrconf.c:4192 addrconf_dad_work+0xb92/0x1480 net/ipv6/addrconf.c:3959 process_one_work+0x471/0x830 kernel/workqueue.c:2275 worker_thread+0x757/0xb10 kernel/workqueue.c:2421 kthread+0x39a/0x3c0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 --- 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.
Re: [PATCH net-next 2/4] net: mvpp2: add mvpp2_phylink_to_port() helper
Hi Jakub,
czw., 10 gru 2020 o 15:35 Marcin Wojtas napisał(a):
>
> Hi Greg,
>
> śr., 9 gru 2020 o 11:59 Greg Kroah-Hartman
> napisał(a):
> >
> > On Tue, Dec 08, 2020 at 04:02:50PM +0100, Marcin Wojtas wrote:
> > > Hi Sasha,
> > >
> > > wt., 8 gru 2020 o 14:35 Sasha Levin napisał(a):
> > > >
> > > > On Tue, Dec 08, 2020 at 01:03:38PM +0100, Marcin Wojtas wrote:
> > > > >Hi Greg,
> > > > >
> > > > >Apologies for delayed response:.
> > > > >
> > > > >
> > > > >pon., 2 lis 2020 o 19:02 Greg Kroah-Hartman
> > > > > napisał(a):
> > > > >>
> > > > >> On Mon, Nov 02, 2020 at 06:38:54PM +0100, Marcin Wojtas wrote:
> > > > >> > Hi Greg and Sasha,
> > > > >> >
> > > > >> > pt., 9 paź 2020 o 05:43 Marcin Wojtas
> > > > >> > napisał(a):
> > > > >> > >
> > > > >> > > Hi,
> > > > >> > >
> > > > >> > > sob., 20 cze 2020 o 11:21 Russell King
> > > > >> > > napisał(a):
> > > > >> > > >
> > > > >> > > > Add a helper to convert the struct phylink_config pointer
> > > > >> > > > passed in
> > > > >> > > > from phylink to the drivers internal struct mvpp2_port.
> > > > >> > > >
> > > > >> > > > Signed-off-by: Russell King
> > > > >> > > > ---
> > > > >> > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 29
> > > > >> > > > +--
> > > > >> > > > 1 file changed, 14 insertions(+), 15 deletions(-)
> > > > >> > > >
> > > > >> > > > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > >> > > > b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > >> > > > index 7653277d03b7..313f5a60a605 100644
> > > > >> > > > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > >> > > > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > >> > > > @@ -4767,12 +4767,16 @@ static void
> > > > >> > > > mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2
> > > > >> > > > *priv,
> > > > >> > > > eth_hw_addr_random(dev);
> > > > >> > > > }
> > > > >> > > >
> > > > >> > > > +static struct mvpp2_port *mvpp2_phylink_to_port(struct
> > > > >> > > > phylink_config *config)
> > > > >> > > > +{
> > > > >> > > > + return container_of(config, struct mvpp2_port,
> > > > >> > > > phylink_config);
> > > > >> > > > +}
> > > > >> > > > +
> > > > >> > > > static void mvpp2_phylink_validate(struct phylink_config
> > > > >> > > > *config,
> > > > >> > > >unsigned long *supported,
> > > > >> > > >struct phylink_link_state
> > > > >> > > > *state)
> > > > >> > > > {
> > > > >> > > > - struct mvpp2_port *port = container_of(config, struct
> > > > >> > > > mvpp2_port,
> > > > >> > > > - phylink_config);
> > > > >> > > > + struct mvpp2_port *port =
> > > > >> > > > mvpp2_phylink_to_port(config);
> > > > >> > > > __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> > > > >> > > >
> > > > >> > > > /* Invalid combinations */
> > > > >> > > > @@ -4913,8 +4917,7 @@ static void
> > > > >> > > > mvpp2_gmac_pcs_get_state(struct mvpp2_port *port,
> > > > >> > > > static void mvpp2_phylink_mac_pcs_get_state(struct
> > > > >> > > > phylink_config *config,
> > > > >> > > > struct
> > > > >> > > > phylink_link_state *state)
> > > > >> > > > {
> > > > >> > > > - struct mvpp2_port *port = container_of(config, struct
> > > > >> > > > mvpp2_port,
> > > > >> > > > - phylink_config);
> > > > >> > > > + struct mvpp2_port *port =
> > > > >> > > > mvpp2_phylink_to_port(config);
> > > > >> > > >
> > > > >> > > > if (port->priv->hw_version == MVPP22 && port->gop_id
> > > > >> > > > == 0) {
> > > > >> > > > u32 mode = readl(port->base +
> > > > >> > > > MVPP22_XLG_CTRL3_REG);
> > > > >> > > > @@ -4931,8 +4934,7 @@ static void
> > > > >> > > > mvpp2_phylink_mac_pcs_get_state(struct phylink_config *config,
> > > > >> > > >
> > > > >> > > > static void mvpp2_mac_an_restart(struct phylink_config
> > > > >> > > > *config)
> > > > >> > > > {
> > > > >> > > > - struct mvpp2_port *port = container_of(config, struct
> > > > >> > > > mvpp2_port,
> > > > >> > > > - phylink_config);
> > > > >> > > > + struct mvpp2_port *port =
> > > > >> > > > mvpp2_phylink_to_port(config);
> > > > >> > > > u32 val = readl(port->base +
> > > > >> > > > MVPP2_GMAC_AUTONEG_CONFIG);
> > > > >> > > >
> > > > >> > > > writel(val | MVPP2_GMAC_IN_BAND_RESTART_AN,
> > > > >> > > > @@ -5105,13 +5107,12 @@ static void mvpp2_gmac_config(struct
> > > > >> > > > mvpp2_port *port, unsigned int mode,
> > > > >> > > > static void mvpp2_mac_config(struct phylink_config *config,
> > > > >> > > > unsigned int mode,
> > > > >> > > > const struct phylink_link_state
> > > > >> > > > *state)
> > > > >> > > > {
> > > > >> > > > - struct net_device *dev = to_net
Re: [PATCH v5 bpf-next 03/14] xdp: add xdp_shared_info data structure
>
>
> Lorenzo Bianconi writes:
>
> >> On Mon, 2020-12-07 at 17:32 +0100, Lorenzo Bianconi wrote:
> >> > Introduce xdp_shared_info data structure to contain info
> >> > about
> >> > "non-linear" xdp frame. xdp_shared_info will alias
> >> > skb_shared_info
> >> > allowing to keep most of the frags in the same cache-line.
> [...]
> >>
> >> > + u16 nr_frags;
> >> > + u16 data_length; /* paged area length */
> >> > + skb_frag_t frags[MAX_SKB_FRAGS];
> >>
> >> why MAX_SKB_FRAGS ? just use a flexible array member
> >> skb_frag_t frags[];
> >>
> >> and enforce size via the n_frags and on the construction of the
> >> tailroom preserved buffer, which is already being done.
> >>
> >> this is waste of unnecessary space, at lease by definition of
> >> the
> >> struct, in your use case you do:
> >> memcpy(frag_list, xdp_sinfo->frags, sizeof(skb_frag_t) *
> >> num_frags);
> >> And the tailroom space was already preserved for a full
> >> skb_shinfo.
> >> so i don't see why you need this array to be of a fixed
> >> MAX_SKB_FRAGS
> >> size.
> >
> > In order to avoid cache-misses, xdp_shared info is built as a
> > variable
> > on mvneta_rx_swbm() stack and it is written to "shared_info"
> > area only on the
> > last fragment in mvneta_swbm_add_rx_fragment(). I used
> > MAX_SKB_FRAGS to be
> > aligned with skb_shared_info struct but probably we can use even
> > a smaller value.
> > Another approach would be to define two different struct, e.g.
> >
> > stuct xdp_frag_metadata {
> > u16 nr_frags;
> > u16 data_length; /* paged area length */
> > };
> >
> > struct xdp_frags {
> > skb_frag_t frags[MAX_SKB_FRAGS];
> > };
> >
> > and then define xdp_shared_info as
> >
> > struct xdp_shared_info {
> > stuct xdp_frag_metadata meta;
> > skb_frag_t frags[];
> > };
> >
> > In this way we can probably optimize the space. What do you
> > think?
>
> We're still reserving ~sizeof(skb_shared_info) bytes at the end of
> the first buffer and it seems like in mvneta code you keep
> updating all three fields (frags, nr_frags and data_length).
> Can you explain how the space is optimized by splitting the
> structs please?
using xdp_shared_info struct we will have the first 3 fragments in the
same cacheline of nr_frags while using skb_shared_info struct only the
first fragment will be in the same cacheline of nr_frags. Moreover
skb_shared_info has multiple fields unused by xdp.
Regards,
Lorenzo
>
> >>
> >> > +};
> >> > +
> >> > +static inline struct xdp_shared_info *
> >> > xdp_get_shared_info_from_buff(struct xdp_buff *xdp)
> >> > {
> >> > - return (struct skb_shared_info *)xdp_data_hard_end(xdp);
> >> > + BUILD_BUG_ON(sizeof(struct xdp_shared_info) >
> >> > + sizeof(struct skb_shared_info));
> >> > + return (struct xdp_shared_info *)xdp_data_hard_end(xdp);
> >> > +}
> >> > +
> >>
> >> Back to my first comment, do we have plans to use this tail
> >> room buffer
> >> for other than frag_list use cases ? what will be the buffer
> >> format
> >> then ? should we push all new fields to the end of the
> >> xdp_shared_info
> >> struct ? or deal with this tailroom buffer as a stack ?
> >> my main concern is that for drivers that don't support frag
> >> list and
> >> still want to utilize the tailroom buffer for other usecases
> >> they will
> >> have to skip the first sizeof(xdp_shared_info) so they won't
> >> break the
> >> stack.
> >
> > for the moment I do not know if this area is used for other
> > purposes.
> > Do you think there are other use-cases for it?
> >
>
> Saeed, the stack receives skb_shared_info when the frames are
> passed to the stack (skb_add_rx_frag is used to add the whole
> information to skb's shared info), and for XDP_REDIRECT use case,
> it doesn't seem like all drivers check page's tailroom for more
> information anyway (ena doesn't at least).
> Can you please explain what do you mean by "break the stack"?
>
> Thanks, Shay
>
> >>
> [...]
> >
> >>
>
Re: [PATCH v5 bpf-next 11/14] bpf: cpumap: introduce xdp multi-buff support
>
>
> Lorenzo Bianconi writes:
>
> > Introduce __xdp_build_skb_from_frame and
> > xdp_build_skb_from_frame
> > utility routines to build the skb from xdp_frame.
> > Add xdp multi-buff support to cpumap
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > include/net/xdp.h | 5
> > kernel/bpf/cpumap.c | 45 +---
> > net/core/xdp.c | 73
> > +
> > 3 files changed, 79 insertions(+), 44 deletions(-)
> >
> [...]
> > diff --git a/net/core/xdp.c b/net/core/xdp.c
> > index 6c8e743ad03a..55f3e9c69427 100644
> > --- a/net/core/xdp.c
> > +++ b/net/core/xdp.c
> > @@ -597,3 +597,76 @@ void xdp_warn(const char *msg, const char
> > *func, const int line)
> > WARN(1, "XDP_WARN: %s(line:%d): %s\n", func, line, msg);
> > };
> > EXPORT_SYMBOL_GPL(xdp_warn);
> > +
> > +struct sk_buff *__xdp_build_skb_from_frame(struct xdp_frame
> > *xdpf,
> > +struct sk_buff *skb,
> > +struct net_device *dev)
> > +{
> > + unsigned int headroom = sizeof(*xdpf) + xdpf->headroom;
> > + void *hard_start = xdpf->data - headroom;
> > + skb_frag_t frag_list[MAX_SKB_FRAGS];
> > + struct xdp_shared_info *xdp_sinfo;
> > + int i, num_frags = 0;
> > +
> > + xdp_sinfo = xdp_get_shared_info_from_frame(xdpf);
> > + if (unlikely(xdpf->mb)) {
> > + num_frags = xdp_sinfo->nr_frags;
> > + memcpy(frag_list, xdp_sinfo->frags,
> > +sizeof(skb_frag_t) * num_frags);
> > + }
>
> nit, can you please move the xdp_sinfo assignment inside this 'if'
> ? This would help to emphasize that regarding xdp_frame tailroom
> as xdp_shared_info struct (rather than skb_shared_info) is correct
> only when the mb bit is set
>
> thanks,
> Shay
ack, will do in v6.
Regards,
Lorenzo
>
> > +
> > + skb = build_skb_around(skb, hard_start, xdpf->frame_sz);
> > + if (unlikely(!skb))
> > + return NULL;
> [...]
>
Re: [PATCH v5 bpf-next 06/14] net: mvneta: add multi buffer support to XDP_TX
On Sat, Dec 19, 2020 at 4:56 PM Shay Agroskin wrote:
>
>
> Lorenzo Bianconi writes:
>
> > Introduce the capability to map non-linear xdp buffer running
> > mvneta_xdp_submit_frame() for XDP_TX and XDP_REDIRECT
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > drivers/net/ethernet/marvell/mvneta.c | 94
> > ---
> > 1 file changed, 56 insertions(+), 38 deletions(-)
> [...]
> > if (napi && buf->type ==
> > MVNETA_TYPE_XDP_TX)
> > xdp_return_frame_rx_napi(buf->xdpf);
> > else
> > @@ -2054,45 +2054,64 @@ mvneta_xdp_put_buff(struct mvneta_port
> > *pp, struct mvneta_rx_queue *rxq,
> >
> > static int
> > mvneta_xdp_submit_frame(struct mvneta_port *pp, struct
> > mvneta_tx_queue *txq,
> > - struct xdp_frame *xdpf, bool dma_map)
> > + struct xdp_frame *xdpf, int *nxmit_byte,
> > bool dma_map)
> > {
> > - struct mvneta_tx_desc *tx_desc;
> > - struct mvneta_tx_buf *buf;
> > - dma_addr_t dma_addr;
> > + struct xdp_shared_info *xdp_sinfo =
> > xdp_get_shared_info_from_frame(xdpf);
> > + int i, num_frames = xdpf->mb ? xdp_sinfo->nr_frags + 1 :
> > 1;
> > + struct mvneta_tx_desc *tx_desc = NULL;
> > + struct page *page;
> >
> > - if (txq->count >= txq->tx_stop_threshold)
> > + if (txq->count + num_frames >= txq->size)
> > return MVNETA_XDP_DROPPED;
> >
> > - tx_desc = mvneta_txq_next_desc_get(txq);
> > + for (i = 0; i < num_frames; i++) {
> > + struct mvneta_tx_buf *buf =
> > &txq->buf[txq->txq_put_index];
> > + skb_frag_t *frag = i ? &xdp_sinfo->frags[i - 1] :
> > NULL;
> > + int len = frag ? xdp_get_frag_size(frag) :
> > xdpf->len;
>
> nit, from branch prediction point of view, maybe it would be
> better to write
> int len = i ? xdp_get_frag_size(frag) : xdpf->len;
>
ack, I will fix it in v6.
Regards,
Lorenzo
> since the value of i is checked one line above
> Disclaimer: I'm far from a compiler expert, and don't know whether
> the compiler would know to group these two assignments together
> into a single branch prediction decision, but it feels like using
> 'i' would make this decision easier for it.
>
> Thanks,
> Shay
>
> [...]
>
WARNING in isotp_tx_timer_handler
Hello, syzbot found the following issue on: HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=179a228750 kernel config: https://syzkaller.appspot.com/x/.config?x=db720fe37a6a41d8 dashboard link: https://syzkaller.appspot.com/bug?extid=78bab6958a614b0c80b9 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10ea3e0f50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+78bab6958a614b0c8...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 0 PID: 9908 at net/can/isotp.c:835 isotp_tx_timer_handler+0x65f/0xba0 net/can/isotp.c:835 Modules linked in: CPU: 0 PID: 9908 Comm: systemd-udevd Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:isotp_tx_timer_handler+0x65f/0xba0 net/can/isotp.c:835 Code: c1 e8 03 83 e1 07 0f b6 04 28 38 c8 7f 08 84 c0 0f 85 b8 04 00 00 41 88 54 24 05 e9 07 fb ff ff 40 84 ed 75 21 e8 21 11 80 f9 <0f> 0b 45 31 e4 e8 17 11 80 f9 44 89 e0 48 83 c4 48 5b 5d 41 5c 41 RSP: 0018:c9007dc8 EFLAGS: 00010246 RAX: RBX: 88803e4e8518 RCX: 0100 RDX: 8880117d5040 RSI: 87f2102f RDI: 0003 RBP: R08: 8a7b6540 R09: 87f20a2e R10: 0003 R11: R12: R13: 8880b9c26c80 R14: 8880b9c26a00 R15: 88803e4e8000 FS: 7fc247dbb8c0() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7ffcab7e7800 CR3: 1c8c6000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __run_hrtimer kernel/time/hrtimer.c:1519 [inline] __hrtimer_run_queues+0x609/0xea0 kernel/time/hrtimer.c:1583 hrtimer_run_softirq+0x17b/0x360 kernel/time/hrtimer.c:1600 __do_softirq+0x2bc/0xa77 kernel/softirq.c:343 asm_call_irq_on_stack+0xf/0x20 __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline] do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77 invoke_softirq kernel/softirq.c:226 [inline] __irq_exit_rcu+0x17f/0x200 kernel/softirq.c:420 irq_exit_rcu+0x5/0x20 kernel/softirq.c:432 sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1096 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:628 RIP: 0010:call_rcu+0x2e7/0x710 kernel/rcu/tree.c:3039 Code: 3c 02 00 0f 85 bb 03 00 00 48 8b 05 63 75 1a 0a 49 03 84 24 f0 00 00 00 49 39 c7 0f 8f 72 01 00 00 e8 5d e4 18 00 ff 34 24 9d <48> 83 c4 20 5b 5d 41 5c 41 5d 41 5e 41 5f c3 80 3c 02 00 0f 84 2f RSP: 0018:c9000adafb88 EFLAGS: 0246 RAX: 10e9 RBX: 8880143c1780 RCX: 815740d7 RDX: RSI: RDI: RBP: 8880b9c35b70 R08: 0001 R09: 8f4f983f R10: fbfff1e9f307 R11: R12: 8880b9c35a80 R13: 8880b9c35b60 R14: 8880b9c35b18 R15: 002c security_inode_free+0x9a/0xc0 security/security.c:1005 __destroy_inode+0x24d/0x740 fs/inode.c:259 destroy_inode+0x91/0x1b0 fs/inode.c:282 iput_final fs/inode.c:1654 [inline] iput.part.0+0x41e/0x840 fs/inode.c:1680 iput+0x58/0x70 fs/inode.c:1670 dentry_unlink_inode+0x2b1/0x3d0 fs/dcache.c:374 __dentry_kill+0x3c0/0x640 fs/dcache.c:579 dentry_kill fs/dcache.c:717 [inline] dput+0x696/0xc10 fs/dcache.c:878 do_renameat2+0xae7/0xbf0 fs/namei.c:4461 __do_sys_rename fs/namei.c:4503 [inline] __se_sys_rename fs/namei.c:4501 [inline] __x64_sys_rename+0x5d/0x80 fs/namei.c:4501 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc246bb7d47 Code: 75 12 48 89 df e8 19 84 07 00 85 c0 0f 95 c0 0f b6 c0 f7 d8 5b c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 52 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 21 41 33 00 f7 d8 64 89 01 48 RSP: 002b:7ffcab6e3c68 EFLAGS: 0246 ORIG_RAX: 0052 RAX: ffda RBX: 5556c8f7a380 RCX: 7fc246bb7d47 RDX: RSI: 7ffcab6e3c70 RDI: 5556c8f823b0 RBP: 7ffcab6e3d30 R08: 5556c8f812c0 R09: 5556c8f811e0 R10: 7fc247dbb8c0 R11: 0246 R12: 7ffcab6e3c70 R13: 0001 R14: 5556c71306cb R15: --- 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-pa
Re: UBSAN: object-size-mismatch in wg_xmit
Hmm, on first glance, I'm not sure I'm seeing the bug:
On Sun, Dec 20, 2020 at 5:54 PM syzbot
wrote:
> UBSAN: object-size-mismatch in ./include/linux/skbuff.h:2021:28
> member access within address 85889cc2 with insufficient space
> for an object of type 'struct sk_buff'
> __skb_queue_before include/linux/skbuff.h:2021 [inline]
> __skb_queue_tail include/linux/skbuff.h:2054 [inline]
> wg_xmit+0x45d/0xdf0 drivers/net/wireguard/device.c:182
The code in question is:
struct sk_buff_head packets;
__skb_queue_head_init(&packets);
...
skb_list_walk_safe(skb, skb, next) {
skb_mark_not_on_list(skb);
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
continue;
...
__skb_queue_tail(&packets, skb);
}
We're in a netdev's xmit function, so nothing else should have skb at
that point. Given the warning is about "member access", I assume it's
the next->prev dereference here:
static inline void __skb_queue_before(struct sk_buff_head *list,
struct sk_buff *next,
struct sk_buff *newsk)
{
__skb_insert(newsk, next->prev, next, list);
}
So where is "next" coming from that UBSAN would complain about
object-size-mismatch?
static inline void __skb_queue_tail(struct sk_buff_head *list,
struct sk_buff *newsk)
{
__skb_queue_before(list, (struct sk_buff *)list, newsk);
}
It comes from casting "list" into an sk_buff. While this might be some
CFI-violating polymorphism, I can't see why this cast would actually
be a problem in practice. The top of sk_buff is intentionally the same
as sk_buff_head:
struct sk_buff_head {
struct sk_buff *next;
struct sk_buff *prev;
...
struct sk_buff {
union {
struct {
struct sk_buff *next;
struct sk_buff *prev;
...
I'd suspect, "oh maybe it's just a clang 11 bug", but syzbot says it
can't reproduce. So that makes me a little more nervous.
Does anybody see something I've missed?
Jason
Re: [PATCH 0/3] mwifiex: disable ps_mode by default for stability
Hello! Please CC me in future for mwifiex discussion :-) On Wednesday 28 October 2020 23:24:30 Tsuchiya Yuto wrote: > Hello all, > > On Microsoft Surface devices (PCIe-88W8897), we are observing stability > issues when ps_mode (IEEE power_save) is enabled, then eventually causes > firmware crash. Especially on 5GHz APs, the connection is completely > unstable and almost unusable. > > I think the most desirable change is to fix the ps_mode itself. But is > seems to be hard work [1], I'm afraid we have to go this way. > > Therefore, the first patch of this series disables the ps_mode by default > instead of enabling it on driver init. I'm not sure if explicitly > disabling it is really required or not. I don't have access to the details > of this chip. Let me know if it's enough to just remove the code that > enables ps_mode. > > The Second patch adds a new module parameter named "allow_ps_mode". Since > other wifi drivers just disable power_save by default by module parameter > like this, I also added this. > > The third patch adds a message when ps_mode will be changed. Useful when > diagnosing connection issues. There are more issues with power save API and implementation in mwifiex. See my email for more details: https://lore.kernel.org/linux-wireless/20200609111544.v7u5ort3yk4s7coy@pali/T/#u These patches would just break power save API and reporting status to userspace even more due to WIPHY_FLAG_PS_ON_BY_DEFAULT and CONFIG_CFG80211_DEFAULT_PS options. I would suggest to first fix issues mentioned in my email and then start providing a way how to blacklist or whitelist power save feature depending on firmware or card/chip version. >From my experience I know that e.g. 88W8997 cards have lot of bugs in their firmware and I'm not aware that bugs are going to be fixed... So we really need workarounds, like disabling power save mode to have cards usable. > Thanks, > Tsuchiya Yuto > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=109681 > > Tsuchiya Yuto (3): > mwifiex: disable ps_mode explicitly by default instead > mwifiex: add allow_ps_mode module parameter > mwifiex: print message when changing ps_mode > > .../net/wireless/marvell/mwifiex/cfg80211.c | 23 +++ > .../net/wireless/marvell/mwifiex/sta_cmd.c| 11 ++--- > 2 files changed, 31 insertions(+), 3 deletions(-) > > -- > 2.29.1 >
Re: [RFC PATCH v2 4/8] net: sparx5: add port module support
> + /* Aneg complete provides more information */
> + if (DEV2G5_PCS1G_ANEG_STATUS_ANEG_COMPLETE_GET(value)) {
> + if (port->conf.portmode == PHY_INTERFACE_MODE_SGMII) {
> + /* SGMII cisco aneg */
> + u32 spdvalue = ((lp_abil >> 10) & 3);
u32 spdvalue = lp_abil & LPA_SGMII_SPD_MASK;
> +
> + status->link = !!((lp_abil >> 15) == 1) && status->link;
Maybe
status->link = !!((lp_abil & LPA_SGMII_LINK) &&
status->link;
> + status->an_complete = true;
> + status->duplex = (lp_abil >> 12) & 0x1 ? DUPLEX_FULL :
> DUPLEX_HALF;
status->duplex = (lp_abil & LPA_SGMII_FULL_DUPLEX) ?
DUPLEX_FULL : DUPLEX_HALF;
> + if (spdvalue == LPA_SGMII_10)
> + status->speed = SPEED_10;
> + else if (spdvalue == LPA_SGMII_100)
> + status->speed = SPEED_100;
> + else
> + status->speed = SPEED_1000;
I wonder if there is a helper for this?
> + } else {
> + /* Clause 37 Aneg */
> + status->link = !((lp_abil >> 12) & 3) && status->link;
> + status->an_complete = true;
> + status->duplex = ((lp_abil >> 5) & 1) ? DUPLEX_FULL :
> DUPLEX_UNKNOWN;
> + if ((lp_abil >> 8) & 1) /* symmetric pause */
> + status->pause = MLO_PAUSE_RX | MLO_PAUSE_TX;
> + if (lp_abil & (1 << 7)) /* asymmetric pause */
> + status->pause |= MLO_PAUSE_RX;
> + }
Please check if there are any standard #defines you can use for
this. Russell King has done some work for clause 37. Maybe there is
some code in phy_driver.c you can use? phylink_decode_sgmii_word()
> +static int sparx5_port_verify_speed(struct sparx5 *sparx5,
> + struct sparx5_port *port,
> + struct sparx5_port_config *conf)
> +{
> + case PHY_INTERFACE_MODE_SGMII:
> + if (conf->speed != SPEED_1000 &&
> + conf->speed != SPEED_100 &&
> + conf->speed != SPEED_10 &&
> + conf->speed != SPEED_2500)
> + return sparx5_port_error(port, conf, SPX5_PERR_SPEED);
Is it really SGMII over clocked at 2500? Or 2500BaseX?
> +static int sparx5_port_fifo_sz(struct sparx5 *sparx5,
> +u32 portno, u32 speed)
> +{
> + u32 sys_clk= sparx5_clk_period(sparx5->coreclock);
> + u32 mac_width = 8;
> + u32 fifo_width = 16;
> + u32 addition = 0;
> + u32 mac_per= 6400, tmp1, tmp2, tmp3;
> + u32 taxi_dist[SPX5_PORTS_ALL] = {
const. As it is at the moment, it gets copied onto the stack, so it
can be modified. Const i guess prevents that copy?
> + 6, 8, 10, 6, 8, 10, 6, 8, 10, 6, 8, 10,
> + 4, 4, 4, 4,
> + 11, 12, 13, 14, 15, 16, 17, 18,
> + 11, 12, 13, 14, 15, 16, 17, 18,
> + 11, 12, 13, 14, 15, 16, 17, 18,
> + 11, 12, 13, 14, 15, 16, 17, 18,
> + 4, 6, 8, 4, 6, 8, 6, 8,
> + 2, 2, 2, 2, 2, 2, 2, 4, 2
> + };
> +static int sparx5_port_fwd_urg(struct sparx5 *sparx5, u32 speed)
What is urg?
> +static u16 sparx5_get_aneg_word(struct sparx5_port_config *conf)
> +{
> + if (conf->portmode == PHY_INTERFACE_MODE_1000BASEX) /* cl-37 aneg */
> + return ((1 << 14) | /* ack */
> + ((conf->pause ? 1 : 0) << 8) | /* asymmetric pause */
> + ((conf->pause ? 1 : 0) << 7) | /* symmetric pause */
> + (1 << 5)); /* FDX only */
ADVERTISE_LPACK, ADVERTISE_PAUSE_ASYM, ADVERTISE_PAUSE_CAP, ADVERTISE_1000XFULL?
> +int sparx5_port_config(struct sparx5 *sparx5,
> +struct sparx5_port *port,
> +struct sparx5_port_config *conf)
> +{
> + bool high_speed_dev = sparx5_is_high_speed_device(conf);
> + int err, urgency, stop_wm;
> +
> + err = sparx5_port_verify_speed(sparx5, port, conf);
> + if (err)
> + return err;
> +
> + /* high speed device is already configured */
> + if (!high_speed_dev)
> + sparx5_port_config_low_set(sparx5, port, conf);
> +
> + /* Configure flow control */
> + err = sparx5_port_fc_setup(sparx5, port, conf);
> + if (err)
> + return err;
> +
> + /* Set the DSM stop watermark */
> + stop_wm = sparx5_port_fifo_sz(sparx5, port->portno, conf->speed);
> + spx5_rmw(DSM_DEV_TX_STOP_WM_CFG_DEV_TX_STOP_WM_SET(stop_wm),
> + DSM_DEV_TX_STOP_WM_CFG_DEV_TX_STOP_WM,
> + sparx5,
> + DSM_DEV_TX_STOP_WM_CFG(port->portno));
> +
> + /* Enable port forwarding */
> + urgency = sparx5_port_fwd_urg(sparx5, co
Re: [RFC PATCH v2 5/8] net: sparx5: add switching, vlan and mactable support
> +++ b/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
> +
> +static inline int sparx5_mact_get_status(struct sparx5 *sparx5)
> +{
> + return spx5_rd(sparx5, LRN_COMMON_ACCESS_CTRL);
> +}
> +
> +static inline int sparx5_mact_wait_for_completion(struct sparx5 *sparx5)
> +{
> + u32 val;
> +
> + return readx_poll_timeout(sparx5_mact_get_status,
> + sparx5, val,
> + LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_GET(val) == 0,
> + TABLE_UPDATE_SLEEP_US, TABLE_UPDATE_TIMEOUT_US);
> +}
No inline functions in C files please.
> +void sparx5_mact_init(struct sparx5 *sparx5)
> +{
> + mutex_init(&sparx5->lock);
> +
> + mutex_lock(&sparx5->lock);
> +
> + /* Flush MAC table */
> + spx5_wr(LRN_COMMON_ACCESS_CTRL_CPU_ACCESS_CMD_SET(MAC_CMD_CLEAR_ALL) |
> + LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_SET(1),
> + sparx5, LRN_COMMON_ACCESS_CTRL);
> +
> + if (sparx5_mact_wait_for_completion(sparx5) != 0)
> + dev_warn(sparx5->dev, "MAC flush error\n");
> +
> + mutex_unlock(&sparx5->lock);
It always seems odd to me, when you initialise a mutex, and then
immediately take it. Who are you locking against? I'm not saying it is
wrong though, especially if you have code in spx5_wr() and spx5_rd()
which check the lock is actually taken. I've found a number of locking
bugs in mv88e6xxx by having such checks.
> +
> + sparx5_set_ageing(sparx5, 10 * MSEC_PER_SEC); /* 10 sec */
BR_DEFAULT_AGEING_TIME is 300 seconds. Is this the same thing?
> +static int sparx5_port_bridge_join(struct sparx5_port *port,
> +struct net_device *bridge)
> +{
> + struct sparx5 *sparx5 = port->sparx5;
> +
> + if (bitmap_empty(sparx5->bridge_mask, SPX5_PORTS))
> + /* First bridged port */
> + sparx5->hw_bridge_dev = bridge;
> + else
> + if (sparx5->hw_bridge_dev != bridge)
> + /* This is adding the port to a second bridge, this is
> + * unsupported
> + */
> + return -ENODEV;
Just checking my understanding. You have a 64 port switch, which only
supports a single bridge?
-EOPNOTSUPP seems like a better return code.
> +
> + set_bit(port->portno, sparx5->bridge_mask);
> +
> + /* Port enters in bridge mode therefor don't need to copy to CPU
> + * frames for multicast in case the bridge is not requesting them
> + */
> + __dev_mc_unsync(port->ndev, sparx5_mc_unsync);
Did you copy that from the mellanox driver? I think in DSA we take the
opposite approach. Multicast/broadcast goes to the CPU until the CPU
says it does not want it.
> +static void sparx5_port_bridge_leave(struct sparx5_port *port,
> + struct net_device *bridge)
> +{
> + struct sparx5 *sparx5 = port->sparx5;
> +
> + clear_bit(port->portno, sparx5->bridge_mask);
> + if (bitmap_empty(sparx5->bridge_mask, SPX5_PORTS))
> + sparx5->hw_bridge_dev = NULL;
> +
> + /* Clear bridge vlan settings before updating the port settings */
> + port->vlan_aware = 0;
> + port->pvid = NULL_VID;
> + port->vid = NULL_VID;
> +
> + /* Port enters in host more therefore restore mc list */
s/more/mode
> +++ b/drivers/net/ethernet/microchip/sparx5/sparx5_vlan.c
> @@ -0,0 +1,223 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Microchip Sparx5 Switch driver
> + *
> + * Copyright (c) 2020 Microchip Technology Inc. and its subsidiaries.
> + */
> +
> +#include "sparx5_main.h"
> +
> +static int sparx5_vlant_set_mask(struct sparx5 *sparx5, u16 vid)
Is the t in vlant typ0?
> +int sparx5_vlan_vid_add(struct sparx5_port *port, u16 vid, bool pvid,
> + bool untagged)
> +{
> + struct sparx5 *sparx5 = port->sparx5;
> + int ret;
> +
> + /* Make the port a member of the VLAN */
> + set_bit(port->portno, sparx5->vlan_mask[vid]);
> + ret = sparx5_vlant_set_mask(sparx5, vid);
> + if (ret)
> + return ret;
> +
> + /* Default ingress vlan classification */
> + if (pvid)
> + port->pvid = vid;
> +
> + /* Untagged egress vlan clasification */
classification
> + if (untagged && port->vid != vid) {
> + if (port->vid) {
> + netdev_err(port->ndev,
> +"Port already has a native VLAN: %d\n",
> +port->vid);
> + return -EBUSY;
> + }
> + port->vid = vid;
> + }
> +
> + sparx5_vlan_port_apply(sparx5, port);
> +
> + return 0;
> +}
> +void sparx5_update_fwd(struct sparx5 *sparx5)
> +{
> + u32 mask[3];
> + DECLARE_BITMAP(workmask, SPX5_PORTS);
> + int port;
> +
> + /* Divide up fwd mask in 32 bit words */
> + bitmap_to_arr32(mask, sparx5->bridge_fwd_mask, SPX5_PORTS);
> +
> + /* Update flood masks */
> + for (port = PGI
Re: linux-next: build warnings after merge of the net-next tree
Hi all,
On Mon, 14 Dec 2020 20:10:25 +1100 Stephen Rothwell
wrote:
>
> After merging the net-next tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on line 1759 - I thought it was a doc line
> include/net/cfg80211.h:5073: warning: Function parameter or member 'sar_capa'
> not described in 'wiphy'
>
> Introduced by commit
>
> 6bdb68cef7bf ("nl80211: add common API to configure SAR power limitations")
I am now getting these warnings from Linus' tree.
--
Cheers,
Stephen Rothwell
pgptLLjvA8yT1.pgp
Description: OpenPGP digital signature
Re: [kbuild-all] Re: [PATCH net 1/4] net-sysfs: take the rtnl lock when storing xps_cpus
On Fri, Dec 18, 2020 at 05:11:28PM +0100, Antoine Tenart wrote: > That build issue seems unrelated to the patch. The series as a whole > builds fine according to the same report, and this code is not modified > by later patches. Hi Antoine, this is a false positive report, kindly ignore this. Sorry for inconvenience. > > It looks a lot like this report from yesterday: > https://www.spinics.net/lists/netdev/msg709132.html > > Which also seemed unrelated to the changes: > https://www.spinics.net/lists/netdev/msg709264.html > > Thanks! > Antoine > > Quoting kernel test robot (2020-12-18 16:27:46) > > Hi Antoine, > > > > I love your patch! Yet something to improve: > > > > [auto build test ERROR on net/master] > > > > url: > > https://github.com/0day-ci/linux/commits/Antoine-Tenart/net-sysfs-fix-race-conditions-in-the-xps-code/20201218-002852 > > base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git > > 3ae32c07815a24ae12de2e7838d9d429ba31e5e0 > > config: riscv-randconfig-r014-20201217 (attached as .config) > > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project > > cee1e7d14f4628d6174b33640d502bff3b54ae45) > > reproduce (this is a W=1 build): > > wget > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > > ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # install riscv cross compiling tool for clang build > > # apt-get install binutils-riscv64-linux-gnu > > # > > https://github.com/0day-ci/linux/commit/f989c3dcbe4d9abd1c6c48b34f08c6c0cd9d44b3 > > git remote add linux-review https://github.com/0day-ci/linux > > git fetch --no-tags linux-review > > Antoine-Tenart/net-sysfs-fix-race-conditions-in-the-xps-code/20201218-002852 > > git checkout f989c3dcbe4d9abd1c6c48b34f08c6c0cd9d44b3 > > # save the attached .config to linux build tree > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross > > ARCH=riscv > > > > If you fix the issue, kindly add following tag as appropriate > > Reported-by: kernel test robot > > > > Note: the > > linux-review/Antoine-Tenart/net-sysfs-fix-race-conditions-in-the-xps-code/20201218-002852 > > HEAD 563d144b47845dea594b409ecf22914b9797cd1e builds fine. > > It only hurts bisectibility. > > > > All errors (new ones prefixed by >>): > > > >/tmp/ics932s401-422897.s: Assembler messages: > > >> /tmp/ics932s401-422897.s:260: Error: unrecognized opcode `zext.b a1,s11' > >/tmp/ics932s401-422897.s:362: Error: unrecognized opcode `zext.b a1,s11' > >/tmp/ics932s401-422897.s:518: Error: unrecognized opcode `zext.b a1,s11' > >/tmp/ics932s401-422897.s:637: Error: unrecognized opcode `zext.b a1,s11' > >/tmp/ics932s401-422897.s:774: Error: unrecognized opcode `zext.b a1,s11' > >/tmp/ics932s401-422897.s:893: Error: unrecognized opcode `zext.b a1,s11' > >/tmp/ics932s401-422897.s:1021: Error: unrecognized opcode `zext.b a1,s11' > > >> /tmp/ics932s401-422897.s:1180: Error: unrecognized opcode `zext.b a1,s2' > >clang-12: error: assembler command failed with exit code 1 (use -v to > > see invocation) > > > > --- > > 0-DAY CI Kernel Test Service, Intel Corporation > > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org > ___ > kbuild-all mailing list -- kbuild-...@lists.01.org > To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [RFC PATCH v2 1/8] dt-bindings: net: sparx5: Add sparx5-switch bindings
On 12/16/2020 11:51 PM, Steen Hegelund wrote: > Document the Sparx5 switch device driver bindings > > Signed-off-by: Steen Hegelund > Signed-off-by: Lars Povlsen > --- [snip] > + max-speed: > +maxItems: 1 > +description: Bandwidth allocated to this port > + > + phys: > +description: phandle of a Ethernet Serdes PHY > + > + phy-handle: > +description: phandle of a Ethernet PHY > + > + phy-mode: > +description: Interface between the serdes and the phy Can you specify this pertains to the Serdes and Ethernet PHY? -- Florian
Fw: [Bug 210781] New: Tun.c fails with tc mirror when using bridges
Begin forwarded message: Date: Fri, 18 Dec 2020 23:24:31 + From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 210781] New: Tun.c fails with tc mirror when using bridges https://bugzilla.kernel.org/show_bug.cgi?id=210781 Bug ID: 210781 Summary: Tun.c fails with tc mirror when using bridges Product: Networking Version: 2.5 Kernel Version: 5.4.78 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other Assignee: step...@networkplumber.org Reporter: pablo.catal...@gmail.com Regression: No Hi, I got a kernel panic and after reboot I tried again and I got the following error: [17665.950212] u32 classifier [17665.950247] input device check on [17665.950278] Actions configured [17665.993688] Mirror/redirect action on [17673.994202] tun: unexpected GSO type: 0x0, gso_size 289, hdr_len 355 [17673.994242] tun: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [17673.994288] tun: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [17673.994333] tun: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [17673.994378] tun: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [17673.994432] [ cut here ] [17673.994479] WARNING: CPU: 7 PID: 4700 at drivers/net/tun.c:2129 tun_do_read+0x535/0x6d0 [17673.994525] Modules linked in: sch_prio act_mirred cls_u32 sch_ingress iptable_mangle xt_TEE nf_dup_ipv6 nf_dup_ipv4 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio veth nfsv3 rpcsec_gss_krb5 nfsv4 nfs fscache ebtable_filter ebtables ip6table_raw ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables iptable_raw ipt_REJECT nf_reject_ipv4 xt_NFLOG xt_set xt_physdev xt_addrtype xt_multiport xt_conntrack xt_mark ip_set_hash_net ip_set sctp iptable_filter xt_nat xt_tcpudp xt_MASQUERADE xt_comment iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter bonding zram softdog nfnetlink_log nfnetlink binfmt_misc i915 intel_rapl_msr intel_rapl_common drm_kms_helper drm x86_pkg_temp_thermal intel_powerclamp i2c_algo_bit coretemp fb_sys_fops syscopyarea sysfillrect sysimgblt dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio kvm_intel kvm snd_hda_intel snd_intel_dspcfg irqbypass snd_hda_codec snd_hda_core crct10dif_pclmul snd_hwdep crc32_pclmul snd_pcm ghash_clmulni_intel [17673.994547] aesni_intel ie31200_edac snd_timer snd crypto_simd eeepc_wmi cryptd soundcore input_leds glue_helper rapl mac_hid asus_wmi intel_cstate sparse_keymap serio_raw wmi_bmof vhost_net vhost tap ib_iser nfsd auth_rpcgss nfs_acl lockd rdma_cm iw_cm ib_cm grace ib_core sunrpc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear ahci xhci_pci i2c_i801 libahci lpc_ich e1000e xhci_hcd ehci_pci ehci_hcd megaraid_sas wmi video [17673.994984] CPU: 7 PID: 4700 Comm: vhost-4644 Not tainted 5.4.78-2-pve #1 [17673.995022] Hardware name: System manufacturer System Product Name/P8B WS, BIOS 9922 06/20/2019 [17673.995075] RIP: 0010:tun_do_read+0x535/0x6d0 [17673.995113] Code: 00 00 6a 01 0f b7 45 aa b9 10 00 00 00 48 c7 c6 f4 63 40 8a 48 c7 c7 ff 5c 35 8a 83 f8 40 48 0f 4f c2 31 d2 50 e8 6b c7 d5 ff <0f> 0b 58 5a 49 c7 c4 ea ff ff ff e9 c2 fc ff ff 4c 89 ea be 04 00 [17673.995187] RSP: 0018:ac334350bc80 EFLAGS: 00010246 [17673.995224] RAX: RBX: 992cb1941600 RCX: 0006 [17673.995263] RDX: RSI: 0096 RDI: 992d1f3d78c0 [17673.995303] RBP: ac334350bd08 R08: 0643 R09: 8abb56ec [17673.995342] R10: 072e R11: ac334350ba08 R12: 016f [17673.995381] R13: ac334350be30 R14: 992b7bd548c0 R15: [17673.995421] FS: () GS:992d1f3c() knlGS: [17673.996652] CS: 0010 DS: ES: CR0: 80050033 [17673.996688] CR2: 7f9a5458ad38 CR3: 0006969bc003 CR4: 001626e0 [17673.996726] Call Trace: [17673.996763] tun_recvmsg+0x76/0x110 [17673.996799] handle_rx+0x5d4/0xa20 [vhost_net] [17673.996837] handle_rx_net+0x15/0x20 [vhost_net] [17673.996873] vhost_worker+0xba/0x110 [vhost] [17673.996910] kthread+0x120/0x140 [17673.996944] ? log_used.part.45+0x20/0x20 [vhost] [17673.996980] ? kthread_park+0x90/0x90 [17673.997015] ret_from_fork+0x35/0x40 [17673.997049] ---[ end trace dc2c3635b10ec80e ]--- [17674.304983] tun: unexpected GSO type: 0x0, gso_size 91, hdr_len 157 [17674.305024] tun: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [17674.305070] tun: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [17674.305116] tun: 00 00 0
[ANNOUNCE] iproute2-5.10
Just in time for the holidays, new iproute2! This update is smaller than usual, not a lot of new features. It does NOT include libbpf, that will be merged in 5.11 (iproute2-next). Download: https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-5.10.0.tar.gz Repository for upcoming release: git://git.kernel.org/pub/scm/network/iproute2/iproute2.git And future release (net-next): git://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git Thanks for all the contributions. Report problems (or enhancements) to the netdev@vger.kernel.org mailing list. --- Andrea Claudi (4): man: tc-flower: fix manpage devlink: fix memory leak in cmd_dev_flash() tc: pedit: fix memory leak in print_pedit ss: mptcp: fix add_addr_accepted stat print Antony Antony (2): ip xfrm: support printing XFRMA_SET_MARK_MASK attribute in states ip xfrm: support setting XFRMA_SET_MARK_MASK attribute in states Ciara Loftus (1): ss: add support for xdp statistics David Ahern (5): Update kernel headers Update kernel headers Update kernel headers Update kernel headers Update kernel headers Guillaume Nault (5): m_vlan: add pop_eth and push_eth actions m_mpls: add mac_push action m_mpls: test the 'mac_push' action after 'modify' tc-vlan: fix help and error message strings tc-mpls: fix manpage example and help message string Hoang Le (1): tipc: support 128bit node identity for peer removing Jacob Keller (2): devlink: support setting the overwrite mask attribute devlink: display elapsed time during flash update Jakub Kicinski (1): ip: promote missed packets to the -s row Jiri Pirko (1): devlink: Add health reporter test command support Johannes Berg (5): libnetlink: add rtattr_for_each_nested() iteration macro libnetlink: add nl_print_policy() helper genl: ctrl: support dumping netlink policy genl: ctrl: print op -> policy idx mapping libnetlink: define __aligned conditionally Luca Boccassi (2): ip/netns: use flock when setting up /run/netns tc/mqprio: json-ify output Nikolay Aleksandrov (6): bridge: mdb: add support for source address bridge: mdb: print fast_leave flag bridge: mdb: show igmpv3/mldv2 flags bridge: mdb: print filter mode when available bridge: mdb: print source list when available bridge: mdb: print protocol when available Parav Pandit (2): devlink: Show external port attribute devlink: Show controller number of a devlink port Roopa Prabhu (1): iplink: add support for protodown reason Stephen Hemminger (15): v5.9.0 uapi: updates from 5.10-rc1 tc/m_gate: fix spelling errors man: fix spelling errors rdma: fix spelling error in comment uapi: update kernel headers from 5.10-rc2 bridge: report correct version devlink: fix uninitialized warning bridge: fix string length warning tc: fix compiler warnings in ip6 pedit misc: fix compiler warning in ifstat and nstat f_u32: fix compiler gcc-10 compiler warning uapi: update devlink.h uapi: update devlink.h uapi: merge in change to bpf.h Tuong Lien (2): tipc: add option to set master key for encryption tipc: add option to set rekeying for encryption Wei Wang (1): iproute2: ss: add support to expose various inet sockopts
Re: [RFC PATCH net-next 3/4] net: systemport: use standard netdevice notifier to detect DSA presence
On 12/19/2020 4:12 AM, Vladimir Oltean wrote:
> On Fri, Dec 18, 2020 at 08:08:56PM -0800, Florian Fainelli wrote:
>> On 12/18/2020 2:38 PM, Vladimir Oltean wrote:
>>> The SYSTEMPORT driver maps each port of the embedded Broadcom DSA switch
>>> port to a certain queue of the master Ethernet controller. For that it
>>> currently uses a dedicated notifier infrastructure which was added in
>>> commit 60724d4bae14 ("net: dsa: Add support for DSA specific notifiers").
>>>
>>> However, since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the
>>> DSA master to get rid of lockdep warnings"), DSA is actually an upper of
>>> the Broadcom SYSTEMPORT as far as the netdevice adjacency lists are
>>> concerned. So naturally, the plain NETDEV_CHANGEUPPER net device notifiers
>>> are emitted. It looks like there is enough API exposed by DSA to the
>>> outside world already to make the call_dsa_notifiers API redundant. So
>>> let's convert its only user to plain netdev notifiers.
>>>
>>> Signed-off-by: Vladimir Oltean
>>
>> The CHANGEUPPER has a slightly different semantic than the current DSA
>> notifier, and so events that would look like this during
>> bcm_sysport_init_tx_ring() (good):
>>
>> [6.781064] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=0,port=0
>> [6.789214] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=1,port=0
>> [6.797337] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=2,port=0
>> [6.805464] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=3,port=0
>> [6.813583] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=0,port=1
>> [6.821701] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=1,port=1
>> [6.829819] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=2,port=1
>> [6.837944] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=3,port=1
>> [6.846063] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=0,port=2
>> [6.854183] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=1,port=2
>> [6.862303] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=2,port=2
>> [6.870425] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=3,port=2
>> [6.878544] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=0,port=5
>> [6.886663] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=1,port=5
>> [6.894783] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=2,port=5
>> [6.902906] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=3,port=5
>>
>> now we are getting (bad):
>>
>> [6.678157] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=0,port=0
>> [6.686302] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=1,port=0
>> [6.694434] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=2,port=0
>> [6.702554] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=3,port=0
>> [6.710679] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=0,port=0
>> [6.718797] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=1,port=0
>> [6.726914] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=2,port=0
>> [6.735033] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=3,port=0
>> [6.743156] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=0,port=1
>> [6.751275] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=1,port=1
>> [6.759395] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=2,port=1
>> [6.767514] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=3,port=1
>> [6.775636] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=0,port=1
>> [6.783754] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=1,port=1
>> [6.791874] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=2,port=1
>> [6.72] brcm-systemport 930.ethernet eth0: TDMA cfg, size=256,
>> switch q=3,port=1
>>
>> Looking further in bcm_sysport_map_queues() we are getting the following:
>>
>> 6.223042] brcm-systemport 930.ethernet eth0: mapping q=0, p=0
>> [6.229369] brcm-systemport 930.ethernet eth0: mapping q=1, p=0
>> [6.235659] brcm-systemport 930.ethernet eth0: mapping q=2, p=0
>> [6.241945] brcm-systemport 930.ethernet eth0: mapping q=3, p=0
>> [6.248232] brcm-systemport 930.ethernet eth0: mapping q=4, p=0
>> [6.254519] brcm-systemport 930.ethernet eth0: mapping q=5, p=0
>> [6.260805] brcm-systemport 930.ethernet eth0: mapping q=
Re: [RFC PATCH v2 0/8] Adding the Sparx5 Switch Driver
On 12/16/2020 11:51 PM, Steen Hegelund wrote: > This series provides the Microchip Sparx5 Switch Driver > > The Sparx5 Carrier Ethernet and Industrial switch family delivers 64 > Ethernet ports and up to 200 Gbps of switching bandwidth. > > It provides a rich set of Ethernet switching features such as hierarchical > QoS, hardware-based OAM and service activation testing, protection > switching, IEEE 1588, and Synchronous Ethernet. > > Using provider bridging (Q-in-Q) and MPLS/MPLS-TP technology, it delivers > MEF CE > 2.0 Ethernet virtual connections (EVCs) and features advanced TCAM > classification in both ingress and egress. > > Per-EVC features include advanced L3-aware classification, a rich set of > statistics, OAM for end-to-end performance monitoring, and dual-rate > policing and shaping. > > Time sensitive networking (TSN) is supported through a comprehensive set of > features including frame preemption, cut-through, frame replication and > elimination for reliability, enhanced scheduling: credit-based shaping, > time-aware shaping, cyclic queuing, and forwarding, and per-stream policing > and filtering. > > Together with IEEE 1588 and IEEE 802.1AS support, this guarantees > low-latency deterministic networking for Fronthaul, Carrier, and Industrial > Ethernet. > > The Sparx5 switch family consists of following SKUs: > > - VSC7546 Sparx5-64 up to 64 Gbps of bandwidth with the following primary > port configurations: > - 6 *10G > - 16 * 2.5G + 2 * 10G > - 24 * 1G + 4 * 10G > > - VSC7549 Sparx5-90 up to 90 Gbps of bandwidth with the following primary > port configurations: > - 9 * 10G > - 16 * 2.5G + 4 * 10G > - 48 * 1G + 4 * 10G > > - VSC7552 Sparx5-128 up to 128 Gbps of bandwidth with the following primary > port configurations: > - 12 * 10G > - 16 * 2.5G + 8 * 10G > - 48 * 1G + 8 * 10G > > - VSC7556 Sparx5-160 up to 160 Gbps of bandwidth with the following primary > port configurations: > - 16 * 10G > - 10 * 10G + 2 * 25G > - 16 * 2.5G + 10 * 10G > - 48 * 1G + 10 * 10G > > - VSC7558 Sparx5-200 up to 200 Gbps of bandwidth with the following primary > port configurations: > - 20 * 10G > - 8 * 25G > > In addition, the device supports one 10/100/1000/2500/5000 Mbps > SGMII/SerDes node processor interface (NPI) Ethernet port. > > The Sparx5 support is developed on the PCB134 and PCB135 evaluation boards. > > - PCB134 main networking features: > - 12x SFP+ front 10G module slots (connected to Sparx5 through SFI). > - 8x SFP28 front 25G module slots (connected to Sparx5 through SFI high > speed). > - Optional, one additional 10/100/1000BASE-T (RJ45) Ethernet port > (on-board VSC8211 PHY connected to Sparx5 through SGMII). > > - PCB135 main networking features: > - 48x1G (10/100/1000M) RJ45 front ports using 12xVSC8514 QuadPHY’s each > connected to VSC7558 through QSGMII. > - 4x10G (1G/2.5G/5G/10G) RJ45 front ports using the AQR407 10G QuadPHY > each port connects to VSC7558 through SFI. > - 4x SFP28 25G module slots on back connected to VSC7558 through SFI high > speed. > - Optional, one additional 1G (10/100/1000M) RJ45 port using an on-board > VSC8211 PHY, which can be connected to VSC7558 NPI port through SGMII > using a loopback add-on PCB) > > This series provides support for: > - SFPs and DAC cables via PHYLINK with a number of 5G, 10G and 25G > devices and media types. > - Port module configuration for 10M to 25G speeds with SGMII, QSGMII, > 1000BASEX, 2500BASEX and 10GBASER as appropriate for these modes. > - SerDes configuration via the Sparx5 SerDes driver (see below). > - Host mode providing register based injection and extraction. > - Switch mode providing MAC/VLAN table learning and Layer2 switching > offloaded to the Sparx5 switch. > - STP state, VLAN support, host/bridge port mode, Forwarding DB, and > configuration and statistics via ethtool. > > More support will be added at a later stage. > > The Sparx5 Switch chip register model can be browsed here: > Link: https://microchip-ung.github.io/sparx-5_reginfo/reginfo_sparx-5.html Out of curiosity, what tool was used to generate the register information page? It looks really neat and well organized. -- Florian
[PATCH] net: lantiq_etop: check the result of request_irq()
The declaration of request_irq() in is marked as
__must_check.
Without the return value check, I see the following warnings:
drivers/net/ethernet/lantiq_etop.c: In function 'ltq_etop_hw_init':
drivers/net/ethernet/lantiq_etop.c:273:4: warning: ignoring return value of
'request_irq', declared with attribute warn_unused_result [-Wunused-result]
273 | request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
| ^~
drivers/net/ethernet/lantiq_etop.c:281:4: warning: ignoring return value of
'request_irq', declared with attribute warn_unused_result [-Wunused-result]
281 | request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);
| ^~
Reported-by: Miguel Ojeda
Signed-off-by: Masahiro Yamada
---
drivers/net/ethernet/lantiq_etop.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/lantiq_etop.c
b/drivers/net/ethernet/lantiq_etop.c
index 2d0c52f7106b..960494f9752b 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -264,13 +264,18 @@ ltq_etop_hw_init(struct net_device *dev)
for (i = 0; i < MAX_DMA_CHAN; i++) {
int irq = LTQ_DMA_CH0_INT + i;
struct ltq_etop_chan *ch = &priv->ch[i];
+ int ret;
ch->idx = ch->dma.nr = i;
ch->dma.dev = &priv->pdev->dev;
if (IS_TX(i)) {
ltq_dma_alloc_tx(&ch->dma);
- request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
+ ret = request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx",
priv);
+ if (ret) {
+ netdev_err(dev, "failed to request irq\n");
+ return ret;
+ }
} else if (IS_RX(i)) {
ltq_dma_alloc_rx(&ch->dma);
for (ch->dma.desc = 0; ch->dma.desc < LTQ_DESC_NUM;
@@ -278,7 +283,11 @@ ltq_etop_hw_init(struct net_device *dev)
if (ltq_etop_alloc_skb(ch))
return -ENOMEM;
ch->dma.desc = 0;
- request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);
+ ret = request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx",
priv);
+ if (ret) {
+ netdev_err(dev, "failed to request irq\n");
+ return ret;
+ }
}
ch->dma.irq = irq;
}
--
2.27.0
RE: [PATCH] [v11] wireless: Initial driver submission for pureLiFi STA devices
> I see lots of magic numbers in the driver like 2, 0x33 and 0x34 here. > Please convert the magic numbers to proper defines explaining the meaning. > And for vendor commands you could even use enum to group them better in .h > file somewhere. Hi Kalle, Thanks for reviewing the driver, We will work on the comments. Regards, Srini
Re: [PATCH] [v11] wireless: Initial driver submission for pureLiFi STA devices
Srinivasan Raju writes: >> I see lots of magic numbers in the driver like 2, 0x33 and 0x34 here. >> Please convert the magic numbers to proper defines explaining the >> meaning. And for vendor commands you could even use enum to group >> them better in .h file somewhere. > > Hi Kalle, > > Thanks for reviewing the driver, We will work on the comments. I haven't had time to do a throrough review yet, but I suggest fixing the stuff I commented and submitting v12. I'll then do a new review with v12. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
On Mon, Dec 14, 2020 at 12:27 AM Miguel Ojeda wrote: > > On Sun, Dec 13, 2020 at 4:16 PM Greg KH wrote: > > > > Because if you get a report of something breaking for your change, you > > need to work to resolve it, not argue about it. Otherwise it needs to > > be dropped/reverted. > > Nobody has argued that. In fact, I explicitly said the opposite: "So I > think we can fix them as they come.". > > I am expecting Masahiro to follow up. It has been less than 24 hours > since the report, on a weekend. > > Cheers, > Miguel Sorry for the delay. Now I sent out the fix for lantiq_etop.c https://lore.kernel.org/patchwork/patch/1355595/ The reason of the complication was I was trying to merge the following patch in the same development cycle: https://patchwork.kernel.org/project/linux-kbuild/patch/20201117104736.24997-1-o...@aepfle.de/ -Werror=return-type gives a bigger impact because any instance of __must_check violation results in build breakage. So, I just dropped it from my tree (and, I will aim for 5.12). The removal of CONFIG_ENABLE_MUST_CHECK is less impactive, because we are still able to build with some warnings. Tomorrow's linux-next should be OK and, you can send my patch in this merge window. -- Best Regards Masahiro Yamada
Re: PROBLEM: Poor wlan performance with lots of retries since kernel 5.9
Am 21.12.20 um 00:19 schrieb Rainer Suhm: Since kernel 5.9 I do have very poor wlan performance with one of my machines. The transmission rate is only about a tenth of normal speed (~60MB/s -> 6 MB/s). iperf3 -c shows hundreds of retries per second --- snip --- [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 8.55 MBytes 71.7 Mbits/sec 649 1.41 KBytes [ 5] 1.00-2.00 sec 5.78 MBytes 48.5 Mbits/sec 366 17.0 KBytes [ 5] 2.00-3.00 sec 5.97 MBytes 50.0 Mbits/sec 371 19.8 KBytes [ 5] 3.00-4.00 sec 5.84 MBytes 49.0 Mbits/sec 390 17.0 KBytes [ 5] 4.00-5.00 sec 6.21 MBytes 52.1 Mbits/sec 380 19.8 KBytes [ 5] 5.00-6.00 sec 4.54 MBytes 38.1 Mbits/sec 299 1.41 KBytes [ 5] 6.00-7.00 sec 6.34 MBytes 53.2 Mbits/sec 367 26.9 KBytes [ 5] 7.00-8.00 sec 6.15 MBytes 51.6 Mbits/sec 390 19.8 KBytes [ 5] 8.00-9.00 sec 5.65 MBytes 47.4 Mbits/sec 370 2.83 KBytes [ 5] 9.00-10.00 sec 5.78 MBytes 48.5 Mbits/sec 377 21.2 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 60.8 MBytes 51.0 Mbits/sec 3959 sender [ 5] 0.00-10.00 sec 60.1 MBytes 50.4 Mbits/sec receiver --- snap --- (this measurement was taken after booting from the current official arch iso) The problem is only when transmitting data. Receiving (iperf3 -c -R) works ok. No related errors/warnings in dmesg. The problem exists since kernel v5.9 up to 10.0.2-rc1 Using other (older) WiFi firmware doesn't help. Hardware: TUXEDO InfinityBook S 14 v5/L140CU, with Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340 The machine runs Arch Linux, all updates installed. On all my other laptops this problem doesn't show up. Bisecting leads to: --- snip --- 3d5b459ba0e3788ab471e8cb98eee89964a9c5e8 is the first bad commit commit 3d5b459ba0e3788ab471e8cb98eee89964a9c5e8 Author: Eric Dumazet Date: Wed Jun 17 20:53:26 2020 -0700 net: tso: add UDP segmentation support Note that like TCP, we do not support additional encapsulations, and that checksums must be offloaded to the NIC. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller net/core/tso.c | 29 ++--- 1 file changed, 18 insertions(+), 11 deletions(-) --- snap --- After reverting e89964a9c5e8, everything seems ok. WLan works with expected speed, and iperf3 doesn't show retries any more. I confirm this for kernels 5.10.1 and 5.10.2-rc1 (00017-gc96cfd687a3f). If I should provide more information, let me know. Please note: I'm not on any list. So please make sure to address me explicitly if replying to this mail. Thx Rainer Sorry, I have to resend this message, as it could not be delivered to the netdev list because of missing TLS. --- snip --- Final-Recipient: rfc822; netdev@vger.kernel.org Original-Recipient: rfc822;netdev@vger.kernel.org Action: failed Status: 5.7.4 Diagnostic-Code: X-Postfix; TLS is required, but was not offered by host vger.kernel.org[23.128.96.18] --- snap --- For now I switched the need for TLS off. Hope that helps. Thx Rainer
Re: [RFC PATCH net-next] net: dsa: mt7530: rename MT7621 compatible
Hi!
On Sun, Dec 20, 2020 at 1:10 AM Florian Fainelli wrote:
>
>
>
> On 12/19/2020 8:26 AM, Andrew Lunn wrote:
> >> --- a/drivers/net/dsa/mt7530.c
> >> +++ b/drivers/net/dsa/mt7530.c
> >> @@ -2688,7 +2688,7 @@ static const struct mt753x_info mt753x_table[] = {
> >> };
> >>
> >> static const struct of_device_id mt7530_of_match[] = {
> >> -{ .compatible = "mediatek,mt7621", .data = &mt753x_table[ID_MT7621],
> >> },
> >> +{ .compatible = "mediatek,mt7621-gsw", .data =
> >> &mt753x_table[ID_MT7621], },
> >> { .compatible = "mediatek,mt7530", .data = &mt753x_table[ID_MT7530],
> >> },
> >> { .compatible = "mediatek,mt7531", .data = &mt753x_table[ID_MT7531],
> >> },
> >> { /* sentinel */ },
> >
> > This will break backwards compatibility with existing DT blobs. You
> > need to keep the old "mediatek,mt7621", but please add a comment that
> > it is deprecated.
>
> Besides, adding -gsw would make it inconsistent with the existing
> matching compatible strings. While it's not ideal to have the same
> top-level SoC compatible and having another sub-node within that SoC's
> DTS have the same compatible, given this would be break backwards
> compatibility, cannot you stay with what is defined today?
U-boot for MT7621 doesn't support device tree, and the kernel image
is always packaged with dt. Do we need to maintain backward
compatibility at all in this situation?
--
Regards,
Chuanhong Guo
