* [PATCHv3] net: bnxt: Fix a uninitialized variable warning.
From: zhong jiang @ 2018-09-18 7:15 UTC (permalink / raw)
To: michael.chan, davem, vasundhara-v.volam; +Cc: netdev, linux-kernel
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 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index f3b9fbc..790c684 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -46,6 +46,9 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
}
}
+ if (i == ARRAY_SIZE(nvm_params))
+ return -EOPNOTSUPP;
+
if (nvm_param.dir_type == BNXT_NVM_PORT_CFG)
idx = bp->pf.port_id;
else if (nvm_param.dir_type == BNXT_NVM_FUNC_CFG)
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH v2] net: bnxt: Fix a uninitialized variable warning.
From: zhong jiang @ 2018-09-18 7:18 UTC (permalink / raw)
To: Michael Chan; +Cc: David Miller, Vasundhara Volam, Netdev, open list
In-Reply-To: <CACKFLin=rgt7EyWJ-P5jhkAQR5NweCWp-5AZN=FoH+AGpVNZWw@mail.gmail.com>
On 2018/9/18 15:02, Michael Chan wrote:
> On Mon, Sep 17, 2018 at 9:55 PM, 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 | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
>> index f3b9fbc..1ae56fc 100644
>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
>> @@ -46,6 +46,9 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
>> }
>> }
>>
>> + if (i == ARRAY_SIZE(nvm_params))
>> + return -EINVAL;
>> +
> -EOPNOTSUPP might be a better return code. Other than that, it looks
> good to me. Thanks.
Thanks for suggestion. Will repost.
Sincerely,
zhong jiang
>> if (nvm_param.dir_type == BNXT_NVM_PORT_CFG)
>> idx = bp->pf.port_id;
>> else if (nvm_param.dir_type == BNXT_NVM_FUNC_CFG)
>> --
>> 1.7.12.4
>>
>
^ permalink raw reply
* Re: [PATCH v2 0/3] r8169 (x86) clk fixes to fix S0ix not being reached
From: David Miller @ 2018-09-18 1:48 UTC (permalink / raw)
To: hdegoede
Cc: hkallweit1, mturquette, sboyd, andriy.shevchenko,
pierre-louis.bossart, linux-wireless, netdev, js, carlo,
linux-clk
In-Reply-To: <20180912093456.23400-1-hdegoede@redhat.com>
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 12 Sep 2018 11:34:53 +0200
> This series adds code to the r8169 ethernet driver to get and enable an
> external clock if present, avoiding the need for a hack in the
> clk-pmc-atom driver where that clock was left on continuesly causing x86
> some devices to not reach deep power saving states (S0ix) when suspended
> causing to them to quickly drain their battery while suspended.
>
> The 3 commits in this series need to be merged in order to avoid
> regressions while bisecting. The clk-pmc-atom driver does not see much
> changes (it was last touched over a year ago). So the clk maintainers
> have agreed with merging all 3 patches through the net tree.
> All 3 patches have Stephen Boyd's Acked-by for this purpose.
>
> This v2 of the series only had some minor tweaks done to the commit
> messages and is ready for merging through the net tree now.
Thanks for all of that useful information.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: caif: remove redundant null check on frontpkt
From: David Miller @ 2018-09-18 1:50 UTC (permalink / raw)
To: colin.king; +Cc: dmitry.tarnyagin, kernel-janitors, netdev
In-Reply-To: <20180914171916.21298-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 14 Sep 2018 18:19:16 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> It is impossible for frontpkt to be null at the point of the null
> check because it has been assigned from rearpkt and there is no
> way realpkt can be null at the point of the assignment because
> of the sanity checking and exit paths taken previously. Remove
> the redundant null check.
>
> Detected by CoverityScan, CID#114434 ("Logically dead code")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Appied to net-next with typo fixed.
Thanks.
^ permalink raw reply
* Re: [GIT] Networking
From: Greg KH @ 2018-09-18 7:31 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20180917.200040.1595079540584326114.davem@davemloft.net>
On Mon, Sep 17, 2018 at 08:00:40PM -0700, David Miller wrote:
>
> Various fixes, all over the place:
>
> 1) OOB data generation fix in bluetooth, from Matias Karhumaa.
>
> 2) BPF BTF boundary calculation fix, from Martin KaFai Lau.
>
> 3) Don't bug on excessive frags, to be compatible in situations mixing
> older and newer kernels on each end. From Juergen Gross.
>
> 4) Scheduling in RCU fix in hv_netvsc, from Stephen Hemminger.
>
> 5) Zero keying information in TLS layer before freeing copies
> of them, from Sabrina Dubroca.
>
> 6) Fix NULL deref in act_sample, from Davide Caratti.
>
> 7) Orphan SKB before GRO in veth to prevent crashes with XDP,
> from Toshiaki Makita.
>
> 8) Fix use after free in ip6_xmit, from Eric Dumazet.
>
> 9) Fix VF mac address regression in bnxt_en, from Micahel Chan.
>
> 10) Fix MSG_PEEK behavior in TLS layer, from Daniel Borkmann.
>
> 11) Programming adjustments to r8169 which fix not being to enter deep
> sleep states on some machines, from Kai-Heng Feng and Hans de
> Goede.
>
> 12) Fix DST_NOCOUNT flag handling for ipv6 routes, from Peter
> Oskolkov.
>
> Please pull, thanks a lot!
>
> The following changes since commit 7428b2e5d0b195f2a5e40f91d2b41a8503fcfe68:
>
> Merge tag 'drm-fixes-2018-09-12' of git://anongit.freedesktop.org/drm/drm (2018-09-12 17:36:47 -1000)
>
> are available in the Git repository at:
>
> gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
Process question, any reason why you don't use signed tags? I noticed
that you didn't use them in the past, just curious.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 0/2] net: ethernet: neterion: use linux/io-64-nonatomic-lo-hi.h
From: Corentin Labbe @ 2018-09-18 7:33 UTC (permalink / raw)
To: davem, jdmason; +Cc: linux-kernel, netdev, Corentin Labbe
Hello
This serie remove usage of custom writeq/readq in favor of ones defined in linux/io-64-nonatomic-lo-hi.h
This serie is only compile tested.
Regards
Changes since v1:
- rebase on net-next
Corentin Labbe (2):
net: neterion: s2io: Use linux/io-64-nonatomic-lo-hi.h
net: neterion: vxfe: Use linux/io-64-nonatomic-lo-hi.h
drivers/net/ethernet/neterion/s2io.c | 1 +
drivers/net/ethernet/neterion/s2io.h | 22 +---------------------
drivers/net/ethernet/neterion/vxge/vxge-config.c | 1 +
drivers/net/ethernet/neterion/vxge/vxge-config.h | 20 --------------------
drivers/net/ethernet/neterion/vxge/vxge-traffic.c | 1 +
5 files changed, 4 insertions(+), 41 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/2] net: neterion: s2io: Use linux/io-64-nonatomic-lo-hi.h
From: Corentin Labbe @ 2018-09-18 7:33 UTC (permalink / raw)
To: davem, jdmason; +Cc: linux-kernel, netdev, Corentin Labbe
In-Reply-To: <1537255994-39517-1-git-send-email-clabbe@baylibre.com>
This patch replace the custom definition of writeq/read and use ones
defined in linux/io-64-nonatomic-lo-hi.h.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
drivers/net/ethernet/neterion/s2io.c | 1 +
drivers/net/ethernet/neterion/s2io.h | 22 +---------------------
2 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/neterion/s2io.c b/drivers/net/ethernet/neterion/s2io.c
index f980f10..6266032 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -75,6 +75,7 @@
#include <linux/tcp.h>
#include <linux/uaccess.h>
#include <linux/io.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
#include <linux/slab.h>
#include <linux/prefetch.h>
#include <net/tcp.h>
diff --git a/drivers/net/ethernet/neterion/s2io.h b/drivers/net/ethernet/neterion/s2io.h
index 1a24a72..0a921f3 100644
--- a/drivers/net/ethernet/neterion/s2io.h
+++ b/drivers/net/ethernet/neterion/s2io.h
@@ -10,6 +10,7 @@
* system is licensed under the GPL.
* See the file COPYING in this distribution for more information.
************************************************************************/
+#include <linux/io-64-nonatomic-lo-hi.h>
#ifndef _S2IO_H
#define _S2IO_H
@@ -970,27 +971,6 @@ struct s2io_nic {
#define RESET_ERROR 1
#define CMD_ERROR 2
-/* OS related system calls */
-#ifndef readq
-static inline u64 readq(void __iomem *addr)
-{
- u64 ret = 0;
- ret = readl(addr + 4);
- ret <<= 32;
- ret |= readl(addr);
-
- return ret;
-}
-#endif
-
-#ifndef writeq
-static inline void writeq(u64 val, void __iomem *addr)
-{
- writel((u32) (val), addr);
- writel((u32) (val >> 32), (addr + 4));
-}
-#endif
-
/*
* Some registers have to be written in a particular order to
* expect correct hardware operation. The macro SPECIAL_REG_WRITE
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] net: neterion: vxge: Use linux/io-64-nonatomic-lo-hi.h
From: Corentin Labbe @ 2018-09-18 7:33 UTC (permalink / raw)
To: davem, jdmason; +Cc: linux-kernel, netdev, Corentin Labbe
In-Reply-To: <1537255994-39517-1-git-send-email-clabbe@baylibre.com>
This patch replace the custom definition of writeq/read and use ones
defined in linux/io-64-nonatomic-lo-hi.h.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
drivers/net/ethernet/neterion/vxge/vxge-config.c | 1 +
drivers/net/ethernet/neterion/vxge/vxge-config.h | 20 --------------------
drivers/net/ethernet/neterion/vxge/vxge-traffic.c | 1 +
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.c b/drivers/net/ethernet/neterion/vxge/vxge-config.c
index 398011c..4c1fb7e 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-config.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-config.c
@@ -13,6 +13,7 @@
******************************************************************************/
#include <linux/vmalloc.h>
#include <linux/etherdevice.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
#include <linux/pci.h>
#include <linux/slab.h>
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.h b/drivers/net/ethernet/neterion/vxge/vxge-config.h
index d743a37..e678ba3 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-config.h
+++ b/drivers/net/ethernet/neterion/vxge/vxge-config.h
@@ -2011,26 +2011,6 @@ enum vxge_hw_status vxge_hw_vpath_mtu_set(
void
vxge_hw_vpath_rx_doorbell_init(struct __vxge_hw_vpath_handle *vp);
-#ifndef readq
-static inline u64 readq(void __iomem *addr)
-{
- u64 ret = 0;
- ret = readl(addr + 4);
- ret <<= 32;
- ret |= readl(addr);
-
- return ret;
-}
-#endif
-
-#ifndef writeq
-static inline void writeq(u64 val, void __iomem *addr)
-{
- writel((u32) (val), addr);
- writel((u32) (val >> 32), (addr + 4));
-}
-#endif
-
static inline void __vxge_hw_pio_mem_write32_upper(u32 val, void __iomem *addr)
{
writel(val, addr + 4);
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-traffic.c b/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
index 0c3b5de..30e5cdc 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
@@ -12,6 +12,7 @@
* Copyright(c) 2002-2010 Exar Corp.
******************************************************************************/
#include <linux/etherdevice.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
#include <linux/prefetch.h>
#include "vxge-traffic.h"
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net,stable] qmi_wwan: set DTR for modems in forced USB2 mode
From: David Miller @ 2018-09-18 2:23 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, fred.veldini, dwen
In-Reply-To: <20180917200024.13571-1-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Mon, 17 Sep 2018 22:00:24 +0200
> Recent firmware revisions have added the ability to force
> these modems to USB2 mode, hiding their SuperSpeed
> capabilities from the host. The driver has been using the
> SuperSpeed capability, as shown by the bcdUSB field of the
> device descriptor, to detect the need to enable the DTR
> quirk. This method fails when the modems are forced to
> USB2 mode by the modem firmware.
>
> Fix by unconditionally enabling the DTR quirk for the
> affected device IDs.
>
> Reported-by: Fred Veldini <fred.veldini@gmail.com>
> Reported-by: Deshu Wen <dwen@sierrawireless.com>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [GIT] Networking
From: Greg KH @ 2018-09-18 8:02 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20180917.200040.1595079540584326114.davem@davemloft.net>
On Mon, Sep 17, 2018 at 08:00:40PM -0700, David Miller wrote:
>
> Various fixes, all over the place:
Now pulled, thanks.
greg k-h
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 fixes 2018-09-17
From: David Miller @ 2018-09-18 2:37 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180918000201.23609-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 17 Sep 2018 17:01:58 -0700
> This series provides three fixes to mlx5 core and mlx5e netdevice
> driver.
>
> Please pull and let me know if there's any problem.
>
> For -stable v4.16:
> ('net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ')
Patches need to target 'net' in order to be queued up for -stable.
It is not appropriate to submit patchs for 'net-next' and ask for
those to be submitted to -stable.
Thank you.
^ permalink raw reply
* [PATCH] net: ethernet: remove redundant include
From: zhong jiang @ 2018-09-18 8:10 UTC (permalink / raw)
To: netanel, davem; +Cc: jcliburn, chris.snook, santosh, netdev, linux-kernel
module.h already contained moduleparam.h, so it is safe to remove
the redundant include.
The issue is detected with the help of Coccinelle.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/amazon/ena/ena_netdev.c | 1 -
drivers/net/ethernet/atheros/atlx/atl1.c | 1 -
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 1 -
drivers/net/ethernet/ibm/ibmveth.c | 1 -
4 files changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 29b5774..b2522e8 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -39,7 +39,6 @@
#include <linux/if_vlan.h>
#include <linux/kernel.h>
#include <linux/module.h>
-#include <linux/moduleparam.h>
#include <linux/numa.h>
#include <linux/pci.h>
#include <linux/utsname.h>
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c
index b81fbf11..72e7fa7 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -63,7 +63,6 @@
#include <linux/jiffies.h>
#include <linux/mii.h>
#include <linux/module.h>
-#include <linux/moduleparam.h>
#include <linux/net.h>
#include <linux/netdevice.h>
#include <linux/pci.h>
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index a19172d..921dd71 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -33,7 +33,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/module.h>
-#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/dma-mapping.h>
diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
index 525d8b8..a468178 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -24,7 +24,6 @@
*/
#include <linux/module.h>
-#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/dma-mapping.h>
--
1.7.12.4
^ permalink raw reply related
* Re: [Patch net v2] net/ipv6: do not copy dst flags on rt init
From: David Miller @ 2018-09-18 2:43 UTC (permalink / raw)
To: posk; +Cc: netdev, dsahern
In-Reply-To: <20180917172053.126170-1-posk@google.com>
From: Peter Oskolkov <posk@google.com>
Date: Mon, 17 Sep 2018 10:20:53 -0700
> DST_NOCOUNT in dst_entry::flags tracks whether the entry counts
> toward route cache size (net->ipv6.sysctl.ip6_rt_max_size).
>
> If the flag is NOT set, dst_ops::pcpuc_entries counter is incremented
> in dist_init() and decremented in dst_destroy().
>
> This flag is tied to allocation/deallocation of dst_entry and
> should not be copied from another dst/route. Otherwise it can happen
> that dst_ops::pcpuc_entries counter grows until no new routes can
> be allocated because the counter reached ip6_rt_max_size due to
> DST_NOCOUNT not set and thus no counter decrements on gc-ed routes.
>
> Fixes: 3b6761d18bc1 ("net/ipv6: Move dst flags to booleans in fib entries")
> Cc: David Ahern <dsahern@gmail.com>
> Acked-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Peter Oskolkov <posk@google.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* [PATCH] net: wan: remove redundant include
From: zhong jiang @ 2018-09-18 8:19 UTC (permalink / raw)
To: davem, khc; +Cc: netdev, linux-kernel
module.h already contained moduleparam.h, so it is safe to remove
the redundant include.
The issue is detected with the help of Coccinelle.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/wan/c101.c | 1 -
drivers/net/wan/pci200syn.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/net/wan/c101.c b/drivers/net/wan/c101.c
index 2371e07..91dbbde 100644
--- a/drivers/net/wan/c101.c
+++ b/drivers/net/wan/c101.c
@@ -24,7 +24,6 @@
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/init.h>
-#include <linux/moduleparam.h>
#include <linux/netdevice.h>
#include <linux/hdlc.h>
#include <linux/delay.h>
diff --git a/drivers/net/wan/pci200syn.c b/drivers/net/wan/pci200syn.c
index 4e437c5..1f8a3f7 100644
--- a/drivers/net/wan/pci200syn.c
+++ b/drivers/net/wan/pci200syn.c
@@ -27,7 +27,6 @@
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/ioport.h>
-#include <linux/moduleparam.h>
#include <linux/netdevice.h>
#include <linux/hdlc.h>
#include <linux/pci.h>
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH net-next] net: mdio: remove duplicated include from mdio_bus.c
From: David Miller @ 2018-09-18 2:53 UTC (permalink / raw)
To: yuehaibing; +Cc: andrew, f.fainelli, linux-kernel, netdev
In-Reply-To: <20180918024841.26068-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 18 Sep 2018 10:48:41 +0800
> Remove duplicated include linux/gpio/consumer.h
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Daniel Borkmann @ 2018-09-18 8:44 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Vakul Garg
In-Reply-To: <20180918101107.74d8689a@canb.auug.org.au>
On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> tools/testing/selftests/net/tls.c
>
> between commit:
>
> 50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
>
> from the net tree and commit:
>
> c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning across multiple records")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
The test from 50c6b58a814d supersedes the one from c2ad647c6442 so the
recv_peek_large_buf_mult_recs could be removed; latter was also not working
correctly due to this bug.
Thanks,
Daniel
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 fixes 2018-09-17
From: Saeed Mahameed @ 2018-09-18 3:35 UTC (permalink / raw)
To: David S. Miller; +Cc: Saeed Mahameed, Linux Netdev List
In-Reply-To: <20180917.193710.153553258834916622.davem@davemloft.net>
On Mon, Sep 17, 2018 at 7:37 PM David Miller <davem@davemloft.net> wrote:
>
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Mon, 17 Sep 2018 17:01:58 -0700
>
> > This series provides three fixes to mlx5 core and mlx5e netdevice
> > driver.
> >
> > Please pull and let me know if there's any problem.
> >
> > For -stable v4.16:
> > ('net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ')
>
> Patches need to target 'net' in order to be queued up for -stable.
>
> It is not appropriate to submit patchs for 'net-next' and ask for
> those to be submitted to -stable.
>
oops, they are mean for net, i will resubmit.
Sorry.
> Thank you.
^ permalink raw reply
* RE: linux-next: manual merge of the net-next tree with the net tree
From: Vakul Garg @ 2018-09-18 9:10 UTC (permalink / raw)
To: Daniel Borkmann, Stephen Rothwell, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <93982e9d-dc78-6423-bb9b-c5773d98e244@iogearbox.net>
> -----Original Message-----
> From: Daniel Borkmann <daniel@iogearbox.net>
> Sent: Tuesday, September 18, 2018 2:14 PM
> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
> <vakul.garg@nxp.com>
> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
>
> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the net-next tree got a conflict in:
> >
> > tools/testing/selftests/net/tls.c
> >
> > between commit:
> >
> > 50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
> >
> > from the net tree and commit:
> >
> > c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
> > across multiple records")
> >
> > from the net-next tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This is
> > now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your
> > tree is submitted for merging. You may also want to consider
> > cooperating with the maintainer of the conflicting tree to minimise
> > any particularly complex conflicts.
>
> The test from 50c6b58a814d supersedes the one from c2ad647c6442 so the
> recv_peek_large_buf_mult_recs could be removed; latter was also not
> working correctly due to this bug.
Why remove recv_peek_large_buf_mult_recs if its correct?
Why not the newly added one which achieves the same thing?
Regards, Vakul
>
> Thanks,
> Daniel
^ permalink raw reply
* Re: [PATCH] docs: fix some broken documentation references
From: Jan Kara @ 2018-09-18 9:17 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: linux-kernel, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, Jan Kara, Stephen Hemminger, David S. Miller,
Michael Ellerman, Greg Kroah-Hartman, Andrew Morton,
Arnd Bergmann, linux-doc, linux-ext4, bridge, netdev, Ted Tso
In-Reply-To: <6b47bf56b898c48a0dc3cd42283c9e5c7c23367a.1537210894.git.mchehab+samsung@kernel.org>
On Mon 17-09-18 15:02:34, Mauro Carvalho Chehab wrote:
> Some documentation files received recent changes and are
> pointing to wrong places.
>
> Those references can easily fixed with the help of a
> script:
>
> $ ./scripts/documentation-file-ref-check --fix
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Looks good to me. Thanks for fixing this up. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> Documentation/filesystems/dax.txt | 2 +-
> Documentation/filesystems/ext2.txt | 2 +-
> MAINTAINERS | 4 ++--
> net/bridge/Kconfig | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt
> index 70cb68bed2e8..bc393e0a22b8 100644
> --- a/Documentation/filesystems/dax.txt
> +++ b/Documentation/filesystems/dax.txt
> @@ -75,7 +75,7 @@ exposure of uninitialized data through mmap.
>
> These filesystems may be used for inspiration:
> - ext2: see Documentation/filesystems/ext2.txt
> -- ext4: see Documentation/filesystems/ext4.txt
> +- ext4: see Documentation/filesystems/ext4/ext4.rst
> - xfs: see Documentation/filesystems/xfs.txt
>
>
> diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt
> index 81c0becab225..a45c9fc0747b 100644
> --- a/Documentation/filesystems/ext2.txt
> +++ b/Documentation/filesystems/ext2.txt
> @@ -358,7 +358,7 @@ and are copied into the filesystem. If a transaction is incomplete at
> the time of the crash, then there is no guarantee of consistency for
> the blocks in that transaction so they are discarded (which means any
> filesystem changes they represent are also lost).
> -Check Documentation/filesystems/ext4.txt if you want to read more about
> +Check Documentation/filesystems/ext4/ext4.rst if you want to read more about
> ext4 and journaling.
>
> References
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9989925f658d..078a4cf6d064 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -840,7 +840,7 @@ ANALOG DEVICES INC ADGS1408 DRIVER
> M: Mircea Caprioru <mircea.caprioru@analog.com>
> S: Supported
> F: drivers/mux/adgs1408.c
> -F: Documentation/devicetree/bindings/mux/adgs1408.txt
> +F: Documentation/devicetree/bindings/mux/adi,adgs1408.txt
>
> ANALOG DEVICES INC ADP5061 DRIVER
> M: Stefan Popa <stefan.popa@analog.com>
> @@ -5515,7 +5515,7 @@ W: http://ext4.wiki.kernel.org
> Q: http://patchwork.ozlabs.org/project/linux-ext4/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> S: Maintained
> -F: Documentation/filesystems/ext4.txt
> +F: Documentation/filesystems/ext4/ext4.rst
> F: fs/ext4/
>
> Extended Verification Module (EVM)
> diff --git a/net/bridge/Kconfig b/net/bridge/Kconfig
> index aa0d3b2f1bb7..3625d6ade45c 100644
> --- a/net/bridge/Kconfig
> +++ b/net/bridge/Kconfig
> @@ -17,7 +17,7 @@ config BRIDGE
> other third party bridge products.
>
> In order to use the Ethernet bridge, you'll need the bridge
> - configuration tools; see <file:Documentation/networking/bridge.txt>
> + configuration tools; see <file:Documentation/networking/bridge.rst>
> for location. Please read the Bridge mini-HOWTO for more
> information.
>
> --
> 2.17.1
>
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [pull request][RESEND net 0/3] Mellanox, mlx5 fixes 2018-09-17
From: Saeed Mahameed @ 2018-09-18 3:49 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
Hi Dave,
Sorry about the previous submission of this series which was mistakenly
marked for net-next, here I am resending with 'net' mark.
This series provides three fixes to mlx5 core and mlx5e netdevice
driver.
Please pull and let me know if there's any problem.
For -stable v4.16:
('net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ')
Thanks,
Saeed.
---
The following changes since commit c73480910e9686a5c25155cb4d418d594b678196:
net: ethernet: Fix a unused function warning. (2018-09-17 08:24:25 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-fixes-2018-09-17
for you to fetch changes up to 8f92e35aff9692028279d3c03e88547df6d15020:
net/mlx5e: TLS, Read capabilities only when it is safe (2018-09-17 15:12:31 -0700)
----------------------------------------------------------------
mlx5-fixes-2018-09-17
----------------------------------------------------------------
Alaa Hleihel (1):
net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ
Eli Cohen (1):
net/mlx5: Fix read from coherent memory
Saeed Mahameed (1):
net/mlx5e: TLS, Read capabilities only when it is safe
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/transobj.c | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
^ permalink raw reply
* [RESEND net 1/3] net/mlx5: Fix read from coherent memory
From: Saeed Mahameed @ 2018-09-18 3:49 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eli Cohen, Saeed Mahameed
In-Reply-To: <20180918034928.28651-1-saeedm@mellanox.com>
From: Eli Cohen <eli@mellanox.com>
Use accessor function READ_ONCE to read from coherent memory modified
by the device and read by the driver. This becomes most important in
preemptive kernels where cond_resched implementation does not have the
side effect which guaranteed the updated value.
Fixes: 269d26f47f6f ("net/mlx5: Reduce command polling interval")
Signed-off-by: Eli Cohen <eli@mellanox.com>
Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index 3ce14d42ddc8..a53736c26c0c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -206,7 +206,7 @@ static void poll_timeout(struct mlx5_cmd_work_ent *ent)
u8 own;
do {
- own = ent->lay->status_own;
+ own = READ_ONCE(ent->lay->status_own);
if (!(own & CMD_OWNER_HW)) {
ent->ret = 0;
return;
--
2.17.1
^ permalink raw reply related
* [RESEND net 2/3] net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ
From: Saeed Mahameed @ 2018-09-18 3:49 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Alaa Hleihel, Saeed Mahameed
In-Reply-To: <20180918034928.28651-1-saeedm@mellanox.com>
From: Alaa Hleihel <alaa@mellanox.com>
When modifying hairpin SQ, instead of checking if the next state equals
to MLX5_SQC_STATE_RDY, we compare it against the MLX5_RQC_STATE_RDY enum
value.
The code worked since both of MLX5_RQC_STATE_RDY and MLX5_SQC_STATE_RDY
have the same value today.
This patch fixes this issue.
Fixes: 18e568c390c6 ("net/mlx5: Hairpin pair core object setup")
Signed-off-by: Alaa Hleihel <alaa@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/transobj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/transobj.c b/drivers/net/ethernet/mellanox/mlx5/core/transobj.c
index dae1c5c5d27c..d2f76070ea7c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/transobj.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/transobj.c
@@ -509,7 +509,7 @@ static int mlx5_hairpin_modify_sq(struct mlx5_core_dev *peer_mdev, u32 sqn,
sqc = MLX5_ADDR_OF(modify_sq_in, in, ctx);
- if (next_state == MLX5_RQC_STATE_RDY) {
+ if (next_state == MLX5_SQC_STATE_RDY) {
MLX5_SET(sqc, sqc, hairpin_peer_rq, peer_rq);
MLX5_SET(sqc, sqc, hairpin_peer_vhca, peer_vhca);
}
--
2.17.1
^ permalink raw reply related
* [RESEND net 3/3] net/mlx5e: TLS, Read capabilities only when it is safe
From: Saeed Mahameed @ 2018-09-18 3:49 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
In-Reply-To: <20180918034928.28651-1-saeedm@mellanox.com>
Read TLS caps from the core driver only when TLS is supported, i.e
mlx5_accel_is_tls_device returns true.
Fixes: 790af90c00d2 ("net/mlx5e: TLS, build TLS netdev from capabilities")
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Boris Pismenny <borisp@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
index eddd7702680b..e88340e196f7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
@@ -183,12 +183,13 @@ static const struct tlsdev_ops mlx5e_tls_ops = {
void mlx5e_tls_build_netdev(struct mlx5e_priv *priv)
{
- u32 caps = mlx5_accel_tls_device_caps(priv->mdev);
struct net_device *netdev = priv->netdev;
+ u32 caps;
if (!mlx5_accel_is_tls_device(priv->mdev))
return;
+ caps = mlx5_accel_tls_device_caps(priv->mdev);
if (caps & MLX5_ACCEL_TLS_TX) {
netdev->features |= NETIF_F_HW_TLS_TX;
netdev->hw_features |= NETIF_F_HW_TLS_TX;
--
2.17.1
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Daniel Borkmann @ 2018-09-18 9:26 UTC (permalink / raw)
To: Vakul Garg, Stephen Rothwell, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <DB7PR04MB42522B223D4E04F5DA519A8B8B1D0@DB7PR04MB4252.eurprd04.prod.outlook.com>
On 09/18/2018 11:10 AM, Vakul Garg wrote:
>> -----Original Message-----
>> From: Daniel Borkmann <daniel@iogearbox.net>
>> Sent: Tuesday, September 18, 2018 2:14 PM
>> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
>> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
>> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
>> Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
>> <vakul.garg@nxp.com>
>> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
>>
>> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the net-next tree got a conflict in:
>>>
>>> tools/testing/selftests/net/tls.c
>>>
>>> between commit:
>>>
>>> 50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
>>>
>>> from the net tree and commit:
>>>
>>> c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
>>> across multiple records")
>>>
>>> from the net-next tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary. This is
>>> now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your
>>> tree is submitted for merging. You may also want to consider
>>> cooperating with the maintainer of the conflicting tree to minimise
>>> any particularly complex conflicts.
>>
>> The test from 50c6b58a814d supersedes the one from c2ad647c6442 so the
>> recv_peek_large_buf_mult_recs could be removed; latter was also not
>> working correctly due to this bug.
>
> Why remove recv_peek_large_buf_mult_recs if its correct?
> Why not the newly added one which achieves the same thing?
Hmm, not quite, on net-next kernel, the recv_peek_large_buf_mult_recs fails
every time I invoke the tls test suite:
# ./tls
[==========] Running 28 tests from 2 test cases.
[ RUN ] tls.sendfile
[ OK ] tls.sendfile
[ RUN ] tls.send_then_sendfile
[ OK ] tls.send_then_sendfile
[ RUN ] tls.recv_max
[ OK ] tls.recv_max
[ RUN ] tls.recv_small
[ OK ] tls.recv_small
[ RUN ] tls.msg_more
[ OK ] tls.msg_more
[ RUN ] tls.sendmsg_single
[ OK ] tls.sendmsg_single
[ RUN ] tls.sendmsg_large
[ OK ] tls.sendmsg_large
[ RUN ] tls.sendmsg_multiple
[ OK ] tls.sendmsg_multiple
[ RUN ] tls.sendmsg_multiple_stress
[ OK ] tls.sendmsg_multiple_stress
[ RUN ] tls.splice_from_pipe
[ OK ] tls.splice_from_pipe
[ RUN ] tls.splice_from_pipe2
[ OK ] tls.splice_from_pipe2
[ RUN ] tls.send_and_splice
[ OK ] tls.send_and_splice
[ RUN ] tls.splice_to_pipe
[ OK ] tls.splice_to_pipe
[ RUN ] tls.recvmsg_single
[ OK ] tls.recvmsg_single
[ RUN ] tls.recvmsg_single_max
[ OK ] tls.recvmsg_single_max
[ RUN ] tls.recvmsg_multiple
[ OK ] tls.recvmsg_multiple
[ RUN ] tls.single_send_multiple_recv
[ OK ] tls.single_send_multiple_recv
[ RUN ] tls.multiple_send_single_recv
[ OK ] tls.multiple_send_single_recv
[ RUN ] tls.recv_partial
[ OK ] tls.recv_partial
[ RUN ] tls.recv_nonblock
[ OK ] tls.recv_nonblock
[ RUN ] tls.recv_peek
[ OK ] tls.recv_peek
[ RUN ] tls.recv_peek_multiple
[ OK ] tls.recv_peek_multiple
[ RUN ] tls.recv_peek_large_buf_mult_recs
tls.c:524:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str, buf, len) (18446744073709551595) == 0 (0)
tls.recv_peek_large_buf_mult_recs: Test failed at step #8
[ FAIL ] tls.recv_peek_large_buf_mult_recs
[ RUN ] tls.pollin
[ OK ] tls.pollin
[ RUN ] tls.poll_wait
[ OK ] tls.poll_wait
[ RUN ] tls.blocking
[ OK ] tls.blocking
[ RUN ] tls.nonblocking
[ OK ] tls.nonblocking
[ RUN ] tls.control_msg
[ OK ] tls.control_msg
[==========] 27 / 28 tests passed.
[ FAILED ]
Here's what the recvfrom() with MSG_PEEK sees:
[pid 2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
[pid 2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
[pid 2602] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid 2602] listen(4, 10) = 0
[pid 2602] getsockname(4, {sa_family=AF_INET, sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
[pid 2602] connect(3, {sa_family=AF_INET, sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid 2602] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
[pid 2602] setsockopt(3, 0x11a /* SOL_?? */, 1, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
[pid 2602] accept(4, {sa_family=AF_INET, sin_port=htons(46290), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
[pid 2602] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
[pid 2602] setsockopt(5, 0x11a /* SOL_?? */, 2, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
[pid 2602] close(4) = 0
[pid 2602] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14
[pid 2602] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11
[pid 2602] recvfrom(5, "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64
[pid 2602] write(2, "tls.c:526:tls.recv_peek_large_bu"..., 112tls.c:526:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str, buf, len) (18446744073709551595) == 0 (0)
) = 112
[pid 2602] close(3) = 0
[pid 2602] close(5) = 0
[pid 2602] exit_group(8) = ?
Reason for the "test_read_peektest_read_peektest[...]" is because MSG_PEEK
cannot call tls_sw_advance_skb(), since the skb is sitting there that needs
to be consumed for non-MSG_PEEK case, and only then we can advance it.
Could you elaborate on where you ever had this test succeeding? With nxp
accelerator?
Thanks,
Daniel
^ permalink raw reply
* RE: linux-next: manual merge of the net-next tree with the net tree
From: Vakul Garg @ 2018-09-18 9:32 UTC (permalink / raw)
To: Daniel Borkmann, Stephen Rothwell, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <236589cd-b55d-1ceb-f236-36f9135f794e@iogearbox.net>
> -----Original Message-----
> From: Daniel Borkmann <daniel@iogearbox.net>
> Sent: Tuesday, September 18, 2018 2:57 PM
> To: Vakul Garg <vakul.garg@nxp.com>; Stephen Rothwell
> <sfr@canb.auug.org.au>; David Miller <davem@davemloft.net>;
> Networking <netdev@vger.kernel.org>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
>
> On 09/18/2018 11:10 AM, Vakul Garg wrote:
> >> -----Original Message-----
> >> From: Daniel Borkmann <daniel@iogearbox.net>
> >> Sent: Tuesday, September 18, 2018 2:14 PM
> >> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
> >> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
> >> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux
> >> Kernel Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
> >> <vakul.garg@nxp.com>
> >> Subject: Re: linux-next: manual merge of the net-next tree with the
> >> net tree
> >>
> >> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Today's linux-next merge of the net-next tree got a conflict in:
> >>>
> >>> tools/testing/selftests/net/tls.c
> >>>
> >>> between commit:
> >>>
> >>> 50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
> >>>
> >>> from the net tree and commit:
> >>>
> >>> c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
> >>> across multiple records")
> >>>
> >>> from the net-next tree.
> >>>
> >>> I fixed it up (see below) and can carry the fix as necessary. This
> >>> is now fixed as far as linux-next is concerned, but any non trivial
> >>> conflicts should be mentioned to your upstream maintainer when your
> >>> tree is submitted for merging. You may also want to consider
> >>> cooperating with the maintainer of the conflicting tree to minimise
> >>> any particularly complex conflicts.
> >>
> >> The test from 50c6b58a814d supersedes the one from c2ad647c6442 so
> >> the recv_peek_large_buf_mult_recs could be removed; latter was also
> >> not working correctly due to this bug.
> >
> > Why remove recv_peek_large_buf_mult_recs if its correct?
> > Why not the newly added one which achieves the same thing?
>
> Hmm, not quite, on net-next kernel, the recv_peek_large_buf_mult_recs fails
> every time I invoke the tls test suite:
>
> # ./tls
> [==========] Running 28 tests from 2 test cases.
> [ RUN ] tls.sendfile
> [ OK ] tls.sendfile
> [ RUN ] tls.send_then_sendfile
> [ OK ] tls.send_then_sendfile
> [ RUN ] tls.recv_max
> [ OK ] tls.recv_max
> [ RUN ] tls.recv_small
> [ OK ] tls.recv_small
> [ RUN ] tls.msg_more
> [ OK ] tls.msg_more
> [ RUN ] tls.sendmsg_single
> [ OK ] tls.sendmsg_single
> [ RUN ] tls.sendmsg_large
> [ OK ] tls.sendmsg_large
> [ RUN ] tls.sendmsg_multiple
> [ OK ] tls.sendmsg_multiple
> [ RUN ] tls.sendmsg_multiple_stress
> [ OK ] tls.sendmsg_multiple_stress
> [ RUN ] tls.splice_from_pipe
> [ OK ] tls.splice_from_pipe
> [ RUN ] tls.splice_from_pipe2
> [ OK ] tls.splice_from_pipe2
> [ RUN ] tls.send_and_splice
> [ OK ] tls.send_and_splice
> [ RUN ] tls.splice_to_pipe
> [ OK ] tls.splice_to_pipe
> [ RUN ] tls.recvmsg_single
> [ OK ] tls.recvmsg_single
> [ RUN ] tls.recvmsg_single_max
> [ OK ] tls.recvmsg_single_max
> [ RUN ] tls.recvmsg_multiple
> [ OK ] tls.recvmsg_multiple
> [ RUN ] tls.single_send_multiple_recv
> [ OK ] tls.single_send_multiple_recv
> [ RUN ] tls.multiple_send_single_recv
> [ OK ] tls.multiple_send_single_recv
> [ RUN ] tls.recv_partial
> [ OK ] tls.recv_partial
> [ RUN ] tls.recv_nonblock
> [ OK ] tls.recv_nonblock
> [ RUN ] tls.recv_peek
> [ OK ] tls.recv_peek
> [ RUN ] tls.recv_peek_multiple
> [ OK ] tls.recv_peek_multiple
> [ RUN ] tls.recv_peek_large_buf_mult_recs
> tls.c:524:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str,
> buf, len) (18446744073709551595) == 0 (0)
> tls.recv_peek_large_buf_mult_recs: Test failed at step #8
> [ FAIL ] tls.recv_peek_large_buf_mult_recs
> [ RUN ] tls.pollin
> [ OK ] tls.pollin
> [ RUN ] tls.poll_wait
> [ OK ] tls.poll_wait
> [ RUN ] tls.blocking
> [ OK ] tls.blocking
> [ RUN ] tls.nonblocking
> [ OK ] tls.nonblocking
> [ RUN ] tls.control_msg
> [ OK ] tls.control_msg
> [==========] 27 / 28 tests passed.
> [ FAILED ]
>
> Here's what the recvfrom() with MSG_PEEK sees:
>
> [pid 2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 [pid 2602]
> socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4 [pid 2602] bind(4,
> {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) =
> 0
> [pid 2602] listen(4, 10) = 0
> [pid 2602] getsockname(4, {sa_family=AF_INET, sin_port=htons(41483),
> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 [pid 2602] connect(3,
> {sa_family=AF_INET, sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")},
> 16) = 0 [pid 2602] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4)
> = 0 [pid 2602] setsockopt(3, 0x11a /* SOL_?? */, 1,
> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 40) = 0 [pid 2602] accept(4, {sa_family=AF_INET, sin_port=htons(46290),
> sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 [pid 2602] setsockopt(5,
> SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0 [pid 2602] setsockopt(5,
> 0x11a /* SOL_?? */, 2,
> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 40) = 0
> [pid 2602] close(4) = 0
> [pid 2602] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14 [pid 2602]
> sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11 [pid 2602] recvfrom(5,
> "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64
> [pid 2602] write(2, "tls.c:526:tls.recv_peek_large_bu"...,
> 112tls.c:526:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str,
> buf, len) (18446744073709551595) == 0 (0)
> ) = 112
> [pid 2602] close(3) = 0
> [pid 2602] close(5) = 0
> [pid 2602] exit_group(8) = ?
>
> Reason for the "test_read_peektest_read_peektest[...]" is because
> MSG_PEEK cannot call tls_sw_advance_skb(), since the skb is sitting there
> that needs to be consumed for non-MSG_PEEK case, and only then we can
> advance it.
>
I general, my plan was to modify the tls_sw_recvmsg() to trigger as many
decryption as possible as required by requested user space PEEK size.
This would have required creating a pending list of decrypted records in tls_tx context.
> Could you elaborate on where you ever had this test succeeding? With nxp
> accelerator?
I never had this test succeeding. I pointed the problem to Dave Watson sometime
back (found during code reading).
To make sure that this bug does not slip out, I simply submitted a test case to keep
reminding ourselves that we need to fix it sometime.
>
> Thanks,
> Daniel
^ 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