* [RFC] net: phy: read link status twice when phy_check_link_status()
From: Yonglong Liu @ 2019-07-26 9:53 UTC (permalink / raw)
To: andrew, davem
Cc: netdev, linux-kernel, linuxarm, salil.mehta, yisen.zhuang,
shiju.jose
According to the datasheet of Marvell phy and Realtek phy, the
copper link status should read twice, or it may get a fake link
up status, and cause up->down->up at the first time when link up.
This happens more oftem at Realtek phy.
I add a fake status read, and can solve this problem.
I also see that in genphy_update_link(), had delete the fake
read in polling mode, so I don't know whether my solution is
correct.
Or provide a phydev->drv->read_status functions for the phy I
used is more acceptable?
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
---
drivers/net/phy/phy.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index ef7aa73..0c03edc 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1,4 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
+ err = phy_read_status(phydev);
+ if (err)
+ return err;
/* Framework for configuring and reading PHY devices
* Based on code in sungem_phy.c and gianfar_phy.c
*
@@ -525,6 +528,11 @@ static int phy_check_link_status(struct phy_device *phydev)
WARN_ON(!mutex_is_locked(&phydev->lock));
+ /* Do a fake read */
+ err = phy_read(phydev, MII_BMSR);
+ if (err < 0)
+ return err;
+
err = phy_read_status(phydev);
if (err)
return err;
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] Revert "net: get rid of an signed integer overflow in ip_idents_reserve()"
From: Eric Dumazet @ 2019-07-26 9:58 UTC (permalink / raw)
To: Shaokun Zhang, netdev, linux-kernel
Cc: Yang Guo, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Eric Dumazet, Jiri Pirko
In-Reply-To: <1564132635-57634-1-git-send-email-zhangshaokun@hisilicon.com>
On 7/26/19 11:17 AM, Shaokun Zhang wrote:
> From: Yang Guo <guoyang2@huawei.com>
>
> There is an significant performance regression with the following
> commit-id <adb03115f459>
> ("net: get rid of an signed integer overflow in ip_idents_reserve()").
>
>
So, you jump around and took ownership of this issue, while some of us
are already working on it ?
Have you first checked that current UBSAN versions will not complain anymore ?
A revert adding back the original issue would be silly, performance of
benchmarks is nice but secondary.
^ permalink raw reply
* [PATCH] ipw2x00: remove redundant assignment to err
From: Colin King @ 2019-07-26 10:06 UTC (permalink / raw)
To: Stanislav Yakovlev, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable err is initialized to a value that is never read and it
is re-assigned later. The initialization is redundant and can
be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index 75c0c29d81f0..8dfbaff2d1fe 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -4413,7 +4413,7 @@ static void ipw2100_kill_works(struct ipw2100_priv *priv)
static int ipw2100_tx_allocate(struct ipw2100_priv *priv)
{
- int i, j, err = -EINVAL;
+ int i, j, err;
void *v;
dma_addr_t p;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 1/2] ipmr: Make cache queue length configurable
From: Stephen Suryaputra @ 2019-07-26 10:10 UTC (permalink / raw)
To: Brodie Greenfield
Cc: davem, stephen, kuznet, yoshfuji, netdev, linux-kernel,
chris.packham, luuk.paulussen
In-Reply-To: <20190725204230.12229-2-brodie.greenfield@alliedtelesis.co.nz>
On Fri, Jul 26, 2019 at 08:42:29AM +1200, Brodie Greenfield wrote:
> We want to be able to keep more spaces available in our queue for
> processing incoming multicast traffic (adding (S,G) entries) - this lets
> us learn more groups faster, rather than dropping them at this stage.
>
> Signed-off-by: Brodie Greenfield <brodie.greenfield@alliedtelesis.co.nz>
Our system can use this. The patch applied cleanly to my net-next
sandbox. Thank you.
Reviewed-by: Stephen Suryaputra <ssuryaextr@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/2] ip6mr: Make cache queue length configurable
From: Stephen Suryaputra @ 2019-07-26 10:10 UTC (permalink / raw)
To: Brodie Greenfield
Cc: davem, stephen, kuznet, yoshfuji, netdev, linux-kernel,
chris.packham, luuk.paulussen
In-Reply-To: <20190725204230.12229-3-brodie.greenfield@alliedtelesis.co.nz>
On Fri, Jul 26, 2019 at 08:42:30AM +1200, Brodie Greenfield wrote:
> We want to be able to keep more spaces available in our queue for
> processing incoming IPv6 multicast traffic (adding (S,G) entries) - this
> lets us learn more groups faster, rather than dropping them at this stage.
>
> Signed-off-by: Brodie Greenfield <brodie.greenfield@alliedtelesis.co.nz>
Reviewed-by: Stephen Suryaputra <ssuryaextr@gmail.com>
^ permalink raw reply
* [PATCH net-next 1/2] net: stmmac: Make MDIO bus reset optional
From: Thierry Reding @ 2019-07-26 10:27 UTC (permalink / raw)
To: David S . Miller
Cc: Jose Abreu, Alexandre Torgue, Giuseppe Cavallaro, Jon Hunter,
netdev, linux-tegra, linux-arm-kernel
From: Thierry Reding <treding@nvidia.com>
The Tegra EQOS driver already resets the MDIO bus at probe time via the
reset GPIO specified in the phy-reset-gpios device tree property. There
is no need to reset the bus again later on.
This avoids the need to query the device tree for the snps,reset GPIO,
which is not part of the Tegra EQOS device tree bindings. This quiesces
an error message from the generic bus reset code if it doesn't find the
snps,reset related delays.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 3 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 4 +++-
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 8 +++++++-
include/linux/stmmac.h | 1 +
5 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 3a14cdd01f5f..66933332c68e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -333,6 +333,9 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
usleep_range(2000, 4000);
gpiod_set_value(eqos->reset, 0);
+ /* MDIO bus was already reset just above */
+ data->mdio_bus_data->needs_reset = false;
+
eqos->rst = devm_reset_control_get(&pdev->dev, "eqos");
if (IS_ERR(eqos->rst)) {
err = PTR_ERR(eqos->rst);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 4304c1abc5d1..40c42637ad75 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -348,7 +348,9 @@ int stmmac_mdio_register(struct net_device *ndev)
max_addr = PHY_MAX_ADDR;
}
- new_bus->reset = &stmmac_mdio_reset;
+ if (mdio_bus_data->needs_reset)
+ new_bus->reset = &stmmac_mdio_reset;
+
snprintf(new_bus->id, MII_BUS_ID_SIZE, "%s-%x",
new_bus->name, priv->plat->bus_id);
new_bus->priv = ndev;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 86f9c07a38cf..d5d08e11c353 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -63,6 +63,7 @@ static void common_default_data(struct plat_stmmacenet_data *plat)
plat->has_gmac = 1;
plat->force_sf_dma_mode = 1;
+ plat->mdio_bus_data->needs_reset = true;
plat->mdio_bus_data->phy_mask = 0;
/* Set default value for multicast hash bins */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 73fc2524372e..333b09564b88 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -342,10 +342,16 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
mdio = true;
}
- if (mdio)
+ if (mdio) {
plat->mdio_bus_data =
devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
GFP_KERNEL);
+ if (!plat->mdio_bus_data)
+ return -ENOMEM;
+
+ plat->mdio_bus_data->needs_reset = true;
+ }
+
return 0;
}
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 7d06241582dd..7b3e354bcd3c 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -81,6 +81,7 @@ struct stmmac_mdio_bus_data {
unsigned int phy_mask;
int *irqs;
int probed_phy_irq;
+ bool needs_reset;
};
struct stmmac_dma_cfg {
--
2.22.0
^ permalink raw reply related
* [PATCH net-next 2/2] net: stmmac: Do not request stmmaceth clock
From: Thierry Reding @ 2019-07-26 10:27 UTC (permalink / raw)
To: David S . Miller
Cc: Jose Abreu, Alexandre Torgue, Giuseppe Cavallaro, Jon Hunter,
netdev, linux-tegra, linux-arm-kernel
In-Reply-To: <20190726102741.27872-1-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
The stmmaceth clock is specified by the slave_bus and apb_pclk clocks in
the device tree bindings for snps,dwc-qos-ethernet-4.10 compatible nodes
of this IP.
The subdrivers for these bindings will be requesting the stmmac clock
correctly at a later point, so there is no need to request it here and
cause an error message to be printed to the kernel log.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 333b09564b88..7ad2bb90ceb1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -521,13 +521,15 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
}
/* clock setup */
- plat->stmmac_clk = devm_clk_get(&pdev->dev,
- STMMAC_RESOURCE_NAME);
- if (IS_ERR(plat->stmmac_clk)) {
- dev_warn(&pdev->dev, "Cannot get CSR clock\n");
- plat->stmmac_clk = NULL;
+ if (!of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
+ plat->stmmac_clk = devm_clk_get(&pdev->dev,
+ STMMAC_RESOURCE_NAME);
+ if (IS_ERR(plat->stmmac_clk)) {
+ dev_warn(&pdev->dev, "Cannot get CSR clock\n");
+ plat->stmmac_clk = NULL;
+ }
+ clk_prepare_enable(plat->stmmac_clk);
}
- clk_prepare_enable(plat->stmmac_clk);
plat->pclk = devm_clk_get(&pdev->dev, "pclk");
if (IS_ERR(plat->pclk)) {
--
2.22.0
^ permalink raw reply related
* Re: [PATCH net-next 2/2] mlx4/en_netdev: call notifiers when hw_enc_features change
From: Davide Caratti @ 2019-07-26 10:39 UTC (permalink / raw)
To: Saeed Mahameed, davem@davemloft.net, Tariq Toukan,
netdev@vger.kernel.org
Cc: Eran Ben Elisha
In-Reply-To: <f9ca12ff3880f94d4576ab4e4239f072ed611293.camel@mellanox.com>
On Thu, 2019-07-25 at 21:27 +0000, Saeed Mahameed wrote:
> On Thu, 2019-07-25 at 14:25 +0200, Davide Caratti wrote:
> > On Wed, 2019-07-24 at 20:47 +0000, Saeed Mahameed wrote:
> > > On Wed, 2019-07-24 at 16:02 +0200, Davide Caratti wrote:
> > > > ensure to call netdev_features_change() when the driver flips its
> > > > hw_enc_features bits.
> > > >
> > > > Signed-off-by: Davide Caratti <dcaratti@redhat.com>
> > >
> > > The patch is correct,
> >
> > hello Saeed, and thanks for looking at this!
> >
> > > but can you explain how did you come to this ?
> > > did you encounter any issue with the current code ?
> > >
> > > I am asking just because i think the whole dynamic changing of dev-
> > > > hw_enc_features is redundant since mlx4 has the featutres_check
> > > callback.
> >
> > we need it to ensure that vlan_transfer_features() updates
> > the (new) value of hw_enc_features in the overlying vlan: otherwise,
> > segmentation will happen anyway when skb passes from vxlan to vlan,
> > if the
> > vxlan is added after the vlan device has been created (see:
> > 7dad9937e064
> > ("net: vlan: add support for tunnel offload") ).
> >
>
> but in previous patch you made sure that the vlan always sees the
> correct hw_enc_features on driver load, we don't need to have this
> dynamic update mechanism,
ok, but the mlx4 driver flips the value of hw_enc_features when VXLAN
tunnels are added or removed. So, assume eth0 is a Cx3-pro, and I do:
# ip link add name vlan5 link eth0 type vlan id 5
# ip link add dev vxlan6 type vxlan id 6 [...] dev vlan5
the value of dev->hw_enc_features is 0 for vlan5, and as a consequence
VXLAN over VLAN traffic becomes segmented by the VLAN, even if eth0, at
the end of this sequence, has the "right" features bits.
> features_check ndo should take care of
> protocols we don't support.
I just had a look at mlx4_en_features_check(), I see it checks if the
packet is tunneled in VXLAN and the destination port matches the
configured value of priv->vxlan_port (when that value is not zero). Now:
On Wed, 2019-07-24 at 20:47 +0000, Saeed Mahameed wrote:
> I am asking just because i think the whole dynamic changing of
> dev-> hw_enc_features is redundant since mlx4 has the featutres_check
> callback.
I read your initial proposal again. Would it be correct if I just use
patch 1/2, where I add an assignment of
dev->hw_enc_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | \
NETIF_F_RXCSUM | \
NETIF_F_TSO | NETIF_F_TSO6 | \
NETIF_F_GSO_UDP_TUNNEL | \
NETIF_F_GSO_UDP_TUNNEL_CSUM | \
NETIF_F_GSO_PARTIAL;
in mlx4_en_init_netdev(), and then remove the code that flips
dev->hw_enc_features in mlx4_en_add_vxlan_offloads() and
mlx4_en_del_vxlan_offloads() ?
thanks,
--
davide
^ permalink raw reply
* KASAN: use-after-free Read in bpf_get_prog_name
From: syzbot @ 2019-07-26 10:59 UTC (permalink / raw)
To: ast, bpf, daniel, davem, hawk, jakub.kicinski, john.fastabend,
kafai, linux-kernel, netdev, songliubraving, syzkaller-bugs,
xdp-newbies, yhs
Hello,
syzbot found the following crash on:
HEAD commit: 192f0f8e Merge tag 'powerpc-5.3-1' of git://git.kernel.org..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=170afe64600000
kernel config: https://syzkaller.appspot.com/x/.config?x=87305c3ca9c25c70
dashboard link: https://syzkaller.appspot.com/bug?extid=4d5cdc96ead2e74e7f90
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4d5cdc96ead2e74e7f90@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in string_nocheck+0x219/0x240 lib/vsprintf.c:605
Read of size 1 at addr ffff88809fee2d70 by task syz-executor.1/30647
CPU: 1 PID: 30647 Comm: syz-executor.1 Not tainted 5.2.0+ #41
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x20 mm/kasan/common.c:612
__asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:129
string_nocheck+0x219/0x240 lib/vsprintf.c:605
string+0xed/0x100 lib/vsprintf.c:668
vsnprintf+0x97b/0x19a0 lib/vsprintf.c:2503
snprintf+0xbb/0xf0 lib/vsprintf.c:2636
bpf_get_prog_name+0x159/0x360 kernel/bpf/core.c:570
perf_event_bpf_emit_ksymbols+0x284/0x390 kernel/events/core.c:7883
perf_event_bpf_event+0x253/0x290 kernel/events/core.c:7914
bpf_prog_load+0x102a/0x1670 kernel/bpf/syscall.c:1723
__do_sys_bpf+0xa46/0x42f0 kernel/bpf/syscall.c:2849
__se_sys_bpf kernel/bpf/syscall.c:2808 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:2808
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f8c78cf3c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000000000070 RSI: 0000000020000240 RDI: 0000000000000005
RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8c78cf46d4
R13: 00000000004bfc7c R14: 00000000004d16d8 R15: 00000000ffffffff
Allocated by task 30647:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
bpf_prog_alloc_no_stats+0xe6/0x2b0 kernel/bpf/core.c:88
bpf_prog_alloc+0x31/0x230 kernel/bpf/core.c:110
bpf_prog_load+0x400/0x1670 kernel/bpf/syscall.c:1652
__do_sys_bpf+0xa46/0x42f0 kernel/bpf/syscall.c:2849
__se_sys_bpf kernel/bpf/syscall.c:2808 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:2808
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 12:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
__bpf_prog_free+0x87/0xc0 kernel/bpf/core.c:258
bpf_jit_free+0x64/0x1b0
bpf_prog_free_deferred+0x27a/0x350 kernel/bpf/core.c:1982
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff88809fee2cc0
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 176 bytes inside of
512-byte region [ffff88809fee2cc0, ffff88809fee2ec0)
The buggy address belongs to the page:
page:ffffea00027fb880 refcount:1 mapcount:0 mapping:ffff8880aa400a80
index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea0002709008 ffffea000246e348 ffff8880aa400a80
raw: 0000000000000000 ffff88809fee2040 0000000100000006 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88809fee2c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88809fee2c80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ffff88809fee2d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88809fee2d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88809fee2e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: possible deadlock in rxrpc_put_peer
From: Dmitry Vyukov @ 2019-07-26 10:59 UTC (permalink / raw)
To: syzbot, David Howells, David Miller, linux-afs, netdev
Cc: LKML, syzkaller-bugs
In-Reply-To: <000000000000b7abcc058e924c12@google.com>
On Fri, Jul 26, 2019 at 11:38 AM syzbot
<syzbot+72af434e4b3417318f84@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 6d21a41b Add linux-next specific files for 20190718
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=174e3af0600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> dashboard link: https://syzkaller.appspot.com/bug?extid=72af434e4b3417318f84
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+72af434e4b3417318f84@syzkaller.appspotmail.com
+net/rxrpc/peer_object.c maintainers
> ============================================
> WARNING: possible recursive locking detected
> 5.2.0-next-20190718 #41 Not tainted
> --------------------------------------------
> kworker/0:3/21678 is trying to acquire lock:
> 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at: spin_lock_bh
> /./include/linux/spinlock.h:343 [inline]
> 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
> __rxrpc_put_peer /net/rxrpc/peer_object.c:415 [inline]
> 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
> rxrpc_put_peer+0x2d3/0x6a0 /net/rxrpc/peer_object.c:435
>
> but task is already holding lock:
> 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at: spin_lock_bh
> /./include/linux/spinlock.h:343 [inline]
> 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
> rxrpc_peer_keepalive_dispatch /net/rxrpc/peer_event.c:378 [inline]
> 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
> rxrpc_peer_keepalive_worker+0x6b3/0xd02 /net/rxrpc/peer_event.c:430
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock(&(&rxnet->peer_hash_lock)->rlock);
> lock(&(&rxnet->peer_hash_lock)->rlock);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 3 locks held by kworker/0:3/21678:
> #0: 000000007c4c2bc3 ((wq_completion)krxrpcd){+.+.}, at: __write_once_size
> /./include/linux/compiler.h:226 [inline]
> #0: 000000007c4c2bc3 ((wq_completion)krxrpcd){+.+.}, at: arch_atomic64_set
> /./arch/x86/include/asm/atomic64_64.h:34 [inline]
> #0: 000000007c4c2bc3 ((wq_completion)krxrpcd){+.+.}, at: atomic64_set
> /./include/asm-generic/atomic-instrumented.h:855 [inline]
> #0: 000000007c4c2bc3 ((wq_completion)krxrpcd){+.+.}, at: atomic_long_set
> /./include/asm-generic/atomic-long.h:40 [inline]
> #0: 000000007c4c2bc3 ((wq_completion)krxrpcd){+.+.}, at: set_work_data
> /kernel/workqueue.c:620 [inline]
> #0: 000000007c4c2bc3 ((wq_completion)krxrpcd){+.+.}, at:
> set_work_pool_and_clear_pending /kernel/workqueue.c:647 [inline]
> #0: 000000007c4c2bc3 ((wq_completion)krxrpcd){+.+.}, at:
> process_one_work+0x88b/0x1740 /kernel/workqueue.c:2240
> #1: 000000006782bc7f
> ((work_completion)(&rxnet->peer_keepalive_work)){+.+.}, at:
> process_one_work+0x8c1/0x1740 /kernel/workqueue.c:2244
> #2: 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
> spin_lock_bh /./include/linux/spinlock.h:343 [inline]
> #2: 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
> rxrpc_peer_keepalive_dispatch /net/rxrpc/peer_event.c:378 [inline]
> #2: 00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
> rxrpc_peer_keepalive_worker+0x6b3/0xd02 /net/rxrpc/peer_event.c:430
>
> stack backtrace:
> CPU: 0 PID: 21678 Comm: kworker/0:3 Not tainted 5.2.0-next-20190718 #41
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: krxrpcd rxrpc_peer_keepalive_worker
> Call Trace:
> __dump_stack /lib/dump_stack.c:77 [inline]
> dump_stack+0x172/0x1f0 /lib/dump_stack.c:113
> print_deadlock_bug /kernel/locking/lockdep.c:2301 [inline]
> check_deadlock /kernel/locking/lockdep.c:2342 [inline]
> validate_chain /kernel/locking/lockdep.c:2881 [inline]
> __lock_acquire.cold+0x194/0x398 /kernel/locking/lockdep.c:3880
> lock_acquire+0x190/0x410 /kernel/locking/lockdep.c:4413
> __raw_spin_lock_bh /./include/linux/spinlock_api_smp.h:135 [inline]
> _raw_spin_lock_bh+0x33/0x50 /kernel/locking/spinlock.c:175
> spin_lock_bh /./include/linux/spinlock.h:343 [inline]
> __rxrpc_put_peer /net/rxrpc/peer_object.c:415 [inline]
> rxrpc_put_peer+0x2d3/0x6a0 /net/rxrpc/peer_object.c:435
> rxrpc_peer_keepalive_dispatch /net/rxrpc/peer_event.c:381 [inline]
> rxrpc_peer_keepalive_worker+0x7a6/0xd02 /net/rxrpc/peer_event.c:430
> process_one_work+0x9af/0x1740 /kernel/workqueue.c:2269
> worker_thread+0x98/0xe40 /kernel/workqueue.c:2415
> kthread+0x361/0x430 /kernel/kthread.c:255
> ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000b7abcc058e924c12%40google.com.
^ permalink raw reply
* Re: [PATCH 1/2] ipmr: Make cache queue length configurable
From: Nikolay Aleksandrov @ 2019-07-26 11:05 UTC (permalink / raw)
To: Brodie Greenfield, davem, stephen, kuznet, yoshfuji, netdev
Cc: linux-kernel, chris.packham, luuk.paulussen
In-Reply-To: <20190725204230.12229-2-brodie.greenfield@alliedtelesis.co.nz>
On 25/07/2019 23:42, Brodie Greenfield wrote:
> We want to be able to keep more spaces available in our queue for
> processing incoming multicast traffic (adding (S,G) entries) - this lets
> us learn more groups faster, rather than dropping them at this stage.
>
> Signed-off-by: Brodie Greenfield <brodie.greenfield@alliedtelesis.co.nz>
> ---
> Documentation/networking/ip-sysctl.txt | 8 ++++++++
> include/net/netns/ipv4.h | 1 +
> net/ipv4/af_inet.c | 1 +
> net/ipv4/ipmr.c | 4 +++-
> net/ipv4/sysctl_net_ipv4.c | 7 +++++++
> 5 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index acdfb5d2bcaa..02f77e932adf 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -887,6 +887,14 @@ ip_local_reserved_ports - list of comma separated ranges
>
> Default: Empty
>
> +ip_mr_cache_queue_length - INTEGER
> + Limit the number of multicast packets we can have in the queue to be
> + resolved.
> + Bear in mind that when an unresolved multicast packet is received,
> + there is an O(n) traversal of the queue. This should be considered
> + if increasing.
> + Default: 10
> +
Hi,
You've said it yourself - it has linear traversal time, but doesn't this patch allow any netns on the
system to increase its limit to any value, thus possibly affecting others ?
Though the socket limit will kick in at some point. I think that's where David
was going with his suggestion back in 2018:
https://www.spinics.net/lists/netdev/msg514543.html
If we add this sysctl now, we'll be stuck with it. I'd prefer David's suggestion
so we can rely only on the receive queue queue limit which is already configurable.
We still need to be careful with the defaults though, the NOCACHE entry is 128 bytes
and with the skb overhead currently on my setup we end up at about 277 entries default limit.
Cheers,
Nik
> ip_unprivileged_port_start - INTEGER
> This is a per-namespace sysctl. It defines the first
> unprivileged port in the network namespace. Privileged ports
> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
> index 104a6669e344..3411d3f18d51 100644
> --- a/include/net/netns/ipv4.h
> +++ b/include/net/netns/ipv4.h
> @@ -187,6 +187,7 @@ struct netns_ipv4 {
> int sysctl_igmp_max_msf;
> int sysctl_igmp_llm_reports;
> int sysctl_igmp_qrv;
> + unsigned int sysctl_ip_mr_cache_queue_length;
>
> struct ping_group_range ping_group_range;
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 0dfb72c46671..8e25538bdb1e 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1827,6 +1827,7 @@ static __net_init int inet_init_net(struct net *net)
> net->ipv4.sysctl_igmp_llm_reports = 1;
> net->ipv4.sysctl_igmp_qrv = 2;
>
> + net->ipv4.sysctl_ip_mr_cache_queue_length = 10;
> return 0;
> }
>
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index ddbf8c9a1abb..c6a6c3e453a9 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -1127,6 +1127,7 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
> struct sk_buff *skb, struct net_device *dev)
> {
> const struct iphdr *iph = ip_hdr(skb);
> + struct net *net = dev_net(dev);
> struct mfc_cache *c;
> bool found = false;
> int err;
> @@ -1142,7 +1143,8 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
>
> if (!found) {
> /* Create a new entry if allowable */
> - if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
> + if (atomic_read(&mrt->cache_resolve_queue_len) >=
> + net->ipv4.sysctl_ip_mr_cache_queue_length ||
> (c = ipmr_cache_alloc_unres()) == NULL) {
> spin_unlock_bh(&mfc_unres_lock);
>
> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index ba0fc4b18465..78ae86e8c6cb 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -784,6 +784,13 @@ static struct ctl_table ipv4_net_table[] = {
> .proc_handler = proc_dointvec
> },
> #ifdef CONFIG_IP_MULTICAST
> + {
> + .procname = "ip_mr_cache_queue_length",
> + .data = &init_net.ipv4.sysctl_ip_mr_cache_queue_length,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec
> + },
> {
> .procname = "igmp_qrv",
> .data = &init_net.ipv4.sysctl_igmp_qrv,
>
^ permalink raw reply
* Re: [PATCH 1/2] ipmr: Make cache queue length configurable
From: Nikolay Aleksandrov @ 2019-07-26 11:15 UTC (permalink / raw)
To: Brodie Greenfield, davem, stephen, kuznet, yoshfuji, netdev
Cc: linux-kernel, chris.packham, luuk.paulussen
In-Reply-To: <e5606cf7-6848-1109-6cbe-63d94868ed65@cumulusnetworks.com>
On 26/07/2019 14:05, Nikolay Aleksandrov wrote:
> On 25/07/2019 23:42, Brodie Greenfield wrote:
>> We want to be able to keep more spaces available in our queue for
>> processing incoming multicast traffic (adding (S,G) entries) - this lets
>> us learn more groups faster, rather than dropping them at this stage.
>>
>> Signed-off-by: Brodie Greenfield <brodie.greenfield@alliedtelesis.co.nz>
>> ---
>> Documentation/networking/ip-sysctl.txt | 8 ++++++++
>> include/net/netns/ipv4.h | 1 +
>> net/ipv4/af_inet.c | 1 +
>> net/ipv4/ipmr.c | 4 +++-
>> net/ipv4/sysctl_net_ipv4.c | 7 +++++++
>> 5 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
>> index acdfb5d2bcaa..02f77e932adf 100644
>> --- a/Documentation/networking/ip-sysctl.txt
>> +++ b/Documentation/networking/ip-sysctl.txt
>> @@ -887,6 +887,14 @@ ip_local_reserved_ports - list of comma separated ranges
>>
>> Default: Empty
>>
>> +ip_mr_cache_queue_length - INTEGER
>> + Limit the number of multicast packets we can have in the queue to be
>> + resolved.
>> + Bear in mind that when an unresolved multicast packet is received,
>> + there is an O(n) traversal of the queue. This should be considered
>> + if increasing.
>> + Default: 10
>> +
>
> Hi,
> You've said it yourself - it has linear traversal time, but doesn't this patch allow any netns on the
> system to increase its limit to any value, thus possibly affecting others ?
> Though the socket limit will kick in at some point. I think that's where David
> was going with his suggestion back in 2018:
> https://www.spinics.net/lists/netdev/msg514543.html
>
> If we add this sysctl now, we'll be stuck with it. I'd prefer David's suggestion
> so we can rely only on the receive queue queue limit which is already configurable.
> We still need to be careful with the defaults though, the NOCACHE entry is 128 bytes
> and with the skb overhead currently on my setup we end up at about 277 entries default limit.
I mean that people might be surprised if they increased that limit by default, that's the
only problem I'm not sure how to handle. Maybe we need some hard limit anyway.
Have you done any tests what value works for your setup ?
In the end we might have to go with this patch, but perhaps limit the per-netns sysctl
to the init_ns value as maximum (similar to what we did for frags) or don't make it per-netns
at all.
>
> Cheers,
> Nik
>
>> ip_unprivileged_port_start - INTEGER
>> This is a per-namespace sysctl. It defines the first
>> unprivileged port in the network namespace. Privileged ports
>> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
>> index 104a6669e344..3411d3f18d51 100644
>> --- a/include/net/netns/ipv4.h
>> +++ b/include/net/netns/ipv4.h
>> @@ -187,6 +187,7 @@ struct netns_ipv4 {
>> int sysctl_igmp_max_msf;
>> int sysctl_igmp_llm_reports;
>> int sysctl_igmp_qrv;
>> + unsigned int sysctl_ip_mr_cache_queue_length;
>>
>> struct ping_group_range ping_group_range;
>>
>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
>> index 0dfb72c46671..8e25538bdb1e 100644
>> --- a/net/ipv4/af_inet.c
>> +++ b/net/ipv4/af_inet.c
>> @@ -1827,6 +1827,7 @@ static __net_init int inet_init_net(struct net *net)
>> net->ipv4.sysctl_igmp_llm_reports = 1;
>> net->ipv4.sysctl_igmp_qrv = 2;
>>
>> + net->ipv4.sysctl_ip_mr_cache_queue_length = 10;
>> return 0;
>> }
>>
>> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
>> index ddbf8c9a1abb..c6a6c3e453a9 100644
>> --- a/net/ipv4/ipmr.c
>> +++ b/net/ipv4/ipmr.c
>> @@ -1127,6 +1127,7 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
>> struct sk_buff *skb, struct net_device *dev)
>> {
>> const struct iphdr *iph = ip_hdr(skb);
>> + struct net *net = dev_net(dev);
>> struct mfc_cache *c;
>> bool found = false;
>> int err;
>> @@ -1142,7 +1143,8 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
>>
>> if (!found) {
>> /* Create a new entry if allowable */
>> - if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
>> + if (atomic_read(&mrt->cache_resolve_queue_len) >=
>> + net->ipv4.sysctl_ip_mr_cache_queue_length ||
>> (c = ipmr_cache_alloc_unres()) == NULL) {
>> spin_unlock_bh(&mfc_unres_lock);
>>
>> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
>> index ba0fc4b18465..78ae86e8c6cb 100644
>> --- a/net/ipv4/sysctl_net_ipv4.c
>> +++ b/net/ipv4/sysctl_net_ipv4.c
>> @@ -784,6 +784,13 @@ static struct ctl_table ipv4_net_table[] = {
>> .proc_handler = proc_dointvec
>> },
>> #ifdef CONFIG_IP_MULTICAST
>> + {
>> + .procname = "ip_mr_cache_queue_length",
>> + .data = &init_net.ipv4.sysctl_ip_mr_cache_queue_length,
>> + .maxlen = sizeof(int),
>> + .mode = 0644,
>> + .proc_handler = proc_dointvec
>> + },
>> {
>> .procname = "igmp_qrv",
>> .data = &init_net.ipv4.sysctl_igmp_qrv,
>>
>
^ permalink raw reply
* [PATCH v2 10/10] docs: remove extra conf.py files
From: Mauro Carvalho Chehab @ 2019-07-26 11:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Jonathan Corbet, Herbert Xu,
David S. Miller, Maarten Lankhorst, Maxime Ripard, Sean Paul,
David Airlie, Daniel Vetter, Dmitry Torokhov, Yoshinori Sato,
Rich Felker, Jaroslav Kysela, Takashi Iwai, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, linux-doc,
linux-crypto, dri-devel, linux-input, netdev, linux-sh,
alsa-devel
In-Reply-To: <cover.1564139914.git.mchehab+samsung@kernel.org>
Now that the latex_documents are handled automatically, we can
remove those extra conf.py files.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/admin-guide/conf.py | 10 ----------
Documentation/core-api/conf.py | 10 ----------
Documentation/crypto/conf.py | 10 ----------
Documentation/dev-tools/conf.py | 10 ----------
Documentation/doc-guide/conf.py | 10 ----------
Documentation/driver-api/80211/conf.py | 10 ----------
Documentation/driver-api/conf.py | 10 ----------
Documentation/driver-api/pm/conf.py | 10 ----------
Documentation/filesystems/conf.py | 10 ----------
Documentation/gpu/conf.py | 10 ----------
Documentation/input/conf.py | 10 ----------
Documentation/kernel-hacking/conf.py | 10 ----------
Documentation/maintainer/conf.py | 10 ----------
Documentation/media/conf.py | 12 ------------
Documentation/networking/conf.py | 10 ----------
Documentation/process/conf.py | 10 ----------
Documentation/sh/conf.py | 10 ----------
Documentation/sound/conf.py | 10 ----------
Documentation/userspace-api/conf.py | 10 ----------
Documentation/vm/conf.py | 10 ----------
Documentation/x86/conf.py | 10 ----------
21 files changed, 212 deletions(-)
delete mode 100644 Documentation/admin-guide/conf.py
delete mode 100644 Documentation/core-api/conf.py
delete mode 100644 Documentation/crypto/conf.py
delete mode 100644 Documentation/dev-tools/conf.py
delete mode 100644 Documentation/doc-guide/conf.py
delete mode 100644 Documentation/driver-api/80211/conf.py
delete mode 100644 Documentation/driver-api/conf.py
delete mode 100644 Documentation/driver-api/pm/conf.py
delete mode 100644 Documentation/filesystems/conf.py
delete mode 100644 Documentation/gpu/conf.py
delete mode 100644 Documentation/input/conf.py
delete mode 100644 Documentation/kernel-hacking/conf.py
delete mode 100644 Documentation/maintainer/conf.py
delete mode 100644 Documentation/media/conf.py
delete mode 100644 Documentation/networking/conf.py
delete mode 100644 Documentation/process/conf.py
delete mode 100644 Documentation/sh/conf.py
delete mode 100644 Documentation/sound/conf.py
delete mode 100644 Documentation/userspace-api/conf.py
delete mode 100644 Documentation/vm/conf.py
delete mode 100644 Documentation/x86/conf.py
diff --git a/Documentation/admin-guide/conf.py b/Documentation/admin-guide/conf.py
deleted file mode 100644
index 86f738953799..000000000000
--- a/Documentation/admin-guide/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel User Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'linux-user.tex', 'Linux Kernel User Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/core-api/conf.py b/Documentation/core-api/conf.py
deleted file mode 100644
index db1f7659f3da..000000000000
--- a/Documentation/core-api/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Core-API Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'core-api.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/crypto/conf.py b/Documentation/crypto/conf.py
deleted file mode 100644
index 4335d251ddf3..000000000000
--- a/Documentation/crypto/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Crypto API'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'crypto-api.tex', 'Linux Kernel Crypto API manual',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/dev-tools/conf.py b/Documentation/dev-tools/conf.py
deleted file mode 100644
index 7faafa3f7888..000000000000
--- a/Documentation/dev-tools/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Development tools for the kernel"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'dev-tools.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/doc-guide/conf.py b/Documentation/doc-guide/conf.py
deleted file mode 100644
index fd3731182d5a..000000000000
--- a/Documentation/doc-guide/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Documentation Guide'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'kernel-doc-guide.tex', 'Linux Kernel Documentation Guide',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/driver-api/80211/conf.py b/Documentation/driver-api/80211/conf.py
deleted file mode 100644
index 4424b4b0b9c3..000000000000
--- a/Documentation/driver-api/80211/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux 802.11 Driver Developer's Guide"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', '80211.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/driver-api/conf.py b/Documentation/driver-api/conf.py
deleted file mode 100644
index 202726d20088..000000000000
--- a/Documentation/driver-api/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "The Linux driver implementer's API guide"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'driver-api.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/driver-api/pm/conf.py b/Documentation/driver-api/pm/conf.py
deleted file mode 100644
index a89fac11272f..000000000000
--- a/Documentation/driver-api/pm/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Device Power Management"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'pm.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/filesystems/conf.py b/Documentation/filesystems/conf.py
deleted file mode 100644
index ea44172af5c4..000000000000
--- a/Documentation/filesystems/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux Filesystems API"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'filesystems.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/gpu/conf.py b/Documentation/gpu/conf.py
deleted file mode 100644
index 1757b040fb32..000000000000
--- a/Documentation/gpu/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux GPU Driver Developer's Guide"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'gpu.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/input/conf.py b/Documentation/input/conf.py
deleted file mode 100644
index d2352fdc92ed..000000000000
--- a/Documentation/input/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "The Linux input driver subsystem"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'linux-input.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/kernel-hacking/conf.py b/Documentation/kernel-hacking/conf.py
deleted file mode 100644
index 3d8acf0f33ad..000000000000
--- a/Documentation/kernel-hacking/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Kernel Hacking Guides"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'kernel-hacking.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/maintainer/conf.py b/Documentation/maintainer/conf.py
deleted file mode 100644
index 81e9eb7a7884..000000000000
--- a/Documentation/maintainer/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Development Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'maintainer.tex', 'Linux Kernel Development Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/media/conf.py b/Documentation/media/conf.py
deleted file mode 100644
index 1f194fcd2cae..000000000000
--- a/Documentation/media/conf.py
+++ /dev/null
@@ -1,12 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-# SPDX-License-Identifier: GPL-2.0
-
-project = 'Linux Media Subsystem Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'media.tex', 'Linux Media Subsystem Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/networking/conf.py b/Documentation/networking/conf.py
deleted file mode 100644
index 40f69e67a883..000000000000
--- a/Documentation/networking/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux Networking Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'networking.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/process/conf.py b/Documentation/process/conf.py
deleted file mode 100644
index 1b01a80ad9ce..000000000000
--- a/Documentation/process/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Development Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'process.tex', 'Linux Kernel Development Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/sh/conf.py b/Documentation/sh/conf.py
deleted file mode 100644
index 1eb684a13ac8..000000000000
--- a/Documentation/sh/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "SuperH architecture implementation manual"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'sh.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/sound/conf.py b/Documentation/sound/conf.py
deleted file mode 100644
index 3f1fc5e74e7b..000000000000
--- a/Documentation/sound/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux Sound Subsystem Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'sound.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/userspace-api/conf.py b/Documentation/userspace-api/conf.py
deleted file mode 100644
index 2eaf59f844e5..000000000000
--- a/Documentation/userspace-api/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "The Linux kernel user-space API guide"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'userspace-api.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/vm/conf.py b/Documentation/vm/conf.py
deleted file mode 100644
index 3b0b601af558..000000000000
--- a/Documentation/vm/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux Memory Management Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'memory-management.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/x86/conf.py b/Documentation/x86/conf.py
deleted file mode 100644
index 33c5c3142e20..000000000000
--- a/Documentation/x86/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "X86 architecture specific documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'x86.tex', project,
- 'The kernel development community', 'manual'),
-]
--
2.21.0
^ permalink raw reply related
* Re: [PATCH net-next v2 1/3] flow_offload: move tc indirect block to flow offload
From: Vlad Buslov @ 2019-07-26 11:43 UTC (permalink / raw)
To: wenxu@ucloud.cn
Cc: pablo@netfilter.org, fw@strlen.de,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <1564121869-3398-2-git-send-email-wenxu@ucloud.cn>
On Fri 26 Jul 2019 at 09:17, wenxu@ucloud.cn wrote:
> From: wenxu <wenxu@ucloud.cn>
>
> move tc indirect block to flow_offload and rename
> it to flow indirect block.The nf_tables can use the
> indr block architecture.
>
> Signed-off-by: wenxu <wenxu@ucloud.cn>
> ---
> v2: make use of flow_block from Pablo
> flow_indr_rhashtable_init advice by jakub.kicinski
>
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 10 +-
> .../net/ethernet/netronome/nfp/flower/offload.c | 10 +-
> include/net/flow_offload.h | 41 ++++
> include/net/pkt_cls.h | 35 ----
> include/net/sch_generic.h | 3 -
> net/core/flow_offload.c | 190 +++++++++++++++++
> net/sched/cls_api.c | 231 ++-------------------
> 7 files changed, 261 insertions(+), 259 deletions(-)
>
[...]
> +
> +int flow_indr_rhashtable_init(void)
> +{
> + static bool rhash_table_init;
> + int err = 0;
> +
> + if (rhash_table_init)
> + return 0;
> +
> + err = rhashtable_init(&indr_setup_block_ht,
> + &flow_indr_setup_block_ht_params);
> + if (err)
> + return err;
> +
> + rhash_table_init = true;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(flow_indr_rhashtable_init);
Shouldn't this be dedicated *_initcall function? That would remove the
necessity for rhash_table_init flag.
^ permalink raw reply
* Re: [PATCH v3 01/14] NFC: fix attrs checks in netlink interface
From: Andy Shevchenko @ 2019-07-26 11:44 UTC (permalink / raw)
To: Sedat Dilek
Cc: Clément Perrochaud, Charles Gorand, netdev, David S. Miller,
Andrey Konovalov
In-Reply-To: <1208463309.1019.1564131262506@ox.credativ.com>
On Fri, Jul 26, 2019 at 10:54:22AM +0200, Sedat Dilek wrote:
> [ Please CC me I am not subscribed to this ML ]
>
> Hi Andy,
>
> unfortunately, I did not found a cover-letter on netdev mailing-list.
> So, I am answering here.
>
> What are the changes v2->v3?
I combined my 11 patches with 1 from syzkaller team and 2 from you.
That's only the change for the series.
Administratively I resent it to have updated Cc list.
> Again, unfortunately I throw away all v2 out of my local linux Git repository.
> So, I could have looked at the diff myself.
It should be no changes in the code.
>
> Thanks for v3 upgrade!
>
> Regards,
> - Sedat -
>
> [1] https://marc.info/?a=131071969100005&r=1&w=2
>
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> hat am 25. Juli 2019 21:34 geschrieben:
> >
> >
> > From: Andrey Konovalov <andreyknvl@google.com>
> >
> > nfc_genl_deactivate_target() relies on the NFC_ATTR_TARGET_INDEX
> > attribute being present, but doesn't check whether it is actually
> > provided by the user. Same goes for nfc_genl_fw_download() and
> > NFC_ATTR_FIRMWARE_NAME.
> >
> > This patch adds appropriate checks.
> >
> > Found with syzkaller.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> > net/nfc/netlink.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
> > index 4a30309bb67f..60fd2748d0ea 100644
> > --- a/net/nfc/netlink.c
> > +++ b/net/nfc/netlink.c
> > @@ -970,7 +970,8 @@ static int nfc_genl_dep_link_down(struct sk_buff *skb, struct genl_info *info)
> > int rc;
> > u32 idx;
> >
> > - if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
> > + if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
> > + !info->attrs[NFC_ATTR_TARGET_INDEX])
> > return -EINVAL;
> >
> > idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
> > @@ -1018,7 +1019,8 @@ static int nfc_genl_llc_get_params(struct sk_buff *skb, struct genl_info *info)
> > struct sk_buff *msg = NULL;
> > u32 idx;
> >
> > - if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
> > + if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
> > + !info->attrs[NFC_ATTR_FIRMWARE_NAME])
> > return -EINVAL;
> >
> > idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
> > --
> > 2.20.1
>
>
> --
> Mit freundlichen Grüssen
> Sedat Dilek
> Telefon: +49 2166 9901-153
> E-Mail: sedat.dilek@credativ.de
> Internet: https://www.credativ.de/
>
> GPG-Fingerprint: EA6D E17D D269 AC7E 101D C910 476F 2B3B 0AF7 F86B
>
> credativ GmbH, Trompeterallee 108, 41189 Mönchengladbach
> Handelsregister: Amtsgericht Mönchengladbach HRB 12080 USt-ID-Nummer DE204566209
> Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
>
> Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen:
> https://www.credativ.de/datenschutz/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] net: ipv6: Fix a possible null-pointer dereference in ip6_xmit()
From: Willem de Bruijn @ 2019-07-26 11:44 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: David Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Network Development, linux-kernel
In-Reply-To: <20190726080307.4414-1-baijiaju1990@gmail.com>
On Fri, Jul 26, 2019 at 4:03 AM Jia-Ju Bai <baijiaju1990@gmail.com> wrote:
>
> In ip6_xmit(), there is an if statement on line 245 to check whether
> np is NULL:
> if (np)
>
> When np is NULL, it is used on line 251:
> ip6_autoflowlabel(net, np)
> if (!np->autoflowlabel_set)
>
> Thus, a possible null-pointer dereference may occur.
>
> To fix this bug, np is checked before calling
> ip6_autoflowlabel(net,np).
>
> This bug is found by a static analysis tool STCheck written by us.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> net/ipv6/ip6_output.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 8e49fd62eea9..07db5ab6e970 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -247,8 +247,10 @@ int ip6_xmit(const struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6,
> if (hlimit < 0)
> hlimit = ip6_dst_hoplimit(dst);
>
> - ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb, fl6->flowlabel,
> - ip6_autoflowlabel(net, np), fl6));
> + if (np) {
> + ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb, fl6->flowlabel,
> + ip6_autoflowlabel(net, np), fl6));
> + }
I don't know when np can be NULL in ip6_xmit. But if so, must still
setup the ipv6 header.
A more narrow change would be in ip6_autoflowlabel
- if (!np->autoflowlabel_set)
+ if (!np || !np->autoflowlabel_set)
^ permalink raw reply
* Re: [PATCH] can: ti_hecc: use timestamp based rx-offloading
From: Marc Kleine-Budde @ 2019-07-26 11:48 UTC (permalink / raw)
To: Jeroen Hofstee, linux-can@vger.kernel.org
Cc: Anant Gole, AnilKumar Ch, Wolfgang Grandegger, David S. Miller,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <1556539376-20932-1-git-send-email-jhofstee@victronenergy.com>
[-- Attachment #1.1: Type: text/plain, Size: 4699 bytes --]
On 4/29/19 2:03 PM, Jeroen Hofstee wrote:
> As already mentioned in [1] and included in [2], there is an off by one
> issue since the high bank is already enabled when the _next_ mailbox to
> be read has index 12, so the mailbox being read was 13. The message can
> therefore go into mailbox 31 and the driver will be repolled until the
> mailbox 12 eventually receives a msg. Or the message might end up in the
> 12th mailbox, but then it would become disabled after reading it and only
> be enabled again in the next "round" after mailbox 13 was read, which can
> cause out of order messages, since the lower priority mailboxes can
> accept messages in the meantime.
>
> As mentioned in [3] there is a hardware race condition when changing the
> CANME register while messages are being received. Even when including a
> busy poll on reception, like in [2] there are still overflows and out of
> order messages at times, but less then without the busy loop polling.
> Unlike what the patch suggests, the polling time is not in the microsecond
> range, but takes as long as a current CAN bus reception needs to finish,
> so typically more in the fraction of millisecond range. Since the timeout
> is in jiffies it won't timeout.
>
> Even with these additional fixes the driver is still not able to provide a
> proper FIFO which doesn't drop packages. So change the driver to use
> rx-offload and base order on timestamp instead of message box numbers. As
> a side affect, this also fixes [4] and [5].
>
> Before this change messages with a single byte counter were dropped /
> received out of order at a bitrate of 250kbit/s on an am3517. With this
> patch that no longer occurs up to and including 1Mbit/s.
>
> [1] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post6
> [2] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=02346892777f07245de4d5af692513ebd852dcb2
> [3] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post5
> [4] https://patchwork.ozlabs.org/patch/895956/
> [5] https://www.spinics.net/lists/netdev/msg494971.html
>
> Cc: Anant Gole <anantgole@ti.com>
> Cc: AnilKumar Ch <anilkumar@ti.com>
> Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
[...]
> @@ -744,8 +652,8 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
> struct net_device *ndev = (struct net_device *)dev_id;
> struct ti_hecc_priv *priv = netdev_priv(ndev);
> struct net_device_stats *stats = &ndev->stats;
> - u32 mbxno, mbx_mask, int_status, err_status;
> - unsigned long ack, flags;
> + u32 mbxno, mbx_mask, int_status, err_status, stamp;
> + unsigned long flags, rx_pending;
>
> int_status = hecc_read(priv,
> (priv->use_hecc1int) ? HECC_CANGIF1 : HECC_CANGIF0);
> @@ -769,11 +677,11 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
> spin_lock_irqsave(&priv->mbx_lock, flags);
> hecc_clear_bit(priv, HECC_CANME, mbx_mask);
> spin_unlock_irqrestore(&priv->mbx_lock, flags);
> - stats->tx_bytes += hecc_read_mbx(priv, mbxno,
> - HECC_CANMCF) & 0xF;
> + stamp = hecc_read_stamp(priv, mbxno);
> + stats->tx_bytes += can_rx_offload_get_echo_skb(&priv->offload,
> + mbxno, stamp);
> stats->tx_packets++;
> can_led_event(ndev, CAN_LED_EVENT_TX);
> - can_get_echo_skb(ndev, mbxno);
> --priv->tx_tail;
> }
>
> @@ -784,12 +692,11 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
> ((priv->tx_head & HECC_TX_MASK) == HECC_TX_MASK)))
> netif_wake_queue(ndev);
>
> - /* Disable RX mailbox interrupts and let NAPI reenable them */
> - if (hecc_read(priv, HECC_CANRMP)) {
> - ack = hecc_read(priv, HECC_CANMIM);
> - ack &= BIT(HECC_MAX_TX_MBOX) - 1;
> - hecc_write(priv, HECC_CANMIM, ack);
> - napi_schedule(&priv->napi);
> + /* offload RX mailboxes and let NAPI deliver them */
> + while ((rx_pending = hecc_read(priv, HECC_CANRMP))) {
> + can_rx_offload_irq_offload_timestamp(&priv->offload,
> + rx_pending);
> + hecc_write(priv, HECC_CANRMP, rx_pending);
Can prepare a patch to move the RMP writing into the mailbox_read()
function. This makes the mailbox available a bit earlier and works
better for memory pressure situations, where no skb can be allocated.
> }
> }
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] vhost: disable metadata prefetch optimization
From: Michael S. Tsirkin @ 2019-07-26 11:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason Wang, kvm, virtualization, netdev
This seems to cause guest and host memory corruption.
Disable for now until we get a better handle on that.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
I put this in linux-next, we'll re-enable if we can fix
the outstanding issues in a short order.
drivers/vhost/vhost.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 819296332913..42a8c2a13ab1 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -96,7 +96,7 @@ struct vhost_uaddr {
};
#if defined(CONFIG_MMU_NOTIFIER) && ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 0
-#define VHOST_ARCH_CAN_ACCEL_UACCESS 1
+#define VHOST_ARCH_CAN_ACCEL_UACCESS 0
#else
#define VHOST_ARCH_CAN_ACCEL_UACCESS 0
#endif
--
MST
^ permalink raw reply related
* Re: [PATCH] vhost: disable metadata prefetch optimization
From: Jason Wang @ 2019-07-26 11:57 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel; +Cc: kvm, virtualization, netdev
In-Reply-To: <20190726115021.7319-1-mst@redhat.com>
On 2019/7/26 下午7:51, Michael S. Tsirkin wrote:
> This seems to cause guest and host memory corruption.
> Disable for now until we get a better handle on that.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> I put this in linux-next, we'll re-enable if we can fix
> the outstanding issues in a short order.
Btw, is this more suitable to e.g revert the
842aa64eddacd23adc6ecdbc69cb2030bec47122 and let syzbot fuzz more on the
current code?
I think we won't accept that patch eventually, so I suspect what syzbot
reports today is a false positives.
Thanks
>
> drivers/vhost/vhost.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> index 819296332913..42a8c2a13ab1 100644
> --- a/drivers/vhost/vhost.h
> +++ b/drivers/vhost/vhost.h
> @@ -96,7 +96,7 @@ struct vhost_uaddr {
> };
>
> #if defined(CONFIG_MMU_NOTIFIER) && ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 0
> -#define VHOST_ARCH_CAN_ACCEL_UACCESS 1
> +#define VHOST_ARCH_CAN_ACCEL_UACCESS 0
> #else
> #define VHOST_ARCH_CAN_ACCEL_UACCESS 0
> #endif
^ permalink raw reply
* Re: [PATCH] net: bridge: Allow bridge to joing multicast groups
From: Horatiu Vultur @ 2019-07-26 12:02 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: roopa, davem, bridge, netdev, linux-kernel, allan.nielsen
In-Reply-To: <e6ad982f-4706-46f9-b8f0-1337b09de350@cumulusnetworks.com>
Hi Nikolay,
The 07/26/2019 12:26, Nikolay Aleksandrov wrote:
> External E-Mail
>
>
> On 26/07/2019 11:41, Nikolay Aleksandrov wrote:
> > On 25/07/2019 17:21, Horatiu Vultur wrote:
> >> Hi Nikolay,
> >>
> >> The 07/25/2019 16:21, Nikolay Aleksandrov wrote:
> >>> External E-Mail
> >>>
> >>>
> >>> On 25/07/2019 16:06, Nikolay Aleksandrov wrote:
> >>>> On 25/07/2019 14:44, Horatiu Vultur wrote:
> >>>>> There is no way to configure the bridge, to receive only specific link
> >>>>> layer multicast addresses. From the description of the command 'bridge
> >>>>> fdb append' is supposed to do that, but there was no way to notify the
> >>>>> network driver that the bridge joined a group, because LLADDR was added
> >>>>> to the unicast netdev_hw_addr_list.
> >>>>>
> >>>>> Therefore update fdb_add_entry to check if the NLM_F_APPEND flag is set
> >>>>> and if the source is NULL, which represent the bridge itself. Then add
> >>>>> address to multicast netdev_hw_addr_list for each bridge interfaces.
> >>>>> And then the .ndo_set_rx_mode function on the driver is called. To notify
> >>>>> the driver that the list of multicast mac addresses changed.
> >>>>>
> >>>>> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
> >>>>> ---
> >>>>> net/bridge/br_fdb.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++---
> >>>>> 1 file changed, 46 insertions(+), 3 deletions(-)
> >>>>>
> >>>>
> >>>> Hi,
> >>>> I'm sorry but this patch is wrong on many levels, some notes below. In general
> >>>> NLM_F_APPEND is only used in vxlan, the bridge does not handle that flag at all.
> >>>> FDB is only for *unicast*, nothing is joined and no multicast should be used with fdbs.
> >>>> MDB is used for multicast handling, but both of these are used for forwarding.
> >>>> The reason the static fdbs are added to the filter is for non-promisc ports, so they can
> >>>> receive traffic destined for these FDBs for forwarding.
> >>>> If you'd like to join any multicast group please use the standard way, if you'd like to join
> >>>> it only on a specific port - join it only on that port (or ports) and the bridge and you'll
> >>>
> >>> And obviously this is for the case where you're not enabling port promisc mode (non-default).
> >>> In general you'll only need to join the group on the bridge to receive traffic for it
> >>> or add it as an mdb entry to forward it.
> >>>
> >>>> have the effect that you're describing. What do you mean there's no way ?
> >>
> >> Thanks for the explanation.
> >> There are few things that are not 100% clear to me and maybe you can
> >> explain them, not to go totally in the wrong direction. Currently I am
> >> writing a network driver on which I added switchdev support. Then I was
> >> looking for a way to configure the network driver to copy link layer
> >> multicast address to the CPU port.
> >>
> >> If I am using bridge mdb I can do it only for IP multicast addreses,
> >> but how should I do it if I want non IP frames with link layer multicast
> >> address to be copy to CPU? For example: all frames with multicast
> >> address '01-21-6C-00-00-01' to be copy to CPU. What is the user space
> >> command for that?
> >>
> >
> > Check SIOCADDMULTI (ip maddr from iproute2), f.e. add that mac to the port
> > which needs to receive it and the bridge will send it up automatically since
> > it's unknown mcast (note that if there's a querier, you'll have to make the
> > bridge mcast router if it is not the querier itself). It would also flood it to all
>
> Actually you mentioned non-IP traffic, so the querier stuff is not a problem. This
> traffic will always be flooded by the bridge (and also a copy will be locally sent up).
> Thus only the flooding may need to be controlled.
OK, I see, but the part which is not clear to me is, which bridge
command(from iproute2) to use so the bridge would notify the network
driver(using swichdev or not) to configure the HW to copy all the frames
with dmac '01-21-6C-00-00-01' to CPU? So that the bridge can receive
those frames and then just to pass them up.
Definitly I would not like to set the front ports in promisc mode, to
copy all the frames to CPU because I think that would overkill it.
Thanks,
>
> > other ports so you may want to control that. It really depends on the setup
> > and the how the hardware is configured.
> >
> >>>>
> >>>> In addition you're allowing a mix of mcast functions to be called with unicast addresses
> >>>> and vice versa, it is not that big of a deal because the kernel will simply return an error
> >>>> but still makes no sense.
> >>>>
> >>>> Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> >>>>
> >>>>> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> >>>>> index b1d3248..d93746d 100644
> >>>>> --- a/net/bridge/br_fdb.c
> >>>>> +++ b/net/bridge/br_fdb.c
> >>>>> @@ -175,6 +175,29 @@ static void fdb_add_hw_addr(struct net_bridge *br, const unsigned char *addr)
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> +static void fdb_add_hw_maddr(struct net_bridge *br, const unsigned char *addr)
> >>>>> +{
> >>>>> + int err;
> >>>>> + struct net_bridge_port *p;
> >>>>> +
> >>>>> + ASSERT_RTNL();
> >>>>> +
> >>>>> + list_for_each_entry(p, &br->port_list, list) {
> >>>>> + if (!br_promisc_port(p)) {
> >>>>> + err = dev_mc_add(p->dev, addr);
> >>>>> + if (err)
> >>>>> + goto undo;
> >>>>> + }
> >>>>> + }
> >>>>> +
> >>>>> + return;
> >>>>> +undo:
> >>>>> + list_for_each_entry_continue_reverse(p, &br->port_list, list) {
> >>>>> + if (!br_promisc_port(p))
> >>>>> + dev_mc_del(p->dev, addr);
> >>>>> + }
> >>>>> +}
> >>>>> +
> >>>>> /* When a static FDB entry is deleted, the HW address from that entry is
> >>>>> * also removed from the bridge private HW address list and updates all
> >>>>> * the ports with needed information.
> >>>>> @@ -192,13 +215,27 @@ static void fdb_del_hw_addr(struct net_bridge *br, const unsigned char *addr)
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> +static void fdb_del_hw_maddr(struct net_bridge *br, const unsigned char *addr)
> >>>>> +{
> >>>>> + struct net_bridge_port *p;
> >>>>> +
> >>>>> + ASSERT_RTNL();
> >>>>> +
> >>>>> + list_for_each_entry(p, &br->port_list, list) {
> >>>>> + if (!br_promisc_port(p))
> >>>>> + dev_mc_del(p->dev, addr);
> >>>>> + }
> >>>>> +}
> >>>>> +
> >>>>> static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f,
> >>>>> bool swdev_notify)
> >>>>> {
> >>>>> trace_fdb_delete(br, f);
> >>>>>
> >>>>> - if (f->is_static)
> >>>>> + if (f->is_static) {
> >>>>> fdb_del_hw_addr(br, f->key.addr.addr);
> >>>>> + fdb_del_hw_maddr(br, f->key.addr.addr);
> >>>>
> >>>> Walking over all ports again for each static delete is a no-go.
> >>>>
> >>>>> + }
> >>>>>
> >>>>> hlist_del_init_rcu(&f->fdb_node);
> >>>>> rhashtable_remove_fast(&br->fdb_hash_tbl, &f->rhnode,
> >>>>> @@ -843,13 +880,19 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
> >>>>> fdb->is_local = 1;
> >>>>> if (!fdb->is_static) {
> >>>>> fdb->is_static = 1;
> >>>>> - fdb_add_hw_addr(br, addr);
> >>>>> + if (flags & NLM_F_APPEND && !source)
> >>>>> + fdb_add_hw_maddr(br, addr);
> >>>>> + else
> >>>>> + fdb_add_hw_addr(br, addr);
> >>>>> }
> >>>>> } else if (state & NUD_NOARP) {
> >>>>> fdb->is_local = 0;
> >>>>> if (!fdb->is_static) {
> >>>>> fdb->is_static = 1;
> >>>>> - fdb_add_hw_addr(br, addr);
> >>>>> + if (flags & NLM_F_APPEND && !source)
> >>>>> + fdb_add_hw_maddr(br, addr);
> >>>>> + else
> >>>>> + fdb_add_hw_addr(br, addr);
> >>>>> }
> >>>>> } else {
> >>>>> fdb->is_local = 0;
> >>>>>
> >>>>
> >>>
> >>
> >
>
--
/Horatiu
^ permalink raw reply
* Re: [PATCH] net/mlx5e: Fix zero table prio set by user.
From: Or Gerlitz @ 2019-07-26 12:19 UTC (permalink / raw)
To: Saeed Mahameed, wenxu@ucloud.cn
Cc: Roi Dayan, Mark Bloch, Paul Blakey, netdev@vger.kernel.org
In-Reply-To: <7b03d1fdda172ce99c3693d8403cbdaf5a31bb6c.camel@mellanox.com>
On Fri, Jul 26, 2019 at 12:24 AM Saeed Mahameed <saeedm@mellanox.com> wrote:
>
> On Thu, 2019-07-25 at 19:24 +0800, wenxu@ucloud.cn wrote:
> > From: wenxu <wenxu@ucloud.cn>
> >
> > The flow_cls_common_offload prio is zero
> >
> > It leads the invalid table prio in hw.
> >
> > Error: Could not process rule: Invalid argument
> >
> > kernel log:
> > mlx5_core 0000:81:00.0: E-Switch: Failed to create FDB Table err -22
> > (table prio: 65535, level: 0, size: 4194304)
> >
> > table_prio = (chain * FDB_MAX_PRIO) + prio - 1;
> > should check (chain * FDB_MAX_PRIO) + prio is not 0
> >
> > Signed-off-by: wenxu <wenxu@ucloud.cn>
> > ---
> > drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > index 089ae4d..64ca90f 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > @@ -970,7 +970,9 @@ static int esw_add_fdb_miss_rule(struct
>
> this piece of code isn't in this function, weird how it got to the
> diff, patch applies correctly though !
>
> > mlx5_eswitch *esw)
> > flags |= (MLX5_FLOW_TABLE_TUNNEL_EN_REFORMAT |
> > MLX5_FLOW_TABLE_TUNNEL_EN_DECAP);
> >
> > - table_prio = (chain * FDB_MAX_PRIO) + prio - 1;
> > + table_prio = (chain * FDB_MAX_PRIO) + prio;
> > + if (table_prio)
> > + table_prio = table_prio - 1;
> >
>
> This is black magic, even before this fix.
> this -1 seems to be needed in order to call
> create_next_size_table(table_prio) with the previous "table prio" ?
> (table_prio - 1) ?
>
> The whole thing looks wrong to me since when prio is 0 and chain is 0,
> there is not such thing table_prio - 1.
>
> mlnx eswitch guys in the cc, please advise.
basically, prio 0 is not something we ever get in the driver, since if
user space
specifies 0, the kernel generates some random non-zero prio, and we support
only prios 1-16 -- Wenxu -- what do you run to get this error?
>
> Thanks,
> Saeed.
>
> > /* create earlier levels for correct fs_core lookup when
> > * connecting tables
^ permalink raw reply
* Re: [PATCH] net: bridge: Allow bridge to joing multicast groups
From: Nikolay Aleksandrov @ 2019-07-26 12:31 UTC (permalink / raw)
To: Horatiu Vultur; +Cc: roopa, davem, bridge, netdev, linux-kernel, allan.nielsen
In-Reply-To: <20190726120214.c26oj5vks7g5ntwu@soft-dev3.microsemi.net>
On 26/07/2019 15:02, Horatiu Vultur wrote:
> Hi Nikolay,
>
> The 07/26/2019 12:26, Nikolay Aleksandrov wrote:
>> External E-Mail
>>
>>
>> On 26/07/2019 11:41, Nikolay Aleksandrov wrote:
>>> On 25/07/2019 17:21, Horatiu Vultur wrote:
>>>> Hi Nikolay,
>>>>
>>>> The 07/25/2019 16:21, Nikolay Aleksandrov wrote:
>>>>> External E-Mail
>>>>>
>>>>>
>>>>> On 25/07/2019 16:06, Nikolay Aleksandrov wrote:
>>>>>> On 25/07/2019 14:44, Horatiu Vultur wrote:
>>>>>>> There is no way to configure the bridge, to receive only specific link
>>>>>>> layer multicast addresses. From the description of the command 'bridge
>>>>>>> fdb append' is supposed to do that, but there was no way to notify the
>>>>>>> network driver that the bridge joined a group, because LLADDR was added
>>>>>>> to the unicast netdev_hw_addr_list.
>>>>>>>
>>>>>>> Therefore update fdb_add_entry to check if the NLM_F_APPEND flag is set
>>>>>>> and if the source is NULL, which represent the bridge itself. Then add
>>>>>>> address to multicast netdev_hw_addr_list for each bridge interfaces.
>>>>>>> And then the .ndo_set_rx_mode function on the driver is called. To notify
>>>>>>> the driver that the list of multicast mac addresses changed.
>>>>>>>
>>>>>>> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
>>>>>>> ---
>>>>>>> net/bridge/br_fdb.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++---
>>>>>>> 1 file changed, 46 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>> I'm sorry but this patch is wrong on many levels, some notes below. In general
>>>>>> NLM_F_APPEND is only used in vxlan, the bridge does not handle that flag at all.
>>>>>> FDB is only for *unicast*, nothing is joined and no multicast should be used with fdbs.
>>>>>> MDB is used for multicast handling, but both of these are used for forwarding.
>>>>>> The reason the static fdbs are added to the filter is for non-promisc ports, so they can
>>>>>> receive traffic destined for these FDBs for forwarding.
>>>>>> If you'd like to join any multicast group please use the standard way, if you'd like to join
>>>>>> it only on a specific port - join it only on that port (or ports) and the bridge and you'll
>>>>>
>>>>> And obviously this is for the case where you're not enabling port promisc mode (non-default).
>>>>> In general you'll only need to join the group on the bridge to receive traffic for it
>>>>> or add it as an mdb entry to forward it.
>>>>>
>>>>>> have the effect that you're describing. What do you mean there's no way ?
>>>>
>>>> Thanks for the explanation.
>>>> There are few things that are not 100% clear to me and maybe you can
>>>> explain them, not to go totally in the wrong direction. Currently I am
>>>> writing a network driver on which I added switchdev support. Then I was
>>>> looking for a way to configure the network driver to copy link layer
>>>> multicast address to the CPU port.
>>>>
>>>> If I am using bridge mdb I can do it only for IP multicast addreses,
>>>> but how should I do it if I want non IP frames with link layer multicast
>>>> address to be copy to CPU? For example: all frames with multicast
>>>> address '01-21-6C-00-00-01' to be copy to CPU. What is the user space
>>>> command for that?
>>>>
>>>
>>> Check SIOCADDMULTI (ip maddr from iproute2), f.e. add that mac to the port
>>> which needs to receive it and the bridge will send it up automatically since
>>> it's unknown mcast (note that if there's a querier, you'll have to make the
>>> bridge mcast router if it is not the querier itself). It would also flood it to all
>>
>> Actually you mentioned non-IP traffic, so the querier stuff is not a problem. This
>> traffic will always be flooded by the bridge (and also a copy will be locally sent up).
>> Thus only the flooding may need to be controlled.
>
> OK, I see, but the part which is not clear to me is, which bridge
> command(from iproute2) to use so the bridge would notify the network
> driver(using swichdev or not) to configure the HW to copy all the frames
> with dmac '01-21-6C-00-00-01' to CPU? So that the bridge can receive
> those frames and then just to pass them up.
> Definitly I would not like to set the front ports in promisc mode, to
> copy all the frames to CPU because I think that would overkill it.
> Thanks,
>
For non-IP traffic there's no such command, if it was IP you could catch
switchdev mdb notifications, but just for a mac address you'll have to configure
the port yourself, e.g. via the ip maddr command if you don't want to put it in
promisc mode. You know that in order to not run in promisc mode you'll have to disable
port flooding and port learning, right ? Otherwise they're always put in promisc.
If you do that you could do a simple hack in your driver with the current situation:
$ bridge fdb add 01:21:6C:00:00:01 dev swpX master static
If swpX is not promisc you'll get dev_uc_add() which will call __dev_set_rx_mode()
and the notifier so you can catch that address being added to the device, traffic
for that mac will *not* be forwarded to swpX later because it's considered multicast
and unknown at that so it will be flooded to all who have the FLOOD flag and will be
sent up the bridge as well.
But this is very hacky, I'd prefer the ip maddr add command on the port where you wish
to receive that traffic, the bridge will pass it up always due to it being unknown.
>>
>>> other ports so you may want to control that. It really depends on the setup
>>> and the how the hardware is configured.
>>>
>>>>>>
>>>>>> In addition you're allowing a mix of mcast functions to be called with unicast addresses
>>>>>> and vice versa, it is not that big of a deal because the kernel will simply return an error
>>>>>> but still makes no sense.
>>>>>>
>>>>>> Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>>>>>>
>>>>>>> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
>>>>>>> index b1d3248..d93746d 100644
>>>>>>> --- a/net/bridge/br_fdb.c
>>>>>>> +++ b/net/bridge/br_fdb.c
>>>>>>> @@ -175,6 +175,29 @@ static void fdb_add_hw_addr(struct net_bridge *br, const unsigned char *addr)
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> +static void fdb_add_hw_maddr(struct net_bridge *br, const unsigned char *addr)
>>>>>>> +{
>>>>>>> + int err;
>>>>>>> + struct net_bridge_port *p;
>>>>>>> +
>>>>>>> + ASSERT_RTNL();
>>>>>>> +
>>>>>>> + list_for_each_entry(p, &br->port_list, list) {
>>>>>>> + if (!br_promisc_port(p)) {
>>>>>>> + err = dev_mc_add(p->dev, addr);
>>>>>>> + if (err)
>>>>>>> + goto undo;
>>>>>>> + }
>>>>>>> + }
>>>>>>> +
>>>>>>> + return;
>>>>>>> +undo:
>>>>>>> + list_for_each_entry_continue_reverse(p, &br->port_list, list) {
>>>>>>> + if (!br_promisc_port(p))
>>>>>>> + dev_mc_del(p->dev, addr);
>>>>>>> + }
>>>>>>> +}
>>>>>>> +
>>>>>>> /* When a static FDB entry is deleted, the HW address from that entry is
>>>>>>> * also removed from the bridge private HW address list and updates all
>>>>>>> * the ports with needed information.
>>>>>>> @@ -192,13 +215,27 @@ static void fdb_del_hw_addr(struct net_bridge *br, const unsigned char *addr)
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> +static void fdb_del_hw_maddr(struct net_bridge *br, const unsigned char *addr)
>>>>>>> +{
>>>>>>> + struct net_bridge_port *p;
>>>>>>> +
>>>>>>> + ASSERT_RTNL();
>>>>>>> +
>>>>>>> + list_for_each_entry(p, &br->port_list, list) {
>>>>>>> + if (!br_promisc_port(p))
>>>>>>> + dev_mc_del(p->dev, addr);
>>>>>>> + }
>>>>>>> +}
>>>>>>> +
>>>>>>> static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f,
>>>>>>> bool swdev_notify)
>>>>>>> {
>>>>>>> trace_fdb_delete(br, f);
>>>>>>>
>>>>>>> - if (f->is_static)
>>>>>>> + if (f->is_static) {
>>>>>>> fdb_del_hw_addr(br, f->key.addr.addr);
>>>>>>> + fdb_del_hw_maddr(br, f->key.addr.addr);
>>>>>>
>>>>>> Walking over all ports again for each static delete is a no-go.
>>>>>>
>>>>>>> + }
>>>>>>>
>>>>>>> hlist_del_init_rcu(&f->fdb_node);
>>>>>>> rhashtable_remove_fast(&br->fdb_hash_tbl, &f->rhnode,
>>>>>>> @@ -843,13 +880,19 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
>>>>>>> fdb->is_local = 1;
>>>>>>> if (!fdb->is_static) {
>>>>>>> fdb->is_static = 1;
>>>>>>> - fdb_add_hw_addr(br, addr);
>>>>>>> + if (flags & NLM_F_APPEND && !source)
>>>>>>> + fdb_add_hw_maddr(br, addr);
>>>>>>> + else
>>>>>>> + fdb_add_hw_addr(br, addr);
>>>>>>> }
>>>>>>> } else if (state & NUD_NOARP) {
>>>>>>> fdb->is_local = 0;
>>>>>>> if (!fdb->is_static) {
>>>>>>> fdb->is_static = 1;
>>>>>>> - fdb_add_hw_addr(br, addr);
>>>>>>> + if (flags & NLM_F_APPEND && !source)
>>>>>>> + fdb_add_hw_maddr(br, addr);
>>>>>>> + else
>>>>>>> + fdb_add_hw_addr(br, addr);
>>>>>>> }
>>>>>>> } else {
>>>>>>> fdb->is_local = 0;
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH] crypto: user - make NETLINK_CRYPTO work inside netns
From: Herbert Xu @ 2019-07-26 12:32 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: linux-crypto, netdev, davem, smueller, steffen.klassert, dzickus
In-Reply-To: <20190709111124.31127-1-omosnace@redhat.com>
Ondrej Mosnacek <omosnace@redhat.com> wrote:
> Currently, NETLINK_CRYPTO works only in the init network namespace. It
> doesn't make much sense to cut it out of the other network namespaces,
> so do the minor plumbing work necessary to make it work in any network
> namespace. Code inspired by net/core/sock_diag.c.
>
> Tested using kcapi-dgst from libkcapi [1]:
> Before:
> # unshare -n kcapi-dgst -c sha256 </dev/null | wc -c
> libkcapi - Error: Netlink error: sendmsg failed
> libkcapi - Error: Netlink error: sendmsg failed
> libkcapi - Error: NETLINK_CRYPTO: cannot obtain cipher information for hmac(sha512) (is required crypto_user.c patch missing? see documentation)
> 0
>
> After:
> # unshare -n kcapi-dgst -c sha256 </dev/null | wc -c
> 32
>
> [1] https://github.com/smuellerDD/libkcapi
>
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> ---
> crypto/crypto_user_base.c | 37 +++++++++++++++++++---------
> crypto/crypto_user_stat.c | 4 ++-
> include/crypto/internal/cryptouser.h | 2 --
> include/net/net_namespace.h | 3 +++
> 4 files changed, 31 insertions(+), 15 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net/mlx5e: Fix zero table prio set by user.
From: wenxu @ 2019-07-26 12:39 UTC (permalink / raw)
To: Or Gerlitz, Saeed Mahameed
Cc: Roi Dayan, Mark Bloch, Paul Blakey, netdev@vger.kernel.org
In-Reply-To: <CAJ3xEMi65JcF97nHeE482xgkps0GLLso+b6hp=34uX+wF=BjiQ@mail.gmail.com>
在 2019/7/26 20:19, Or Gerlitz 写道:
> On Fri, Jul 26, 2019 at 12:24 AM Saeed Mahameed <saeedm@mellanox.com> wrote:
>> On Thu, 2019-07-25 at 19:24 +0800, wenxu@ucloud.cn wrote:
>>> From: wenxu <wenxu@ucloud.cn>
>>>
>>> The flow_cls_common_offload prio is zero
>>>
>>> It leads the invalid table prio in hw.
>>>
>>> Error: Could not process rule: Invalid argument
>>>
>>> kernel log:
>>> mlx5_core 0000:81:00.0: E-Switch: Failed to create FDB Table err -22
>>> (table prio: 65535, level: 0, size: 4194304)
>>>
>>> table_prio = (chain * FDB_MAX_PRIO) + prio - 1;
>>> should check (chain * FDB_MAX_PRIO) + prio is not 0
>>>
>>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>>> ---
>>> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git
>>> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
>>> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
>>> index 089ae4d..64ca90f 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
>>> @@ -970,7 +970,9 @@ static int esw_add_fdb_miss_rule(struct
>> this piece of code isn't in this function, weird how it got to the
>> diff, patch applies correctly though !
>>
>>> mlx5_eswitch *esw)
>>> flags |= (MLX5_FLOW_TABLE_TUNNEL_EN_REFORMAT |
>>> MLX5_FLOW_TABLE_TUNNEL_EN_DECAP);
>>>
>>> - table_prio = (chain * FDB_MAX_PRIO) + prio - 1;
>>> + table_prio = (chain * FDB_MAX_PRIO) + prio;
>>> + if (table_prio)
>>> + table_prio = table_prio - 1;
>>>
>> This is black magic, even before this fix.
>> this -1 seems to be needed in order to call
>> create_next_size_table(table_prio) with the previous "table prio" ?
>> (table_prio - 1) ?
>>
>> The whole thing looks wrong to me since when prio is 0 and chain is 0,
>> there is not such thing table_prio - 1.
>>
>> mlnx eswitch guys in the cc, please advise.
> basically, prio 0 is not something we ever get in the driver, since if
> user space
> specifies 0, the kernel generates some random non-zero prio, and we support
> only prios 1-16 -- Wenxu -- what do you run to get this error?
>
>
I run offload with nfatbles(but not tc), there is no prio for each rule.
prio of flow_cls_common_offload init as 0.
static void nft_flow_offload_common_init(struct flow_cls_common_offload *common,
__be16 proto,
struct netlink_ext_ack *extack)
{
common->protocol = proto;
common->extack = extack;
}
flow_cls_common_offload
^ permalink raw reply
* Re: [PATCH net] mvpp2: refactor MTU change code
From: Antoine Tenart @ 2019-07-26 12:50 UTC (permalink / raw)
To: Matteo Croce
Cc: netdev, Antoine Tenart, Maxime Chevallier, Marcin Wojtas,
Stefan Chulski, LKML
In-Reply-To: <20190725231931.24073-1-mcroce@redhat.com>
Hi Matteo,
On Fri, Jul 26, 2019 at 01:19:31AM +0200, Matteo Croce wrote:
> The MTU change code can call napi_disable() with the device already down,
> leading to a deadlock. Also, lot of code is duplicated unnecessarily.
>
> Rework mvpp2_change_mtu() to avoid the deadlock and remove duplicated code.
>
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
As this is a fix sent to net, you could add a Fixes: tag.
Otherwise this looks good,
Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
Thanks!
Antoine
> ---
> .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 41 ++++++-------------
> 1 file changed, 13 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 2f7286bd203b..60eb98f99571 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -3612,6 +3612,7 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
> static int mvpp2_change_mtu(struct net_device *dev, int mtu)
> {
> struct mvpp2_port *port = netdev_priv(dev);
> + bool running = netif_running(dev);
> int err;
>
> if (!IS_ALIGNED(MVPP2_RX_PKT_SIZE(mtu), 8)) {
> @@ -3620,40 +3621,24 @@ static int mvpp2_change_mtu(struct net_device *dev, int mtu)
> mtu = ALIGN(MVPP2_RX_PKT_SIZE(mtu), 8);
> }
>
> - if (!netif_running(dev)) {
> - err = mvpp2_bm_update_mtu(dev, mtu);
> - if (!err) {
> - port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
> - return 0;
> - }
> -
> - /* Reconfigure BM to the original MTU */
> - err = mvpp2_bm_update_mtu(dev, dev->mtu);
> - if (err)
> - goto log_error;
> - }
> -
> - mvpp2_stop_dev(port);
> + if (running)
> + mvpp2_stop_dev(port);
>
> err = mvpp2_bm_update_mtu(dev, mtu);
> - if (!err) {
> + if (err) {
> + netdev_err(dev, "failed to change MTU\n");
> + /* Reconfigure BM to the original MTU */
> + mvpp2_bm_update_mtu(dev, dev->mtu);
> + } else {
> port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
> - goto out_start;
> }
>
> - /* Reconfigure BM to the original MTU */
> - err = mvpp2_bm_update_mtu(dev, dev->mtu);
> - if (err)
> - goto log_error;
> -
> -out_start:
> - mvpp2_start_dev(port);
> - mvpp2_egress_enable(port);
> - mvpp2_ingress_enable(port);
> + if (running) {
> + mvpp2_start_dev(port);
> + mvpp2_egress_enable(port);
> + mvpp2_ingress_enable(port);
> + }
>
> - return 0;
> -log_error:
> - netdev_err(dev, "failed to change MTU\n");
> return err;
> }
>
> --
> 2.21.0
>
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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