* Re: RATE not being printed on tc -s class show dev XXXX
From: Cong Wang @ 2020-06-19 1:30 UTC (permalink / raw)
To: Roberto J. Blandino Cisneros; +Cc: Linux Kernel Network Developers
In-Reply-To: <d33998c7-f529-e1d1-31a5-626aa8dd44da@ibw.com.ni>
On Tue, Jun 16, 2020 at 7:06 AM Roberto J. Blandino Cisneros
<roberto.blandino@ibw.com.ni> wrote:
> I am seing "rate 0bit".
>
> But installing from debian package iproute2 i got nothing so i decide to
> compile iproute2 using version 5.7.0
>
> But my output is the same as below:
You either need to enable /sys/module/sch_htb/parameters/htb_rate_est
or specify a rate estimator when you create your HTB class.
Thanks.
^ permalink raw reply
* Re: [PATCH] bpf: Allow small structs to be type of function argument
From: Alexei Starovoitov @ 2020-06-19 2:04 UTC (permalink / raw)
To: John Fastabend
Cc: Andrii Nakryiko, Jiri Olsa, Andrii Nakryiko, Jiri Olsa,
Alexei Starovoitov, Daniel Borkmann, Networking, bpf,
Yonghong Song, Martin KaFai Lau, Jakub Kicinski, David Miller,
Jesper Dangaard Brouer, KP Singh, Masanori Misono
In-Reply-To: <5eec061598dcf_403f2afa5de805bcde@john-XPS-13-9370.notmuch>
On Thu, Jun 18, 2020 at 5:26 PM John Fastabend <john.fastabend@gmail.com> wrote:
>
> foo(int a, __int128 b)
>
> would put a in r0 and b in r2 and r3 leaving a hole in r1. But that
> was some old reference manual and might no longer be the case
> in reality. Perhaps just spreading hearsay, but the point is we
> should say something about what the BPF backend convention
> is and write it down. We've started to bump into these things
> lately.
calling convention for int128 in bpf is _undefined_.
calling convention for struct by value in bpf is also _undefined_.
In many cases the compiler has to have the backend code
so other parts of the compiler can function.
I didn't bother explicitly disabling every undefined case.
Please don't read too much into llvm generated code.
^ permalink raw reply
* Re: [PATCH 02/11] bpf: Compile btfid tool at kernel compilation start
From: Alexei Starovoitov @ 2020-06-19 2:08 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Andrii Nakryiko, Jiri Olsa, Alexei Starovoitov, Daniel Borkmann,
Networking, bpf, Song Liu, Yonghong Song, Martin KaFai Lau,
David Miller, John Fastabend, Wenbo Zhang, KP Singh,
Andrii Nakryiko, Brendan Gregg, Florent Revest, Al Viro
In-Reply-To: <F126D92D-E9D8-4895-AA4E-717B553AC45A@gmail.com>
On Thu, Jun 18, 2020 at 5:47 PM Arnaldo Carvalho de Melo
<arnaldo.melo@gmail.com> wrote:
>
>
>
> On June 18, 2020 9:40:32 PM GMT-03:00, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >On Tue, Jun 16, 2020 at 3:06 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >>
> >> The btfid tool will be used during the vmlinux linking,
> >> so it's necessary it's ready for it.
> >>
> >
> >Seeing troubles John runs into, I wonder if it maybe would be better
> >to add it to pahole instead? It's already a dependency for anything
> >BTF-related in the kernel. It has libelf, libbpf linked and set up.
> >WDYT? I've cc'ed Arnaldo as well for an opinion.
>
> I was reading this thread with a low prio, but my gut feeling was that yeah, since pahole is already there, why not have it do this?
>
> I'll try to look at this tomorrow and see if this is more than just a hunch.
I think it's better to keep it separate like Jiri did.
It is really vmlinux specific as far as I can see and can change in the future.
^ permalink raw reply
* Re: [PATCH iproute2] tc: m_tunnel_key: fix geneve opt output
From: Hangbin Liu @ 2020-06-19 2:25 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, Davide Caratti, lucien.xin, Stephen Hemminger
In-Reply-To: <20200618105107.GB27897@netronome.com>
On Thu, Jun 18, 2020 at 12:51:08PM +0200, Simon Horman wrote:
> On Thu, Jun 18, 2020 at 06:44:20PM +0800, Hangbin Liu wrote:
> > Commit f72c3ad00f3b changed the geneve option output from "geneve_opt"
> > to "geneve_opts", which may break the program compatibility. Reset
> > it back to geneve_opt.
> >
> > Fixes: f72c3ad00f3b ("tc: m_tunnel_key: add options support for vxlan")
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>
> Thanks Hangbin.
>
> I agree that the patch in question did change the name of the option
> as you describe, perhaps inadvertently. But I wonder if perhaps this fix
> is too simple as the patch mentioned also:
>
> 1. Documents the option as geneve_opts
> 2. Adds vxlan_opts
>
> So this patch invalidates the documentation and creates asymmetry between
> the VXLAN and Geneve variants of this feature.
Not sure if I understand you comment correctly. This patch only fix the cmd
output(revert to previous output format), The cmd option is not changed. e.g.
# tc actions add action tunnel_key set src_ip 1.1.1.1 dst_ip 2.2.2.2 id 42 \
dst_port 6081 geneve_opts 0102:80:00880022 index 1
# tc actions get action tunnel_key index 1
total acts 0
action order 1: tunnel_key set
src_ip 1.1.1.1
dst_ip 2.2.2.2
key_id 42
dst_port 6081
geneve_opt 0102:80:00880022
csum pipe
index 1 ref 1 bind 0
But this do make a asymmetry for vxlan and geneve output. I prefer
to let them consistent personally. Also it looks more reasonable
to output "geneve_opts" when we have parameter geneve_opts.
So I'm not going to fix it in iproute, but do as Davide mentioned, make
tdc test case accept both 'geneve_opts' and 'geneve_opt'.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH iproute2] tc: m_tunnel_key: fix geneve opt output
From: Hangbin Liu @ 2020-06-19 2:29 UTC (permalink / raw)
To: Davide Caratti; +Cc: netdev, lucien.xin, Simon Horman, Stephen Hemminger
In-Reply-To: <70911c86d54033c956cb06593858f6e0111eb58a.camel@redhat.com>
On Thu, Jun 18, 2020 at 01:25:46PM +0200, Davide Caratti wrote:
> On Thu, 2020-06-18 at 18:44 +0800, Hangbin Liu wrote:
> > Commit f72c3ad00f3b changed the geneve option output from "geneve_opt"
> > to "geneve_opts", which may break the program compatibility. Reset
> > it back to geneve_opt.
> >
> > Fixes: f72c3ad00f3b ("tc: m_tunnel_key: add options support for vxlan")
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> > ---
> > tc/m_tunnel_key.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tc/m_tunnel_key.c b/tc/m_tunnel_key.c
> > index bfec9072..0074f744 100644
> > --- a/tc/m_tunnel_key.c
> > +++ b/tc/m_tunnel_key.c
> > @@ -534,7 +534,7 @@ static void tunnel_key_print_geneve_options(struct rtattr *attr)
> > struct rtattr *i = RTA_DATA(attr);
> > int ii, data_len = 0, offset = 0;
> > int rem = RTA_PAYLOAD(attr);
> > - char *name = "geneve_opts";
> > + char *name = "geneve_opt";
> > char strbuf[rem * 2 + 1];
> > char data[rem * 2 + 1];
> > uint8_t data_r[rem];
>
> ... by the way, this patch does not look good to me. It fixes program
> compatibility for
>
> # tc action show
>
> but at the same time, I think it breaks program compatibility for
>
> # tc -j action show
Ah, sorry, I'm not familiar with json output and forgot to check it.
Thanks for the remind.
>
> see below: looking at commit f72c3ad00f3b,
>
> static void tunnel_key_print_tos_ttl(FILE *f, char *name,
> @@ -519,8 +586,7 @@ static int print_tunnel_key(struct action_util *au, FILE *f, struct rtattr *arg)
> tb[TCA_TUNNEL_KEY_ENC_KEY_ID]);
> tunnel_key_print_dst_port(f, "dst_port",
> tb[TCA_TUNNEL_KEY_ENC_DST_PORT]);
> - tunnel_key_print_key_opt("geneve_opts",
> - tb[TCA_TUNNEL_KEY_ENC_OPTS]);
> + tunnel_key_print_key_opt(tb[TCA_TUNNEL_KEY_ENC_OPTS])
>
> here "name" was "geneve_opts", with the 's', and it was used here:
>
> open_json_array(PRINT_JSON, name);
>
> so, the proper way to restore script compatibility is to do something
> like:
>
> - print_string(PRINT_FP, name, "\t%s ", name);
> + print_string(PRINT_FP, NULL, "\t%s ", "geneve_opt");
>
> yes, we can "harmonize" like Simon proposed, but then the fix in the
> (currently broken) tdc test case should accept both 'geneve_opts' and
> 'geneve_opt'. Something similar has been done in the past for act_ife
> see net.git commit 91fa038d9446 ("selftests: tc-testing: fix parsing of
> ife type").
From semantics, it looks more reasonable to output "geneve_opts" as the
parameter is "geneve_opts", which is also symmetry with vxlan.
So I'm going to fix the tdc to accept both 'geneve_opts' and 'geneve_opt'.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH net-next v8 2/5] net: phy: Add a helper to return the index for of the internal delay
From: kernel test robot @ 2020-06-19 2:36 UTC (permalink / raw)
To: Dan Murphy, andrew, f.fainelli, hkallweit1, davem, robh
Cc: kbuild-all, clang-built-linux, netdev, linux-kernel, devicetree,
Dan Murphy
In-Reply-To: <20200618211011.28837-3-dmurphy@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Dan-Murphy/RGMII-Internal-delay-common-property/20200619-051238
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2
config: x86_64-defconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 487ca07fcc75d52755c9fe2ee05bcb3b6eeeec44)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/net/phy/phy_device.c:2677:16: error: expected ';' after return statement
return -EINVAL
^
;
1 error generated.
vim +2677 drivers/net/phy/phy_device.c
2660
2661 #if IS_ENABLED(CONFIG_OF_MDIO)
2662 static int phy_get_int_delay_property(struct device *dev, const char *name)
2663 {
2664 s32 int_delay;
2665 int ret;
2666
2667 ret = device_property_read_u32(dev, name, &int_delay);
2668 if (ret)
2669 return ret;
2670
2671 return int_delay;
2672 }
2673 #else
2674 static inline int phy_get_int_delay_property(struct device *dev,
2675 const char *name)
2676 {
> 2677 return -EINVAL
2678 }
2679 #endif
2680
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29341 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: dsa: bcm_sf2: Fix node reference count
From: David Miller @ 2020-06-19 2:41 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev, vivien.didelot, kuba, linux-kernel
In-Reply-To: <20200618125640.GL249144@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Thu, 18 Jun 2020 14:56:40 +0200
> That if_find_node_by_name() does a put is not very intuitive.
> Maybe document that as well in the kerneldocs?
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
I've been complaining about the non-intuitiveness of the various
OF interfaces for a long time. They transfer reference counts
across objects, and that makes the logic hard to audit.
The iterators are the worst.
^ permalink raw reply
* Re: [PATCH 1/2] net: ethernet: mvneta: Fix Serdes configuration for SoCs without comphy
From: David Miller @ 2020-06-19 3:00 UTC (permalink / raw)
To: s.hauer
Cc: netdev, linux-kernel, linux-arm-kernel, thomas.petazzoni, kernel,
linux, rmk+kernel
In-Reply-To: <20200616083140.8498-1-s.hauer@pengutronix.de>
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue, 16 Jun 2020 10:31:39 +0200
> The MVNETA_SERDES_CFG register is only available on older SoCs like the
> Armada XP. On newer SoCs like the Armada 38x the fields are moved to
> comphy. This patch moves the writes to this register next to the comphy
> initialization, so that depending on the SoC either comphy or
> MVNETA_SERDES_CFG is configured.
> With this we no longer write to the MVNETA_SERDES_CFG on SoCs where it
> doesn't exist.
>
> Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: ethernet: mvneta: Add 2500BaseX support for SoCs without comphy
From: David Miller @ 2020-06-19 3:00 UTC (permalink / raw)
To: s.hauer
Cc: netdev, linux-kernel, linux-arm-kernel, thomas.petazzoni, kernel,
linux
In-Reply-To: <20200616083140.8498-2-s.hauer@pengutronix.de>
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue, 16 Jun 2020 10:31:40 +0200
> The older SoCs like Armada XP support a 2500BaseX mode in the datasheets
> referred to as DR-SGMII (Double rated SGMII) or HS-SGMII (High Speed
> SGMII). This is an upclocked 1000BaseX mode, thus
> PHY_INTERFACE_MODE_2500BASEX is the appropriate mode define for it.
> adding support for it merely means writing the correct magic value into
> the MVNETA_SERDES_CFG register.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: fix memleak in register_netdevice()
From: David Miller @ 2020-06-19 3:06 UTC (permalink / raw)
To: yangyingliang; +Cc: netdev, weiyongjun1
In-Reply-To: <20200616093921.2185939-1-yangyingliang@huawei.com>
From: Yang Yingliang <yangyingliang@huawei.com>
Date: Tue, 16 Jun 2020 09:39:21 +0000
> I got a memleak report when doing some fuzz test:
...
> If call_netdevice_notifiers() failed, then rollback_registered()
> calls netdev_unregister_kobject() which holds the kobject. The
> reference cannot be put because the netdev won't be add to todo
> list, so it will leads a memleak, we need put the reference to
> avoid memleak.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 net 0/2] Reapply DSA fix for dpaa-eth with proper Fixes: tag
From: David Miller @ 2020-06-19 3:11 UTC (permalink / raw)
To: olteanv
Cc: netdev, andrew, vivien.didelot, f.fainelli, joakim.tjernlund,
madalin.bucur, fido_max, linux-kernel
In-Reply-To: <20200616151910.3908882-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Tue, 16 Jun 2020 18:19:08 +0300
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> Joakim notified me that this fix breaks stable trees.
> It turns out that my assessment about who-broke-who was wrong.
> The real Fixes: tag should have been:
>
> Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
>
> which changes the device on which SET_NETDEV_DEV is made.
>
> git describe --tags 060ad66f97954
> v5.4-rc3-783-g060ad66f9795
>
> Which means that it shouldn't have been backported to 4.19 and below.
> This series reverts the commit with the misleading commit message, and
> reapplies it with a corrected one. The resulting code is exactly the
> same, but now, the revert should make it to the stable trees (along with
> the bad fix), and the new fix should only make it down to v5.4.y.
>
> Changes in v2:
> Corrected the reversed sysfs paths in the new commit description.
This is so messy.
What's done is done, just submit the necessary revert to -stable
if necessary and let's not just change things back and forth
because then we'll have two commits which make identical changes
and each having a different Fixes: tag which is confusing.
Thanks.
^ permalink raw reply
* Re: [PATCH net v2] net: core: reduce recursion limit value
From: David Miller @ 2020-06-19 3:13 UTC (permalink / raw)
To: ap420073; +Cc: kuba, netdev, fw
In-Reply-To: <20200616155205.8276-1-ap420073@gmail.com>
From: Taehee Yoo <ap420073@gmail.com>
Date: Tue, 16 Jun 2020 15:52:05 +0000
> In the current code, ->ndo_start_xmit() can be executed recursively only
> 10 times because of stack memory.
> But, in the case of the vxlan, 10 recursion limit value results in
> a stack overflow.
> In the current code, the nested interface is limited by 8 depth.
> There is no critical reason that the recursion limitation value should
> be 10.
> So, it would be good to be the same value with the limitation value of
> nesting interface depth.
>
> Test commands:
...
> Splat looks like:
...
>
> Fixes: 11a766ce915f ("net: Increase xmit RECURSION_LIMIT to 10.")
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net v2] ip6_gre: fix use-after-free in ip6gre_tunnel_lookup()
From: David Miller @ 2020-06-19 3:14 UTC (permalink / raw)
To: ap420073; +Cc: kuba, netdev, xeb, eric.dumazet
In-Reply-To: <20200616160400.8579-1-ap420073@gmail.com>
From: Taehee Yoo <ap420073@gmail.com>
Date: Tue, 16 Jun 2020 16:04:00 +0000
> In the datapath, the ip6gre_tunnel_lookup() is used and it internally uses
> fallback tunnel device pointer, which is fb_tunnel_dev.
> This pointer variable should be set to NULL when a fb interface is deleted.
> But there is no routine to set fb_tunnel_dev pointer to NULL.
> So, this pointer will be still used after interface is deleted and
> it eventually results in the use-after-free problem.
>
> Test commands:
...
> Splat looks like:
...
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net v3] ip_tunnel: fix use-after-free in ip_tunnel_lookup()
From: David Miller @ 2020-06-19 3:15 UTC (permalink / raw)
To: ap420073; +Cc: kuba, netdev, pshelar, eric.dumazet
In-Reply-To: <20200616165151.19540-1-ap420073@gmail.com>
From: Taehee Yoo <ap420073@gmail.com>
Date: Tue, 16 Jun 2020 16:51:51 +0000
> In the datapath, the ip_tunnel_lookup() is used and it internally uses
> fallback tunnel device pointer, which is fb_tunnel_dev.
> This pointer variable should be set to NULL when a fb interface is deleted.
> But there is no routine to set fb_tunnel_dev pointer to NULL.
> So, this pointer will be still used after interface is deleted and
> it eventually results in the use-after-free problem.
>
> Test commands:
...
> Splat looks like:
...
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net v3 0/2] two fixes for 'act_gate' control plane
From: David Miller @ 2020-06-19 3:18 UTC (permalink / raw)
To: dcaratti; +Cc: Po.Liu, xiyou.wangcong, olteanv, netdev
In-Reply-To: <cover.1592338450.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Tue, 16 Jun 2020 22:25:19 +0200
> - patch 1/2 attempts to fix the error path of tcf_gate_init() when users
> try to configure 'act_gate' rules with wrong parameters
> - patch 2/2 is a follow-up of a recent fix for NULL dereference in
> the error path of tcf_gate_init()
>
> further work will introduce a tdc test for 'act_gate'.
>
> changes since v2:
> - fix undefined behavior in patch 1/2
> - improve comment in patch 2/2
> changes since v1:
> coding style fixes in patch 1/2 and 2/2
Series applied, thanks Davide.
^ permalink raw reply
* Re: [PATCH][next] net: stmmac: selftests: Use struct_size() helper in kzalloc()
From: David Miller @ 2020-06-19 3:19 UTC (permalink / raw)
To: gustavoars
Cc: peppe.cavallaro, alexandre.torgue, joabreu, kuba, mcoquelin.stm32,
netdev, linux-stm32, linux-arm-kernel, linux-kernel, gustavo
In-Reply-To: <20200616230328.GA23281@embeddedor>
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Date: Tue, 16 Jun 2020 18:03:28 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net 0/3] Fix VLAN checks for SJA1105 DSA tc-flower filters
From: David Miller @ 2020-06-19 3:21 UTC (permalink / raw)
To: olteanv; +Cc: netdev, andrew, f.fainelli, vivien.didelot, kuba
In-Reply-To: <20200616235843.756413-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Wed, 17 Jun 2020 02:58:40 +0300
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> This fixes a ridiculous situation where the driver, in VLAN-unaware
> mode, would refuse accepting any tc filter:
>
> tc filter replace dev sw1p3 ingress flower skip_sw \
> dst_mac 42:be:24:9b:76:20 \
> action gate (...)
> Error: sja1105: Can only gate based on {DMAC, VID, PCP}.
>
> tc filter replace dev sw1p3 ingress protocol 802.1Q flower skip_sw \
> vlan_id 1 vlan_prio 0 dst_mac 42:be:24:9b:76:20 \
> action gate (...)
> Error: sja1105: Can only gate based on DMAC.
>
> So, without changing the VLAN awareness state, it says it doesn't want
> VLAN-aware rules, and it doesn't want VLAN-unaware rules either. One
> would say it's in Schrodinger's state...
>
> Now, the situation has been made worse by commit 7f14937facdc ("net:
> dsa: sja1105: keep the VLAN awareness state in a driver variable"),
> which made VLAN awareness a ternary attribute, but after inspecting the
> code from before that patch with a truth table, it looks like the
> logical bug was there even before.
>
> While attempting to fix this, I also noticed some leftover debugging
> code in one of the places that needed to be fixed. It would have
> appeared in the context of patch 3/3 anyway, so I decided to create a
> patch that removes it.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 01/02] net: phy: marvell: Add Marvell 88E1340 support
From: David Miller @ 2020-06-19 3:24 UTC (permalink / raw)
To: fido_max; +Cc: netdev, andrew, f.fainelli, hkallweit1, linux
In-Reply-To: <05f6912b-d529-ae7d-183e-efa6951e94b7@inbox.ru>
These patches have been corrupted by your email client, try to apply what
ended up in the mailing list and you will see, from "git am":
Applying: net: phy: marvell: Add Marvell 88E1340 support
error: corrupt patch at line 40
^ permalink raw reply
* [PATCHv2 net] tc-testing: update geneve options match in tunnel_key unit tests
From: Hangbin Liu @ 2020-06-19 3:24 UTC (permalink / raw)
To: netdev; +Cc: Lucas Bates, Simon Horman, David Miller, Davide Caratti,
Hangbin Liu
In-Reply-To: <20200618083705.449619-1-liuhangbin@gmail.com>
Since iproute2 commit f72c3ad00f3b ("tc: m_tunnel_key: add options
support for vxlan"), the geneve opt output use key word "geneve_opts"
instead of "geneve_opt". To make compatibility for both old and new
iproute2, let's accept both "geneve_opt" and "geneve_opts".
Suggested-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
.../tc-testing/tc-tests/actions/tunnel_key.json | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/tunnel_key.json b/tools/testing/selftests/tc-testing/tc-tests/actions/tunnel_key.json
index fbeb9197697d..7357c58fa2dc 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/actions/tunnel_key.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/tunnel_key.json
@@ -629,7 +629,7 @@
"cmdUnderTest": "$TC actions add action tunnel_key set src_ip 1.1.1.1 dst_ip 2.2.2.2 id 42 dst_port 6081 geneve_opts 0102:80:00880022 index 1",
"expExitCode": "0",
"verifyCmd": "$TC actions get action tunnel_key index 1",
- "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt 0102:80:00880022.*index 1",
+ "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt[s]? 0102:80:00880022.*index 1",
"matchCount": "1",
"teardown": [
"$TC actions flush action tunnel_key"
@@ -653,7 +653,7 @@
"cmdUnderTest": "$TC actions add action tunnel_key set src_ip 1.1.1.1 dst_ip 2.2.2.2 id 42 dst_port 6081 geneve_opts 0102:80:00880022,0408:42:0040007611223344,0111:02:1020304011223344 index 1",
"expExitCode": "0",
"verifyCmd": "$TC actions get action tunnel_key index 1",
- "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt 0102:80:00880022,0408:42:0040007611223344,0111:02:1020304011223344.*index 1",
+ "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt[s]? 0102:80:00880022,0408:42:0040007611223344,0111:02:1020304011223344.*index 1",
"matchCount": "1",
"teardown": [
"$TC actions flush action tunnel_key"
@@ -677,7 +677,7 @@
"cmdUnderTest": "$TC actions add action tunnel_key set src_ip 1.1.1.1 dst_ip 2.2.2.2 id 42 dst_port 6081 geneve_opts 824212:80:00880022 index 1",
"expExitCode": "255",
"verifyCmd": "$TC actions get action tunnel_key index 1",
- "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt 824212:80:00880022.*index 1",
+ "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt[s]? 824212:80:00880022.*index 1",
"matchCount": "0",
"teardown": [
"$TC actions flush action tunnel_key"
@@ -701,7 +701,7 @@
"cmdUnderTest": "$TC actions add action tunnel_key set src_ip 1.1.1.1 dst_ip 2.2.2.2 id 42 dst_port 6081 geneve_opts 0102:4224:00880022 index 1",
"expExitCode": "255",
"verifyCmd": "$TC actions get action tunnel_key index 1",
- "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt 0102:4224:00880022.*index 1",
+ "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt[s]? 0102:4224:00880022.*index 1",
"matchCount": "0",
"teardown": [
"$TC actions flush action tunnel_key"
@@ -725,7 +725,7 @@
"cmdUnderTest": "$TC actions add action tunnel_key set src_ip 1.1.1.1 dst_ip 2.2.2.2 id 42 dst_port 6081 geneve_opts 0102:80:4288 index 1",
"expExitCode": "255",
"verifyCmd": "$TC actions get action tunnel_key index 1",
- "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt 0102:80:4288.*index 1",
+ "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt[s]? 0102:80:4288.*index 1",
"matchCount": "0",
"teardown": [
"$TC actions flush action tunnel_key"
@@ -749,7 +749,7 @@
"cmdUnderTest": "$TC actions add action tunnel_key set src_ip 1.1.1.1 dst_ip 2.2.2.2 id 42 dst_port 6081 geneve_opts 0102:80:4288428822 index 1",
"expExitCode": "255",
"verifyCmd": "$TC actions get action tunnel_key index 1",
- "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt 0102:80:4288428822.*index 1",
+ "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt[s]? 0102:80:4288428822.*index 1",
"matchCount": "0",
"teardown": [
"$TC actions flush action tunnel_key"
@@ -773,7 +773,7 @@
"cmdUnderTest": "$TC actions add action tunnel_key set src_ip 1.1.1.1 dst_ip 2.2.2.2 id 42 dst_port 6081 geneve_opts 0102:80:00880022,0408:42: index 1",
"expExitCode": "255",
"verifyCmd": "$TC actions get action tunnel_key index 1",
- "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt 0102:80:00880022,0408:42:.*index 1",
+ "matchPattern": "action order [0-9]+: tunnel_key.*set.*src_ip 1.1.1.1.*dst_ip 2.2.2.2.*key_id 42.*dst_port 6081.*geneve_opt[s]? 0102:80:00880022,0408:42:.*index 1",
"matchCount": "0",
"teardown": [
"$TC actions flush action tunnel_key"
--
2.25.4
^ permalink raw reply related
* Re: [PATCH net 0/2] mptcp: cope with syncookie on MP_JOINs
From: David Miller @ 2020-06-19 3:26 UTC (permalink / raw)
To: pabeni; +Cc: netdev, kuba, mptcp
In-Reply-To: <cover.1592388398.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 17 Jun 2020 12:08:55 +0200
> Currently syncookies on MP_JOIN connections are not handled correctly: the
> connections fallback to TCP and are kept alive instead of resetting them at
> fallback time.
>
> The first patch propagates the required information up to syn_recv_sock time,
> and the 2nd patch addresses the unifying the error path for all MP_JOIN
> requests.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] s390/qeth: fixes 2020-06-17
From: David Miller @ 2020-06-19 3:27 UTC (permalink / raw)
To: jwi; +Cc: kuba, netdev, linux-s390, heiko.carstens, ubraun, kgraul
In-Reply-To: <20200617145453.61382-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Wed, 17 Jun 2020 16:54:51 +0200
> please apply the following patch series for qeth to netdev's net tree.
>
> The first patch fixes a regression in the error handling for a specific
> cmd type. I have some follow-ups queued up for net-next to clean this
> up properly...
>
> The second patch fine-tunes the HW offload restrictions that went in
> with this merge window. In some setups we don't need to apply them.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: napi: remove useless stack trace
From: David Miller @ 2020-06-19 3:30 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20200617164051.128487-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 17 Jun 2020 09:40:51 -0700
> Whenever a buggy NAPI driver returns more than its budget,
> we emit a stack trace that is of no use, since it does not
> tell which driver is buggy.
>
> Instead, emit a message giving the function name, and a
> descriptive message.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net v3] bareudp: Fixed multiproto mode configuration
From: David Miller @ 2020-06-19 3:32 UTC (permalink / raw)
To: martinvarghesenokia; +Cc: netdev, martin.varghese
In-Reply-To: <1592413223-9098-1-git-send-email-martinvarghesenokia@gmail.com>
From: Martin Varghese <martinvarghesenokia@gmail.com>
Date: Wed, 17 Jun 2020 22:30:23 +0530
> From: Martin <martin.varghese@nokia.com>
>
> Code to handle multiproto configuration is missing.
>
> Fixes: 4b5f67232d95 ("net: Special handling for IP & MPLS")
> Signed-off-by: Martin <martin.varghese@nokia.com>
Applied and queued up for v5.7 -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v8 5/5] net: phy: DP83822: Add setting the fixed internal delay
From: kernel test robot @ 2020-06-19 3:27 UTC (permalink / raw)
To: Dan Murphy, andrew, f.fainelli, hkallweit1, davem, robh
Cc: kbuild-all, clang-built-linux, netdev, linux-kernel, devicetree,
Dan Murphy
In-Reply-To: <20200618211011.28837-6-dmurphy@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2816 bytes --]
Hi Dan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Dan-Murphy/RGMII-Internal-delay-common-property/20200619-051238
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 487ca07fcc75d52755c9fe2ee05bcb3b6eeeec44)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/net/phy/dp83822.c:284:7: warning: variable 'rgmii_delay' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (rx_int_delay <= 0)
^~~~~~~~~~~~~~~~~
drivers/net/phy/dp83822.c:296:7: note: uninitialized use occurs here
if (rgmii_delay) {
^~~~~~~~~~~
drivers/net/phy/dp83822.c:284:3: note: remove the 'if' if its condition is always false
if (rx_int_delay <= 0)
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/phy/dp83822.c:276:17: note: initialize the variable 'rgmii_delay' to silence this warning
int rgmii_delay;
^
= 0
1 warning generated.
vim +284 drivers/net/phy/dp83822.c
272
273 static int dp83822_config_init(struct phy_device *phydev)
274 {
275 struct device *dev = &phydev->mdio.dev;
276 int rgmii_delay;
277 s32 rx_int_delay;
278 s32 tx_int_delay;
279 int err = 0;
280
281 if (phy_interface_is_rgmii(phydev)) {
282 rx_int_delay = phy_get_internal_delay(phydev, dev, NULL, 0,
283 true);
> 284 if (rx_int_delay <= 0)
285 rx_int_delay = 0;
286 else
287 rgmii_delay = DP83822_RX_CLK_SHIFT;
288
289 tx_int_delay = phy_get_internal_delay(phydev, dev, NULL, 0,
290 false);
291 if (tx_int_delay <= 0)
292 tx_int_delay = 0;
293 else
294 rgmii_delay |= DP83822_TX_CLK_SHIFT;
295
296 if (rgmii_delay) {
297 err = phy_set_bits_mmd(phydev, DP83822_DEVADDR,
298 MII_DP83822_RCSR, rgmii_delay);
299 if (err)
300 return err;
301 }
302 }
303
304 return dp8382x_disable_wol(phydev);
305 }
306
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 74440 bytes --]
^ permalink raw reply
* [PATCH net-next 1/9] net/devlink: Prepare devlink port functions to fill extack
From: Parav Pandit @ 2020-06-19 3:32 UTC (permalink / raw)
To: netdev; +Cc: saeedm, davem, kuba, jiri, Parav Pandit
In-Reply-To: <20200619033255.163-1-parav@mellanox.com>
Prepare devlink port related functions to optionally fill up
the extack information which will be used in subsequent patch by port
function attribute(s).
Signed-off-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
net/core/devlink.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 2cafbc808b09..05197631d52a 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -566,7 +566,8 @@ static int devlink_nl_port_attrs_put(struct sk_buff *msg,
static int devlink_nl_port_fill(struct sk_buff *msg, struct devlink *devlink,
struct devlink_port *devlink_port,
enum devlink_command cmd, u32 portid,
- u32 seq, int flags)
+ u32 seq, int flags,
+ struct netlink_ext_ack *extack)
{
void *hdr;
@@ -634,7 +635,8 @@ static void devlink_port_notify(struct devlink_port *devlink_port,
if (!msg)
return;
- err = devlink_nl_port_fill(msg, devlink, devlink_port, cmd, 0, 0, 0);
+ err = devlink_nl_port_fill(msg, devlink, devlink_port, cmd, 0, 0, 0,
+ NULL);
if (err) {
nlmsg_free(msg);
return;
@@ -708,7 +710,8 @@ static int devlink_nl_cmd_port_get_doit(struct sk_buff *skb,
err = devlink_nl_port_fill(msg, devlink, devlink_port,
DEVLINK_CMD_PORT_NEW,
- info->snd_portid, info->snd_seq, 0);
+ info->snd_portid, info->snd_seq, 0,
+ info->extack);
if (err) {
nlmsg_free(msg);
return err;
@@ -740,7 +743,8 @@ static int devlink_nl_cmd_port_get_dumpit(struct sk_buff *msg,
DEVLINK_CMD_NEW,
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
- NLM_F_MULTI);
+ NLM_F_MULTI,
+ cb->extack);
if (err) {
mutex_unlock(&devlink->lock);
goto out;
--
2.19.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox