* [PATCH rdma-next 25/25] IB/mlx5: Enable DEVX on IB
From: Leon Romanovsky @ 2018-09-17 11:04 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180917110418.18937-1-leon@kernel.org>
From: Yishai Hadas <yishaih@mellanox.com>
IB has additional protections with SELinux that cannot be extended to
the DEVX domain. SELinux can restrict access to pkeys. The first version
of DEVX blocked IB entirely until this could be understood.
Since DEVX requires CAP_NET_RAW, it supersedes the SELinux restriction
and allows userspace to form arbitrary packets with arbitrary pkeys.
Thus we enable IB for DEVX when CAP_NET_RAW is given.
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/hw/mlx5/main.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 8cc285c4da8e..c31e57bead8e 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1759,12 +1759,6 @@ static struct ib_ucontext *mlx5_ib_alloc_ucontext(struct ib_device *ibdev,
#endif
if (req.flags & MLX5_IB_ALLOC_UCTX_DEVX) {
- /* Block DEVX on Infiniband as of SELinux */
- if (mlx5_ib_port_link_layer(ibdev, 1) != IB_LINK_LAYER_ETHERNET) {
- err = -EPERM;
- goto out_uars;
- }
-
err = mlx5_ib_devx_create(dev);
if (err < 0)
goto out_uars;
--
2.14.4
^ permalink raw reply related
* [PATCH rdma-next 21/25] IB/mlx5: Set valid umem bit on DEVX
From: Leon Romanovsky @ 2018-09-17 11:04 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180917110418.18937-1-leon@kernel.org>
From: Yishai Hadas <yishaih@mellanox.com>
Set valid umem bit on DEVX commands that use umem.
This will enforce the umem usage by the firmware and not the 'pas' info.
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/hw/mlx5/devx.c | 95 +++++++++++++++++++++++++++++++++++++++
1 file changed, 95 insertions(+)
diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c
index 25dafa4ff6ca..562c7936bbad 100644
--- a/drivers/infiniband/hw/mlx5/devx.c
+++ b/drivers/infiniband/hw/mlx5/devx.c
@@ -264,6 +264,97 @@ static int devx_is_valid_obj_id(struct devx_obj *obj, const void *in)
return false;
}
+static void devx_set_umem_valid(const void *in)
+{
+ u16 opcode = MLX5_GET(general_obj_in_cmd_hdr, in, opcode);
+
+ switch (opcode) {
+ case MLX5_CMD_OP_CREATE_MKEY:
+ MLX5_SET(create_mkey_in, in, mkey_umem_valid, 1);
+ break;
+ case MLX5_CMD_OP_CREATE_CQ:
+ {
+ void *cqc;
+
+ MLX5_SET(create_cq_in, in, cq_umem_valid, 1);
+ cqc = MLX5_ADDR_OF(create_cq_in, in, cq_context);
+ MLX5_SET(cqc, cqc, dbr_umem_valid, 1);
+ break;
+ }
+ case MLX5_CMD_OP_CREATE_QP:
+ {
+ void *qpc;
+
+ qpc = MLX5_ADDR_OF(create_qp_in, in, qpc);
+ MLX5_SET(qpc, qpc, dbr_umem_valid, 1);
+ MLX5_SET(create_qp_in, in, wq_umem_valid, 1);
+ break;
+ }
+
+ case MLX5_CMD_OP_CREATE_RQ:
+ {
+ void *rqc, *wq;
+
+ rqc = MLX5_ADDR_OF(create_rq_in, in, ctx);
+ wq = MLX5_ADDR_OF(rqc, rqc, wq);
+ MLX5_SET(wq, wq, dbr_umem_valid, 1);
+ MLX5_SET(wq, wq, wq_umem_valid, 1);
+ break;
+ }
+
+ case MLX5_CMD_OP_CREATE_SQ:
+ {
+ void *sqc, *wq;
+
+ sqc = MLX5_ADDR_OF(create_sq_in, in, ctx);
+ wq = MLX5_ADDR_OF(sqc, sqc, wq);
+ MLX5_SET(wq, wq, dbr_umem_valid, 1);
+ MLX5_SET(wq, wq, wq_umem_valid, 1);
+ break;
+ }
+
+ case MLX5_CMD_OP_MODIFY_CQ:
+ MLX5_SET(modify_cq_in, in, cq_umem_valid, 1);
+ break;
+
+ case MLX5_CMD_OP_CREATE_RMP:
+ {
+ void *rmpc, *wq;
+
+ rmpc = MLX5_ADDR_OF(create_rmp_in, in, ctx);
+ wq = MLX5_ADDR_OF(rmpc, rmpc, wq);
+ MLX5_SET(wq, wq, dbr_umem_valid, 1);
+ MLX5_SET(wq, wq, wq_umem_valid, 1);
+ break;
+ }
+
+ case MLX5_CMD_OP_CREATE_XRQ:
+ {
+ void *xrqc, *wq;
+
+ xrqc = MLX5_ADDR_OF(create_xrq_in, in, xrq_context);
+ wq = MLX5_ADDR_OF(xrqc, xrqc, wq);
+ MLX5_SET(wq, wq, dbr_umem_valid, 1);
+ MLX5_SET(wq, wq, wq_umem_valid, 1);
+ break;
+ }
+
+ case MLX5_CMD_OP_CREATE_XRC_SRQ:
+ {
+ void *xrc_srqc;
+
+ MLX5_SET(create_xrc_srq_in, in, xrc_srq_umem_valid, 1);
+ xrc_srqc = MLX5_ADDR_OF(create_xrc_srq_in, in,
+ xrc_srq_context_entry);
+ MLX5_SET(xrc_srqc, xrc_srqc, dbr_umem_valid, 1);
+ break;
+ }
+
+ default:
+ return;
+ }
+}
+
static bool devx_is_obj_create_cmd(const void *in)
{
u16 opcode = MLX5_GET(general_obj_in_cmd_hdr, in, opcode);
@@ -741,6 +832,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
return -ENOMEM;
MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, c->devx_uid);
+ devx_set_umem_valid(cmd_in);
+
err = mlx5_cmd_exec(dev->mdev, cmd_in,
uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OBJ_CREATE_CMD_IN),
cmd_out, cmd_out_len);
@@ -790,6 +883,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_MODIFY)(
return PTR_ERR(cmd_out);
MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, c->devx_uid);
+ devx_set_umem_valid(cmd_in);
+
err = mlx5_cmd_exec(obj->mdev, cmd_in,
uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN),
cmd_out, cmd_out_len);
--
2.14.4
^ permalink raw reply related
* Re: iproute2: Debian 9 No ELF support
From: Bo YU @ 2018-09-17 11:46 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: yuzibode, netdev
In-Reply-To: <b7e1ba40-7cd2-ac4a-7544-ec3ff454ad15@iogearbox.net>
Hi,
On Mon, Sep 17, 2018 at 11:57:12AM +0200, Daniel Borkmann wrote:
>On 09/17/2018 10:23 AM, Bo YU wrote:
>> Hello,
>> I have followed the instructions from:
>>
>> https://cilium.readthedocs.io/en/latest/bpf/#bpftool
>>
>> to test xdp program.
>> But i can not enable elf support.
>>
>> ./configure --prefix=/usr
>> ```output
>> TC schedulers
>> ATM no
>>
>> libc has setns: yes
>> SELinux support: no
>> ELF support: no
>> libmnl support: yes
>> Berkeley DB: yes
>> need for strlcpy: yes
>> libcap support: yes
>> ```
>> And i have installed libelf-dev :
>> ```output
>> sudo apt show libelf-dev
>> Package: libelf-dev
>> Version: 0.168-1
>> Priority: optional
>> Section: libdevel
>> Source: elfutils
>> Maintainer: Kurt Roeckx <kurt@roeckx.be>
>> Installed-Size: 353 kB
>> Depends: libelf1 (= 0.168-1)
>> Conflicts: libelfg0-dev
>> Homepage: https://sourceware.org/elfutils/
>> Tag: devel::library, role::devel-lib
>> ```
>>
>> And gcc version:
>> gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
>>
>> uname -a:
>> Linux debian 4.18.0-rc1+ #2 SMP Sun Jun 24 16:53:57 HKT 2018 x86_64 GNU/Linux
>>
>> Any help is appreciate.
>
>Debian's official iproute2 packaging build says 'libelf-dev' [0], and having
>libelf-dev installed should work ...
>
> [...]
> Build-Depends: bison,
> debhelper (>= 10~),
> flex,
> iptables-dev,
> libatm1-dev,
> libcap-dev,
> libdb-dev,
> libelf-dev,
> libmnl-dev,
> libselinux1-dev,
> linux-libc-dev,
> pkg-config,
> po-debconf,
> zlib1g-dev,
> [...]
>
>Did you ran into this one perhaps [1]? Do you have zlib1g-dev installed?
Yes,You are right. I install zlib1g-dev with your help,iproute2 enable ELF
support.
```output
./configure --prefix=/usr
TC schedulers
ATM no
libc has setns: yes
SELinux support: no
ELF support: yes
libmnl support: yes
Berkeley DB: yes
need for strlcpy: yes
libcap support: yes
```
But there is no effect after [1], right? When i install libelf-dev,it should
install zlib1g-dev also.
Is there any way to update the page [2]?
Thank you, Daniel
[2] https://cilium.readthedocs.io/en/latest/bpf/#bpftool
>
> [0] https://salsa.debian.org/debian/iproute2/blob/master/debian/control
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885071
^ permalink raw reply
* Re: [PATCH net-next] net/smc: cast sizeof to int for comparison
From: Ursula Braun @ 2018-09-17 11:49 UTC (permalink / raw)
To: YueHaibing; +Cc: davem, linux-kernel, netdev, linux-s390
In-Reply-To: <c50b9154-e72b-437b-d0c4-40f2b8943c65@huawei.com>
On 09/17/2018 11:38 AM, YueHaibing wrote:
>
> On 2018/9/17 16:49, Ursula Braun wrote:
>>
>>
>> On 09/15/2018 12:00 PM, YueHaibing wrote:
>>> Comparing an int to a size, which is unsigned, causes the int to become
>>> unsigned, giving the wrong result. kernel_sendmsg can return a negative
>>> error code.
>>>
>>
>> Thanks for reporting this issue!
>>
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>> ---
>>> net/smc/smc_clc.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/smc/smc_clc.c b/net/smc/smc_clc.c
>>> index 83aba9a..fd0f5ce 100644
>>> --- a/net/smc/smc_clc.c
>>> +++ b/net/smc/smc_clc.c
>>> @@ -446,7 +446,7 @@ int smc_clc_send_proposal(struct smc_sock *smc, int smc_type,
>>> vec[i++].iov_len = sizeof(trl);
>>> /* due to the few bytes needed for clc-handshake this cannot block */
>>> len = kernel_sendmsg(smc->clcsock, &msg, vec, i, plen);
>>> - if (len < sizeof(pclc)) {
>>> + if (len < (int)sizeof(pclc)) {
>>> if (len >= 0) {
>>> reason_code = -ENETUNREACH;
>>> smc->sk.sk_err = -reason_code;
>>>
>>
>> Your fix helps, but I would like to follow the hint of Andreas Schwab, and split
>> the return value check like this:
>>
>> ---
>> net/smc/smc_clc.c | 14 ++++++--------
>> 1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> --- a/net/smc/smc_clc.c
>> +++ b/net/smc/smc_clc.c
>> @@ -446,14 +446,12 @@ int smc_clc_send_proposal(struct smc_soc
>> vec[i++].iov_len = sizeof(trl);
>> /* due to the few bytes needed for clc-handshake this cannot block */
>> len = kernel_sendmsg(smc->clcsock, &msg, vec, i, plen);
>> - if (len < sizeof(pclc)) {
>> - if (len >= 0) {
>> - reason_code = -ENETUNREACH;
>> - smc->sk.sk_err = -reason_code;
>> - } else {
>> - smc->sk.sk_err = smc->clcsock->sk->sk_err;
>> - reason_code = -smc->sk.sk_err;
>> - }
>> + if (len < 0) {
>> + smc->sk.sk_err = smc->clcsock->sk->sk_err;
>> + reason_code = -smc->sk.sk_err;
>> + } else if (len < (int)sizeof(pclc)) {
>> + reason_code = -ENETUNREACH;
>> + smc->sk.sk_err = -reason_code;
>> }
>>
>> return reason_code;
>>
>> Agreed?
>
> Yes, Need a new patch from me?
>
Not necessary, I will make sure this patch version is added to the smc code.
>>
>> Regards, Ursula
>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH net] net: phy: sfp: Prevent NULL deference of socket_ops
From: Florian Fainelli @ 2018-09-17 17:30 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: netdev, Andrew Lunn, David S. Miller, open list
In-Reply-To: <20180915073228.GE30658@n2100.armlinux.org.uk>
On 09/15/2018 12:32 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 14, 2018 at 04:01:31PM -0700, Florian Fainelli wrote:
>> In case we have specified a SFP and an I2C phandle in the Device Tree,
>> but we somehow failed to look up the I2C adapter (e.g: the driver is not
>> enabled), we will leave dangling socket_ops, and the sfp_bus will still
>> have been registered. We can then observe NULL pointer dereferences
>> while doing ethtool -m:
>>
>> [ 20.218613] Unable to handle kernel NULL pointer dereference at virtual address 00000008
>> [ 20.226977] pgd = (ptrval)
>> [ 20.229785] [00000008] *pgd=7c400831, *pte=00000000, *ppte=00000000
>> [ 20.236274] Internal error: Oops: 17 [#1] SMP ARM
>> [ 20.241122] Modules linked in:
>> [ 20.244278] CPU: 0 PID: 1480 Comm: ethtool Not tainted 4.19.0-rc3 #138
>> [ 20.251013] Hardware name: Broadcom Northstar Plus SoC
>> [ 20.256316] PC is at sfp_get_module_info+0x8/0x10
>> [ 20.261172] LR is at dev_ethtool+0x218c/0x2afc
>>
>> Specifically guard against that.
>
> The other alternative to this would be to only set ndev->sfp_bus when
> the bus moves to registered state, which would probably be a saner
> alternative than to add an additional layer of tests. IOW:
Indeed, your patch works for me:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>
> drivers/net/phy/sfp-bus.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
> index 48ca980f5c96..c4c2b5269216 100644
> --- a/drivers/net/phy/sfp-bus.c
> +++ b/drivers/net/phy/sfp-bus.c
> @@ -362,6 +362,7 @@ static int sfp_register_bus(struct sfp_bus *bus)
> }
> if (bus->started)
> bus->socket_ops->start(bus->sfp);
> + bus->netdev->sfp_bus = bus;
> bus->registered = true;
> return 0;
> }
> @@ -370,6 +371,7 @@ static void sfp_unregister_bus(struct sfp_bus *bus)
> {
> const struct sfp_upstream_ops *ops = bus->upstream_ops;
>
> + bus->netdev->sfp_bus = NULL;
> if (bus->registered) {
> if (bus->started)
> bus->socket_ops->stop(bus->sfp);
> @@ -451,7 +453,6 @@ static void sfp_upstream_clear(struct sfp_bus *bus)
> {
> bus->upstream_ops = NULL;
> bus->upstream = NULL;
> - bus->netdev->sfp_bus = NULL;
> bus->netdev = NULL;
> }
>
> @@ -480,7 +481,6 @@ struct sfp_bus *sfp_register_upstream(struct fwnode_handle *fwnode,
> bus->upstream_ops = ops;
> bus->upstream = upstream;
> bus->netdev = ndev;
> - ndev->sfp_bus = bus;
>
> if (bus->sfp) {
> ret = sfp_register_bus(bus);
>
--
Florian
^ permalink raw reply
* Re: iproute2: Debian 9 No ELF support
From: Daniel Borkmann @ 2018-09-17 12:07 UTC (permalink / raw)
To: yuzibode; +Cc: netdev
In-Reply-To: <20180917114607.zdfynraumichm4id@yubo-2>
On 09/17/2018 01:46 PM, Bo YU wrote:
> On Mon, Sep 17, 2018 at 11:57:12AM +0200, Daniel Borkmann wrote:
>> On 09/17/2018 10:23 AM, Bo YU wrote:
>>> Hello,
>>> I have followed the instructions from:
>>>
>>> https://cilium.readthedocs.io/en/latest/bpf/#bpftool
>>>
>>> to test xdp program.
>>> But i can not enable elf support.
>>>
>>> ./configure --prefix=/usr
>>> ```output
>>> TC schedulers
>>> ATM no
>>>
>>> libc has setns: yes
>>> SELinux support: no
>>> ELF support: no
>>> libmnl support: yes
>>> Berkeley DB: yes
>>> need for strlcpy: yes
>>> libcap support: yes
>>> ```
>>> And i have installed libelf-dev :
>>> ```output
>>> sudo apt show libelf-dev
>>> Package: libelf-dev
>>> Version: 0.168-1
>>> Priority: optional
>>> Section: libdevel
>>> Source: elfutils
>>> Maintainer: Kurt Roeckx <kurt@roeckx.be>
>>> Installed-Size: 353 kB
>>> Depends: libelf1 (= 0.168-1)
>>> Conflicts: libelfg0-dev
>>> Homepage: https://sourceware.org/elfutils/
>>> Tag: devel::library, role::devel-lib
>>> ```
>>>
>>> And gcc version:
>>> gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
>>>
>>> uname -a:
>>> Linux debian 4.18.0-rc1+ #2 SMP Sun Jun 24 16:53:57 HKT 2018 x86_64 GNU/Linux
>>>
>>> Any help is appreciate.
>>
>> Debian's official iproute2 packaging build says 'libelf-dev' [0], and having
>> libelf-dev installed should work ...
>>
>> [...]
>> Build-Depends: bison,
>> debhelper (>= 10~),
>> flex,
>> iptables-dev,
>> libatm1-dev,
>> libcap-dev,
>> libdb-dev,
>> libelf-dev,
>> libmnl-dev,
>> libselinux1-dev,
>> linux-libc-dev,
>> pkg-config,
>> po-debconf,
>> zlib1g-dev,
>> [...]
>>
>> Did you ran into this one perhaps [1]? Do you have zlib1g-dev installed?
> Yes,You are right. I install zlib1g-dev with your help,iproute2 enable ELF
> support.
> ```output
> ./configure --prefix=/usr
> TC schedulers
> ATM no
>
> libc has setns: yes
> SELinux support: no
> ELF support: yes
> libmnl support: yes
> Berkeley DB: yes
> need for strlcpy: yes
> libcap support: yes
>
> ```
> But there is no effect after [1], right? When i install libelf-dev,it should
> install zlib1g-dev also.
>
> Is there any way to update the page [2]?
This bug should be Debian specific, so it would make sense to contact Debian
developers or comment on [1] if it's still not resolved in current versions.
> Thank you, Daniel
>
> [2] https://cilium.readthedocs.io/en/latest/bpf/#bpftool
>>
>> [0] https://salsa.debian.org/debian/iproute2/blob/master/debian/control
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885071
^ permalink raw reply
* Re: [PATCH] net: bnxt: Fix a uninitialized variable warning.
From: Michael Chan @ 2018-09-17 17:36 UTC (permalink / raw)
To: zhong jiang, Vasundhara Volam; +Cc: David Miller, Netdev, open list
In-Reply-To: <1537201883-2518-1-git-send-email-zhongjiang@huawei.com>
On Mon, Sep 17, 2018 at 9:31 AM, zhong jiang <zhongjiang@huawei.com> wrote:
>
> Fix the following compile warning:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:49:5: warning: ‘nvm_param.dir_type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (nvm_param.dir_type == BNXT_NVM_PORT_CFG)
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> index f3b9fbc..ab88217 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> @@ -31,7 +31,7 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
> {
> struct hwrm_nvm_get_variable_input *req = msg;
> void *data_addr = NULL, *buf = NULL;
> - struct bnxt_dl_nvm_param nvm_param;
> + struct bnxt_dl_nvm_param nvm_param = {0};
> int bytesize, idx = 0, rc, i;
> dma_addr_t data_dma_addr;
>
I think it is better to return error if there is no param_id match
after the for loop. The for loop will initialize nvm_param if there
is param_id match.
^ permalink raw reply
* [PATCH v2 net] net/ipv4: defensive cipso option parsing
From: Stefan Nuernberger @ 2018-09-17 17:46 UTC (permalink / raw)
To: netdev; +Cc: aams, dwmw, yujuan.qi, paul, snu, sveith, stable
In-Reply-To: <CAHC9VhQ+VKPFmx3R7Ty60KAJhiZwnc2-ZKRYG9w2NSAH7vgnoQ@mail.gmail.com>
commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
a possible infinite loop in the IP option parsing of CIPSO. The fix
assumes that ip_options_compile filtered out all zero length options and
that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
While this assumption currently holds true, add explicit checks for zero
length and invalid length options to be safe for the future. Even though
ip_options_compile should have validated the options, the introduction of
new one-byte options can still confuse this code without the additional
checks.
Signed-off-by: Stefan Nuernberger <snu@amazon.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Simon Veith <sveith@amazon.de>
Cc: stable@vger.kernel.org
---
net/ipv4/cipso_ipv4.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 82178cc69c96..777fa3b7fb13 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1512,7 +1512,7 @@ static int cipso_v4_parsetag_loc(const struct cipso_v4_doi *doi_def,
*
* Description:
* Parse the packet's IP header looking for a CIPSO option. Returns a pointer
- * to the start of the CIPSO option on success, NULL if one if not found.
+ * to the start of the CIPSO option on success, NULL if one is not found.
*
*/
unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
@@ -1522,10 +1522,8 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
int optlen;
int taglen;
- for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
+ for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 1; ) {
switch (optptr[0]) {
- case IPOPT_CIPSO:
- return optptr;
case IPOPT_END:
return NULL;
case IPOPT_NOOP:
@@ -1534,6 +1532,11 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
default:
taglen = optptr[1];
}
+ if (!taglen || taglen > optlen)
+ return NULL;
+ if (optptr[0] == IPOPT_CIPSO)
+ return optptr;
+
optlen -= taglen;
optptr += taglen;
}
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net-next v3 0/2] net: stmmac: Coalesce and tail addr fixes
From: Jose Abreu @ 2018-09-17 12:51 UTC (permalink / raw)
To: Jerome Brunet, Jose Abreu, netdev
Cc: Florian Fainelli, Neil Armstrong, Martin Blumenstingl,
David S. Miller, Joao Pinto, Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <8ff91f0c9c302e26149bb0d02a73d44472eb190a.camel@baylibre.com>
Hi Jerome,
On 14-09-2018 16:06, Jerome Brunet wrote:
>
> Looks better this time. Stable so far, with even a small throughput improvement
> on the Tx path.
>
> so for the a113 s400 board (single queue)
> Tested-by: Jerome Brunet <jbrunet@baylibre.com>
>
Thanks for testing! I sent out a rebased version against net.
Can you share what's the throughput improvement in % ?
Do you still see the performance drop when tx/rx work at same
time ? I remember that was another issue ...
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH net] selftests: pmtu: properly redirect stderr to /dev/null
From: Sabrina Dubroca @ 2018-09-17 13:30 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Stefano Brivio
The cleanup function uses "$CMD 2 > /dev/null", which doesn't actually
send stderr to /dev/null, so when the netns doesn't exist, the error
message is shown. Use "2> /dev/null" instead, so that those messages
disappear, as was intended.
Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
tools/testing/selftests/net/pmtu.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh
index 32a194e3e07a..0ab9423d009f 100755
--- a/tools/testing/selftests/net/pmtu.sh
+++ b/tools/testing/selftests/net/pmtu.sh
@@ -178,8 +178,8 @@ setup() {
cleanup() {
[ ${cleanup_done} -eq 1 ] && return
- ip netns del ${NS_A} 2 > /dev/null
- ip netns del ${NS_B} 2 > /dev/null
+ ip netns del ${NS_A} 2> /dev/null
+ ip netns del ${NS_B} 2> /dev/null
cleanup_done=1
}
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net] selftests: pmtu: properly redirect stderr to /dev/null
From: Stefano Brivio @ 2018-09-17 13:45 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: netdev
In-Reply-To: <132b14cab49cd959d9cf6e6607b01c383db2d984.1537190905.git.sd@queasysnail.net>
On Mon, 17 Sep 2018 15:30:06 +0200
Sabrina Dubroca <sd@queasysnail.net> wrote:
> The cleanup function uses "$CMD 2 > /dev/null", which doesn't actually
> send stderr to /dev/null, so when the netns doesn't exist, the error
> message is shown. Use "2> /dev/null" instead, so that those messages
> disappear, as was intended.
Oops, thanks for catching this.
> Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Stefano Brivio <sbrivio@redhat.com>
--
Stefano
^ permalink raw reply
* Re: [RFC PATCH 2/4] net: enable UDP gro on demand.
From: Willem de Bruijn @ 2018-09-17 14:07 UTC (permalink / raw)
To: Paolo Abeni
Cc: Network Development, David Miller, Willem de Bruijn,
steffen.klassert
In-Reply-To: <ceb3e427666e5b498aae13af1a97241e8216bcc6.camel@redhat.com>
On Mon, Sep 17, 2018 at 6:18 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Sun, 2018-09-16 at 14:23 -0400, Willem de Bruijn wrote:
> > That udp gro implementation is clearly less complete than yours in
> > this patchset. The point I wanted to bring up for discussion is not the
> > protocol implementation, but the infrastructure for enabling it
> > conditionally.
>
> I'm still [trying to] processing your patchset ;) So please perdon me
> for any obvious interpretation mistakes...
>
> > Assuming cycle cost is comparable, what do you think of using the
> > existing sk offload callbacks to enable this on a per-socket basis?
>
> I have no objection about that, if there are no performance drawbacks.
> In my measures retpoline costs is relevant for every indirect call
> added. Using the existing sk offload approach will require an
> additional indirect call per packet compared to the implementation
> here.
Fair enough. The question is whether it is significant to the real workload.
This is also an issue with GRO processing in general, all those callbacks
as well as the two cacheline lookups to get to each callback.
> > As for the protocol-wide knob, I do strongly prefer something that can
> > work for all protocols, not just UDP.
>
> I like the general infrastructure idea. I think there is some agreement
> in avoiding the addition of more user-controllable knobs, as we already
> have a lot of them. If I read your patch correctly, user-space need to
> enable/disable the UDO GSO explicitly via procfs, right?
No, like other GRO callbacks, the feature is enabled by default.
Patch 7/8 disables the most expensive part behind a static key
until a socket actually registers a GRO callback, whether tunnel
or the new application GRO.
Patch 6/9 makes it possible to disable any protocol completely,
indeed through a sysctl.
> I tried to look for something that does not require user action.
>
> > I also implemented a version that
> > atomically swaps the struct ptr instead of the flag based approach I sent
> > for review. I'm fairly agnostic about that point.
>
> I think/fear security oriented guys may scream for the somewhat large
> deconstification ?!?
Hmm.. yes, interesting point. Since const pointers are a compile time
feature, in practice I don't think that they buy any protection against
callback pointer rewriting. Let me think about that some more.
>
> > One subtle issue is that I
> > believe we need to keep the gro_complete callbacks enabled, as gro
> > packets may be queued for completion when gro_receive gets disabled.
>
> Good point, thanks! I missed that.
>
> Cheers,
>
> Paolo
>
>
^ permalink raw reply
* Re: [PATCH net-next RFC 7/8] udp: gro behind static key
From: Willem de Bruijn @ 2018-09-17 14:10 UTC (permalink / raw)
To: steffen.klassert
Cc: Network Development, Paolo Abeni, David Miller, Willem de Bruijn
In-Reply-To: <20180917090323.GF23674@gauss3.secunet.de>
On Mon, Sep 17, 2018 at 5:03 AM Steffen Klassert
<steffen.klassert@secunet.com> wrote:
>
> On Fri, Sep 14, 2018 at 01:59:40PM -0400, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@google.com>
> >
> > Avoid the socket lookup cost in udp_gro_receive if no socket has a
> > gro callback configured.
> >
> > Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> ...
>
> > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > index 4f6aa95a9b12..f44fe328aa0f 100644
> > --- a/net/ipv4/udp_offload.c
> > +++ b/net/ipv4/udp_offload.c
> > @@ -405,7 +405,7 @@ static struct sk_buff *udp4_gro_receive(struct list_head *head,
> > {
> > struct udphdr *uh = udp_gro_udphdr(skb);
> >
> > - if (unlikely(!uh))
> > + if (unlikely(!uh) || !static_branch_unlikely(&udp_encap_needed_key))
> > goto flush;
>
> If you use udp_encap_needed_key to enalbe UDP GRO, then a UDP
> encapsulation socket will enable it too. Not sure if this is
> intentional.
Yes. That is already the case to a certain point. The function was
introduced with tunnels and is enabled by tunnels, but so far only
compiles out the encap_rcv() branch in udp_qeueue_rcv_skb.
With patch 7/8 it also toggles the GRO path. Critically, both are
enabled as soon as a tunnel is registered.
>
> That said, enabling UDP GRO on a UDP encapsulation socket
> (ESP in UPD etc.) will fail badly as then encrypted ESP
> packets might be merged together. So we somehow should
> make sure that this does not happen.
Absolutely. This initial implementation probably breaks UDP tunnels
badly. That needs to be addressed.
>
> Anyway, this reminds me that we can support GRO for
> UDP encapsulation. It just requires separate GRO
> callbacks for the different encapsulation types.
^ permalink raw reply
* Re: [PATCH net-next RFC 7/8] udp: gro behind static key
From: Willem de Bruijn @ 2018-09-17 14:12 UTC (permalink / raw)
To: Paolo Abeni
Cc: Network Development, steffen.klassert, David Miller,
Willem de Bruijn
In-Reply-To: <203cd0cd80a6876b5d5de42e234aac5ff6a5ebf5.camel@redhat.com>
On Mon, Sep 17, 2018 at 6:24 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Fri, 2018-09-14 at 13:59 -0400, Willem de Bruijn wrote:
> > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > index 4f6aa95a9b12..f44fe328aa0f 100644
> > --- a/net/ipv4/udp_offload.c
> > +++ b/net/ipv4/udp_offload.c
> > @@ -405,7 +405,7 @@ static struct sk_buff *udp4_gro_receive(struct list_head *head,
> > {
> > struct udphdr *uh = udp_gro_udphdr(skb);
> >
> > - if (unlikely(!uh))
> > + if (unlikely(!uh) || !static_branch_unlikely(&udp_encap_needed_key))
> > goto flush;
> >
> > /* Don't bother verifying checksum if we're going to flush anyway. */
>
> If I read this correctly, once udp_encap_needed_key is enabled, it will
> never be turned off, because the tunnel and encap socket shut down does
> not cope with udp_encap_needed_key.
>
> Perhaps we should take care of that, too.
Agreed. For now I reused what's already there, but I can extend
that with refcounting using static_branch_inc/static_branch_dec.
^ permalink raw reply
* Re: [PATCH net-next RFC 7/8] udp: gro behind static key
From: Willem de Bruijn @ 2018-09-17 14:19 UTC (permalink / raw)
To: steffen.klassert
Cc: Network Development, Paolo Abeni, David Miller, Willem de Bruijn
In-Reply-To: <20180917103728.GG23674@gauss3.secunet.de>
On Mon, Sep 17, 2018 at 6:37 AM Steffen Klassert
<steffen.klassert@secunet.com> wrote:
>
> On Fri, Sep 14, 2018 at 01:59:40PM -0400, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@google.com>
> >
> > Avoid the socket lookup cost in udp_gro_receive if no socket has a
> > gro callback configured.
>
> It would be nice if we could do GRO not just for GRO configured
> sockets, but also for flows that are going to be IPsec transformed
> or directly forwarded.
I thought about that, as we have GSO. An egregious hack enables
GRO for all registered local sockets that support it and for any flow
for which no local socket is registered:
@@ -365,11 +369,13 @@ struct sk_buff *udp_gro_receive(struct list_head
*head, struct sk_buff *skb,
rcu_read_lock();
sk = (*lookup)(skb, uh->source, uh->dest);
- if (sk && udp_sk(sk)->gro_receive)
- goto unflush;
- goto out_unlock;
+ if (!sk)
+ gro_receive_cb = udp_gro_receive_cb;
+ else if (!udp_sk(sk)->gro_receive)
+ goto out_unlock;
+ else
+ gro_receive_cb = udp_sk(sk)->gro_receive;
@@ -392,7 +398,7 @@ struct sk_buff *udp_gro_receive(struct list_head
*head, struct sk_buff *skb,
skb_gro_pull(skb, sizeof(struct udphdr)); /* pull
encapsulating udp header */
skb_gro_postpull_rcsum(skb, uh, sizeof(struct udphdr));
- pp = call_gro_receive_sk(udp_sk(sk)->gro_receive, sk, head, skb);
+ pp = call_gro_receive_sk(gro_receive_cb, sk, head, skb);
But not having a local socket does not imply forwarding path, of course.
>
> Maybe in case that forwarding is enabled on the receiving device,
> inet_gro_receive() could do a route lookup and allow GRO if the
> route lookup returned at forwarding route.
That's a better solution, if the cost is acceptable. We do have to
be careful against increasing per packet cycle cost in this path
given that it's a possible vector for DoS attempts.
> For flows that are likely software segmented after that, it
> would be worth to build packet chains insted of merging the
> payload. Packets of the same flow could travel together, but
> it would save the cost of the packet merging and segmenting.
With software GSO that is faster, as it would have to allocate
all the separate segment skbs in skb_segment later. Though
there is some complexity if MTUs differ.
With hardware UDP GSO, having a single skb will be cheaper in
the forwarding path. Using napi_gro_frags, device drivers really
do only end up allocating one skb for the GSO packet.
> This could be done similar to what I proposed for the list
> receive case:
>
> https://www.spinics.net/lists/netdev/msg522706.html
>
> How GRO should be done could be even configured
> by replacing the net_offload pointer similar
> to what Paolo propsed in his pachset with
> the inet_update_offload() function.
Right. The above hack also already has to use two distinct
callback assignments.
^ permalink raw reply
* [PATCH] net: phy: phylink: fix SFP interface autodetection
From: Baruch Siach @ 2018-09-17 14:19 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli
Cc: netdev, Russell King, Antoine Tenart, Gregory CLEMENT,
Baruch Siach
When the switching to the SFP detected link mode update the main
link_interface field as well. Otherwise, the link fails to come up when
the configured 'phy-mode' defers from the SFP detected mode.
This fixes 1GB SFP module link up on eth3 of the Macchiatobin board that
is configured in the DT to "2500base-x" phy-mode.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/phy/phylink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 3ba5cf2a8a5f..3ece48c86841 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1631,6 +1631,7 @@ static int phylink_sfp_module_insert(void *upstream,
if (pl->link_an_mode != MLO_AN_INBAND ||
pl->link_config.interface != config.interface) {
pl->link_config.interface = config.interface;
+ pl->link_interface = config.interface;
pl->link_an_mode = MLO_AN_INBAND;
changed = true;
--
2.18.0
^ permalink raw reply related
* Re: [PATCH] bonding: avoid repeated display of same link status change
From: Eric Dumazet @ 2018-09-17 14:38 UTC (permalink / raw)
To: mk.singh, netdev
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David S. Miller,
linux-kernel
In-Reply-To: <20180917072059.32657-1-mk.singh@oracle.com>
On 09/17/2018 12:20 AM, mk.singh@oracle.com wrote:
> From: Manish Kumar Singh <mk.singh@oracle.com>
>
> When link status change needs to be committed and rtnl lock couldn't be
> taken, avoid redisplay of same link status change message.
>
> Signed-off-by: Manish Kumar Singh <mk.singh@oracle.com>
> ---
> drivers/net/bonding/bond_main.c | 6 ++++--
> include/net/bonding.h | 1 +
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 217b790d22ed..fb4e3aff1677 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2087,7 +2087,7 @@ static int bond_miimon_inspect(struct bonding *bond)
> bond_propose_link_state(slave, BOND_LINK_FAIL);
> commit++;
> slave->delay = bond->params.downdelay;
> - if (slave->delay) {
> + if (slave->delay && !bond->rtnl_needed) {
> netdev_info(bond->dev, "link status down for %sinterface %s, disabling it in %d ms\n",
> (BOND_MODE(bond) ==
> BOND_MODE_ACTIVEBACKUP) ?
> @@ -2127,7 +2127,7 @@ static int bond_miimon_inspect(struct bonding *bond)
> commit++;
> slave->delay = bond->params.updelay;
>
> - if (slave->delay) {
> + if (slave->delay && !bond->rtnl_needed) {
> netdev_info(bond->dev, "link status up for interface %s, enabling it in %d ms\n",
> slave->dev->name,
> ignore_updelay ? 0 :
> @@ -2301,9 +2301,11 @@ static void bond_mii_monitor(struct work_struct *work)
> if (!rtnl_trylock()) {
> delay = 1;
> should_notify_peers = false;
> + bond->rtnl_needed = true;
How can you set a shared variable with no synchronization ?
A bool is particularly dangerous here, at least on some arches.
> goto re_arm;
> }
>
> + bond->rtnl_needed = false;
> bond_for_each_slave(bond, slave, iter) {
> bond_commit_link_state(slave, BOND_SLAVE_NOTIFY_LATER);
> }
> diff --git a/include/net/bonding.h b/include/net/bonding.h
> index 808f1d167349..50d61cf77855 100644
> --- a/include/net/bonding.h
> +++ b/include/net/bonding.h
> @@ -234,6 +234,7 @@ struct bonding {
> struct dentry *debug_dir;
> #endif /* CONFIG_DEBUG_FS */
> struct rtnl_link_stats64 bond_stats;
> + bool rtnl_needed;
> };
>
> #define bond_slave_get_rcu(dev) \
>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: net: qcom: Add binding for shared mdio bus
From: Andrew Lunn @ 2018-09-17 14:50 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: timur, davem, yu.zheng, netdev, devicetree
In-Reply-To: <1537174411-34510-3-git-send-email-dongsheng.wang@hxt-semitech.com>
On Mon, Sep 17, 2018 at 04:53:29PM +0800, Wang Dongsheng wrote:
> This property copy from "ibm,emac.txt" to describe a shared MIDO bus.
> Since emac include MDIO, so If the motherboard has more than one PHY
> connected to an MDIO bus, this property will point to the MAC device
> that has the MDIO bus.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
> ---
> V2: s/Since QDF2400 emac/Since emac/
> ---
> Documentation/devicetree/bindings/net/qcom-emac.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/qcom-emac.txt b/Documentation/devicetree/bindings/net/qcom-emac.txt
> index 346e6c7f47b7..50db71771358 100644
> --- a/Documentation/devicetree/bindings/net/qcom-emac.txt
> +++ b/Documentation/devicetree/bindings/net/qcom-emac.txt
> @@ -24,6 +24,9 @@ Internal PHY node:
> The external phy child node:
> - reg : The phy address
>
> +Optional properties:
> +- mdio-device : Shared MIDO bus.
Hi Dongsheng
I don't see why you need this property. The ethernet interface has a
phy-handle which points to a PHY. That is all you need to find the PHY.
emac0: ethernet@feb20000 {
compatible = "qcom,fsm9900-emac";
reg = <0xfeb20000 0x10000>,
<0xfeb36000 0x1000>;
interrupts = <76>;
clocks = <&gcc 0>, <&gcc 1>, <&gcc 3>, <&gcc 4>, <&gcc 5>,
<&gcc 6>, <&gcc 7>;
clock-names = "axi_clk", "cfg_ahb_clk", "high_speed_clk",
"mdio_clk", "tx_clk", "rx_clk", "sys_clk";
internal-phy = <&emac_sgmii>;
phy-handle = <&phy0>;
#address-cells = <1>;
#size-cells = <0>;
phy0: ethernet-phy@0 {
reg = <0>;
};
phy1: ethernet-phy@1 {
reg = <1>;
};
pinctrl-names = "default";
pinctrl-0 = <&mdio_pins_a>;
};
emac1: ethernet@38900000 {
compatible = "qcom,fsm9900-emac";
...
...
phy-handle = <&phy1>;
};
Andrew
^ permalink raw reply
* Re: [PATCH net] pppoe: fix reception of frames with no mac header
From: David Miller @ 2018-09-17 14:51 UTC (permalink / raw)
To: g.nault; +Cc: netdev, mostrows, eric.dumazet
In-Reply-To: <274ac54fa02052104201d4738a6326a637e87a83.1536935190.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Fri, 14 Sep 2018 16:28:05 +0200
> pppoe_rcv() needs to look back at the Ethernet header in order to
> lookup the PPPoE session. Therefore we need to ensure that the mac
> header is big enough to contain an Ethernet header. Otherwise
> eth_hdr(skb)->h_source might access invalid data.
...
> Fixes: 224cf5ad14c0 ("ppp: Move the PPP drivers")
> Reported-by: syzbot+f5f6080811c849739212@syzkaller.appspotmail.com
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv6: fix possible use-after-free in ip6_xmit()
From: David Miller @ 2018-09-17 14:58 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20180914190232.184779-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 14 Sep 2018 12:02:31 -0700
> In the unlikely case ip6_xmit() has to call skb_realloc_headroom(),
> we need to call skb_set_owner_w() before consuming original skb,
> otherwise we risk a use-after-free.
>
> Bring IPv6 in line with what we do in IPv4 to fix this.
>
> Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] bnxt_en: Fix VF mac address regression.
From: David Miller @ 2018-09-17 14:58 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, seth.forshee, loseweigh
In-Reply-To: <1536954089-6061-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 14 Sep 2018 15:41:29 -0400
> The recent commit to always forward the VF MAC address to the PF for
> approval may not work if the PF driver or the firmware is older. This
> will cause the VF driver to fail during probe:
>
> bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): hwrm req_type 0xf seq id 0x5 error 0xffff
> bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): VF MAC address 00:00:17:02:05:d0 not approved by the PF
> bnxt_en 0000:00:03.0: Unable to initialize mac address.
> bnxt_en: probe of 0000:00:03.0 failed with error -99
>
> We fix it by treating the error as fatal only if the VF MAC address is
> locally generated by the VF.
>
> Fixes: 707e7e966026 ("bnxt_en: Always forward VF MAC address to the PF.")
> Reported-by: Seth Forshee <seth.forshee@canonical.com>
> Reported-by: Siwei Liu <loseweigh@gmail.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
> Please queue this for stable as well. Thanks.
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 0/2] hv_netvsc: associate VF and PV device by serial number
From: David Miller @ 2018-09-17 14:59 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, devel, netdev, linux-pci
In-Reply-To: <20180914195457.20433-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 14 Sep 2018 12:54:55 -0700
> The Hyper-V implementation of PCI controller has concept of 32 bit serial number
> (not to be confused with PCI-E serial number). This value is sent in the protocol
> from the host to indicate SR-IOV VF device is attached to a synthetic NIC.
>
> Using the serial number (instead of MAC address) to associate the two devices
> avoids lots of potential problems when there are duplicate MAC addresses from
> tunnels or layered devices.
>
> The patch set is broken into two parts, one is for the PCI controller
> and the other is for the netvsc device. Normally, these go through different
> trees but sending them together here for better review. The PCI changes
> were submitted previously, but the main review comment was "why do you
> need this?". This is why.
>
> v2 - slot name can be shorter.
> remove locking when creating pci_slots; see comment for explaination
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-17 14:59 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Miller, Herbert Xu, Andrew Lutomirski, Andrew Lunn,
Eric Biggers, Greg Kroah-Hartman, Ard Biesheuvel, LKML, Netdev,
Samuel Neves, Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <40088431-D4EE-4D1C-A369-2CE15F758483@amacapital.net>
On Mon, Sep 17, 2018 at 4:56 PM Andy Lutomirski <luto@amacapital.net> wrote:
> Would you accept Ard’s (and/or Eric Biggers’, perhaps, as an alternative)? Or, if you really want Herbert’s review, can you ask him to review it? (Hi Herbert!)
Preferably Eric's.
^ permalink raw reply
* Re: [net-next PATCH] tls: async support causes out-of-bounds access in crypto APIs
From: David Miller @ 2018-09-17 15:02 UTC (permalink / raw)
To: john.fastabend
Cc: vakul.garg, davejwatson, doronrk, netdev, alexei.starovoitov,
daniel
In-Reply-To: <20180914200146.6302.50472.stgit@john-Precision-Tower-5810>
From: John Fastabend <john.fastabend@gmail.com>
Date: Fri, 14 Sep 2018 13:01:46 -0700
> When async support was added it needed to access the sk from the async
> callback to report errors up the stack. The patch tried to use space
> after the aead request struct by directly setting the reqsize field in
> aead_request. This is an internal field that should not be used
> outside the crypto APIs. It is used by the crypto code to define extra
> space for private structures used in the crypto context. Users of the
> API then use crypto_aead_reqsize() and add the returned amount of
> bytes to the end of the request memory allocation before posting the
> request to encrypt/decrypt APIs.
>
> So this breaks (with general protection fault and KASAN error, if
> enabled) because the request sent to decrypt is shorter than required
> causing the crypto API out-of-bounds errors. Also it seems unlikely the
> sk is even valid by the time it gets to the callback because of memset
> in crypto layer.
>
> Anyways, fix this by holding the sk in the skb->sk field when the
> callback is set up and because the skb is already passed through to
> the callback handler via void* we can access it in the handler. Then
> in the handler we need to be careful to NULL the pointer again before
> kfree_skb. I added comments on both the setup (in tls_do_decryption)
> and when we clear it from the crypto callback handler
> tls_decrypt_done(). After this selftests pass again and fixes KASAN
> errors/warnings.
>
> Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Applied, thanks John.
^ permalink raw reply
* Re: [Patch net-next] ipv4: initialize ra_mutex in inet_init_net()
From: David Miller @ 2018-09-17 15:02 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, ktkhai
In-Reply-To: <20180914203242.2712-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 14 Sep 2018 13:32:42 -0700
> ra_mutex is a IPv4 specific mutex, it is inside struct netns_ipv4,
> but its initialization is in the generic netns code, setup_net().
>
> Move it to IPv4 specific net init code, inet_init_net().
>
> Fixes: d9ff3049739e ("net: Replace ip_ra_lock with per-net mutex")
> Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Please take into consideration Kirill's feedback.
Thank you.
^ permalink raw reply
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