* Re: [PATCH v3 0/6] stmmac: pci: Refactor DMI probing
From: David Miller @ 2017-05-31 16:32 UTC (permalink / raw)
To: andy.shevchenko
Cc: jan.kiszka, peppe.cavallaro, alexandre.torgue, netdev,
linux-kernel
In-Reply-To: <CAHp75VcGNr78mfGgtrKuZJtLppv=rAJ4Bxejcec3MhnC6ejSjQ@mail.gmail.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Tue, 30 May 2017 21:48:05 +0300
> On Tue, May 30, 2017 at 10:33 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> Some cleanups of the way we probe DMI platforms in the driver. Reduces
>> a bit of open-coding and makes the logic easier reusable for any
>> potential DMI platform != Quark.
>>
>> Tested on IOT2000 and Galileo Gen2.
>
> So, for patches 1-4,
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> I'm not convinced that patch 6 is needed, so, my vote is not to include it.
>
> Patch 5 I would like to review later. Main problem to me is {-1, -1}.
> It looks non-standard and feels not good. I'll try to think on the
> solution.
Ok, so at a minimum I'm expecting another respin of this.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: dsa: mv88e6xxx: PHY nitpicks
From: David Miller @ 2017-05-31 16:35 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170526220307.23503-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Fri, 26 May 2017 18:03:04 -0400
> This patchset isolates more PPU code into phy.c and makes distinction
> between PHY Registers read and write implementations vs. generic PHY
> routines.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: remove dev arg of dsa_register_switch
From: David Miller @ 2017-05-31 16:36 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170526221251.14972-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Fri, 26 May 2017 18:12:51 -0400
> The current dsa_register_switch function takes a useless struct device
> pointer argument, which always equals ds->dev.
>
> Drivers either call it with ds->dev, or with the same device pointer
> passed to dsa_switch_alloc, which ends up being assigned to ds->dev.
>
> This patch removes the second argument of the dsa_register_switch and
> _dsa_register_switch functions.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Those invariants seem to hold indeed, so this looks fine, applied.
^ permalink raw reply
* Re: [PATCH v2] net: fec: add post PHY reset delay DT property
From: Rob Herring @ 2017-05-31 16:44 UTC (permalink / raw)
To: Quentin Schulz
Cc: fugang.duan-3arQi8VN3Tc, mark.rutland-5wv7dgnIgG8,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20170523094808.11102-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, May 23, 2017 at 11:48:08AM +0200, Quentin Schulz wrote:
> Some PHY require to wait for a bit after the reset GPIO has been
> toggled. This adds support for the DT property `phy-reset-post-delay`
> which gives the delay in milliseconds to wait after reset.
>
> If the DT property is not given, no delay is observed. Post reset delay
> greater than 1000ms are invalid.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> v2:
> - return -EINVAL when phy-reset-post-delay is greater than 1000ms
> instead of defaulting to 1ms,
> - remove `default to 1ms` when phy-reset-post-delay > 1000Ms from DT
> binding doc and commit log,
> - move phy-reset-post-delay property reading before
> devm_gpio_request_one(),
>
> Documentation/devicetree/bindings/net/fsl-fec.txt | 4 ++++
> drivers/net/ethernet/freescale/fec_main.c | 16 +++++++++++++++-
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
> index a1e3693cca16..6f55bdd52f8a 100644
> --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
> +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
> @@ -15,6 +15,10 @@ Optional properties:
> - phy-reset-active-high : If present then the reset sequence using the GPIO
> specified in the "phy-reset-gpios" property is reversed (H=reset state,
> L=operation state).
> +- phy-reset-post-delay : Post reset delay in milliseconds. If present then
This needs unit suffix minimally. It should also have a vendor prefix or
be made generic.
But really, this is a property of the phy and should be in the phy node
as should phy-reset-gpios, phy-reset-active-high, phy-supply, etc.
> + a delay of phy-reset-post-delay milliseconds will be observed after the
> + phy-reset-gpios has been toggled. Can be omitted thus no delay is
> + observed. Delay is in range of 1ms to 1000ms. Other delays are invalid.
> - phy-supply : regulator that powers the Ethernet PHY.
> - phy-handle : phandle to the PHY device connected to this device.
> - fixed-link : Assume a fixed link. See fixed-link.txt in the same directory.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: net/ipv6: use-after-free in ip6_dst_ifdown
From: Cong Wang @ 2017-05-31 16:45 UTC (permalink / raw)
To: Andrey Konovalov
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Eric Dumazet,
David Ahern, Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <CAAeHK+wBQgfW_mRjmP-rScMtvUfs61iCzCHn1SmkdnLGNyRm0A@mail.gmail.com>
On Wed, May 31, 2017 at 2:42 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).
>
> Unfortunately it's not reproducible.
>
> ==================================================================
> BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
> Read of size 8 at addr ffff88006afa4ad8 by task syz-executor6/23554
This one is very interesting.
Here we are at:
if (dev != loopback_dev) {
if (idev && idev->dev == dev) {
struct inet6_dev *loopback_idev =
in6_dev_get(loopback_dev);
if (loopback_idev) {
rt->rt6i_idev = loopback_idev;
in6_dev_put(idev);
}
}
}
clearly no skb involved, it looks like idev is the one used-after-free.
But below it is actually skb which is allocated and freed...
>
> CPU: 3 PID: 23554 Comm: syz-executor6 Not tainted 4.12.0-rc3+ #370
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16 [inline]
> dump_stack+0x292/0x395 lib/dump_stack.c:52
> print_address_description+0x73/0x280 mm/kasan/report.c:252
> kasan_report_error mm/kasan/report.c:351 [inline]
> kasan_report+0x22b/0x340 mm/kasan/report.c:408
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
> ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
> dst_ifdown+0x75/0x230 net/core/dst.c:439
> dst_dev_event+0xb1/0x230 net/core/dst.c:466
> notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93
> __raw_notifier_call_chain kernel/notifier.c:394 [inline]
> raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
> call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649
> call_netdevice_notifiers net/core/dev.c:1665 [inline]
> __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640
> dev_change_flags+0xf5/0x140 net/core/dev.c:6671
> dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254
> dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532
> sock_do_ioctl+0x94/0xb0 net/socket.c:913
> sock_ioctl+0x28f/0x440 net/socket.c:1004
> vfs_ioctl fs/ioctl.c:45 [inline]
> do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685
> SYSC_ioctl fs/ioctl.c:700 [inline]
> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
> entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x446179
> RSP: 002b:00007fd1da4bdc08 EFLAGS: 00000282 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000003220 RCX: 0000000000446179
> RDX: 0000000020d34000 RSI: 0000000000008914 RDI: 0000000000000005
> RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000282 R12: 0000000000000005
> R13: 0000000000000390 R14: 00000000006e1450 R15: 0000000000000000
>
> Allocated by task 23235:
> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
> set_track mm/kasan/kasan.c:525 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
> slab_post_alloc_hook mm/slab.h:456 [inline]
> slab_alloc_node mm/slub.c:2718 [inline]
> __kmalloc_node_track_caller+0x20d/0x350 mm/slub.c:4303
> __kmalloc_reserve.isra.32+0x41/0xd0 net/core/skbuff.c:138
> __alloc_skb+0x157/0x770 net/core/skbuff.c:231
> alloc_skb include/linux/skbuff.h:936 [inline]
> alloc_skb_with_frags+0x12e/0x780 net/core/skbuff.c:4690
> sock_alloc_send_pskb+0x804/0xa30 net/core/sock.c:2000
> tun_alloc_skb drivers/net/tun.c:1144 [inline]
> tun_get_user+0x91a/0x2e10 drivers/net/tun.c:1274
> tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
> call_write_iter include/linux/fs.h:1734 [inline]
> new_sync_write fs/read_write.c:497 [inline]
> __vfs_write+0x483/0x760 fs/read_write.c:510
> vfs_write+0x187/0x500 fs/read_write.c:558
> SYSC_write fs/read_write.c:605 [inline]
> SyS_write+0xfb/0x230 fs/read_write.c:597
> entry_SYSCALL_64_fastpath+0x1f/0xbe
>
> Freed by task 23235:
> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
> set_track mm/kasan/kasan.c:525 [inline]
> kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
> slab_free_hook mm/slub.c:1357 [inline]
> slab_free_freelist_hook mm/slub.c:1379 [inline]
> slab_free mm/slub.c:2961 [inline]
> kfree+0xe8/0x2b0 mm/slub.c:3882
> skb_free_head+0x74/0xb0 net/core/skbuff.c:579
> skb_release_data+0x3ce/0x4a0 net/core/skbuff.c:610
> skb_release_all+0x4a/0x60 net/core/skbuff.c:669
> __kfree_skb+0x15/0x20 net/core/skbuff.c:683
> kfree_skb+0x16e/0x4e0 net/core/skbuff.c:704
> llc_rcv+0x5c7/0xed0 net/llc/llc_input.c:214
> __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4216
> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4254
> netif_receive_skb_internal+0x240/0x1b20 net/core/dev.c:4416
> netif_receive_skb+0xae/0x3b0 net/core/dev.c:4440
> tun_rx_batched.isra.40+0x5e5/0x8c0 drivers/net/tun.c:1167
> tun_get_user+0x100d/0x2e10 drivers/net/tun.c:1339
> tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
> call_write_iter include/linux/fs.h:1734 [inline]
> new_sync_write fs/read_write.c:497 [inline]
> __vfs_write+0x483/0x760 fs/read_write.c:510
> vfs_write+0x187/0x500 fs/read_write.c:558
> SYSC_write fs/read_write.c:605 [inline]
> SyS_write+0xfb/0x230 fs/read_write.c:597
> entry_SYSCALL_64_fastpath+0x1f/0xbe
>
> The buggy address belongs to the object at ffff88006afa4ad8
> which belongs to the cache kmalloc-1024 of size 1024
> The buggy address is located 0 bytes inside of
> 1024-byte region [ffff88006afa4ad8, ffff88006afa4ed8)
> The buggy address belongs to the page:
> page:ffffea0001abe800 count:1 mapcount:0 mapping: (null)
> index:0x0 compound_mapcount: 0
> flags: 0x500000000008100(slab|head)
> raw: 0500000000008100 0000000000000000 0000000000000000 0000000100170017
> raw: ffffea00017ef420 ffffea0001aaa420 ffff88003e80efc0 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88006afa4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88006afa4a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>ffff88006afa4a80: fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb
> ^
> ffff88006afa4b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88006afa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
^ permalink raw reply
* Re: [PATCH net-next 0/3] udp: reduce cache pressure
From: David Miller @ 2017-05-31 16:47 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet
In-Reply-To: <cover.1496070490.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Mon, 29 May 2017 17:27:22 +0200
> In the most common use case, many skb fields are not used by recvmsg(), and
> the few ones actually accessed lays on cold cachelines, which leads to several
> cache miss per packet.
>
> This patch series attempts to reduce such misses with different strategies:
> * caching the interesting fields in the scratched space
> * avoid accessing at all uninteresting fields
> * prefetching
>
> Tested using the udp_sink program by Jesper[1] as the receiver, an h/w l4 rx
> hash on the ingress nic, so that the number of ingress nic rx queues hit by the
> udp traffic could be controlled via ethtool -L.
>
> The udp_sink program was bound to the first idle cpu, to get more
> stable numbers.
>
> On a single numa node receiver:
>
> nic rx queues vanilla patched kernel delta
> 1 1850 kpps 1850 kpps 0%
> 2 2370 kpps 2700 kpps 13.9%
> 16 2000 kpps 2220 kpps 11%
>
> [1] https://github.com/netoptimizer/network-testing/blob/master/src/udp_sink.c
Eric can you give this a quick review when you get a chance?
Thanks.
^ permalink raw reply
* [PATCH net-next] liquidio: VF interrupt initialization cleanup
From: Felix Manlunas @ 2017-05-31 16:48 UTC (permalink / raw)
To: davem
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
ricardo.farrington
From: Rick Farrington <ricardo.farrington@cavium.com>
Set initialization state variable to (reflect interrupt initialization) at
correct time (immediately after having configured interrupts). This fixes
problem of inconsistent IRQ allocation in case of [obscure] failure when
negotiating with PF driver during init.
Clean-up of interrupt enablement during initialization & avoid potential
race condition with chip-specific code (i.e. perform interrupt control in
main driver module). Added explanatory comments regarding interrupt
enablement.
Signed-off-by: Rick Farrington <ricardo.farrington@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
---
.../net/ethernet/cavium/liquidio/cn23xx_vf_device.c | 10 ----------
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 19 +++++++++++++++++--
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
index b6117b6..20f3d2a 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
@@ -431,11 +431,6 @@ int cn23xx_octeon_pfvf_handshake(struct octeon_device *oct)
mbox_cmd.fn = (octeon_mbox_callback_t)octeon_pfvf_hs_callback;
mbox_cmd.fn_arg = &status;
- /* Interrupts are not enabled at this point.
- * Enable them with default oq ticks
- */
- oct->fn_list.enable_interrupt(oct, OCTEON_ALL_INTR);
-
octeon_mbox_write(oct, &mbox_cmd);
atomic_set(&status, 0);
@@ -444,11 +439,6 @@ int cn23xx_octeon_pfvf_handshake(struct octeon_device *oct)
schedule_timeout_uninterruptible(1);
} while ((!atomic_read(&status)) && (count++ < 100000));
- /* Disable the interrupt so that the interrupsts will be reenabled
- * with the oq ticks received from the PF
- */
- oct->fn_list.disable_interrupt(oct, OCTEON_ALL_INTR);
-
ret = atomic_read(&status);
if (!ret) {
dev_err(&oct->pci_dev->dev, "octeon_pfvf_handshake timeout\n");
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
index 31d737c..0712409 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
@@ -3188,13 +3188,28 @@ static int octeon_device_init(struct octeon_device *oct)
if (octeon_setup_interrupt(oct))
return 1;
+ atomic_set(&oct->status, OCT_DEV_INTR_SET_DONE);
+
+ /* ***************************************************************
+ * The interrupts need to be enabled for the PF<-->VF handshake.
+ * They are [re]-enabled after the PF<-->VF handshake so that the
+ * correct OQ tick value is used (i.e. the value retrieved from
+ * the PF as part of the handshake).
+ */
+
+ /* Enable Octeon device interrupts */
+ oct->fn_list.enable_interrupt(oct, OCTEON_ALL_INTR);
+
if (cn23xx_octeon_pfvf_handshake(oct))
return 1;
+ /* Here we [re]-enable the interrupts so that the correct OQ tick value
+ * is used (i.e. the value that was retrieved during the handshake)
+ */
+
/* Enable Octeon device interrupts */
oct->fn_list.enable_interrupt(oct, OCTEON_ALL_INTR);
-
- atomic_set(&oct->status, OCT_DEV_INTR_SET_DONE);
+ /* *************************************************************** */
/* Enable the input and output queues for this Octeon device */
if (oct->fn_list.enable_io_queues(oct)) {
^ permalink raw reply related
* Re: [PATCH net-next 0/3] udp: reduce cache pressure
From: Eric Dumazet @ 2017-05-31 16:52 UTC (permalink / raw)
To: David Miller; +Cc: Paolo Abeni, netdev
In-Reply-To: <20170531.124734.427032219057695744.davem@davemloft.net>
On Wed, May 31, 2017 at 9:47 AM, David Miller <davem@davemloft.net> wrote:
>
> Eric can you give this a quick review when you get a chance?
Sure, will do in a few minutes. Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/mlxfw: select CONFIG_XZ_DEC
From: David Miller @ 2017-05-31 16:53 UTC (permalink / raw)
To: arnd; +Cc: yotamg, idosch, jiri, netdev, linux-kernel
In-Reply-To: <20170530092628.1306028-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 30 May 2017 11:26:14 +0200
> The new mlxfw code fails to build without the xz library:
>
> drivers/net/ethernet/mellanox/mlxfw/mlxfw_mfa2.o: In function `mlxfw_mfa2_xz_dec_run':
> :(.text.mlxfw_mfa2_xz_dec_run+0x8): undefined reference to `xz_dec_run'
> drivers/net/ethernet/mellanox/mlxfw/mlxfw_mfa2.o: In function `mlxfw_mfa2_file_component_get':
> :(.text.mlxfw_mfa2_file_component_get+0x218): undefined reference to `xz_dec_init'
> :(.text.mlxfw_mfa2_file_component_get+0x2c0): undefined reference to `xz_dec_end'
>
> This adds a Kconfig 'select' statement for it, which is also what
> the other user of that library has.
>
> Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks Arnd.
^ permalink raw reply
* Re: net/ipv6: use-after-free in ip6_dst_ifdown
From: Eric Dumazet @ 2017-05-31 16:55 UTC (permalink / raw)
To: Cong Wang
Cc: Andrey Konovalov, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, David Ahern,
Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <CAM_iQpUxmME-9Gi9=dtAgeGeK4v3R0NV-REFRtMAU26yBXwrPQ@mail.gmail.com>
On Wed, May 31, 2017 at 9:45 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, May 31, 2017 at 2:42 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).
>>
>> Unfortunately it's not reproducible.
>>
>> ==================================================================
>> BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
>> Read of size 8 at addr ffff88006afa4ad8 by task syz-executor6/23554
>
>
> This one is very interesting.
>
> Here we are at:
>
> if (dev != loopback_dev) {
> if (idev && idev->dev == dev) {
> struct inet6_dev *loopback_idev =
> in6_dev_get(loopback_dev);
> if (loopback_idev) {
> rt->rt6i_idev = loopback_idev;
> in6_dev_put(idev);
> }
> }
> }
>
> clearly no skb involved, it looks like idev is the one used-after-free.
>
> But below it is actually skb which is allocated and freed...
>
skb->head was a kmalloc(X) with X = 1024 in this case.
So it is very possible the two different objects (skb->head and idev )
were accidentally using the same slab (1024 bytes).
KASAN only remember the last pair of alloc/free for a particular memory zone.
>
>>
>> CPU: 3 PID: 23554 Comm: syz-executor6 Not tainted 4.12.0-rc3+ #370
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:16 [inline]
>> dump_stack+0x292/0x395 lib/dump_stack.c:52
>> print_address_description+0x73/0x280 mm/kasan/report.c:252
>> kasan_report_error mm/kasan/report.c:351 [inline]
>> kasan_report+0x22b/0x340 mm/kasan/report.c:408
>> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
>> ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
>> dst_ifdown+0x75/0x230 net/core/dst.c:439
>> dst_dev_event+0xb1/0x230 net/core/dst.c:466
>> notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93
>> __raw_notifier_call_chain kernel/notifier.c:394 [inline]
>> raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>> call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649
>> call_netdevice_notifiers net/core/dev.c:1665 [inline]
>> __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640
>> dev_change_flags+0xf5/0x140 net/core/dev.c:6671
>> dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254
>> dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532
>> sock_do_ioctl+0x94/0xb0 net/socket.c:913
>> sock_ioctl+0x28f/0x440 net/socket.c:1004
>> vfs_ioctl fs/ioctl.c:45 [inline]
>> do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685
>> SYSC_ioctl fs/ioctl.c:700 [inline]
>> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
>> entry_SYSCALL_64_fastpath+0x1f/0xbe
>> RIP: 0033:0x446179
>> RSP: 002b:00007fd1da4bdc08 EFLAGS: 00000282 ORIG_RAX: 0000000000000010
>> RAX: ffffffffffffffda RBX: 0000000000003220 RCX: 0000000000446179
>> RDX: 0000000020d34000 RSI: 0000000000008914 RDI: 0000000000000005
>> RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000282 R12: 0000000000000005
>> R13: 0000000000000390 R14: 00000000006e1450 R15: 0000000000000000
>>
>> Allocated by task 23235:
>> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>> set_track mm/kasan/kasan.c:525 [inline]
>> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
>> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
>> slab_post_alloc_hook mm/slab.h:456 [inline]
>> slab_alloc_node mm/slub.c:2718 [inline]
>> __kmalloc_node_track_caller+0x20d/0x350 mm/slub.c:4303
>> __kmalloc_reserve.isra.32+0x41/0xd0 net/core/skbuff.c:138
>> __alloc_skb+0x157/0x770 net/core/skbuff.c:231
>> alloc_skb include/linux/skbuff.h:936 [inline]
>> alloc_skb_with_frags+0x12e/0x780 net/core/skbuff.c:4690
>> sock_alloc_send_pskb+0x804/0xa30 net/core/sock.c:2000
>> tun_alloc_skb drivers/net/tun.c:1144 [inline]
>> tun_get_user+0x91a/0x2e10 drivers/net/tun.c:1274
>> tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
>> call_write_iter include/linux/fs.h:1734 [inline]
>> new_sync_write fs/read_write.c:497 [inline]
>> __vfs_write+0x483/0x760 fs/read_write.c:510
>> vfs_write+0x187/0x500 fs/read_write.c:558
>> SYSC_write fs/read_write.c:605 [inline]
>> SyS_write+0xfb/0x230 fs/read_write.c:597
>> entry_SYSCALL_64_fastpath+0x1f/0xbe
>>
>> Freed by task 23235:
>> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>> set_track mm/kasan/kasan.c:525 [inline]
>> kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
>> slab_free_hook mm/slub.c:1357 [inline]
>> slab_free_freelist_hook mm/slub.c:1379 [inline]
>> slab_free mm/slub.c:2961 [inline]
>> kfree+0xe8/0x2b0 mm/slub.c:3882
>> skb_free_head+0x74/0xb0 net/core/skbuff.c:579
>> skb_release_data+0x3ce/0x4a0 net/core/skbuff.c:610
>> skb_release_all+0x4a/0x60 net/core/skbuff.c:669
>> __kfree_skb+0x15/0x20 net/core/skbuff.c:683
>> kfree_skb+0x16e/0x4e0 net/core/skbuff.c:704
>> llc_rcv+0x5c7/0xed0 net/llc/llc_input.c:214
>> __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4216
>> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4254
>> netif_receive_skb_internal+0x240/0x1b20 net/core/dev.c:4416
>> netif_receive_skb+0xae/0x3b0 net/core/dev.c:4440
>> tun_rx_batched.isra.40+0x5e5/0x8c0 drivers/net/tun.c:1167
>> tun_get_user+0x100d/0x2e10 drivers/net/tun.c:1339
>> tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
>> call_write_iter include/linux/fs.h:1734 [inline]
>> new_sync_write fs/read_write.c:497 [inline]
>> __vfs_write+0x483/0x760 fs/read_write.c:510
>> vfs_write+0x187/0x500 fs/read_write.c:558
>> SYSC_write fs/read_write.c:605 [inline]
>> SyS_write+0xfb/0x230 fs/read_write.c:597
>> entry_SYSCALL_64_fastpath+0x1f/0xbe
>>
>> The buggy address belongs to the object at ffff88006afa4ad8
>> which belongs to the cache kmalloc-1024 of size 1024
>> The buggy address is located 0 bytes inside of
>> 1024-byte region [ffff88006afa4ad8, ffff88006afa4ed8)
>> The buggy address belongs to the page:
>> page:ffffea0001abe800 count:1 mapcount:0 mapping: (null)
>> index:0x0 compound_mapcount: 0
>> flags: 0x500000000008100(slab|head)
>> raw: 0500000000008100 0000000000000000 0000000000000000 0000000100170017
>> raw: ffffea00017ef420 ffffea0001aaa420 ffff88003e80efc0 0000000000000000
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>> ffff88006afa4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff88006afa4a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>>ffff88006afa4a80: fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb
>> ^
>> ffff88006afa4b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff88006afa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
^ permalink raw reply
* Re: [PATCH nf-next] netns: add and use net_ns_barrier
From: David Miller @ 2017-05-31 16:55 UTC (permalink / raw)
To: fw; +Cc: netfilter-devel, netdev, ebiederm
In-Reply-To: <20170530093812.10712-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 30 May 2017 11:38:12 +0200
> Quoting Joe Stringer:
> If a user loads nf_conntrack_ftp, sends FTP traffic through a network
> namespace, destroys that namespace then unloads the FTP helper module,
> then the kernel will crash.
>
> Events that lead to the crash:
> 1. conntrack is created with ftp helper in netns x
> 2. This netns is destroyed
> 3. netns destruction is scheduled
> 4. netns destruction wq starts, removes netns from global list
> 5. ftp helper is unloaded, which resets all helpers of the conntracks
> via for_each_net()
>
> but because netns is already gone from list the for_each_net() loop
> doesn't include it, therefore all of these conntracks are unaffected.
>
> 6. helper module unload finishes
> 7. netns wq invokes destructor for rmmod'ed helper
>
> CC: "Eric W. Biederman" <ebiederm@xmission.com>
> Reported-by: Joe Stringer <joe@ovn.org>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> Eric, I'd like an explicit (n)ack from you for this one.
Indeed, Eric, please do.
Otherwise I'm fine with the generic parts:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: factor out a helper to decrement the skb refcount
From: Eric Dumazet @ 2017-05-31 16:56 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <d8ae2b225a566fb1addf970db79cbcea834b4ad0.1496070490.git.pabeni@redhat.com>
On Mon, 2017-05-29 at 17:27 +0200, Paolo Abeni wrote:
> The same code is replicated in 3 different places; move it to a
> common helper.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"
From: kbuild test robot @ 2017-05-31 16:56 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: kbuild-all, netdev, sowmini.varadhan, davem, stephen
In-Reply-To: <1496173944-82125-1-git-send-email-sowmini.varadhan@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 5956 bytes --]
Hi Sowmini,
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Sowmini-Varadhan/neigh-Really-delete-an-arp-neigh-entry-on-ip-neigh-delete-or-arp-d/20170531-235737
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/srcu.h:33:0,
from include/linux/notifier.h:15,
from include/linux/memory_hotplug.h:6,
from include/linux/mmzone.h:757,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from net//core/neighbour.c:20:
net//core/neighbour.c: In function 'neigh_del':
net//core/neighbour.c:130:25: error: 'tbl' undeclared (first use in this function)
lockdep_is_held(&tbl->lock)));
^
include/linux/rcupdate.h:637:36: note: in definition of macro 'rcu_assign_pointer'
uintptr_t _r_a_p__v = (uintptr_t)(v); \
^
>> include/linux/rcupdate.h:587:2: note: in expansion of macro 'RCU_LOCKDEP_WARN'
RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_protected() usage"); \
^~~~~~~~~~~~~~~~
>> include/linux/rcupdate.h:751:2: note: in expansion of macro '__rcu_dereference_protected'
__rcu_dereference_protected((p), (c), __rcu)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> net//core/neighbour.c:129:8: note: in expansion of macro 'rcu_dereference_protected'
rcu_dereference_protected(n->next,
^~~~~~~~~~~~~~~~~~~~~~~~~
>> net//core/neighbour.c:130:8: note: in expansion of macro 'lockdep_is_held'
lockdep_is_held(&tbl->lock)));
^~~~~~~~~~~~~~~
net//core/neighbour.c:130:25: note: each undeclared identifier is reported only once for each function it appears in
lockdep_is_held(&tbl->lock)));
^
include/linux/rcupdate.h:637:36: note: in definition of macro 'rcu_assign_pointer'
uintptr_t _r_a_p__v = (uintptr_t)(v); \
^
>> include/linux/rcupdate.h:587:2: note: in expansion of macro 'RCU_LOCKDEP_WARN'
RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_protected() usage"); \
^~~~~~~~~~~~~~~~
>> include/linux/rcupdate.h:751:2: note: in expansion of macro '__rcu_dereference_protected'
__rcu_dereference_protected((p), (c), __rcu)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> net//core/neighbour.c:129:8: note: in expansion of macro 'rcu_dereference_protected'
rcu_dereference_protected(n->next,
^~~~~~~~~~~~~~~~~~~~~~~~~
>> net//core/neighbour.c:130:8: note: in expansion of macro 'lockdep_is_held'
lockdep_is_held(&tbl->lock)));
^~~~~~~~~~~~~~~
--
In file included from include/linux/srcu.h:33:0,
from include/linux/notifier.h:15,
from include/linux/memory_hotplug.h:6,
from include/linux/mmzone.h:757,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from net/core/neighbour.c:20:
net/core/neighbour.c: In function 'neigh_del':
net/core/neighbour.c:130:25: error: 'tbl' undeclared (first use in this function)
lockdep_is_held(&tbl->lock)));
^
include/linux/rcupdate.h:637:36: note: in definition of macro 'rcu_assign_pointer'
uintptr_t _r_a_p__v = (uintptr_t)(v); \
^
>> include/linux/rcupdate.h:587:2: note: in expansion of macro 'RCU_LOCKDEP_WARN'
RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_protected() usage"); \
^~~~~~~~~~~~~~~~
>> include/linux/rcupdate.h:751:2: note: in expansion of macro '__rcu_dereference_protected'
__rcu_dereference_protected((p), (c), __rcu)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
net/core/neighbour.c:129:8: note: in expansion of macro 'rcu_dereference_protected'
rcu_dereference_protected(n->next,
^~~~~~~~~~~~~~~~~~~~~~~~~
net/core/neighbour.c:130:8: note: in expansion of macro 'lockdep_is_held'
lockdep_is_held(&tbl->lock)));
^~~~~~~~~~~~~~~
net/core/neighbour.c:130:25: note: each undeclared identifier is reported only once for each function it appears in
lockdep_is_held(&tbl->lock)));
^
include/linux/rcupdate.h:637:36: note: in definition of macro 'rcu_assign_pointer'
uintptr_t _r_a_p__v = (uintptr_t)(v); \
^
>> include/linux/rcupdate.h:587:2: note: in expansion of macro 'RCU_LOCKDEP_WARN'
RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_protected() usage"); \
^~~~~~~~~~~~~~~~
>> include/linux/rcupdate.h:751:2: note: in expansion of macro '__rcu_dereference_protected'
__rcu_dereference_protected((p), (c), __rcu)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
net/core/neighbour.c:129:8: note: in expansion of macro 'rcu_dereference_protected'
rcu_dereference_protected(n->next,
^~~~~~~~~~~~~~~~~~~~~~~~~
net/core/neighbour.c:130:8: note: in expansion of macro 'lockdep_is_held'
lockdep_is_held(&tbl->lock)));
^~~~~~~~~~~~~~~
vim +/rcu_dereference_protected +129 net//core/neighbour.c
123 {
124 bool retval = false;
125
126 write_lock(&n->lock);
127 if (atomic_read(&n->refcnt) == 1 && !(n->nud_state & state)) {
128 rcu_assign_pointer(*np,
> 129 rcu_dereference_protected(n->next,
> 130 lockdep_is_held(&tbl->lock)));
131 n->dead = 1;
132 retval = true;
133 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38863 bytes --]
^ permalink raw reply
* [PATCH V2 net-next] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"
From: Sowmini Varadhan @ 2017-05-30 21:31 UTC (permalink / raw)
To: netdev, sowmini.varadhan; +Cc: davem, stephen, sowmini.varadhan
The command
# arp -s 62.2.0.1 a:b:c:d:e:f dev eth2
adds an entry like the following (listed by "arp -an")
? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2
but the symmetric deletion command
# arp -i eth2 -d 62.2.0.1
does not remove the PERM entry from the table, and instead leaves behind
? (62.2.0.1) at <incomplete> on eth2
The reason is that there is a refcnt of 1 for the arp_tbl itself
(neigh_alloc starts off the entry with a refcnt of 1), thus
the neigh_release() call from arp_invalidate() will (at best) just
decrement the ref to 1, but will never actually free it from the
table.
To fix this, we need to do something like neigh_forced_gc: if
the refcnt is 1 (i.e., on the table's ref), remove the entry from
the table and free it. This patch refactors and shares common code
between neigh_forced_gc and the newly added neigh_remove_one.
A similar issue exists for IPv6 Neighbor Cache entries, and is fixed
in a similar manner by this patch.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
v2: fix kbuild-test-robot compile error.
include/net/neighbour.h | 1 +
net/core/neighbour.c | 63 ++++++++++++++++++++++++++++++++++++++--------
net/ipv4/arp.c | 1 +
3 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index e4dd3a2..639b675 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -317,6 +317,7 @@ struct neighbour *__neigh_create(struct neigh_table *tbl, const void *pkey,
int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, u32 flags,
u32 nlmsg_pid);
void __neigh_set_probe_once(struct neighbour *neigh);
+bool neigh_remove_one(struct neighbour *ndel, struct neigh_table *tbl);
void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev);
int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev);
int neigh_resolve_output(struct neighbour *neigh, struct sk_buff *skb);
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index d274f81..cedab54 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -118,6 +118,55 @@ unsigned long neigh_rand_reach_time(unsigned long base)
EXPORT_SYMBOL(neigh_rand_reach_time);
+static bool neigh_del(struct neighbour *n, __u8 state,
+ struct neighbour __rcu **np, struct neigh_table *tbl)
+{
+ bool retval = false;
+
+ write_lock(&n->lock);
+ if (atomic_read(&n->refcnt) == 1 && !(n->nud_state & state)) {
+ rcu_assign_pointer(*np,
+ rcu_dereference_protected(n->next,
+ lockdep_is_held(&tbl->lock)));
+ n->dead = 1;
+ retval = true;
+ }
+ write_unlock(&n->lock);
+ if (retval)
+ neigh_cleanup_and_release(n);
+ return retval;
+}
+
+bool neigh_remove_one(struct neighbour *ndel, struct neigh_table *tbl)
+{
+ struct neigh_hash_table *nht;
+ void *pkey = ndel->primary_key;
+ u32 hash_val;
+ struct neighbour *n;
+ struct neighbour __rcu **np;
+ bool retval = false;
+
+ write_lock_bh(&tbl->lock);
+ nht = rcu_dereference_protected(tbl->nht,
+ lockdep_is_held(&tbl->lock));
+ hash_val = tbl->hash(pkey, ndel->dev, nht->hash_rnd);
+ hash_val = hash_val >> (32 - nht->hash_shift);
+
+ np = &nht->hash_buckets[hash_val];
+ while ((n = rcu_dereference_protected(*np,
+ lockdep_is_held(&tbl->lock))) != NULL) {
+ if (n == ndel) {
+ retval = neigh_del(n, 0, np, tbl);
+ write_unlock_bh(&tbl->lock);
+ return retval;
+ }
+ np = &n->next;
+ }
+ write_unlock_bh(&tbl->lock);
+ return retval;
+}
+EXPORT_SYMBOL(neigh_remove_one);
+
static int neigh_forced_gc(struct neigh_table *tbl)
{
int shrunk = 0;
@@ -140,19 +189,10 @@ static int neigh_forced_gc(struct neigh_table *tbl)
* - nobody refers to it.
* - it is not permanent
*/
- write_lock(&n->lock);
- if (atomic_read(&n->refcnt) == 1 &&
- !(n->nud_state & NUD_PERMANENT)) {
- rcu_assign_pointer(*np,
- rcu_dereference_protected(n->next,
- lockdep_is_held(&tbl->lock)));
- n->dead = 1;
- shrunk = 1;
- write_unlock(&n->lock);
- neigh_cleanup_and_release(n);
+ if (neigh_del(n, NUD_PERMANENT, np, tbl)) {
+ shrunk = 1;
continue;
}
- write_unlock(&n->lock);
np = &n->next;
}
}
@@ -1650,6 +1690,7 @@ static int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh,
NEIGH_UPDATE_F_ADMIN,
NETLINK_CB(skb).portid);
neigh_release(neigh);
+ neigh_remove_one(neigh, tbl);
out:
return err;
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index e9f3386..5264004 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -1120,6 +1120,7 @@ static int arp_invalidate(struct net_device *dev, __be32 ip)
NEIGH_UPDATE_F_OVERRIDE|
NEIGH_UPDATE_F_ADMIN, 0);
neigh_release(neigh);
+ neigh_remove_one(neigh, &arp_tbl);
}
return err;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net] samples/bpf: bpf_load.c order of prog_fd[] should correspond with ELF order
From: David Miller @ 2017-05-31 16:59 UTC (permalink / raw)
To: brouer; +Cc: alexei.starovoitov, netdev
In-Reply-To: <149614787132.15375.2590780903240304298.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Tue, 30 May 2017 14:37:51 +0200
> An eBPF ELF file generated with LLVM can contain several program
> section, which can be used for bpf tail calls. The bpf prog file
> descriptors are accessible via array prog_fd[].
>
> At-least XDP samples assume ordering, and uses prog_fd[0] is the main
> XDP program to attach. The actual order of array prog_fd[] depend on
> whether or not a bpf program section is referencing any maps or not.
> Not using a map result in being loaded/processed after all other
> prog section. Thus, this can lead to some very strange and hard to
> debug situation, as the user can only see a FD and cannot correlated
> that with the ELF section name.
>
> The fix is rather simple, and even removes duplicate memcmp code.
> Simply load program sections as the last step, instead of
> load_and_attach while processing the relocation section.
>
> When working with tail calls, it become even more essential that the
> order of prog_fd[] is consistant, like the current dependency of the
> map_fd[] order.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied to net-next, thanks Jesper.
^ permalink raw reply
* Re: [PATCH net-next 2/3] udp: avoid a cache miss on dequeue
From: Eric Dumazet @ 2017-05-31 17:00 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <b07f7111480bb0ca2d98fe9fef49a593ab1c4787.1496070490.git.pabeni@redhat.com>
On Mon, 2017-05-29 at 17:27 +0200, Paolo Abeni wrote:
> Since UDP no more uses sk->destructor, we can clear completely
> the skb head state before enqueuing.
...
> @@ -1739,6 +1740,9 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> sk_mark_napi_id_once(sk, skb);
> }
>
> + /* drop all pending head states; dst, nf and sk are dropped by caller */
> + secpath_reset(skb);
> +
I wonder if using skb_release_head_state() would be more appropriate ?
Surely more descriptive and probably not more expensive since all
cache lines should be already hot at this point.
> rc = __udp_enqueue_schedule_skb(sk, skb);
> if (rc < 0) {
> int is_udplite = IS_UDPLITE(sk);
^ permalink raw reply
* Re: [PATCH net-next 3/3] udp: try to avoid 2 cache miss on dequeue
From: Eric Dumazet @ 2017-05-31 17:04 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <53a22c4f792ffd2efe76e233212185ecee868c1a.1496070490.git.pabeni@redhat.com>
On Mon, 2017-05-29 at 17:27 +0200, Paolo Abeni wrote:
> when udp_recvmsg() is executed, on x86_64 and other archs, most skb
> fields are on cold cachelines.
> If the skb are linear and the kernel don't need to compute the udp
> csum, only a handful of skb fields are required by udp_recvmsg().
> Since we already use skb->dev_scratch to cache hot data, and
> there are 32 bits unused on 64 bit archs, use such field to cache
> as much data as we can, and try to prefetch on dequeue the relevant
> fields that are left out.
>
> This can save up to 2 cache miss per packet.
okay ;)
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv4/udp.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 103 insertions(+), 11 deletions(-)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 53fa48d..616132e 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1163,6 +1163,83 @@ int udp_sendpage(struct sock *sk, struct page *page, int offset,
> return ret;
> }
>
> +/* Copy as much information as possible into skb->dev_scratch to avoid
> + * possibly multiple cache miss on dequeue();
> + */
> +#if BITS_PER_LONG == 64
> +
> +/* we can store multiple info here: truesize, len and the bit needed to
> + * compute skb_csum_unnecessary will be on cold cache lines at recvmsg
> + * time.
> + * skb->len can be stored on 16 bits since the udp header has been already
> + * validated and pulled.
> + */
> +struct udp_dev_scratch {
> + __u32 truesize;
> + __u16 len;
> + __u16 is_linear:1;
> + __u16 csum_unnecessary:1;
What about
u32 truesize;
u16 len;
bool is_linear;
bool csum_unnecessary;
I do not believe the __ prefix is necessary for a local structure (not
uapi)
Also a plain bool or u8 is faster than a bit field (shorter
instructions)
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: use the new rtnl_get_event() interface
From: David Miller @ 2017-05-31 17:08 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, dsahern, vyasevic
In-Reply-To: <1496153222-13382-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Tue, 30 May 2017 10:07:02 -0400
> Small clean-up to rtmsg_ifinfo() to use the rtnl_get_event()
> interface instead of using 'internal' values directly.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Applied, thanks Vlad.
^ permalink raw reply
* [PATCH net-next, 1/2] tools: hv: set allow-hotplug for VF on Ubuntu
From: Simon Xiao @ 2017-05-31 17:28 UTC (permalink / raw)
To: netdev, davem, kys, haiyangz, sthemmin; +Cc: Simon Xiao
On HyperV, the VF interface can be offered by a host at any time.
Mark the VF interface as hotplug, to make sure it will be brought up
automatically when it is registered.
Signed-off-by: Simon Xiao <sixiao@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
---
tools/hv/bondvf.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/hv/bondvf.sh b/tools/hv/bondvf.sh
index 112deba..8abd46e 100755
--- a/tools/hv/bondvf.sh
+++ b/tools/hv/bondvf.sh
@@ -134,7 +134,6 @@ function create_eth_cfg_ubuntu {
local fn=$cfgdir/interfaces
del_eth_cfg_ubuntu $1
-
echo $'\n'auto $1 >>$fn
echo iface $1 inet manual >>$fn
echo bond-master $2 >>$fn
@@ -143,7 +142,10 @@ function create_eth_cfg_ubuntu {
function create_eth_cfg_pri_ubuntu {
local fn=$cfgdir/interfaces
- create_eth_cfg_ubuntu $1 $2
+ del_eth_cfg_ubuntu $1
+ echo $'\n'allow-hotplug $1 >>$fn
+ echo iface $1 inet manual >>$fn
+ echo bond-master $2 >>$fn
echo bond-primary $1 >>$fn
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next, 2/2] tools: hv: set hotplug for VF on Suse
From: Simon Xiao @ 2017-05-31 17:28 UTC (permalink / raw)
To: netdev, davem, kys, haiyangz, sthemmin; +Cc: Simon Xiao
On HyperV, the VF interface can be offered by a host at any time.
Mark the VF interface as hotplug, to make sure it will be brought up
automatically when it is registered.
Signed-off-by: Simon Xiao <sixiao@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
---
tools/hv/bondvf.sh | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/hv/bondvf.sh b/tools/hv/bondvf.sh
index 8abd46e..89b2506 100755
--- a/tools/hv/bondvf.sh
+++ b/tools/hv/bondvf.sh
@@ -170,7 +170,11 @@ function create_eth_cfg_suse {
}
function create_eth_cfg_pri_suse {
- create_eth_cfg_suse $1
+ local fn=$cfgdir/ifcfg-$1
+
+ rm -f $fn
+ echo BOOTPROTO=none >>$fn
+ echo STARTMODE=hotplug >>$fn
}
function create_bond_cfg_suse {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store
From: Larry Finger @ 2017-05-31 17:33 UTC (permalink / raw)
To: Jia-Ju Bai, kvalo; +Cc: linux-wireless, b43-dev, netdev, linux-kernel
In-Reply-To: <1496226547-5921-1-git-send-email-baijiaju1990@163.com>
On 05/31/2017 05:29 AM, Jia-Ju Bai wrote:
> The driver may sleep under a spin lock, and the function call path is:
> b43legacy_attr_interfmode_store (acquire the lock by spin_lock_irqsave)
> b43legacy_radio_set_interference_mitigation
> b43legacy_radio_interference_mitigation_disable
> b43legacy_calc_nrssi_slope
> b43legacy_synth_pu_workaround
> might_sleep and msleep --> may sleep
>
> Fixing it may be complex, and a possible way is to remove
> spin_lock_irqsave and spin_lock_irqrestore in
> b43legacy_attr_interfmode_store, and the code has been protected by
> mutex_lock and mutex_unlock.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
> ---
> drivers/net/wireless/broadcom/b43legacy/sysfs.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43legacy/sysfs.c b/drivers/net/wireless/broadcom/b43legacy/sysfs.c
> index 2a1da15..9ede143 100644
> --- a/drivers/net/wireless/broadcom/b43legacy/sysfs.c
> +++ b/drivers/net/wireless/broadcom/b43legacy/sysfs.c
> @@ -137,14 +137,12 @@ static ssize_t b43legacy_attr_interfmode_store(struct device *dev,
> }
>
> mutex_lock(&wldev->wl->mutex);
> - spin_lock_irqsave(&wldev->wl->irq_lock, flags);
>
> err = b43legacy_radio_set_interference_mitigation(wldev, mode);
> if (err)
> b43legacyerr(wldev->wl, "Interference Mitigation not "
> "supported by device\n");
> mmiowb();
> - spin_unlock_irqrestore(&wldev->wl->irq_lock, flags);
> mutex_unlock(&wldev->wl->mutex);
>
> return err ? err : count;
>
Jia-Ju,
Did you actually observe the attempt to sleep under the spin lock, or did you
discover this using some tool? In other words, have either of your patches been
tested?
Larry
^ permalink raw reply
* Re: loosing netdevices with namespaces and unshare?
From: Cong Wang @ 2017-05-31 17:44 UTC (permalink / raw)
To: Harald Welte; +Cc: Linux Kernel Network Developers
In-Reply-To: <20170531122752.siaou43verg4epep@nataraja>
On Wed, May 31, 2017 at 5:27 AM, Harald Welte <laforge@gnumonks.org> wrote:
> Hi Cong,
>
> On Tue, May 30, 2017 at 04:18:17PM -0700, Cong Wang wrote:
>> On Tue, May 30, 2017 at 3:07 PM, Harald Welte <laforge@gnumonks.org> wrote:
>> > But, to the contrary, this doesn't happen. The unshare-created netns is
>> > gone, but the netdevice did not get moved back to the root namespace
>> > either. The only hack to get back to the "eth0" device is to unload the
>> > driver and re-load it.
>>
>>
>> Net namespace simply unregisters all netdevices inside when it is
>> gone, no matter where they are from.
>
> ah, ok. I missed that part. Is there a good piece of documentation on
> netwokr namespaces that I should read?
I don't know any doc mentioning this.
>> I am pretty sure you can move it back to root-ns if you want,
>
> Yes, I can explicitly do that, but this of course doesn't work if e.g.
> my [single] process in that namespace crashes due to some bug, OOM or
> the like.
>
>> it is a little tricky because you have to give the root-ns a name
>> first.
>
> It's actually not, as you can just identify the root-ns by pid 1, so
> "ip link set $DEV netns 1" will move it back. As indicated, I'm worried
> about the error paths.
>
Yeah, using PID works too. Unfortunately the whole namespace
is gone too no matter the last process exits normally or not, it is
just refcount'ed.
>> > What am I missing here? Is this the intended behavior?
>>
>> Yes it is.
>
> thanks for your confirmation. Guess I have to get used to it.
>
>> > Of course I know I could simply do something like "ip link set eth0
>> > netns 1" from within the namespace before leaving. But what if the
>> > process is not bash and the process exits abnormally? I'd consider
>> > that explicit reassignment more like a hack than a proper solution...
>>
>> It doesn't make sense to move it back to where it is from, for example,
>> what if you move a veth0 from netns1 to netns2 and netns1 is gone
>> before netns2?
>
> for virtual devices, I would agree. For physical devices, I think the
> default behavior to unregister them is - from my of course very
> subjective point of view - quite questionable.
Network namespace does not special-case the physical devices,
it treats them all equally as abstract net devices.
Hope this helps.
^ permalink raw reply
* [PATCH net-next] liquidio: Fix checkpatch errors with references crossing single line
From: Felix Manlunas @ 2017-05-31 17:45 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
From: Satanand Burla <satananda.burla@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 8 ++++----
drivers/net/ethernet/cavium/liquidio/octeon_droq.c | 11 +++++------
drivers/net/ethernet/cavium/liquidio/request_manager.c | 3 +--
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 579dc73..2e25306 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -984,11 +984,11 @@ lio_get_ethtool_stats(struct net_device *netdev,
data[i++] =
CVM_CAST64(oct_dev->instr_queue[j]->stats.instr_posted);
/*# of instructions processed */
- data[i++] = CVM_CAST64(oct_dev->instr_queue[j]->
- stats.instr_processed);
+ data[i++] = CVM_CAST64(
+ oct_dev->instr_queue[j]->stats.instr_processed);
/*# of instructions could not be processed */
- data[i++] = CVM_CAST64(oct_dev->instr_queue[j]->
- stats.instr_dropped);
+ data[i++] = CVM_CAST64(
+ oct_dev->instr_queue[j]->stats.instr_dropped);
/*bytes sent through the queue */
data[i++] =
CVM_CAST64(oct_dev->instr_queue[j]->stats.bytes_sent);
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
index 286be55..d3a6a1c 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
@@ -425,8 +425,7 @@ octeon_droq_refill_pullup_descs(struct octeon_droq *droq,
droq->max_count);
desc_refilled++;
droq->refill_count--;
- } while (droq->recv_buf_list[droq->refill_idx].
- buffer);
+ } while (droq->recv_buf_list[droq->refill_idx].buffer);
}
refill_index = incr_index(refill_index, 1, droq->max_count);
} /* while */
@@ -490,8 +489,8 @@ octeon_droq_refill(struct octeon_device *octeon_dev, struct octeon_droq *droq)
droq->recv_buf_list[droq->refill_idx].data = data;
desc_ring[droq->refill_idx].buffer_ptr =
- lio_map_ring(droq->recv_buf_list[droq->
- refill_idx].buffer);
+ lio_map_ring(droq->recv_buf_list[
+ droq->refill_idx].buffer);
/* Reset any previous values in the length field. */
droq->info_list[droq->refill_idx].length = 0;
@@ -690,8 +689,8 @@ octeon_droq_fast_process_packets(struct octeon_device *oct,
nicbuf,
cpy_len,
idx);
- buf = droq->recv_buf_list[idx].
- buffer;
+ buf = droq->recv_buf_list[
+ idx].buffer;
recv_buffer_fast_free(buf);
droq->recv_buf_list[idx].buffer
= NULL;
diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c b/drivers/net/ethernet/cavium/liquidio/request_manager.c
index 261f448..7b297f1 100644
--- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
@@ -252,8 +252,7 @@ int lio_wait_for_instr_fetch(struct octeon_device *oct)
if (!(oct->io_qmask.iq & BIT_ULL(i)))
continue;
pending =
- atomic_read(&oct->
- instr_queue[i]->instr_pending);
+ atomic_read(&oct->instr_queue[i]->instr_pending);
if (pending)
__check_db_timeout(oct, i);
instr_cnt += pending;
^ permalink raw reply related
* RE: [net-qed] question about potential null pointer dereference
From: Mintz, Yuval @ 2017-05-31 17:51 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170530124252.Horde.ZtBHOOxQIQFInhiQILVtpD_@gator4166.hostgator.com>
> While looking into Coverity ID 1362293 I ran into the following piece of code
> at drivers/net/ethernet/qlogic/qed/qed_sriov.c:3863:
>
> 3863static int
> 3864qed_iov_configure_min_tx_rate(struct qed_dev *cdev, int vfid, u32 rate)
> 3865{
> 3866 struct qed_vf_info *vf;
> 3867 u8 vport_id;
> 3868 int i;
> 3869
> 3870 for_each_hwfn(cdev, i) {
> 3871 struct qed_hwfn *p_hwfn = &cdev->hwfns[i];
> 3872
> 3873 if (!qed_iov_pf_sanity_check(p_hwfn, vfid)) {
> 3874 DP_NOTICE(p_hwfn,
> 3875 "SR-IOV sanity check failed,
> can't set min rate\n");
> 3876 return -EINVAL;
> 3877 }
> 3878 }
> 3879
> 3880 vf = qed_iov_get_vf_info(QED_LEADING_HWFN(cdev), (u16)vfid,
> true);
Unless I'm missing something, this sounds like a false-positive from coverity.
The validation of qed_iov_pf_sanity_check() should be sufficient for qed_iov_get_vf_info()
to always return a valid value, and there's no scenario where we'd reach this
part of the code if the hw-functions aren't initialized; so we're bound to enter the loop.
^ permalink raw reply
* Re: [PATCH nf-next] netns: add and use net_ns_barrier
From: Eric W. Biederman @ 2017-05-31 17:46 UTC (permalink / raw)
To: David Miller; +Cc: fw, netfilter-devel, netdev
In-Reply-To: <20170531.125527.1553231867217469072.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Florian Westphal <fw@strlen.de>
> Date: Tue, 30 May 2017 11:38:12 +0200
>
>> Quoting Joe Stringer:
>> If a user loads nf_conntrack_ftp, sends FTP traffic through a network
>> namespace, destroys that namespace then unloads the FTP helper module,
>> then the kernel will crash.
>>
>> Events that lead to the crash:
>> 1. conntrack is created with ftp helper in netns x
>> 2. This netns is destroyed
>> 3. netns destruction is scheduled
>> 4. netns destruction wq starts, removes netns from global list
>> 5. ftp helper is unloaded, which resets all helpers of the conntracks
>> via for_each_net()
>>
>> but because netns is already gone from list the for_each_net() loop
>> doesn't include it, therefore all of these conntracks are unaffected.
>>
>> 6. helper module unload finishes
>> 7. netns wq invokes destructor for rmmod'ed helper
>>
>> CC: "Eric W. Biederman" <ebiederm@xmission.com>
>> Reported-by: Joe Stringer <joe@ovn.org>
>> Signed-off-by: Florian Westphal <fw@strlen.de>
>> ---
>> Eric, I'd like an explicit (n)ack from you for this one.
>
> Indeed, Eric, please do.
Taking a look now. The original didn't make it's way into my inbox. I
just have a copy from netdev. Florian there may be a bit of an email
black hole between us.
> Otherwise I'm fine with the generic parts:
>
> Acked-by: David S. Miller <davem@davemloft.net>
Eric
^ 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