* [PATCH bpf-next] selftests/bpf: fix test_align liveliness expectations
From: Stanislav Fomichev @ 2019-07-03 21:29 UTC (permalink / raw)
To: netdev, bpf; +Cc: davem, ast, daniel, Stanislav Fomichev
Commit 2589726d12a1 ("bpf: introduce bounded loops") caused a change
in the way some registers liveliness is reported in the test_align.
Add missing "_w" to a couple of tests. Note, there are no offset
changes!
Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/testing/selftests/bpf/test_align.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_align.c b/tools/testing/selftests/bpf/test_align.c
index 3c789d03b629..0262f7b374f9 100644
--- a/tools/testing/selftests/bpf/test_align.c
+++ b/tools/testing/selftests/bpf/test_align.c
@@ -180,7 +180,7 @@ static struct bpf_align_test tests[] = {
},
.prog_type = BPF_PROG_TYPE_SCHED_CLS,
.matches = {
- {7, "R0=pkt(id=0,off=8,r=8,imm=0)"},
+ {7, "R0_w=pkt(id=0,off=8,r=8,imm=0)"},
{7, "R3_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff))"},
{8, "R3_w=inv(id=0,umax_value=510,var_off=(0x0; 0x1fe))"},
{9, "R3_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
@@ -315,7 +315,7 @@ static struct bpf_align_test tests[] = {
/* Calculated offset in R6 has unknown value, but known
* alignment of 4.
*/
- {8, "R2=pkt(id=0,off=0,r=8,imm=0)"},
+ {8, "R2_w=pkt(id=0,off=0,r=8,imm=0)"},
{8, "R6_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
/* Offset is added to packet pointer R5, resulting in
* known fixed offset, and variable offset from R6.
@@ -405,7 +405,7 @@ static struct bpf_align_test tests[] = {
/* Calculated offset in R6 has unknown value, but known
* alignment of 4.
*/
- {8, "R2=pkt(id=0,off=0,r=8,imm=0)"},
+ {8, "R2_w=pkt(id=0,off=0,r=8,imm=0)"},
{8, "R6_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
/* Adding 14 makes R6 be (4n+2) */
{9, "R6_w=inv(id=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
@@ -473,12 +473,12 @@ static struct bpf_align_test tests[] = {
/* (4n) + 14 == (4n+2). We blow our bounds, because
* the add could overflow.
*/
- {7, "R5=inv(id=0,var_off=(0x2; 0xfffffffffffffffc))"},
+ {7, "R5_w=inv(id=0,var_off=(0x2; 0xfffffffffffffffc))"},
/* Checked s>=0 */
{9, "R5=inv(id=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
/* packet pointer + nonnegative (4n+2) */
{11, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
- {13, "R4=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
+ {13, "R4_w=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
/* NET_IP_ALIGN + (4n+2) == (4n), alignment is fine.
* We checked the bounds, but it might have been able
* to overflow if the packet pointer started in the
@@ -486,7 +486,7 @@ static struct bpf_align_test tests[] = {
* So we did not get a 'range' on R6, and the access
* attempt will fail.
*/
- {15, "R6=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
+ {15, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
}
},
{
@@ -521,7 +521,7 @@ static struct bpf_align_test tests[] = {
/* Calculated offset in R6 has unknown value, but known
* alignment of 4.
*/
- {7, "R2=pkt(id=0,off=0,r=8,imm=0)"},
+ {7, "R2_w=pkt(id=0,off=0,r=8,imm=0)"},
{9, "R6_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
/* Adding 14 makes R6 be (4n+2) */
{10, "R6_w=inv(id=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
@@ -574,7 +574,7 @@ static struct bpf_align_test tests[] = {
/* Calculated offset in R6 has unknown value, but known
* alignment of 4.
*/
- {7, "R2=pkt(id=0,off=0,r=8,imm=0)"},
+ {7, "R2_w=pkt(id=0,off=0,r=8,imm=0)"},
{10, "R6_w=inv(id=0,umax_value=60,var_off=(0x0; 0x3c))"},
/* Adding 14 makes R6 be (4n+2) */
{11, "R6_w=inv(id=0,umin_value=14,umax_value=74,var_off=(0x2; 0x7c))"},
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH v2 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Andrew Lunn @ 2019-07-03 21:33 UTC (permalink / raw)
To: Rob Herring
Cc: Matthias Kaehlcke, David S . Miller, Mark Rutland,
Florian Fainelli, Heiner Kallweit, netdev, devicetree,
linux-kernel@vger.kernel.org, Douglas Anderson
In-Reply-To: <CAL_JsqJdBAMPc1sZJfL7V9cxGgCb4GWwRokwJDmac5L2AO2-wg@mail.gmail.com>
> I think if we're going to have custom properties for phys, we should
> have a compatible string to at least validate whether the custom
> properties are even valid for the node.
Hi Rob
What happens with other enumerable busses where a compatible string is
not used?
The Ethernet PHY subsystem will ignore the compatible string and load
the driver which fits the enumeration data. Using the compatible
string only to get the right YAML validator seems wrong. I would
prefer adding some other property with a clear name indicates its is
selecting the validator, and has nothing to do with loading the
correct driver. And it can then be used as well for USB and PCI
devices etc.
Andrew
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Florian Fainelli @ 2019-07-03 21:37 UTC (permalink / raw)
To: Matthias Kaehlcke, David S . Miller, Rob Herring, Mark Rutland,
Andrew Lunn, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson
In-Reply-To: <20190703193724.246854-6-mka@chromium.org>
On 7/3/19 12:37 PM, Matthias Kaehlcke wrote:
> The LED behavior of some Realtek PHYs is configurable. Add the
> property 'realtek,led-modes' to specify the configuration of the
> LEDs.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes in v2:
> - patch added to the series
> ---
> .../devicetree/bindings/net/realtek.txt | 9 +++++++++
> include/dt-bindings/net/realtek.h | 17 +++++++++++++++++
> 2 files changed, 26 insertions(+)
> create mode 100644 include/dt-bindings/net/realtek.h
>
> diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
> index 71d386c78269..40b0d6f9ee21 100644
> --- a/Documentation/devicetree/bindings/net/realtek.txt
> +++ b/Documentation/devicetree/bindings/net/realtek.txt
> @@ -9,6 +9,12 @@ Optional properties:
>
> SSC is only available on some Realtek PHYs (e.g. RTL8211E).
>
> +- realtek,led-modes: LED mode configuration.
> +
> + A 0..3 element vector, with each element configuring the operating
> + mode of an LED. Omitted LEDs are turned off. Allowed values are
> + defined in "include/dt-bindings/net/realtek.h".
This should probably be made more general and we should define LED modes
that makes sense regardless of the PHY device, introduce a set of
generic functions for validating and then add new function pointer for
setting the LED configuration to the PHY driver. This would allow to be
more future proof where each PHY driver could expose standard LEDs class
devices to user-space, and it would also allow facilities like: ethtool
-p to plug into that.
Right now, each driver invents its own way of configuring LEDs, that
does not scale, and there is not really a good reason for that other
than reviewing drivers in isolation and therefore making it harder to
extract the commonality. Yes, I realize that since you are the latest
person submitting something in that area, you are being selected :)
> +
> Example:
>
> mdio0 {
> @@ -20,5 +26,8 @@ mdio0 {
> reg = <1>;
> realtek,eee-led-mode-disable;
> realtek,enable-ssc;
> + realtek,led-modes = <RTL8211E_LINK_ACTIVITY
> + RTL8211E_LINK_100
> + RTL8211E_LINK_1000>;
> };
> };
> diff --git a/include/dt-bindings/net/realtek.h b/include/dt-bindings/net/realtek.h
> new file mode 100644
> index 000000000000..8d64f58d58f8
> --- /dev/null
> +++ b/include/dt-bindings/net/realtek.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _DT_BINDINGS_REALTEK_H
> +#define _DT_BINDINGS_REALTEK_H
> +
> +/* LED modes for RTL8211E PHY */
> +
> +#define RTL8211E_LINK_10 1
> +#define RTL8211E_LINK_100 2
> +#define RTL8211E_LINK_1000 4
> +#define RTL8211E_LINK_10_100 3
> +#define RTL8211E_LINK_10_1000 5
> +#define RTL8211E_LINK_100_1000 6
> +#define RTL8211E_LINK_10_100_1000 7
> +
> +#define RTL8211E_LINK_ACTIVITY (1 << 16)
> +
> +#endif
>
--
Florian
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net-next tree
From: Stephen Rothwell @ 2019-07-03 21:42 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Mahesh Bandewar
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
Hi all,
In commit
d62962b37ceb ("loopback: fix lockdep splat")
Fixes tag
Fixes: 4de83b88c66 ("loopback: create blackhole net device similar to loopack.")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next] iavf: remove unused debug function iavf_debug_d
From: Bowers, AndrewX @ 2019-07-03 21:44 UTC (permalink / raw)
To: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190702062021.41524-1-yuehaibing@huawei.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of YueHaibing
> Sent: Monday, July 1, 2019 11:20 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; davem@davemloft.net;
> intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; YueHaibing <yuehaibing@huawei.com>; linux-
> kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-next] iavf: remove unused debug
> function iavf_debug_d
>
> There is no caller of function iavf_debug_d() in tree since commit
> 75051ce4c5d8 ("iavf: Fix up debug print macro"), so it can be removed.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf_main.c | 22 ----------------------
> 1 file changed, 22 deletions(-)
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Matthias Kaehlcke @ 2019-07-03 22:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, David S . Miller, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel@vger.kernel.org,
Douglas Anderson
In-Reply-To: <20190703213327.GH18473@lunn.ch>
On Wed, Jul 03, 2019 at 11:33:27PM +0200, Andrew Lunn wrote:
> > I think if we're going to have custom properties for phys, we should
> > have a compatible string to at least validate whether the custom
> > properties are even valid for the node.
>
> Hi Rob
>
> What happens with other enumerable busses where a compatible string is
> not used?
>
> The Ethernet PHY subsystem will ignore the compatible string and load
> the driver which fits the enumeration data. Using the compatible
> string only to get the right YAML validator seems wrong. I would
> prefer adding some other property with a clear name indicates its is
> selecting the validator, and has nothing to do with loading the
> correct driver. And it can then be used as well for USB and PCI
> devices etc.
I also have doubts whether a compatible string is the right answer
here. It's not needed/used by the subsystem, but would it be a
required property because it's needed for validation?
^ permalink raw reply
* Re: [PATCH v3 bpf-next 2/4] selftests/bpf: add __int and __type macro for BTF-defined maps
From: Yonghong Song @ 2019-07-03 22:41 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko@gmail.com, Alexei Starovoitov,
daniel@iogearbox.net, bpf@vger.kernel.org, netdev@vger.kernel.org,
Kernel Team
In-Reply-To: <20190703190604.4173641-3-andriin@fb.com>
On 7/3/19 12:06 PM, Andrii Nakryiko wrote:
> Add simple __int and __type macro that hide details of how type and
The "__int" should be "__uint".
The subject line should change from __int to __uint.
> integer values are captured in BTF-defined maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/testing/selftests/bpf/bpf_helpers.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> index 1a5b1accf091..5a3d92c8bec8 100644
> --- a/tools/testing/selftests/bpf/bpf_helpers.h
> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> @@ -8,6 +8,9 @@
> */
> #define SEC(NAME) __attribute__((section(NAME), used))
>
> +#define __uint(name, val) int (*name)[val]
> +#define __type(name, val) val *name
> +
> /* helper macro to print out debug messages */
> #define bpf_printk(fmt, ...) \
> ({ \
>
^ permalink raw reply
* Re: [PATCH v3 bpf-next 0/4] capture integers in BTF type info for map defs
From: Yonghong Song @ 2019-07-03 22:42 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko@gmail.com, Alexei Starovoitov,
daniel@iogearbox.net, bpf@vger.kernel.org, netdev@vger.kernel.org,
Kernel Team
In-Reply-To: <20190703190604.4173641-1-andriin@fb.com>
On 7/3/19 12:06 PM, Andrii Nakryiko wrote:
> This patch set implements an update to how BTF-defined maps are specified. The
> change is in how integer attributes, e.g., type, max_entries, map_flags, are
> specified: now they are captured as part of map definition struct's BTF type
> information (using array dimension), eliminating the need for compile-time
> data initialization and keeping all the metadata in one place.
>
> All existing selftests that were using BTF-defined maps are updated, along
> with some other selftests, that were switched to new syntax.
>
> v2->v3:
> - rename __int into __uint (Yonghong);
> v1->v2:
> - split bpf_helpers.h change from libbpf change (Song).
>
> Andrii Nakryiko (4):
> libbpf: capture value in BTF type info for BTF-defined map defs
> selftests/bpf: add __int and __type macro for BTF-defined maps
> selftests/bpf: convert selftests using BTF-defined maps to new syntax
> selftests/bpf: convert legacy BPF maps to BTF-defined ones
>
With typos in patch 2/4 (mentioned in another thread), ack the whole series.
Acked-by: Yonghong Song <yhs@fb.com>
> tools/lib/bpf/libbpf.c | 58 +++++----
> tools/testing/selftests/bpf/bpf_helpers.h | 3 +
> tools/testing/selftests/bpf/progs/bpf_flow.c | 28 ++---
> .../selftests/bpf/progs/get_cgroup_id_kern.c | 26 ++---
> .../testing/selftests/bpf/progs/netcnt_prog.c | 20 ++--
> tools/testing/selftests/bpf/progs/pyperf.h | 90 +++++++-------
> .../selftests/bpf/progs/sample_map_ret0.c | 24 ++--
> .../selftests/bpf/progs/socket_cookie_prog.c | 13 +--
> .../bpf/progs/sockmap_verdict_prog.c | 48 ++++----
> .../testing/selftests/bpf/progs/strobemeta.h | 68 +++++------
> .../selftests/bpf/progs/test_btf_newkv.c | 13 +--
> .../bpf/progs/test_get_stack_rawtp.c | 39 +++----
> .../selftests/bpf/progs/test_global_data.c | 37 +++---
> tools/testing/selftests/bpf/progs/test_l4lb.c | 65 ++++-------
> .../selftests/bpf/progs/test_l4lb_noinline.c | 65 ++++-------
> .../selftests/bpf/progs/test_map_in_map.c | 30 ++---
> .../selftests/bpf/progs/test_map_lock.c | 26 ++---
> .../testing/selftests/bpf/progs/test_obj_id.c | 12 +-
> .../bpf/progs/test_select_reuseport_kern.c | 67 ++++-------
> .../bpf/progs/test_send_signal_kern.c | 26 ++---
> .../bpf/progs/test_sock_fields_kern.c | 78 +++++--------
> .../selftests/bpf/progs/test_spin_lock.c | 36 +++---
> .../bpf/progs/test_stacktrace_build_id.c | 55 ++++-----
> .../selftests/bpf/progs/test_stacktrace_map.c | 52 +++------
> .../selftests/bpf/progs/test_tcp_estats.c | 13 +--
> .../selftests/bpf/progs/test_tcpbpf_kern.c | 26 ++---
> .../selftests/bpf/progs/test_tcpnotify_kern.c | 28 ++---
> tools/testing/selftests/bpf/progs/test_xdp.c | 26 ++---
> .../selftests/bpf/progs/test_xdp_loop.c | 26 ++---
> .../selftests/bpf/progs/test_xdp_noinline.c | 81 +++++--------
> .../selftests/bpf/progs/xdp_redirect_map.c | 12 +-
> .../testing/selftests/bpf/progs/xdping_kern.c | 12 +-
> .../selftests/bpf/test_queue_stack_map.h | 30 ++---
> .../testing/selftests/bpf/test_sockmap_kern.h | 110 +++++++++---------
> 34 files changed, 571 insertions(+), 772 deletions(-)
>
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: add test_tcp_rtt to .gitignore
From: Y Song @ 2019-07-03 22:46 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, bpf, David Miller, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko
In-Reply-To: <20190703200952.159728-1-sdf@google.com>
On Wed, Jul 3, 2019 at 1:10 PM Stanislav Fomichev <sdf@google.com> wrote:
>
> Forgot to add it in the original patch.
>
> Fixes: b55873984dab ("selftests/bpf: test BPF_SOCK_OPS_RTT_CB")
> Reported-by: Andrii Nakryiko <andriin@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> tools/testing/selftests/bpf/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/bpf/.gitignore b/tools/testing/selftests/bpf/.gitignore
> index a2f7f79c7908..90f70d2c7c22 100644
> --- a/tools/testing/selftests/bpf/.gitignore
> +++ b/tools/testing/selftests/bpf/.gitignore
> @@ -42,3 +42,4 @@ xdping
> test_sockopt
> test_sockopt_sk
> test_sockopt_multi
> +test_tcp_rtt
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
^ permalink raw reply
* pull-request: bpf-next 2019-07-03
From: Daniel Borkmann @ 2019-07-03 22:47 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, saeedm, netdev, bpf
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
There is a minor merge conflict in mlx5 due to 8960b38932be ("linux/dim:
Rename externally used net_dim members") which has been pulled into your
tree in the meantime, but resolution seems not that bad ... getting current
bpf-next out now before there's coming more on mlx5. ;) I'm Cc'ing Saeed
just so he's aware of the resolution below:
** First conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
<<<<<<< HEAD
static int mlx5e_open_cq(struct mlx5e_channel *c,
struct dim_cq_moder moder,
struct mlx5e_cq_param *param,
struct mlx5e_cq *cq)
=======
int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
struct mlx5e_cq_param *param, struct mlx5e_cq *cq)
>>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
Resolution is to take the second chunk and rename net_dim_cq_moder into
dim_cq_moder. Also the signature for mlx5e_open_cq() in ...
drivers/net/ethernet/mellanox/mlx5/core/en.h +977
... and in mlx5e_open_xsk() ...
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c +64
... needs the same rename from net_dim_cq_moder into dim_cq_moder.
** Second conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
<<<<<<< HEAD
int cpu = cpumask_first(mlx5_comp_irq_get_affinity_mask(priv->mdev, ix));
struct dim_cq_moder icocq_moder = {0, 0};
struct net_device *netdev = priv->netdev;
struct mlx5e_channel *c;
unsigned int irq;
=======
struct net_dim_cq_moder icocq_moder = {0, 0};
>>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
Take the second chunk and rename net_dim_cq_moder into dim_cq_moder
as well.
Let me know if you run into any issues. Anyway, the main changes are:
1) Long-awaited AF_XDP support for mlx5e driver, from Maxim.
2) Addition of two new per-cgroup BPF hooks for getsockopt and
setsockopt along with a new sockopt program type which allows more
fine-grained pass/reject settings for containers. Also add a sock_ops
callback that can be selectively enabled on a per-socket basis and is
executed for every RTT to help tracking TCP statistics, both features
from Stanislav.
3) Follow-up fix from loops in precision tracking which was not propagating
precision marks and as a result verifier assumed that some branches were
not taken and therefore wrongly removed as dead code, from Alexei.
4) Fix BPF cgroup release synchronization race which could lead to a
double-free if a leaf's cgroup_bpf object is released and a new BPF
program is attached to the one of ancestor cgroups in parallel, from Roman.
5) Support for bulking XDP_TX on veth devices which improves performance
in some cases by around 9%, from Toshiaki.
6) Allow for lookups into BPF devmap and improve feedback when calling into
bpf_redirect_map() as lookup is now performed right away in the helper
itself, from Toke.
7) Add support for fq's Earliest Departure Time to the Host Bandwidth
Manager (HBM) sample BPF program, from Lawrence.
8) Various cleanups and minor fixes all over the place from many others.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 7d30a7f6424e88c958c19a02f6f54ab8d25919cd:
Merge branch 'ipv6-avoid-taking-refcnt-on-dst-during-route-lookup' (2019-06-23 13:24:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
for you to fetch changes up to e5a3e259ef239f443951d401db10db7d426c9497:
Merge branch 'bpf-tcp-rtt-hook' (2019-07-03 16:52:03 +0200)
----------------------------------------------------------------
Alexei Starovoitov (2):
Merge branch 'bpf-sockopt-hooks'
bpf: fix precision tracking
Andrii Nakryiko (2):
selftests/bpf: build tests with debug info
libbpf: fix GCC8 warning for strncpy
Colin Ian King (1):
libbpf: fix spelling mistake "conflictling" -> "conflicting"
Daniel Borkmann (3):
Merge branch 'bpf-af-xdp-mlx5e'
Merge branch 'bpf-lookup-devmap'
Merge branch 'bpf-tcp-rtt-hook'
Daniel T. Lee (1):
samples: bpf: make the use of xdp samples consistent
Eric Leblond (1):
xsk: sample kernel code is now in libbpf
Ivan Khoronzhuk (1):
libbpf: fix max() type mismatch for 32bit
Jiri Benc (1):
selftests: bpf: standardize to static __always_inline
Leo Yan (1):
bpf, libbpf, smatch: Fix potential NULL pointer dereference
Maxim Mikityanskiy (16):
net/mlx5e: Attach/detach XDP program safely
xsk: Add API to check for available entries in FQ
xsk: Add getsockopt XDP_OPTIONS
libbpf: Support getsockopt XDP_OPTIONS
xsk: Change the default frame size to 4096 and allow controlling it
xsk: Return the whole xdp_desc from xsk_umem_consume_tx
net/mlx5e: Replace deprecated PCI_DMA_TODEVICE
net/mlx5e: Calculate linear RX frag size considering XSK
net/mlx5e: Allow ICO SQ to be used by multiple RQs
net/mlx5e: Refactor struct mlx5e_xdp_info
net/mlx5e: Share the XDP SQ for XDP_TX between RQs
net/mlx5e: XDP_TX from UMEM support
net/mlx5e: Consider XSK in XDP MTU limit calculation
net/mlx5e: Encapsulate open/close queues into a function
net/mlx5e: Move queue param structs to en/params.h
net/mlx5e: Add XSK zero-copy support
Michal Rostecki (1):
samples: bpf: Remove bpf_debug macro in favor of bpf_printk
Roman Gushchin (1):
bpf: fix cgroup bpf release synchronization
Stanislav Fomichev (18):
bpf: implement getsockopt and setsockopt hooks
bpf: sync bpf.h to tools/
libbpf: support sockopt hooks
selftests/bpf: test sockopt section name
selftests/bpf: add sockopt test
selftests/bpf: add sockopt test that exercises sk helpers
selftests/bpf: add sockopt test that exercises BPF_F_ALLOW_MULTI
bpf: add sockopt documentation
bpftool: support cgroup sockopt
selftests/bpf: fix -Wstrict-aliasing in test_sockopt_sk.c
bpf: add BPF_CGROUP_SOCK_OPS callback that is executed on every RTT
bpf: split shared bpf_tcp_sock and bpf_sock_ops implementation
bpf: add dsack_dups/delivered{, _ce} to bpf_tcp_sock
bpf: add icsk_retransmits to bpf_tcp_sock
bpf/tools: sync bpf.h
selftests/bpf: test BPF_SOCK_OPS_RTT_CB
samples/bpf: add sample program that periodically dumps TCP stats
samples/bpf: fix tcp_bpf.readme detach command
Toke Høiland-Jørgensen (5):
xskmap: Move non-standard list manipulation to helper
devmap/cpumap: Use flush list instead of bitmap
devmap: Rename ifindex member in bpf_redirect_info
bpf_xdp_redirect_map: Perform map lookup in eBPF helper
devmap: Allow map lookups from eBPF
Toshiaki Makita (3):
selftests, bpf: Add test for veth native XDP
xdp: Add tracepoint for bulk XDP_TX
veth: Support bulk XDP_TX
Yonghong Song (1):
bpf: fix compiler warning with CONFIG_MODULES=n
YueHaibing (1):
xdp: Make __mem_id_disconnect static
brakmo (1):
bpf: Add support for fq's EDT to HBM
Documentation/bpf/index.rst | 1 +
Documentation/bpf/prog_cgroup_sockopt.rst | 93 ++
Documentation/networking/af_xdp.rst | 16 +-
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 12 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 15 +-
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 155 ++-
.../net/ethernet/mellanox/mlx5/core/en/params.c | 108 ++-
.../net/ethernet/mellanox/mlx5/core/en/params.h | 118 ++-
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 231 +++--
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 36 +-
.../ethernet/mellanox/mlx5/core/en/xsk/Makefile | 1 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/rx.c | 192 ++++
.../net/ethernet/mellanox/mlx5/core/en/xsk/rx.h | 27 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 223 +++++
.../net/ethernet/mellanox/mlx5/core/en/xsk/setup.h | 25 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/tx.c | 111 +++
.../net/ethernet/mellanox/mlx5/core/en/xsk/tx.h | 15 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/umem.c | 267 +++++
.../net/ethernet/mellanox/mlx5/core/en/xsk/umem.h | 31 +
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 25 +-
.../ethernet/mellanox/mlx5/core/en_fs_ethtool.c | 18 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 730 +++++++++-----
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 12 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 104 +-
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 115 ++-
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 30 +
drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 42 +-
.../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 14 +-
drivers/net/ethernet/mellanox/mlx5/core/wq.h | 5 -
drivers/net/veth.c | 60 +-
include/linux/bpf-cgroup.h | 45 +
include/linux/bpf.h | 2 +
include/linux/bpf_types.h | 1 +
include/linux/filter.h | 13 +-
include/linux/list.h | 14 +
include/net/tcp.h | 8 +
include/net/xdp_sock.h | 27 +-
include/trace/events/xdp.h | 34 +-
include/uapi/linux/bpf.h | 33 +-
include/uapi/linux/if_xdp.h | 8 +
kernel/bpf/cgroup.c | 352 ++++++-
kernel/bpf/core.c | 10 +
kernel/bpf/cpumap.c | 105 +-
kernel/bpf/devmap.c | 112 +--
kernel/bpf/syscall.c | 19 +
kernel/bpf/verifier.c | 136 ++-
kernel/bpf/xskmap.c | 3 +-
kernel/trace/bpf_trace.c | 27 +-
net/core/filter.c | 269 ++++--
net/core/xdp.c | 2 +-
net/ipv4/tcp_input.c | 4 +
net/socket.c | 30 +
net/xdp/xsk.c | 36 +-
net/xdp/xsk_queue.h | 14 +
samples/bpf/Makefile | 3 +
samples/bpf/do_hbm_test.sh | 22 +-
samples/bpf/hbm.c | 18 +-
samples/bpf/hbm_edt_kern.c | 168 ++++
samples/bpf/hbm_kern.h | 40 +-
samples/bpf/ibumad_kern.c | 18 +-
samples/bpf/tcp_bpf.readme | 2 +-
samples/bpf/tcp_dumpstats_kern.c | 68 ++
samples/bpf/xdp_adjust_tail_user.c | 12 +-
samples/bpf/xdp_redirect_map_user.c | 15 +-
samples/bpf/xdp_redirect_user.c | 15 +-
samples/bpf/xdp_tx_iptunnel_user.c | 12 +-
samples/bpf/xdpsock_user.c | 44 +-
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 7 +-
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 3 +-
tools/bpf/bpftool/bash-completion/bpftool | 9 +-
tools/bpf/bpftool/cgroup.c | 5 +-
tools/bpf/bpftool/main.h | 1 +
tools/bpf/bpftool/prog.c | 3 +-
tools/include/uapi/linux/bpf.h | 26 +-
tools/include/uapi/linux/if_xdp.h | 8 +
tools/lib/bpf/libbpf.c | 23 +-
tools/lib/bpf/libbpf_probes.c | 1 +
tools/lib/bpf/xsk.c | 15 +-
tools/lib/bpf/xsk.h | 2 +-
tools/testing/selftests/bpf/.gitignore | 3 +
tools/testing/selftests/bpf/Makefile | 10 +-
tools/testing/selftests/bpf/progs/pyperf.h | 9 +-
tools/testing/selftests/bpf/progs/sockopt_multi.c | 71 ++
tools/testing/selftests/bpf/progs/sockopt_sk.c | 111 +++
tools/testing/selftests/bpf/progs/strobemeta.h | 36 +-
tools/testing/selftests/bpf/progs/tcp_rtt.c | 61 ++
tools/testing/selftests/bpf/progs/test_jhash.h | 3 +-
tools/testing/selftests/bpf/progs/test_seg6_loop.c | 23 +-
.../selftests/bpf/progs/test_verif_scale2.c | 2 +-
.../testing/selftests/bpf/progs/xdp_redirect_map.c | 31 +
tools/testing/selftests/bpf/progs/xdp_tx.c | 12 +
tools/testing/selftests/bpf/test_section_names.c | 10 +
tools/testing/selftests/bpf/test_sockopt.c | 1021 ++++++++++++++++++++
tools/testing/selftests/bpf/test_sockopt_multi.c | 374 +++++++
tools/testing/selftests/bpf/test_sockopt_sk.c | 211 ++++
tools/testing/selftests/bpf/test_tcp_rtt.c | 254 +++++
tools/testing/selftests/bpf/test_xdp_veth.sh | 118 +++
98 files changed, 6197 insertions(+), 841 deletions(-)
create mode 100644 Documentation/bpf/prog_cgroup_sockopt.rst
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/Makefile
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.h
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.h
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.h
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/umem.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/umem.h
create mode 100644 samples/bpf/hbm_edt_kern.c
create mode 100644 samples/bpf/tcp_dumpstats_kern.c
create mode 100644 tools/testing/selftests/bpf/progs/sockopt_multi.c
create mode 100644 tools/testing/selftests/bpf/progs/sockopt_sk.c
create mode 100644 tools/testing/selftests/bpf/progs/tcp_rtt.c
create mode 100644 tools/testing/selftests/bpf/progs/xdp_redirect_map.c
create mode 100644 tools/testing/selftests/bpf/progs/xdp_tx.c
create mode 100644 tools/testing/selftests/bpf/test_sockopt.c
create mode 100644 tools/testing/selftests/bpf/test_sockopt_multi.c
create mode 100644 tools/testing/selftests/bpf/test_sockopt_sk.c
create mode 100644 tools/testing/selftests/bpf/test_tcp_rtt.c
create mode 100755 tools/testing/selftests/bpf/test_xdp_veth.sh
^ permalink raw reply
* Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
From: Matthias Kaehlcke @ 2019-07-03 22:56 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <3e47639a-bbbb-f438-bc66-a29423090e95@gmail.com>
On Wed, Jul 03, 2019 at 11:27:41PM +0200, Heiner Kallweit wrote:
> On 03.07.2019 23:24, Matthias Kaehlcke wrote:
> > On Wed, Jul 03, 2019 at 11:01:09PM +0200, Heiner Kallweit wrote:
> >> On 03.07.2019 22:36, Matthias Kaehlcke wrote:
> >>> On Wed, Jul 03, 2019 at 10:12:12PM +0200, Heiner Kallweit wrote:
> >>>> On 03.07.2019 21:37, Matthias Kaehlcke wrote:
> >>>>> The RTL8211E has extension pages, which can be accessed after
> >>>>> selecting a page through a custom method. Add a function to
> >>>>> modify bits in a register of an extension page and a helper for
> >>>>> selecting an ext page.
> >>>>>
> >>>>> rtl8211e_modify_ext_paged() is inspired by its counterpart
> >>>>> phy_modify_paged().
> >>>>>
> >>>>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> >>>>> ---
> >>>>> Changes in v2:
> >>>>> - assign .read/write_page handlers for RTL8211E
> >>>>
> >>>> Maybe this was planned, but it's not part of the patch.
> >>>
> >>> Oops, it was definitely there when I tested ... I guess this got
> >>> somehow lost when changing the patch order and resolving minor
> >>> conflicts, seems like I only build tested after that :/
> >>>
> >> RTL8211E also supports normal pages (reg 0x1f = page).
> >> See e.g. rtl8168e_2_hw_phy_config in the r8169 driver, this network
> >> chip has an integrated RTL8211E PHY. There settings on page 3 and 5
> >> are done.
> >> Therefore I would prefer to use .read/write_page for normal paging
> >> in all Realtek PHY drivers. Means the code here would remain as it
> >> is and just the changelog would need to be fixed.
> >
> > Do I understand correctly that you suggest an additional patch that
> > assigns .read/write_page() for all entries of realtek_drvs?
> >
>
> No, basically all the Realtek PHY drivers use the following already:
> .read_page = rtl821x_read_page,
> .write_page = rtl821x_write_page,
> What I mean is that this should stay as it is, and not be overwritten
> with the extended paging.
I now see the source of our/my misunderstanding. I'm working on a 4.19
kernel, which doesn't have your recent patch:
commit daf3ddbe11a2ff74c95bc814df8e5fe3201b4cb5
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri May 10 22:11:26 2019 +0200
net: phy: realtek: add missing page operations
That's what I intended to do for RTL8211E, no need to overwrite it
with the extended paging.
Thanks
Matthias
^ permalink raw reply
* [PATCH iproute2 1/2] tc: added mask parameter in skbedit action
From: Roman Mashak @ 2019-07-03 23:05 UTC (permalink / raw)
To: stephen; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
Add 32-bit missing mask attribute in iproute2/tc, which has been long
supported by the kernel side.
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
tc/m_skbedit.c | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/tc/m_skbedit.c b/tc/m_skbedit.c
index b6b839f8ef6c..f47c9705a990 100644
--- a/tc/m_skbedit.c
+++ b/tc/m_skbedit.c
@@ -33,7 +33,7 @@ static void explain(void)
fprintf(stderr, "Usage: ... skbedit <[QM] [PM] [MM] [PT] [IF]>\n"
"QM = queue_mapping QUEUE_MAPPING\n"
"PM = priority PRIORITY\n"
- "MM = mark MARK\n"
+ "MM = mark MARK[/MASK]\n"
"PT = ptype PACKETYPE\n"
"IF = inheritdsfield\n"
"PACKETYPE = is one of:\n"
@@ -41,6 +41,7 @@ static void explain(void)
"QUEUE_MAPPING = device transmit queue to use\n"
"PRIORITY = classID to assign to priority field\n"
"MARK = firewall mark to set\n"
+ "MASK = mask applied to firewall mark (0xffffffff by default)\n"
"note: inheritdsfield maps DS field to skb->priority\n");
}
@@ -61,7 +62,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
struct rtattr *tail;
unsigned int tmp;
__u16 queue_mapping, ptype;
- __u32 flags = 0, priority, mark;
+ __u32 flags = 0, priority, mark, mask;
__u64 pure_flags = 0;
struct tc_skbedit sel = { 0 };
@@ -89,12 +90,26 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
}
ok++;
} else if (matches(*argv, "mark") == 0) {
- flags |= SKBEDIT_F_MARK;
+ char *slash;
+
NEXT_ARG();
+ slash = strchr(*argv, '/');
+ if (slash)
+ *slash = '\0';
+
+ flags |= SKBEDIT_F_MARK;
if (get_u32(&mark, *argv, 0)) {
fprintf(stderr, "Illegal mark\n");
return -1;
}
+
+ if (slash) {
+ if (get_u32(&mask, slash + 1, 0)) {
+ fprintf(stderr, "Illegal mask\n");
+ return -1;
+ }
+ flags |= SKBEDIT_F_MASK;
+ }
ok++;
} else if (matches(*argv, "ptype") == 0) {
@@ -133,7 +148,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
if (matches(*argv, "index") == 0) {
NEXT_ARG();
if (get_u32(&sel.index, *argv, 10)) {
- fprintf(stderr, "Pedit: Illegal \"index\"\n");
+ fprintf(stderr, "skbedit: Illegal \"index\"\n");
return -1;
}
argc--;
@@ -159,6 +174,9 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
if (flags & SKBEDIT_F_MARK)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_MARK,
&mark, sizeof(mark));
+ if (flags & SKBEDIT_F_MASK)
+ addattr_l(n, MAX_MSG, TCA_SKBEDIT_MASK,
+ &mask, sizeof(mask));
if (flags & SKBEDIT_F_PTYPE)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_PTYPE,
&ptype, sizeof(ptype));
@@ -206,6 +224,10 @@ static int print_skbedit(struct action_util *au, FILE *f, struct rtattr *arg)
print_uint(PRINT_ANY, "mark", " mark %u",
rta_getattr_u32(tb[TCA_SKBEDIT_MARK]));
}
+ if (tb[TCA_SKBEDIT_MASK]) {
+ print_uint(PRINT_ANY, "mask", "/0x%x",
+ rta_getattr_u32(tb[TCA_SKBEDIT_MASK]));
+ }
if (tb[TCA_SKBEDIT_PTYPE] != NULL) {
ptype = rta_getattr_u16(tb[TCA_SKBEDIT_PTYPE]);
if (ptype == PACKET_HOST)
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2 2/2] tc: document 'mask' parameter in skbedit man page
From: Roman Mashak @ 2019-07-03 23:05 UTC (permalink / raw)
To: stephen; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
In-Reply-To: <1562195132-9829-1-git-send-email-mrv@mojatatu.com>
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
man/man8/tc-skbedit.8 | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/man/man8/tc-skbedit.8 b/man/man8/tc-skbedit.8
index 2459198261e6..704f63bdb061 100644
--- a/man/man8/tc-skbedit.8
+++ b/man/man8/tc-skbedit.8
@@ -9,8 +9,7 @@ skbedit - SKB editing action
.IR QUEUE_MAPPING " ] ["
.B priority
.IR PRIORITY " ] ["
-.B mark
-.IR MARK " ] ["
+.BI mark " MARK\fR[\fB/\fIMASK] ] ["
.B ptype
.IR PTYPE " ] ["
.BR inheritdsfield " ]"
@@ -49,12 +48,14 @@ or a hexadecimal major class ID optionally followed by a colon
.RB ( : )
and a hexadecimal minor class ID.
.TP
-.BI mark " MARK"
+.BI mark " MARK\fR[\fB/\fIMASK]"
Change the packet's firewall mark value.
.I MARK
is an unsigned 32bit value in automatically detected format (i.e., prefix with
.RB ' 0x '
for hexadecimal interpretation, etc.).
+.I MASK
+defines the 32-bit mask selecting bits of mark value. Default is 0xffffffff.
.TP
.BI ptype " PTYPE"
Override the packet's type. Useful for setting packet type to host when
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 0/2] Mellanox, mlx5 devlink versions query
From: Saeed Mahameed @ 2019-07-03 23:07 UTC (permalink / raw)
To: David Miller; +Cc: Saeed Mahameed, Linux Netdev List
In-Reply-To: <20190703.134935.540885263693556753.davem@davemloft.net>
On Wed, Jul 3, 2019 at 1:49 PM David Miller <davem@davemloft.net> wrote:
>
> From: David Miller <davem@davemloft.net>
> Date: Wed, 03 Jul 2019 13:47:00 -0700 (PDT)
>
> > From: Saeed Mahameed <saeedm@mellanox.com>
> > Date: Tue, 2 Jul 2019 23:55:07 +0000
> >
> >> This humble 2 patch series from Shay adds the support for devlink fw
> >> versions query to mlx5 driver.
> >>
> >> In the first patch we implement the needed fw commands to support this
> >> feature.
> >> In the 2nd patch we implement the devlink callbacks themselves.
> >>
> >> I am not sending this as a pull request since i am not sure when my next
> >> pull request is going to be ready, and these two patches are straight
> >> forward net-next patches.
> >
> > Series applied to net-next, thanks.
>
> This doesn't build, there is some dependency...
>
> [davem@localhost net-next]$ make -s -j14
> In file included from ./include/linux/mlx5/driver.h:51,
> from drivers/net/ethernet/mellanox/mlx5/core/fw.c:33:
> drivers/net/ethernet/mellanox/mlx5/core/fw.c: In function ‘mlx5_reg_mcqi_query’:
> ./include/linux/mlx5/device.h:68:36: error: invalid application of ‘sizeof’ to incomplete type ‘union mlx5_ifc_mcqi_reg_data_bits’
> #define MLX5_UN_SZ_DW(typ) (sizeof(union mlx5_ifc_##typ##_bits) / 32)
> ^~~~~
Yep, My bad :(, I thought [1] was part of my last pull, but it wasn't
One way to solve this is if you pull latest mlx5-next branch form:
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git
All patches there already passed review on net-next and rdma-next mailing lists.
Or just wait for my next pull request.
sorry for this!
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/commit/?h=mlx5-next&id=a82e0b5bdac29d9719d3ca2df01494a7947351aa
^ permalink raw reply
* Re: pull-request: bpf-next 2019-07-03
From: Saeed Mahameed @ 2019-07-03 23:11 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, Alexei Starovoitov, Saeed Mahameed,
Linux Netdev List, bpf
In-Reply-To: <20190703224740.15354-1-daniel@iogearbox.net>
On Wed, Jul 3, 2019 at 3:47 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> Hi David,
>
> The following pull-request contains BPF updates for your *net-next* tree.
>
> There is a minor merge conflict in mlx5 due to 8960b38932be ("linux/dim:
> Rename externally used net_dim members") which has been pulled into your
> tree in the meantime, but resolution seems not that bad ... getting current
> bpf-next out now before there's coming more on mlx5. ;) I'm Cc'ing Saeed
> just so he's aware of the resolution below:
>
> ** First conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
>
> <<<<<<< HEAD
> static int mlx5e_open_cq(struct mlx5e_channel *c,
> struct dim_cq_moder moder,
> struct mlx5e_cq_param *param,
> struct mlx5e_cq *cq)
> =======
> int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
> struct mlx5e_cq_param *param, struct mlx5e_cq *cq)
> >>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
>
> Resolution is to take the second chunk and rename net_dim_cq_moder into
> dim_cq_moder. Also the signature for mlx5e_open_cq() in ...
>
> drivers/net/ethernet/mellanox/mlx5/core/en.h +977
>
> ... and in mlx5e_open_xsk() ...
>
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c +64
>
> ... needs the same rename from net_dim_cq_moder into dim_cq_moder.
>
> ** Second conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
>
> <<<<<<< HEAD
> int cpu = cpumask_first(mlx5_comp_irq_get_affinity_mask(priv->mdev, ix));
> struct dim_cq_moder icocq_moder = {0, 0};
> struct net_device *netdev = priv->netdev;
> struct mlx5e_channel *c;
> unsigned int irq;
> =======
> struct net_dim_cq_moder icocq_moder = {0, 0};
> >>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
>
> Take the second chunk and rename net_dim_cq_moder into dim_cq_moder
> as well.
>
Thank you Daniel, Looks Good,
I didn't test this since i am traveling, will double check tomorrow.
but basically all you need is to pass the build.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: fix "alu with different scalars 1" on s390
From: Y Song @ 2019-07-03 23:11 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, netdev
In-Reply-To: <20190703160346.63982-1-iii@linux.ibm.com>
On Wed, Jul 3, 2019 at 9:06 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> BPF_LDX_MEM is used to load the least significant byte of the retrieved
> test_val.index, however, on big-endian machines it ends up retrieving
> the most significant byte.
>
> Use the correct least significant byte offset on big-endian machines.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
> tools/testing/selftests/bpf/verifier/value_ptr_arith.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/verifier/value_ptr_arith.c b/tools/testing/selftests/bpf/verifier/value_ptr_arith.c
> index c3de1a2c9dc5..3b221bb4b317 100644
> --- a/tools/testing/selftests/bpf/verifier/value_ptr_arith.c
> +++ b/tools/testing/selftests/bpf/verifier/value_ptr_arith.c
> @@ -183,7 +183,11 @@
> BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1),
> BPF_EXIT_INSN(),
> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> BPF_LDX_MEM(BPF_B, BPF_REG_1, BPF_REG_0, 0),
> +#else
> + BPF_LDX_MEM(BPF_B, BPF_REG_1, BPF_REG_0, sizeof(int) - 1),
> +#endif
> BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0, 3),
> BPF_MOV64_IMM(BPF_REG_2, 0),
> BPF_MOV64_IMM(BPF_REG_3, 0x100000),
> --
> 2.21.0
>
In verifier directory, we mostly use __BYTE_ORDER macros.
-bash-4.4$ pwd
/home/yhs/work/net-next/tools/testing/selftests/bpf/verifier
-bash-4.4$ grep __BYTE_ORDER *
ctx_skb.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
ctx_skb.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
ctx_skb.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
ctx_skb.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
ctx_skb.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
ctx_skb.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
ctx_skb.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
lwt.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
perf_event_sample_period.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
perf_event_sample_period.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
perf_event_sample_period.c:#if __BYTE_ORDER == __LITTLE_ENDIAN
-bash-4.4$
Your code above should also work (it requires gcc 4.6 and later, but
we require newer gcc compiler anyway).
Maybe if the above __BYTE_ORDER works for s360, maybe using that is
better for consistency?
^ permalink raw reply
* Re: pull-request: bpf-next 2019-07-03
From: Daniel Borkmann @ 2019-07-03 23:13 UTC (permalink / raw)
To: Saeed Mahameed
Cc: David S. Miller, Alexei Starovoitov, Saeed Mahameed,
Linux Netdev List, bpf
In-Reply-To: <CALzJLG9vsv3A=SAGA97_HUZxdCr7gAMET8yTWofD6Wsq_7sCuA@mail.gmail.com>
On 07/04/2019 01:11 AM, Saeed Mahameed wrote:
> On Wed, Jul 3, 2019 at 3:47 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>
>> Hi David,
>>
>> The following pull-request contains BPF updates for your *net-next* tree.
>>
>> There is a minor merge conflict in mlx5 due to 8960b38932be ("linux/dim:
>> Rename externally used net_dim members") which has been pulled into your
>> tree in the meantime, but resolution seems not that bad ... getting current
>> bpf-next out now before there's coming more on mlx5. ;) I'm Cc'ing Saeed
>> just so he's aware of the resolution below:
>>
>> ** First conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
>>
>> <<<<<<< HEAD
>> static int mlx5e_open_cq(struct mlx5e_channel *c,
>> struct dim_cq_moder moder,
>> struct mlx5e_cq_param *param,
>> struct mlx5e_cq *cq)
>> =======
>> int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
>> struct mlx5e_cq_param *param, struct mlx5e_cq *cq)
>> >>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
>>
>> Resolution is to take the second chunk and rename net_dim_cq_moder into
>> dim_cq_moder. Also the signature for mlx5e_open_cq() in ...
>>
>> drivers/net/ethernet/mellanox/mlx5/core/en.h +977
>>
>> ... and in mlx5e_open_xsk() ...
>>
>> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c +64
>>
>> ... needs the same rename from net_dim_cq_moder into dim_cq_moder.
>>
>> ** Second conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
>>
>> <<<<<<< HEAD
>> int cpu = cpumask_first(mlx5_comp_irq_get_affinity_mask(priv->mdev, ix));
>> struct dim_cq_moder icocq_moder = {0, 0};
>> struct net_device *netdev = priv->netdev;
>> struct mlx5e_channel *c;
>> unsigned int irq;
>> =======
>> struct net_dim_cq_moder icocq_moder = {0, 0};
>> >>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
>>
>> Take the second chunk and rename net_dim_cq_moder into dim_cq_moder
>> as well.
>>
>
> Thank you Daniel, Looks Good,
> I didn't test this since i am traveling, will double check tomorrow.
> but basically all you need is to pass the build.
That was definitely the case for me, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: fix test_align liveliness expectations
From: Y Song @ 2019-07-03 23:20 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, bpf, David Miller, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190703212907.189141-1-sdf@google.com>
On Wed, Jul 3, 2019 at 2:31 PM Stanislav Fomichev <sdf@google.com> wrote:
>
> Commit 2589726d12a1 ("bpf: introduce bounded loops") caused a change
> in the way some registers liveliness is reported in the test_align.
> Add missing "_w" to a couple of tests. Note, there are no offset
> changes!
>
> Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Matthias Kaehlcke @ 2019-07-03 23:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Heiner Kallweit, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <e8fe7baf-e4e0-c713-7b93-07a3859c33c6@gmail.com>
Hi Florian,
On Wed, Jul 03, 2019 at 02:37:47PM -0700, Florian Fainelli wrote:
> On 7/3/19 12:37 PM, Matthias Kaehlcke wrote:
> > The LED behavior of some Realtek PHYs is configurable. Add the
> > property 'realtek,led-modes' to specify the configuration of the
> > LEDs.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > Changes in v2:
> > - patch added to the series
> > ---
> > .../devicetree/bindings/net/realtek.txt | 9 +++++++++
> > include/dt-bindings/net/realtek.h | 17 +++++++++++++++++
> > 2 files changed, 26 insertions(+)
> > create mode 100644 include/dt-bindings/net/realtek.h
> >
> > diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
> > index 71d386c78269..40b0d6f9ee21 100644
> > --- a/Documentation/devicetree/bindings/net/realtek.txt
> > +++ b/Documentation/devicetree/bindings/net/realtek.txt
> > @@ -9,6 +9,12 @@ Optional properties:
> >
> > SSC is only available on some Realtek PHYs (e.g. RTL8211E).
> >
> > +- realtek,led-modes: LED mode configuration.
> > +
> > + A 0..3 element vector, with each element configuring the operating
> > + mode of an LED. Omitted LEDs are turned off. Allowed values are
> > + defined in "include/dt-bindings/net/realtek.h".
>
> This should probably be made more general and we should define LED modes
> that makes sense regardless of the PHY device, introduce a set of
> generic functions for validating and then add new function pointer for
> setting the LED configuration to the PHY driver. This would allow to be
> more future proof where each PHY driver could expose standard LEDs class
> devices to user-space, and it would also allow facilities like: ethtool
> -p to plug into that.
>
> Right now, each driver invents its own way of configuring LEDs, that
> does not scale, and there is not really a good reason for that other
> than reviewing drivers in isolation and therefore making it harder to
> extract the commonality. Yes, I realize that since you are the latest
> person submitting something in that area, you are being selected :)
I see the merit of your proposal to come up with a generic mechanism
to configure Ethernet LEDs, however I can't justify spending much of
my work time on this. If it is deemed useful I'm happy to send another
version of the current patchset that addresses the reviewer's comments,
but if the implementation of a generic LED configuration interface is
a requirement I will have to abandon at least the LED configuration
part of this series.
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: make verifier loop tests arch independent
From: Y Song @ 2019-07-03 23:39 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, bpf, David Miller, Alexei Starovoitov, Daniel Borkmann,
Ilya Leoshkevich
In-Reply-To: <20190703205100.142904-1-sdf@google.com>
On Wed, Jul 3, 2019 at 1:51 PM Stanislav Fomichev <sdf@google.com> wrote:
>
> Take the first x bytes of pt_regs for scalability tests, there is
> no real reason we need x86 specific rax.
>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
> ---
> tools/testing/selftests/bpf/progs/loop1.c | 3 ++-
> tools/testing/selftests/bpf/progs/loop2.c | 3 ++-
> tools/testing/selftests/bpf/progs/loop3.c | 3 ++-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/progs/loop1.c b/tools/testing/selftests/bpf/progs/loop1.c
> index dea395af9ea9..d530c61d2517 100644
> --- a/tools/testing/selftests/bpf/progs/loop1.c
> +++ b/tools/testing/selftests/bpf/progs/loop1.c
> @@ -14,11 +14,12 @@ SEC("raw_tracepoint/kfree_skb")
> int nested_loops(volatile struct pt_regs* ctx)
> {
> int i, j, sum = 0, m;
> + volatile int *any_reg = (volatile int *)ctx;
>
> for (j = 0; j < 300; j++)
> for (i = 0; i < j; i++) {
> if (j & 1)
> - m = ctx->rax;
> + m = *any_reg;
I agree. ctx->rax here is only to generate some operations, which
cannot be optimized away by the compiler. dereferencing a volatile
pointee may just serve that purpose.
Comparing the byte code generated with ctx->rax and *any_reg, they are
slightly different. Using *any_reg is slighly worse, but this should
be still okay for the test.
> else
> m = j;
> sum += i * m;
> diff --git a/tools/testing/selftests/bpf/progs/loop2.c b/tools/testing/selftests/bpf/progs/loop2.c
> index 0637bd8e8bcf..91bb89d901e3 100644
> --- a/tools/testing/selftests/bpf/progs/loop2.c
> +++ b/tools/testing/selftests/bpf/progs/loop2.c
> @@ -14,9 +14,10 @@ SEC("raw_tracepoint/consume_skb")
> int while_true(volatile struct pt_regs* ctx)
> {
> int i = 0;
> + volatile int *any_reg = (volatile int *)ctx;
>
> while (true) {
> - if (ctx->rax & 1)
> + if (*any_reg & 1)
> i += 3;
> else
> i += 7;
> diff --git a/tools/testing/selftests/bpf/progs/loop3.c b/tools/testing/selftests/bpf/progs/loop3.c
> index 30a0f6cba080..3a7f12d7186c 100644
> --- a/tools/testing/selftests/bpf/progs/loop3.c
> +++ b/tools/testing/selftests/bpf/progs/loop3.c
> @@ -14,9 +14,10 @@ SEC("raw_tracepoint/consume_skb")
> int while_true(volatile struct pt_regs* ctx)
> {
> __u64 i = 0, sum = 0;
> + volatile __u64 *any_reg = (volatile __u64 *)ctx;
> do {
> i++;
> - sum += ctx->rax;
> + sum += *any_reg;
> } while (i < 0x100000000ULL);
> return sum;
> }
> --
> 2.22.0.410.gd8fdbe21b5-goog
Ilya Leoshkevich (iii@linux.ibm.com, cc'ed) has another patch set
trying to solve this problem by introducing s360 arch register access
macros. I guess for now that patch set is not needed any more?
^ permalink raw reply
* Re: [PATCH net-next v5 0/5] Add MPLS actions to TC
From: Cong Wang @ 2019-07-04 0:09 UTC (permalink / raw)
To: John Hurley
Cc: Linux Kernel Network Developers, David Miller, Jiri Pirko,
David Ahern, Willem de Bruijn, Simon Horman, Jakub Kicinski,
oss-drivers
In-Reply-To: <1562113531-29296-1-git-send-email-john.hurley@netronome.com>
On Tue, Jul 2, 2019 at 5:25 PM John Hurley <john.hurley@netronome.com> wrote:
>
> This patchset introduces a new TC action module that allows the
> manipulation of the MPLS headers of packets. The code impliments
> functionality including push, pop, and modify.
>
> Also included are tests for the new funtionality. Note that these will
> require iproute2 changes to be submitted soon.
>
> NOTE: these patches are applied to net-next along with the patch:
> [PATCH net 1/1] net: openvswitch: fix csum updates for MPLS actions
> This patch has been accepted into net but, at time of posting, is not yet
> in net-next.
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Thanks for the update.
^ permalink raw reply
* [Patch net 0/3] hsr: a few bug fixes
From: Cong Wang @ 2019-07-04 0:21 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Arvid Brodin
This patchset contains 3 bug fixes for hsr triggered by a syzbot
reproducer, please check each patch for details.
Cc: Arvid Brodin <arvid.brodin@alten.se>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Cong Wang (3):
hsr: fix a memory leak in hsr_del_port()
hsr: implement dellink to clean up resources
hsr: fix a NULL pointer deref in hsr_dev_xmit()
---
net/hsr/hsr_device.c | 29 ++++++++++++++++-------------
net/hsr/hsr_device.h | 1 +
net/hsr/hsr_framereg.c | 11 ++++++++++-
net/hsr/hsr_framereg.h | 3 ++-
net/hsr/hsr_netlink.c | 7 +++++++
net/hsr/hsr_slave.c | 1 +
6 files changed, 37 insertions(+), 15 deletions(-)
--
2.21.0
^ permalink raw reply
* [Patch net 1/3] hsr: fix a memory leak in hsr_del_port()
From: Cong Wang @ 2019-07-04 0:21 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Arvid Brodin
In-Reply-To: <20190704002114.29004-1-xiyou.wangcong@gmail.com>
hsr_del_port() should release all the resources allocated
in hsr_add_port().
As a consequence of this change, hsr_for_each_port() is no
longer safe to work with hsr_del_port(), switch to
list_for_each_entry_safe() as we always hold RTNL lock.
Cc: Arvid Brodin <arvid.brodin@alten.se>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/hsr/hsr_device.c | 6 ++++--
net/hsr/hsr_slave.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index 15c72065df79..f48b6a275cf0 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -351,13 +351,14 @@ static void hsr_dev_destroy(struct net_device *hsr_dev)
{
struct hsr_priv *hsr;
struct hsr_port *port;
+ struct hsr_port *tmp;
hsr = netdev_priv(hsr_dev);
hsr_debugfs_term(hsr);
rtnl_lock();
- hsr_for_each_port(hsr, port)
+ list_for_each_entry_safe(port, tmp, &hsr->ports, port_list)
hsr_del_port(port);
rtnl_unlock();
@@ -428,6 +429,7 @@ int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2],
{
struct hsr_priv *hsr;
struct hsr_port *port;
+ struct hsr_port *tmp;
int res;
hsr = netdev_priv(hsr_dev);
@@ -492,7 +494,7 @@ int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2],
return 0;
fail:
- hsr_for_each_port(hsr, port)
+ list_for_each_entry_safe(port, tmp, &hsr->ports, port_list)
hsr_del_port(port);
err_add_port:
hsr_del_node(&hsr->self_node_db);
diff --git a/net/hsr/hsr_slave.c b/net/hsr/hsr_slave.c
index 88b6705ded83..ee561297d8a7 100644
--- a/net/hsr/hsr_slave.c
+++ b/net/hsr/hsr_slave.c
@@ -193,4 +193,5 @@ void hsr_del_port(struct hsr_port *port)
if (port != master)
dev_put(port->dev);
+ kfree(port);
}
--
2.21.0
^ permalink raw reply related
* [Patch net 2/3] hsr: implement dellink to clean up resources
From: Cong Wang @ 2019-07-04 0:21 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, syzbot+c6167ec3de7def23d1e8, Arvid Brodin
In-Reply-To: <20190704002114.29004-1-xiyou.wangcong@gmail.com>
hsr_link_ops implements ->newlink() but not ->dellink(),
which leads that resources not released after removing the device,
particularly the entries in self_node_db and node_db.
So add ->dellink() implementation to replace the priv_destructor.
This also makes the code slightly easier to understand.
Reported-by: syzbot+c6167ec3de7def23d1e8@syzkaller.appspotmail.com
Cc: Arvid Brodin <arvid.brodin@alten.se>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/hsr/hsr_device.c | 13 +++++--------
net/hsr/hsr_device.h | 1 +
net/hsr/hsr_framereg.c | 11 ++++++++++-
net/hsr/hsr_framereg.h | 3 ++-
net/hsr/hsr_netlink.c | 7 +++++++
5 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index f48b6a275cf0..4ea7d54a8262 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -344,10 +344,7 @@ static void hsr_announce(struct timer_list *t)
rcu_read_unlock();
}
-/* According to comments in the declaration of struct net_device, this function
- * is "Called from unregister, can be used to call free_netdev". Ok then...
- */
-static void hsr_dev_destroy(struct net_device *hsr_dev)
+void hsr_dev_destroy(struct net_device *hsr_dev)
{
struct hsr_priv *hsr;
struct hsr_port *port;
@@ -357,15 +354,16 @@ static void hsr_dev_destroy(struct net_device *hsr_dev)
hsr_debugfs_term(hsr);
- rtnl_lock();
list_for_each_entry_safe(port, tmp, &hsr->ports, port_list)
hsr_del_port(port);
- rtnl_unlock();
del_timer_sync(&hsr->prune_timer);
del_timer_sync(&hsr->announce_timer);
synchronize_rcu();
+
+ hsr_del_self_node(&hsr->self_node_db);
+ hsr_del_nodes(&hsr->node_db);
}
static const struct net_device_ops hsr_device_ops = {
@@ -392,7 +390,6 @@ void hsr_dev_setup(struct net_device *dev)
dev->priv_flags |= IFF_NO_QUEUE;
dev->needs_free_netdev = true;
- dev->priv_destructor = hsr_dev_destroy;
dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDMA |
NETIF_F_GSO_MASK | NETIF_F_HW_CSUM |
@@ -497,7 +494,7 @@ int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2],
list_for_each_entry_safe(port, tmp, &hsr->ports, port_list)
hsr_del_port(port);
err_add_port:
- hsr_del_node(&hsr->self_node_db);
+ hsr_del_self_node(&hsr->self_node_db);
return res;
}
diff --git a/net/hsr/hsr_device.h b/net/hsr/hsr_device.h
index 6d7759c4f5f9..d0fa6b0696d2 100644
--- a/net/hsr/hsr_device.h
+++ b/net/hsr/hsr_device.h
@@ -14,6 +14,7 @@
void hsr_dev_setup(struct net_device *dev);
int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2],
unsigned char multicast_spec, u8 protocol_version);
+void hsr_dev_destroy(struct net_device *hsr_dev);
void hsr_check_carrier_and_operstate(struct hsr_priv *hsr);
bool is_hsr_master(struct net_device *dev);
int hsr_get_max_mtu(struct hsr_priv *hsr);
diff --git a/net/hsr/hsr_framereg.c b/net/hsr/hsr_framereg.c
index 2d7a19750436..292be446007b 100644
--- a/net/hsr/hsr_framereg.c
+++ b/net/hsr/hsr_framereg.c
@@ -104,7 +104,7 @@ int hsr_create_self_node(struct list_head *self_node_db,
return 0;
}
-void hsr_del_node(struct list_head *self_node_db)
+void hsr_del_self_node(struct list_head *self_node_db)
{
struct hsr_node *node;
@@ -117,6 +117,15 @@ void hsr_del_node(struct list_head *self_node_db)
}
}
+void hsr_del_nodes(struct list_head *node_db)
+{
+ struct hsr_node *node;
+ struct hsr_node *tmp;
+
+ list_for_each_entry_safe(node, tmp, node_db, mac_list)
+ kfree(node);
+}
+
/* Allocate an hsr_node and add it to node_db. 'addr' is the node's address_A;
* seq_out is used to initialize filtering of outgoing duplicate frames
* originating from the newly added node.
diff --git a/net/hsr/hsr_framereg.h b/net/hsr/hsr_framereg.h
index a3bdcdab469d..89a3ce38151d 100644
--- a/net/hsr/hsr_framereg.h
+++ b/net/hsr/hsr_framereg.h
@@ -12,7 +12,8 @@
struct hsr_node;
-void hsr_del_node(struct list_head *self_node_db);
+void hsr_del_self_node(struct list_head *self_node_db);
+void hsr_del_nodes(struct list_head *node_db);
struct hsr_node *hsr_add_node(struct list_head *node_db, unsigned char addr[],
u16 seq_out);
struct hsr_node *hsr_get_node(struct hsr_port *port, struct sk_buff *skb,
diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c
index 8f8337f893ba..160edd24de4e 100644
--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -69,6 +69,12 @@ static int hsr_newlink(struct net *src_net, struct net_device *dev,
return hsr_dev_finalize(dev, link, multicast_spec, hsr_version);
}
+static void hsr_dellink(struct net_device *hsr_dev, struct list_head *head)
+{
+ hsr_dev_destroy(hsr_dev);
+ unregister_netdevice_queue(hsr_dev, head);
+}
+
static int hsr_fill_info(struct sk_buff *skb, const struct net_device *dev)
{
struct hsr_priv *hsr;
@@ -113,6 +119,7 @@ static struct rtnl_link_ops hsr_link_ops __read_mostly = {
.priv_size = sizeof(struct hsr_priv),
.setup = hsr_dev_setup,
.newlink = hsr_newlink,
+ .dellink = hsr_dellink,
.fill_info = hsr_fill_info,
};
--
2.21.0
^ permalink raw reply related
* [Patch net 3/3] hsr: fix a NULL pointer deref in hsr_dev_xmit()
From: Cong Wang @ 2019-07-04 0:21 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Arvid Brodin
In-Reply-To: <20190704002114.29004-1-xiyou.wangcong@gmail.com>
hsr_port_get_hsr() could return NULL and kernel
could crash:
BUG: kernel NULL pointer dereference, address: 0000000000000010
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 8000000074b84067 P4D 8000000074b84067 PUD 7057d067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 754 Comm: a.out Not tainted 5.2.0-rc6+ #718
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
RIP: 0010:hsr_dev_xmit+0x20/0x31
Code: 48 8b 1b eb e0 5b 5d 41 5c c3 66 66 66 66 90 55 48 89 fd 48 8d be 40 0b 00 00 be 04 00 00 00 e8 ee f2 ff ff 48 89 ef 48 89 c6 <48> 8b 40 10 48 89 45 10 e8 6c 1b 00 00 31 c0 5d c3 66 66 66 66 90
RSP: 0018:ffffb5b400003c48 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff9821b4509a88 RCX: 0000000000000000
RDX: ffff9821b4509a88 RSI: 0000000000000000 RDI: ffff9821bc3fc7c0
RBP: ffff9821bc3fc7c0 R08: 0000000000000000 R09: 00000000000c2019
R10: 0000000000000000 R11: 0000000000000002 R12: ffff9821bc3fc7c0
R13: ffff9821b4509a88 R14: 0000000000000000 R15: 000000000000006e
FS: 00007fee112a1800(0000) GS:ffff9821bd800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000010 CR3: 000000006e9ce000 CR4: 00000000000406f0
Call Trace:
<IRQ>
netdev_start_xmit+0x1b/0x38
dev_hard_start_xmit+0x121/0x21e
? validate_xmit_skb.isra.0+0x19/0x1e3
__dev_queue_xmit+0x74c/0x823
? lockdep_hardirqs_on+0x12b/0x17d
ip6_finish_output2+0x3d3/0x42c
? ip6_mtu+0x55/0x5c
? mld_sendpack+0x191/0x229
mld_sendpack+0x191/0x229
mld_ifc_timer_expire+0x1f7/0x230
? mld_dad_timer_expire+0x58/0x58
call_timer_fn+0x12e/0x273
__run_timers.part.0+0x174/0x1b5
? mld_dad_timer_expire+0x58/0x58
? sched_clock_cpu+0x10/0xad
? mark_lock+0x26/0x1f2
? __lock_is_held+0x40/0x71
run_timer_softirq+0x26/0x48
__do_softirq+0x1af/0x392
irq_exit+0x53/0xa2
smp_apic_timer_interrupt+0x1c4/0x1d9
apic_timer_interrupt+0xf/0x20
</IRQ>
Cc: Arvid Brodin <arvid.brodin@alten.se>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/hsr/hsr_device.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index 4ea7d54a8262..f0f9b493c47b 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -227,9 +227,13 @@ static int hsr_dev_xmit(struct sk_buff *skb, struct net_device *dev)
struct hsr_port *master;
master = hsr_port_get_hsr(hsr, HSR_PT_MASTER);
- skb->dev = master->dev;
- hsr_forward_skb(skb, master);
-
+ if (master) {
+ skb->dev = master->dev;
+ hsr_forward_skb(skb, master);
+ } else {
+ atomic_long_inc(&dev->tx_dropped);
+ dev_kfree_skb_any(skb);
+ }
return NETDEV_TX_OK;
}
--
2.21.0
^ 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