* Re: [PATCH mlx5-next v2 11/13] IB/mlx5: Add flow counters binding support
From: Jason Gunthorpe @ 2018-05-29 19:56 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Boris Pismenny,
Matan Barak, Raed Salem, Yishai Hadas, Saeed Mahameed,
linux-netdev, Alex Rosenbaum
In-Reply-To: <20180529130917.13592-12-leon@kernel.org>
On Tue, May 29, 2018 at 04:09:15PM +0300, Leon Romanovsky wrote:
> diff --git a/include/uapi/rdma/mlx5-abi.h b/include/uapi/rdma/mlx5-abi.h
> index 508ea8c82da7..ef3f430a7050 100644
> +++ b/include/uapi/rdma/mlx5-abi.h
> @@ -443,4 +443,18 @@ enum {
> enum {
> MLX5_IB_CLOCK_INFO_V1 = 0,
> };
> +
> +struct mlx5_ib_flow_counters_data {
> + __aligned_u64 counters_data;
> + __u32 ncounters;
> + __u32 reserved;
> +};
> +
> +struct mlx5_ib_create_flow {
> + __u32 ncounters_data;
> + __u32 reserved;
> + /* Following are counters data based on ncounters_data */
> + struct mlx5_ib_flow_counters_data data[];
> +};
> +
> #endif /* MLX5_ABI_USER_H */
This uapi thing still needs to be fixed as I pointed out before.
I still can't figure out why this should be a 2d array. I think it
should be written simply as:
struct mlx5_ib_flow_counter_desc {
__u32 description;
__u32 index;
};
struct mlx5_ib_create_flow {
RDMA_UAPI_PTR(struct mlx5_ib_flow_counter_desc, counters_data);
__u32 ncounters;
__u32 reserved;
};
With the corresponding changes elsewhere.
A flex array at the end of a struct means that the struct can never be
extended again which seems like a terrible idea, especially since I
can't fathom why we'd need more that one array of counters and the
current code doesn't even support more than one..
Jason
^ permalink raw reply
* Re: [1/4,RFCv2] net: phy: realtek: Support RTL8366RB variant
From: Linus Walleij @ 2018-05-29 20:01 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
OpenWrt Development List, LEDE Development List,
Antti Seppälä, Roman Yeryomin, Colin Leitner,
Gabor Juhos
In-Reply-To: <a69f23bf-cc3d-195b-03f9-17b2b9aa180b@gmail.com>
On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> +#define RTL8366RB_POWER_SAVE 0x21
> Typically PHY register addresses are 5 bits wide, is 0x21 correct
> and I miss something?
If it is correct I don't know, but it appears in the vendor
code:
/*Power Saving*/
#define RTL8368S_POWER_SAVING_PAGE 0
#define RTL8368S_POWER_SAVING_REG 21
#define RTL8368S_POWER_SAVING_BIT_MSK 0x1000
Then:
phySmiAddr = 0x8000 | (1<<(phyNo +RTL8368S_PHY_NO_OFFSET)) |
((RTL8368S_POWER_SAVING_PAGE<<RTL8368S_PHY_PAGE_OFFSET)&RTL8368S_PHY_PAGE_MASK)
|
(RTL8368S_POWER_SAVING_REG&RTL8368S_PHY_REG_MASK);
retVal = rtl8368s_setAsicReg(phySmiAddr, 0);
if (retVal != SUCCESS)
return retVal;
The PHYs are accessed here in memory area 0x8000.
Fixed the rest, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] net: sched: split tc_ctl_tfilter into three handlers
From: David Miller @ 2018-05-29 20:04 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, kliteyn
In-Reply-To: <1527450903-11408-1-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Sun, 27 May 2018 22:55:03 +0300
> tc_ctl_tfilter handles three netlink message types: RTM_NEWTFILTER,
> RTM_DELTFILTER, RTM_GETTFILTER. However, implementation of this function
> involves a lot of branching on specific message type because most of the
> code is message-specific. This significantly complicates adding new
> functionality and doesn't provide much benefit of code reuse.
>
> Split tc_ctl_tfilter to three standalone functions that handle filter new,
> delete and get requests.
>
> The only truly protocol independent part of tc_ctl_tfilter is code that
> looks up queue, class, and block. Refactor this code to standalone
> tcf_block_find function that is used by all three new handlers.
>
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
This looks fine but doesn't apply cleanly to net-next.
^ permalink raw reply
* Re: [PATCH rdma-next 0/3] Introduce new mlx5 CQE format
From: Jason Gunthorpe @ 2018-05-29 20:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Guy Levi,
Yishai Hadas, Yonatan Cohen, Saeed Mahameed, linux-netdev
In-Reply-To: <20180527104234.17261-1-leon@kernel.org>
On Sun, May 27, 2018 at 01:42:31PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Introduce new internal to mlx5 CQE format - mini-CQE. It is a CQE in
> compressed form that holds data needed to extra a single full CQE.
>
> It stride index, byte count and packet checksum.
>
> Thanks
>
> Yonatan Cohen (3):
> net/mlx5: Exposing a new mini-CQE format
> IB/mlx5: Refactor CQE compression response
> IB/mlx5: Introduce a new mini-CQE format
Applied to for-next.
Generally taking new uapi patches that are first the list should have
a few weeks of comment period, but since this is just adding a new bit
to an existing driver private api it seems OK to go this merge window.
Thanks,
Jason
^ permalink raw reply
* Re: [1/4,RFCv2] net: phy: realtek: Support RTL8366RB variant
From: Andrew Lunn @ 2018-05-29 20:17 UTC (permalink / raw)
To: Linus Walleij
Cc: Heiner Kallweit, Vivien Didelot, Florian Fainelli, netdev,
OpenWrt Development List, LEDE Development List,
Antti Seppälä, Roman Yeryomin, Colin Leitner,
Gabor Juhos
In-Reply-To: <CACRpkdaKZC2YHYO_xLEtTB6DYW4FpapNBe4KQSCO57iHmCLZvw@mail.gmail.com>
On Tue, May 29, 2018 at 10:01:14PM +0200, Linus Walleij wrote:
> On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> >> +#define RTL8366RB_POWER_SAVE 0x21
>
> > Typically PHY register addresses are 5 bits wide, is 0x21 correct
> > and I miss something?
Heiner is correct, MDIO only supports 32 register, when using clause
22. However, your device is not clause 22, it is its own thing. So one
danger you have is that we put some checks in the generic code testing
for values > 31, and return -EINVAL.
I think you have two choices:
1) A comment explaining what is going on here, how 0x21 is valid in
this context. And check the return value and give out a good warning
which will point somebody in the right direction to notice this 0x21.
2) Move this into the DSA driver, which does not have this
restriction.
Andrew
^ permalink raw reply
* Re: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure
From: Jason Gunthorpe @ 2018-05-29 20:21 UTC (permalink / raw)
To: Ruhl, Michael J
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Boris Pismenny, Matan Barak, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <14063C7AD467DE4B82DEDB5C278E8663B38ED738@FMSMSX108.amr.corp.intel.com>
On Tue, May 29, 2018 at 07:31:22PM +0000, Ruhl, Michael J wrote:
> >- struct ib_uverbs_destroy_cq_resp resp;
> > struct ib_uobject *uobj =
> >- uverbs_attr_get(attrs,
> >UVERBS_ATTR_DESTROY_CQ_HANDLE)->obj_attr.uobject;
> >- struct ib_ucq_object *obj = container_of(uobj, struct ib_ucq_object,
> >- uobject);
> >+ uverbs_attr_get_uobject(attrs,
> >UVERBS_ATTR_DESTROY_CQ_HANDLE);
> >+ struct ib_uverbs_destroy_cq_resp resp;
> >+ struct ib_ucq_object *obj;
> > int ret;
> >
> >+ if (IS_ERR(uobj))
> >+ return PTR_ERR(uobj);
> >+
>
> I remember a conversation that if an method attribute was mandatory, that you did not need to
> test the uobj for error (since it was checked in the infrastructure).
Yes.
> Is this error check necessary?
No
But there is no way to check one way or the other at compile time
right now, and omitting the check makes smatch mad.
We need some more patches to be able to safely omit the check...
Jason
^ permalink raw reply
* [PATCH bpf-next] bpftool: Support sendmsg{4,6} attach types
From: Andrey Ignatov @ 2018-05-29 20:29 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kubakici, quentin.monnet,
kernel-team
Add support for recently added BPF_CGROUP_UDP4_SENDMSG and
BPF_CGROUP_UDP6_SENDMSG attach types to bpftool, update documentation
and bash completion.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
I'm not sure about "since 4.18" in Documentation part. I can follow-up when
the next kernel version is known.
---
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 9 +++++++--
tools/bpf/bpftool/bash-completion/bpftool | 5 +++--
tools/bpf/bpftool/cgroup.c | 4 +++-
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
index d004f63..7b0e6d4 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
@@ -27,7 +27,8 @@ MAP COMMANDS
|
| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
| *ATTACH_TYPE* := { **ingress** | **egress** | **sock_create** | **sock_ops** | **device** |
-| **bind4** | **bind6** | **post_bind4** | **post_bind6** | **connect4** | **connect6** }
+| **bind4** | **bind6** | **post_bind4** | **post_bind6** | **connect4** | **connect6** |
+| **sendmsg4** | **sendmsg6** }
| *ATTACH_FLAGS* := { **multi** | **override** }
DESCRIPTION
@@ -70,7 +71,11 @@ DESCRIPTION
**post_bind4** return from bind(2) for an inet4 socket (since 4.17);
**post_bind6** return from bind(2) for an inet6 socket (since 4.17);
**connect4** call to connect(2) for an inet4 socket (since 4.17);
- **connect6** call to connect(2) for an inet6 socket (since 4.17).
+ **connect6** call to connect(2) for an inet6 socket (since 4.17);
+ **sendmsg4** call to sendto(2), sendmsg(2), sendmmsg(2) for an
+ unconnected udp4 socket (since 4.18);
+ **sendmsg6** call to sendto(2), sendmsg(2), sendmmsg(2) for an
+ unconnected udp6 socket (since 4.18).
**bpftool cgroup detach** *CGROUP* *ATTACH_TYPE* *PROG*
Detach *PROG* from the cgroup *CGROUP* and attach type
diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
index 7bc198d..1e10833 100644
--- a/tools/bpf/bpftool/bash-completion/bpftool
+++ b/tools/bpf/bpftool/bash-completion/bpftool
@@ -407,7 +407,7 @@ _bpftool()
attach|detach)
local ATTACH_TYPES='ingress egress sock_create sock_ops \
device bind4 bind6 post_bind4 post_bind6 connect4 \
- connect6'
+ connect6 sendmsg4 sendmsg6'
local ATTACH_FLAGS='multi override'
local PROG_TYPE='id pinned tag'
case $prev in
@@ -416,7 +416,8 @@ _bpftool()
return 0
;;
ingress|egress|sock_create|sock_ops|device|bind4|bind6|\
- post_bind4|post_bind6|connect4|connect6)
+ post_bind4|post_bind6|connect4|connect6|sendmsg4|\
+ sendmsg6)
COMPREPLY=( $( compgen -W "$PROG_TYPE" -- \
"$cur" ) )
return 0
diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
index 1351bd6..16bee01 100644
--- a/tools/bpf/bpftool/cgroup.c
+++ b/tools/bpf/bpftool/cgroup.c
@@ -20,7 +20,7 @@
" ATTACH_TYPE := { ingress | egress | sock_create |\n" \
" sock_ops | device | bind4 | bind6 |\n" \
" post_bind4 | post_bind6 | connect4 |\n" \
- " connect6 }"
+ " connect6 | sendmsg4 | sendmsg6 }"
static const char * const attach_type_strings[] = {
[BPF_CGROUP_INET_INGRESS] = "ingress",
@@ -34,6 +34,8 @@ static const char * const attach_type_strings[] = {
[BPF_CGROUP_INET6_CONNECT] = "connect6",
[BPF_CGROUP_INET4_POST_BIND] = "post_bind4",
[BPF_CGROUP_INET6_POST_BIND] = "post_bind6",
+ [BPF_CGROUP_UDP4_SENDMSG] = "sendmsg4",
+ [BPF_CGROUP_UDP6_SENDMSG] = "sendmsg6",
[__MAX_BPF_ATTACH_TYPE] = NULL,
};
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net-next 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Samudrala, Sridhar @ 2018-05-29 20:46 UTC (permalink / raw)
To: Michael Chan, davem; +Cc: netdev
In-Reply-To: <1527581920-3778-2-git-send-email-michael.chan@broadcom.com>
On 5/29/2018 1:18 AM, Michael Chan wrote:
> VF Queue resources are always limited and there is currently no
> infrastructure to allow the admin. on the host to add or reduce queue
> resources for any particular VF. With ever increasing number of VFs
> being supported, it is desirable to allow the admin. to configure queue
> resources differently for the VFs. Some VFs may require more or fewer
> queues due to different bandwidth requirements or different number of
> vCPUs in the VM. This patch adds the infrastructure to do that by
> adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues()
> to the net_device_ops.
>
> Four parameters are exposed for each VF:
>
> o min_tx_queues - Guaranteed tx queues available to the VF.
>
> o max_tx_queues - Maximum but not necessarily guaranteed tx queues
> available to the VF.
>
> o min_rx_queues - Guaranteed rx queues available to the VF.
>
> o max_rx_queues - Maximum but not necessarily guaranteed rx queues
> available to the VF.
>
> The "ip link set" command will subsequently be patched to support the new
> operation to set the above parameters.
>
> After the admin. makes a change to the above parameters, the corresponding
> VF will have a new range of channels to set using ethtool -L. The VF may
> have to go through IF down/up before the new queues will take effect. Up
> to the min values are guaranteed. Up to the max values are possible but not
> guaranteed.
>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
> include/linux/if_link.h | 4 ++++
> include/linux/netdevice.h | 6 ++++++
> include/uapi/linux/if_link.h | 9 +++++++++
> net/core/rtnetlink.c | 32 +++++++++++++++++++++++++++++---
> 4 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> index 622658d..8e81121 100644
> --- a/include/linux/if_link.h
> +++ b/include/linux/if_link.h
> @@ -29,5 +29,9 @@ struct ifla_vf_info {
> __u32 rss_query_en;
> __u32 trusted;
> __be16 vlan_proto;
> + __u32 min_tx_queues;
> + __u32 max_tx_queues;
> + __u32 min_rx_queues;
> + __u32 max_rx_queues;
> };
> #endif /* _LINUX_IF_LINK_H */
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 8452f72..17f5892 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1023,6 +1023,8 @@ struct dev_ifalias {
> * with PF and querying it may introduce a theoretical security risk.
> * int (*ndo_set_vf_rss_query_en)(struct net_device *dev, int vf, bool setting);
> * int (*ndo_get_vf_port)(struct net_device *dev, int vf, struct sk_buff *skb);
> + * int (*ndo_set_vf_queues)(struct net_device *dev, int vf, int min_txq,
> + * int max_txq, int min_rxq, int max_rxq);
Isn't ndo_set_vf_xxx() considered a legacy interface and not planned to be extended?
Shouldn't we enable this via ethtool on the port representor netdev?
^ permalink raw reply
* RE: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure
From: Ruhl, Michael J @ 2018-05-29 20:49 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Boris Pismenny, Matan Barak, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180529202119.GK18442@mellanox.com>
>-----Original Message-----
>From: Jason Gunthorpe [mailto:jgg@mellanox.com]
>Sent: Tuesday, May 29, 2018 4:21 PM
>To: Ruhl, Michael J <michael.j.ruhl@intel.com>
>Cc: Leon Romanovsky <leon@kernel.org>; Doug Ledford
><dledford@redhat.com>; Leon Romanovsky <leonro@mellanox.com>; RDMA
>mailing list <linux-rdma@vger.kernel.org>; Boris Pismenny
><borisp@mellanox.com>; Matan Barak <matanb@mellanox.com>; Raed
>Salem <raeds@mellanox.com>; Yishai Hadas <yishaih@mellanox.com>; Saeed
>Mahameed <saeedm@mellanox.com>; linux-netdev
><netdev@vger.kernel.org>
>Subject: Re: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter
>to ioctl() infrastructure
>
>On Tue, May 29, 2018 at 07:31:22PM +0000, Ruhl, Michael J wrote:
>> >- struct ib_uverbs_destroy_cq_resp resp;
>> > struct ib_uobject *uobj =
>> >- uverbs_attr_get(attrs,
>> >UVERBS_ATTR_DESTROY_CQ_HANDLE)->obj_attr.uobject;
>> >- struct ib_ucq_object *obj = container_of(uobj, struct ib_ucq_object,
>> >- uobject);
>> >+ uverbs_attr_get_uobject(attrs,
>> >UVERBS_ATTR_DESTROY_CQ_HANDLE);
>> >+ struct ib_uverbs_destroy_cq_resp resp;
>> >+ struct ib_ucq_object *obj;
>> > int ret;
>> >
>> >+ if (IS_ERR(uobj))
>> >+ return PTR_ERR(uobj);
>> >+
>>
>> I remember a conversation that if an method attribute was mandatory, that
>you did not need to
>> test the uobj for error (since it was checked in the infrastructure).
>
>Yes.
>
>> Is this error check necessary?
>
>No
>
>But there is no way to check one way or the other at compile time
>right now, and omitting the check makes smatch mad.
Is smatch going to get mad at (same patch):
diff --git a/drivers/infiniband/core/uverbs_std_types_flow_action.c b/drivers/infiniband/core/uverbs_std_types_flow_action.c
index b4f016dfa23d..a7be51cf2e42 100644
--- a/drivers/infiniband/core/uverbs_std_types_flow_action.c
+++ b/drivers/infiniband/core/uverbs_std_types_flow_action.c
@@ -320,7 +320,7 @@ static int UVERBS_HANDLER(UVERBS_METHOD_FLOW_ACTION_ESP_CREATE)(struct ib_device
return ret;
/* No need to check as this attribute is marked as MANDATORY */
- uobj = uverbs_attr_get(attrs, UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE)->obj_attr.uobject;
+ uobj = uverbs_attr_get_uobject(attrs, UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE);
action = ib_dev->create_flow_action_esp(ib_dev, &esp_attr.hdr, attrs);
if (IS_ERR(action))
return PTR_ERR(action);
@@ -350,7 +350,7 @@ static int UVERBS_HANDLER(UVERBS_METHOD_FLOW_ACTION_ESP_MODIFY)(struct ib_device
if (ret)
return ret;
- uobj = uverbs_attr_get(attrs, UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE)->obj_attr.uobject;
+ uobj = uverbs_attr_get_uobject(attrs, UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE);
action = uobj->object;
?
If not,
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Thanks,
Mike
>We need some more patches to be able to safely omit the check...
>
>Jason
^ permalink raw reply related
* Re: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure
From: Jason Gunthorpe @ 2018-05-29 20:51 UTC (permalink / raw)
To: Ruhl, Michael J
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Boris Pismenny, Matan Barak, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <14063C7AD467DE4B82DEDB5C278E8663B38EE87B@FMSMSX108.amr.corp.intel.com>
On Tue, May 29, 2018 at 08:49:58PM +0000, Ruhl, Michael J wrote:
> >From: Jason Gunthorpe [mailto:jgg@mellanox.com]
> >Sent: Tuesday, May 29, 2018 4:21 PM
> >To: Ruhl, Michael J <michael.j.ruhl@intel.com>
> >Cc: Leon Romanovsky <leon@kernel.org>; Doug Ledford
> ><dledford@redhat.com>; Leon Romanovsky <leonro@mellanox.com>; RDMA
> >mailing list <linux-rdma@vger.kernel.org>; Boris Pismenny
> ><borisp@mellanox.com>; Matan Barak <matanb@mellanox.com>; Raed
> >Salem <raeds@mellanox.com>; Yishai Hadas <yishaih@mellanox.com>; Saeed
> >Mahameed <saeedm@mellanox.com>; linux-netdev
> ><netdev@vger.kernel.org>
> >Subject: Re: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter
> >to ioctl() infrastructure
> >
> >On Tue, May 29, 2018 at 07:31:22PM +0000, Ruhl, Michael J wrote:
> >> >- struct ib_uverbs_destroy_cq_resp resp;
> >> > struct ib_uobject *uobj =
> >> >- uverbs_attr_get(attrs,
> >> >UVERBS_ATTR_DESTROY_CQ_HANDLE)->obj_attr.uobject;
> >> >- struct ib_ucq_object *obj = container_of(uobj, struct ib_ucq_object,
> >> >- uobject);
> >> >+ uverbs_attr_get_uobject(attrs,
> >> >UVERBS_ATTR_DESTROY_CQ_HANDLE);
> >> >+ struct ib_uverbs_destroy_cq_resp resp;
> >> >+ struct ib_ucq_object *obj;
> >> > int ret;
> >> >
> >> >+ if (IS_ERR(uobj))
> >> >+ return PTR_ERR(uobj);
> >> >+
> >>
> >> I remember a conversation that if an method attribute was mandatory, that
> >you did not need to
> >> test the uobj for error (since it was checked in the infrastructure).
> >
> >Yes.
> >
> >> Is this error check necessary?
> >
> >No
> >
> >But there is no way to check one way or the other at compile time
> >right now, and omitting the check makes smatch mad.
>
> Is smatch going to get mad at (same patch):
Yes, this is where it already got mad, IIRC :(
Fixing this whole thing is a todo on my list..
Jason
^ permalink raw reply
* Re: [PATCH mlx5-next 1/3] net/mlx5: Exposing a new mini-CQE format
From: Saeed Mahameed @ 2018-05-29 21:01 UTC (permalink / raw)
To: Jason Gunthorpe, leon@kernel.org, dledford@redhat.com
Cc: Yonatan Cohen, netdev@vger.kernel.org, Guy Levi(SW),
Leon Romanovsky, linux-rdma@vger.kernel.org, Yishai Hadas
In-Reply-To: <20180527104234.17261-2-leon@kernel.org>
On Sun, 2018-05-27 at 13:42 +0300, Leon Romanovsky wrote:
> From: Yonatan Cohen <yonatanc@mellanox.com>
>
> The new mini-CQE format includes byte-count, checksum
> and stride index.
>
> Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> Reviewed-by: Guy Levi <guyle@mellanox.com>
> Signed-off-by: Yonatan Cohen <yonatanc@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Applied to mlx5-next.
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-
next
commit-id: ab741b2eed3e456cebd2240d4c9c6be003d5ae72
Thanks!
^ permalink raw reply
* Re: [1/4,RFCv2] net: phy: realtek: Support RTL8366RB variant
From: Heiner Kallweit @ 2018-05-29 21:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
OpenWrt Development List, LEDE Development List,
Antti Seppälä, Roman Yeryomin, Colin Leitner,
Gabor Juhos
In-Reply-To: <CACRpkdaKZC2YHYO_xLEtTB6DYW4FpapNBe4KQSCO57iHmCLZvw@mail.gmail.com>
Am 29.05.2018 um 22:01 schrieb Linus Walleij:
> On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
>>> +#define RTL8366RB_POWER_SAVE 0x21
>
>> Typically PHY register addresses are 5 bits wide, is 0x21 correct
>> and I miss something?
>
> If it is correct I don't know, but it appears in the vendor
> code:
>
> /*Power Saving*/
> #define RTL8368S_POWER_SAVING_PAGE 0
> #define RTL8368S_POWER_SAVING_REG 21
This is a decimal number .. You use 0x21.
> #define RTL8368S_POWER_SAVING_BIT_MSK 0x1000
>
> Then:
>
> phySmiAddr = 0x8000 | (1<<(phyNo +RTL8368S_PHY_NO_OFFSET)) |
>
> ((RTL8368S_POWER_SAVING_PAGE<<RTL8368S_PHY_PAGE_OFFSET)&RTL8368S_PHY_PAGE_MASK)
> |
> (RTL8368S_POWER_SAVING_REG&RTL8368S_PHY_REG_MASK);
>
> retVal = rtl8368s_setAsicReg(phySmiAddr, 0);
> if (retVal != SUCCESS)
> return retVal;
>
> The PHYs are accessed here in memory area 0x8000.
>
> Fixed the rest, thanks!
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] net/ipv6: Fix route append and replace use cases
From: Thomas Winter @ 2018-05-29 21:16 UTC (permalink / raw)
To: David Ahern, David Miller, dsahern@kernel.org
Cc: netdev@vger.kernel.org, idosch@mellanox.com,
sharpd@cumulusnetworks.com, roopa@cumulusnetworks.com
In-Reply-To: <6d61c529-5b51-dc3b-86ee-e912f1a8e0a8@gmail.com>
The only thing this breaks is adding IPv6 routes via ioctl. Previously they would be automatically appended to form multipath routes but this no longer occurs. Changing to netlink or use iproute2 and using NLM_F_APPEND gets around this. This basically what David Ahern said earlier but I wanted to make it clear the default ioctl behaviour has changed.
________________________________________
From: David Ahern <dsahern@gmail.com>
Sent: 23 May 2018 08:44
To: David Miller; dsahern@kernel.org
Cc: netdev@vger.kernel.org; Thomas Winter; idosch@mellanox.com; sharpd@cumulusnetworks.com; roopa@cumulusnetworks.com
Subject: Re: [PATCH net-next 0/7] net/ipv6: Fix route append and replace use cases
On 5/22/18 12:46 PM, David Miller wrote:
>
> Ok, I'll apply this series.
>
> But if this breaks things for anyone in a practical way, I am unfortunately
> going to have to revert no matter how silly the current behavior may be.
>
Understood. I have to try the best option first. I'll look at
regressions if they happen.
^ permalink raw reply
* Re: [PATCH bpf-next] bpftool: Support sendmsg{4,6} attach types
From: Jakub Kicinski @ 2018-05-29 21:20 UTC (permalink / raw)
To: Andrey Ignatov; +Cc: netdev, ast, daniel, quentin.monnet, kernel-team
In-Reply-To: <20180529202931.538817-1-rdna@fb.com>
On Tue, 29 May 2018 13:29:31 -0700, Andrey Ignatov wrote:
> Add support for recently added BPF_CGROUP_UDP4_SENDMSG and
> BPF_CGROUP_UDP6_SENDMSG attach types to bpftool, update documentation
> and bash completion.
>
> Signed-off-by: Andrey Ignatov <rdna@fb.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> I'm not sure about "since 4.18" in Documentation part. I can follow-up when
> the next kernel version is known.
IMHO it's fine, we can follow up if Linus decides to call it something
else :)
Thanks!
^ permalink raw reply
* Re: [PATCH mlx5-next 1/3] net/mlx5: Exposing a new mini-CQE format
From: Jason Gunthorpe @ 2018-05-29 21:35 UTC (permalink / raw)
To: Saeed Mahameed
Cc: leon@kernel.org, dledford@redhat.com, Yonatan Cohen,
netdev@vger.kernel.org, Guy Levi(SW), Leon Romanovsky,
linux-rdma@vger.kernel.org, Yishai Hadas
In-Reply-To: <7aba104bb1313c1cda01baae2ff8495d5623f4b1.camel@mellanox.com>
On Tue, May 29, 2018 at 03:01:27PM -0600, Saeed Mahameed wrote:
> On Sun, 2018-05-27 at 13:42 +0300, Leon Romanovsky wrote:
> > From: Yonatan Cohen <yonatanc@mellanox.com>
> >
> > The new mini-CQE format includes byte-count, checksum
> > and stride index.
> >
> > Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> > Reviewed-by: Guy Levi <guyle@mellanox.com>
> > Signed-off-by: Yonatan Cohen <yonatanc@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
>
>
> Applied to mlx5-next.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-
> next
>
> commit-id: ab741b2eed3e456cebd2240d4c9c6be003d5ae72
Thanks, everything is now merged as:
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=wip/jgg-for-next&id=f3ca0ab114e0de3bbad4c4a537d32fb57aa42f81
Jason
^ permalink raw reply
* Re: [PATCH net-next 0/8] nfp: offload LAG for tc flower egress
From: Jiri Pirko @ 2018-05-29 22:09 UTC (permalink / raw)
To: John Hurley
Cc: Jakub Kicinski, David Miller, Linux Netdev List, oss-drivers,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <CAK+XE=kAM=sv4vpSKuyaiHzdLCNZUwuEL0ggODCQnsM+sfCw8w@mail.gmail.com>
Tue, May 29, 2018 at 04:08:48PM CEST, john.hurley@netronome.com wrote:
>On Sat, May 26, 2018 at 3:47 AM, Jakub Kicinski
><jakub.kicinski@netronome.com> wrote:
>> On Fri, 25 May 2018 08:48:09 +0200, Jiri Pirko wrote:
>>> Thu, May 24, 2018 at 04:22:47AM CEST, jakub.kicinski@netronome.com wrote:
>>> >Hi!
>>> >
>>> >This series from John adds bond offload to the nfp driver. Patch 5
>>> >exposes the hash type for NETDEV_LAG_TX_TYPE_HASH to make sure nfp
>>> >hashing matches that of the software LAG. This may be unnecessarily
>>> >conservative, let's see what LAG maintainers think :)
>>>
>>> So you need to restrict offload to only certain hash algo? In mlxsw, we
>>> just ignore the lag setting and do some hw default hashing. Would not be
>>> enough? Note that there's a good reason for it, as you see, in team, the
>>> hashing is done in a BPF function and could be totally arbitrary.
>>> Your patchset effectively disables team offload for nfp.
>>
>> My understanding is that the project requirements only called for L3/L4
>> hash algorithm offload, hence the temptation to err on the side of
>> caution and not offload all the bond configurations. John can provide
>> more details. Not being able to offload team is unfortunate indeed.
>
>Hi Jiri,
>Yes, as Jakub mentions, we restrict ourselves to L3/L4 hash algorithm
>as this is currently what is supported in fw.
In mlxsw, a default l3/l4 is used always, no matter what the
bonding/team sets. It is not correct, but it works with team as well.
Perhaps we can have NETDEV_LAG_HASH_UNKNOWN to indicate to the driver to
do some default? That would make the "team" offload functional.
>Hopefully this will change as fw features are expanded.
>I understand the issue this presents with offloading team.
>Perhaps resorting to a default hw hash for team is acceptable.
>John
^ permalink raw reply
* Re: [net] vhost: Use kzalloc() to allocate vhost_msg_node
From: Guenter Roeck @ 2018-05-29 22:19 UTC (permalink / raw)
To: Kevin Easton
Cc: Michael S. Tsirkin, Jason Wang, kvm, virtualization, netdev,
linux-kernel, syzkaller-bugs
In-Reply-To: <20180427154502.GA22544@la.guarana.org>
On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
> The struct vhost_msg within struct vhost_msg_node is copied to userspace,
> so it should be allocated with kzalloc() to ensure all structure padding
> is zeroed.
>
> Signed-off-by: Kevin Easton <kevin@guarana.org>
> Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com
Is this patch going anywhere ?
The patch fixes CVE-2018-1118. It would be useful to understand if and when
this problem is going to be fixed.
Thanks,
Guenter
> ---
> drivers/vhost/vhost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index f3bd8e9..1b84dcff 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
> /* Create a new message. */
> struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
> {
> - struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
> + struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
> if (!node)
> return NULL;
> node->vq = vq;
^ permalink raw reply
* Missing skb->dst with flow offloading
From: Jason A. Donenfeld @ 2018-05-30 0:01 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netdev, netfilter-devel, Jaap Buurman, openwrt-devel,
WireGuard mailing list, Felix Fietkau
Hey Pablo,
Some OpenWRT people have reported to me that there's a crash when
enabling flow offloading, because I rely on skb_dst(skb) being
non-null in ndo_start_xmit. The fix in my code for this is very
simple:
- mtu = dst_mtu(skb_dst(skb));
+ dst = skb_dst(skb);
+ mtu = dst ? dst_mtu(dst) : dev->mtu;
I can make this change, but I wanted to be certain first that omitting
the dst in the skb is intentional on your part. (If so, there might be
other drivers to fix as well.) In tracing this, it looks like a packet
that's forwarded from a flow offloaded interface to a virtual
interface gets diverted immediately via neigh_xmit, where it is then
passed to a virtual interface via dev_queue_xmit. I can't see anywhere
along this path a call to skb_dst_set. Perhaps this is intended, as
flow offloading is supposed to skip the routing table? Or is there an
oversight in the new flow offloading code?
I'd appreciate your input, so that I can make the appropriate change
-- or not -- to my code.
Regards,
Jason
^ permalink raw reply
* Re: [PATCH bpf-next] bpftool: Support sendmsg{4,6} attach types
From: Song Liu @ 2018-05-30 0:12 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrey Ignatov, Networking, Alexei Starovoitov, Daniel Borkmann,
Quentin Monnet, kernel-team
In-Reply-To: <20180529142021.7fa6f5c1@cakuba>
On Tue, May 29, 2018 at 2:20 PM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Tue, 29 May 2018 13:29:31 -0700, Andrey Ignatov wrote:
>> Add support for recently added BPF_CGROUP_UDP4_SENDMSG and
>> BPF_CGROUP_UDP6_SENDMSG attach types to bpftool, update documentation
>> and bash completion.
>>
>> Signed-off-by: Andrey Ignatov <rdna@fb.com>
>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
>> I'm not sure about "since 4.18" in Documentation part. I can follow-up when
>> the next kernel version is known.
>
> IMHO it's fine, we can follow up if Linus decides to call it something
> else :)
>
> Thanks!
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH bpf-next 11/11] bpf, doc: add missing patchwork url and libbpf to maintainers
From: Song Liu @ 2018-05-30 0:16 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Alexei Starovoitov, Networking
In-Reply-To: <20180528004344.3606-12-daniel@iogearbox.net>
On Sun, May 27, 2018 at 5:43 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> Add missing bits under tools/lib/bpf/ and also Q: entry in order to
> make it easier for people to retrieve current patch queue.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f492431..2fd51db 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2722,6 +2722,7 @@ L: netdev@vger.kernel.org
> L: linux-kernel@vger.kernel.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
> +Q: https://patchwork.ozlabs.org/project/netdev/list/?delegate=77147
> S: Supported
> F: arch/x86/net/bpf_jit*
> F: Documentation/networking/filter.txt
> @@ -2740,6 +2741,7 @@ F: net/sched/act_bpf.c
> F: net/sched/cls_bpf.c
> F: samples/bpf/
> F: tools/bpf/
> +F: tools/lib/bpf/
> F: tools/testing/selftests/bpf/
>
> BROADCOM B44 10/100 ETHERNET DRIVER
> --
> 2.9.5
>
^ permalink raw reply
* [PATCH mlx5-next 0/2] Mellanox, mlx5 new device events
From: Saeed Mahameed @ 2018-05-30 0:19 UTC (permalink / raw)
To: netdev, linux-rdma; +Cc: Leon Romanovsky, Jason Gunthorpe, Saeed Mahameed
Hi,
The following series is for mlx5-next tree [1], it adds the support of two
new device events, from Ilan Tayari:
1. High temperature warnings.
2. FPGA QP error event.
In case of no objection this series will be applied to mlx5-next tree
and will be sent later as a pull request to both rdma and net trees.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-next
Thanks,
Saeed.
Ilan Tayari (2):
net/mlx5: Add temperature warning event to log
net/mlx5: Add FPGA QP error event
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 28 +++++++++++++++++++-
include/linux/mlx5/device.h | 8 ++++++
include/linux/mlx5/mlx5_ifc.h | 3 ++-
include/linux/mlx5/mlx5_ifc_fpga.h | 16 +++++++++++
4 files changed, 53 insertions(+), 2 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH mlx5-next 1/2] net/mlx5: Add temperature warning event to log
From: Saeed Mahameed @ 2018-05-30 0:19 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, Ilan Tayari, Adi Nissim,
Saeed Mahameed
In-Reply-To: <20180530001954.12000-1-saeedm@mellanox.com>
From: Ilan Tayari <ilant@mellanox.com>
Temperature warning event is sent by FW to indicate high temperature
as detected by one of the sensors on the board.
Add handling of this event by writing the numbers of the alert sensors
to the kernel log.
Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Signed-off-by: Adi Nissim <adin@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 23 ++++++++++++++++++++
include/linux/mlx5/device.h | 7 ++++++
include/linux/mlx5/mlx5_ifc.h | 2 +-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
index c1c94974e16b..4bd4f011f0a9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -141,6 +141,8 @@ static const char *eqe_type_str(u8 type)
return "MLX5_EVENT_TYPE_GPIO_EVENT";
case MLX5_EVENT_TYPE_PORT_MODULE_EVENT:
return "MLX5_EVENT_TYPE_PORT_MODULE_EVENT";
+ case MLX5_EVENT_TYPE_TEMP_WARN_EVENT:
+ return "MLX5_EVENT_TYPE_TEMP_WARN_EVENT";
case MLX5_EVENT_TYPE_REMOTE_CONFIG:
return "MLX5_EVENT_TYPE_REMOTE_CONFIG";
case MLX5_EVENT_TYPE_DB_BF_CONGESTION:
@@ -393,6 +395,20 @@ static void general_event_handler(struct mlx5_core_dev *dev,
}
}
+static void mlx5_temp_warning_event(struct mlx5_core_dev *dev,
+ struct mlx5_eqe *eqe)
+{
+ u64 value_lsb;
+ u64 value_msb;
+
+ value_lsb = be64_to_cpu(eqe->data.temp_warning.sensor_warning_lsb);
+ value_msb = be64_to_cpu(eqe->data.temp_warning.sensor_warning_msb);
+
+ mlx5_core_warn(dev,
+ "High temperature on sensors with bit set %llx %llx",
+ value_msb, value_lsb);
+}
+
/* caller must eventually call mlx5_cq_put on the returned cq */
static struct mlx5_core_cq *mlx5_eq_cq_get(struct mlx5_eq *eq, u32 cqn)
{
@@ -547,6 +563,10 @@ static irqreturn_t mlx5_eq_int(int irq, void *eq_ptr)
mlx5_fpga_event(dev, eqe->type, &eqe->data.raw);
break;
+ case MLX5_EVENT_TYPE_TEMP_WARN_EVENT:
+ mlx5_temp_warning_event(dev, eqe);
+ break;
+
case MLX5_EVENT_TYPE_GENERAL_EVENT:
general_event_handler(dev, eqe);
break;
@@ -824,6 +844,9 @@ int mlx5_start_eqs(struct mlx5_core_dev *dev)
async_event_mask |= (1ull << MLX5_EVENT_TYPE_DCT_DRAINED);
+ if (MLX5_CAP_GEN(dev, temp_warn_event))
+ async_event_mask |= (1ull << MLX5_EVENT_TYPE_TEMP_WARN_EVENT);
+
err = mlx5_create_map_eq(dev, &table->cmd_eq, MLX5_EQ_VEC_CMD,
MLX5_NUM_CMD_EQE, 1ull << MLX5_EVENT_TYPE_CMD,
"mlx5_cmd_eq", MLX5_EQ_TYPE_ASYNC);
diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h
index 2bc27f8c5b87..eddacee5cf61 100644
--- a/include/linux/mlx5/device.h
+++ b/include/linux/mlx5/device.h
@@ -314,6 +314,7 @@ enum mlx5_event {
MLX5_EVENT_TYPE_PORT_CHANGE = 0x09,
MLX5_EVENT_TYPE_GPIO_EVENT = 0x15,
MLX5_EVENT_TYPE_PORT_MODULE_EVENT = 0x16,
+ MLX5_EVENT_TYPE_TEMP_WARN_EVENT = 0x17,
MLX5_EVENT_TYPE_REMOTE_CONFIG = 0x19,
MLX5_EVENT_TYPE_GENERAL_EVENT = 0x22,
MLX5_EVENT_TYPE_PPS_EVENT = 0x25,
@@ -626,6 +627,11 @@ struct mlx5_eqe_dct {
__be32 dctn;
};
+struct mlx5_eqe_temp_warning {
+ __be64 sensor_warning_msb;
+ __be64 sensor_warning_lsb;
+} __packed;
+
union ev_data {
__be32 raw[7];
struct mlx5_eqe_cmd cmd;
@@ -642,6 +648,7 @@ union ev_data {
struct mlx5_eqe_port_module port_module;
struct mlx5_eqe_pps pps;
struct mlx5_eqe_dct dct;
+ struct mlx5_eqe_temp_warning temp_warning;
} __packed;
struct mlx5_eqe {
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 10c1613d9434..ba30c26aa6eb 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -926,7 +926,7 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 log_max_msg[0x5];
u8 reserved_at_1c8[0x4];
u8 max_tc[0x4];
- u8 reserved_at_1d0[0x1];
+ u8 temp_warn_event[0x1];
u8 dcbx[0x1];
u8 general_notification_event[0x1];
u8 reserved_at_1d3[0x2];
--
2.17.0
^ permalink raw reply related
* [PATCH mlx5-next 2/2] net/mlx5: Add FPGA QP error event
From: Saeed Mahameed @ 2018-05-30 0:19 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, Ilan Tayari, Adi Nissim,
Saeed Mahameed
In-Reply-To: <20180530001954.12000-1-saeedm@mellanox.com>
From: Ilan Tayari <ilant@mellanox.com>
The FPGA QP event fires whenever a QP on the FPGA trasitions
to the error state.
At this stage, this event is unrecoverable, it may become recoverable
in the future.
Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Signed-off-by: Adi Nissim <adin@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 7 +++++--
include/linux/mlx5/device.h | 1 +
include/linux/mlx5/mlx5_ifc.h | 1 +
include/linux/mlx5/mlx5_ifc_fpga.h | 16 ++++++++++++++++
4 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
index 4bd4f011f0a9..77c685645c66 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -161,6 +161,8 @@ static const char *eqe_type_str(u8 type)
return "MLX5_EVENT_TYPE_NIC_VPORT_CHANGE";
case MLX5_EVENT_TYPE_FPGA_ERROR:
return "MLX5_EVENT_TYPE_FPGA_ERROR";
+ case MLX5_EVENT_TYPE_FPGA_QP_ERROR:
+ return "MLX5_EVENT_TYPE_FPGA_QP_ERROR";
case MLX5_EVENT_TYPE_GENERAL_EVENT:
return "MLX5_EVENT_TYPE_GENERAL_EVENT";
default:
@@ -560,6 +562,7 @@ static irqreturn_t mlx5_eq_int(int irq, void *eq_ptr)
break;
case MLX5_EVENT_TYPE_FPGA_ERROR:
+ case MLX5_EVENT_TYPE_FPGA_QP_ERROR:
mlx5_fpga_event(dev, eqe->type, &eqe->data.raw);
break;
@@ -839,11 +842,11 @@ int mlx5_start_eqs(struct mlx5_core_dev *dev)
async_event_mask |= (1ull << MLX5_EVENT_TYPE_PPS_EVENT);
if (MLX5_CAP_GEN(dev, fpga))
- async_event_mask |= (1ull << MLX5_EVENT_TYPE_FPGA_ERROR);
+ async_event_mask |= (1ull << MLX5_EVENT_TYPE_FPGA_ERROR) |
+ (1ull << MLX5_EVENT_TYPE_FPGA_QP_ERROR);
if (MLX5_CAP_GEN_MAX(dev, dct))
async_event_mask |= (1ull << MLX5_EVENT_TYPE_DCT_DRAINED);
-
if (MLX5_CAP_GEN(dev, temp_warn_event))
async_event_mask |= (1ull << MLX5_EVENT_TYPE_TEMP_WARN_EVENT);
diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h
index eddacee5cf61..71e1dc2523a6 100644
--- a/include/linux/mlx5/device.h
+++ b/include/linux/mlx5/device.h
@@ -331,6 +331,7 @@ enum mlx5_event {
MLX5_EVENT_TYPE_DCT_DRAINED = 0x1c,
MLX5_EVENT_TYPE_FPGA_ERROR = 0x20,
+ MLX5_EVENT_TYPE_FPGA_QP_ERROR = 0x21,
};
enum {
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index ba30c26aa6eb..3e8845dc85fe 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -60,6 +60,7 @@ enum {
MLX5_EVENT_TYPE_CODING_COMMAND_INTERFACE_COMPLETION = 0xa,
MLX5_EVENT_TYPE_CODING_PAGE_REQUEST = 0xb,
MLX5_EVENT_TYPE_CODING_FPGA_ERROR = 0x20,
+ MLX5_EVENT_TYPE_CODING_FPGA_QP_ERROR = 0x21
};
enum {
diff --git a/include/linux/mlx5/mlx5_ifc_fpga.h b/include/linux/mlx5/mlx5_ifc_fpga.h
index ec052491ba3d..7ddca31fa05d 100644
--- a/include/linux/mlx5/mlx5_ifc_fpga.h
+++ b/include/linux/mlx5/mlx5_ifc_fpga.h
@@ -432,6 +432,22 @@ struct mlx5_ifc_ipsec_counters_bits {
u8 dropped_cmd[0x40];
};
+enum {
+ MLX5_FPGA_QP_ERROR_EVENT_SYNDROME_RETRY_COUNTER_EXPIRED = 0x1,
+ MLX5_FPGA_QP_ERROR_EVENT_SYNDROME_RNR_EXPIRED = 0x2,
+};
+
+struct mlx5_ifc_fpga_qp_error_event_bits {
+ u8 reserved_at_0[0x40];
+
+ u8 reserved_at_40[0x18];
+ u8 syndrome[0x8];
+
+ u8 reserved_at_60[0x60];
+
+ u8 reserved_at_c0[0x8];
+ u8 fpga_qpn[0x18];
+};
enum mlx5_ifc_fpga_ipsec_response_syndrome {
MLX5_FPGA_IPSEC_RESPONSE_SUCCESS = 0,
MLX5_FPGA_IPSEC_RESPONSE_ILLEGAL_REQUEST = 1,
--
2.17.0
^ permalink raw reply related
* [PATCH] netfilter: nfnetlink: Remove VLA usage
From: Kees Cook @ 2018-05-30 0:35 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel
In the quest to remove all stack VLA usage from the kernel[1], this
allocates the maximum size expected for all possible attrs and adds
a sanity-check to make sure nothing gets out of sync.
[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Signed-off-by: Kees Cook <keescook@chromium.org>
---
net/netfilter/nfnetlink.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 03ead8a9e90c..0cb395f9627e 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -28,6 +28,7 @@
#include <net/netlink.h>
#include <linux/netfilter/nfnetlink.h>
+#include <linux/netfilter/nf_tables.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Harald Welte <laforge@netfilter.org>");
@@ -37,6 +38,11 @@ MODULE_ALIAS_NET_PF_PROTO(PF_NETLINK, NETLINK_NETFILTER);
rcu_dereference_protected(table[(id)].subsys, \
lockdep_nfnl_is_held((id)))
+#define NFTA_MAX_ATTR max(max(max(NFTA_CHAIN_MAX, NFTA_FLOWTABLE_MAX),\
+ max(NFTA_OBJ_MAX, NFTA_RULE_MAX)), \
+ max(NFTA_TABLE_MAX, \
+ max(NFTA_SET_ELEM_LIST_MAX, NFTA_SET_MAX)))
+
static struct {
struct mutex mutex;
const struct nfnetlink_subsystem __rcu *subsys;
@@ -185,11 +191,17 @@ static int nfnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
{
int min_len = nlmsg_total_size(sizeof(struct nfgenmsg));
u8 cb_id = NFNL_MSG_TYPE(nlh->nlmsg_type);
- struct nlattr *cda[ss->cb[cb_id].attr_count + 1];
+ struct nlattr *cda[NFTA_MAX_ATTR + 1];
struct nlattr *attr = (void *)nlh + min_len;
int attrlen = nlh->nlmsg_len - min_len;
__u8 subsys_id = NFNL_SUBSYS_ID(type);
+ /* Sanity-check NFTA_MAX_ATTR */
+ if (ss->cb[cb_id].attr_count > NFTA_MAX_ATTR) {
+ rcu_read_unlock();
+ return -ENOMEM;
+ }
+
err = nla_parse(cda, ss->cb[cb_id].attr_count, attr, attrlen,
ss->cb[cb_id].policy, extack);
if (err < 0) {
@@ -379,10 +391,16 @@ static void nfnetlink_rcv_batch(struct sk_buff *skb, struct nlmsghdr *nlh,
{
int min_len = nlmsg_total_size(sizeof(struct nfgenmsg));
u8 cb_id = NFNL_MSG_TYPE(nlh->nlmsg_type);
- struct nlattr *cda[ss->cb[cb_id].attr_count + 1];
+ struct nlattr *cda[NFTA_MAX_ATTR + 1];
struct nlattr *attr = (void *)nlh + min_len;
int attrlen = nlh->nlmsg_len - min_len;
+ /* Sanity-check NFTA_MAX_ATTR */
+ if (ss->cb[cb_id].attr_count > NFTA_MAX_ATTR) {
+ err = -ENOMEM;
+ goto ack;
+ }
+
err = nla_parse(cda, ss->cb[cb_id].attr_count, attr,
attrlen, ss->cb[cb_id].policy, NULL);
if (err < 0)
--
2.17.0
--
Kees Cook
Pixel Security
^ permalink raw reply related
* [PATCH] ixgbe: check ipsec ip addr against mgmt filter
From: Shannon Nelson @ 2018-05-30 0:44 UTC (permalink / raw)
To: intel-wired-lan, jeffrey.t.kirsher; +Cc: netdev
Make sure we don't try to offload the decryption of an incoming
packet that should get delivered to the management engine. This
is a corner case that will likely be very seldom seen, but could
really confuse someone if they were to hit it.
Suggested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 64 ++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 99b170f..ea3b5fa 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -445,6 +445,65 @@ static int ixgbe_ipsec_parse_proto_keys(struct xfrm_state *xs,
}
/**
+ * ixgbe_ipsec_check_mgmt_ip - make sure there is no clash with mgmt IP filters
+ * @xs: pointer to transformer state struct
+ **/
+static int ixgbe_ipsec_check_mgmt_ip(struct xfrm_state *xs)
+{
+ struct net_device *dev = xs->xso.dev;
+ struct ixgbe_adapter *adapter = netdev_priv(dev);
+ struct ixgbe_hw *hw = &adapter->hw;
+ u32 mfval, manc, reg;
+ int num_filters = 4;
+ bool manc_ipv4;
+ int i, j;
+
+#define MANC_EN_IPV4_FILTER BIT(24)
+#define MFVAL_IPV4_FILTER_SHIFT 16
+#define MFVAL_IPV6_FILTER_SHIFT 24
+#define MIPAF_ARR(_m, _n) (IXGBE_MIPAF + ((_m) * 0x10) + ((_n) * 4))
+
+ manc = IXGBE_READ_REG(hw, IXGBE_MANC);
+ manc_ipv4 = !!(manc & MANC_EN_IPV4_FILTER);
+ mfval = IXGBE_READ_REG(hw, IXGBE_MFVAL);
+
+ if (xs->props.family == AF_INET) {
+ /* are there any IPv4 filters to check? */
+ if (!manc_ipv4)
+ return 0;
+
+ /* the 4 ipv4 filters are all in MIPAF(3, i) */
+ for (i = 0; i < num_filters; i++) {
+ if (!(mfval & BIT(MFVAL_IPV4_FILTER_SHIFT + i)))
+ continue;
+
+ reg = IXGBE_READ_REG(hw, MIPAF_ARR(3, i));
+ if (reg == xs->id.daddr.a4)
+ return 1;
+ }
+ } else {
+ /* if there are ipv4 filters, they are in the last ipv6 slot */
+ if (manc_ipv4)
+ num_filters = 3;
+
+ for (i = 0; i < num_filters; i++) {
+ if (!(mfval & BIT(MFVAL_IPV6_FILTER_SHIFT + i)))
+ continue;
+
+ for (j = 0; j < 4; j++) {
+ reg = IXGBE_READ_REG(hw, MIPAF_ARR(i, j));
+ if (reg != xs->id.daddr.a6[j])
+ break;
+ }
+ if (j == 4) /* did we match all 4 words? */
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
+/**
* ixgbe_ipsec_add_sa - program device with a security association
* @xs: pointer to transformer state struct
**/
@@ -465,6 +524,11 @@ static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
return -EINVAL;
}
+ if (ixgbe_ipsec_check_mgmt_ip(xs)) {
+ netdev_err(dev, "IPsec IP addr clash with mgmt filters\n");
+ return -EINVAL;
+ }
+
if (xs->xso.flags & XFRM_OFFLOAD_INBOUND) {
struct rx_sa rsa;
--
2.7.4
^ 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