* Bad MAINTAINERS pattern in section 'MELLANOX ETHERNET INNOVA IPSEC DRIVER'
From: Joe Perches @ 2018-09-28 21:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Boris Pismenny, netdev
Please fix this defect appropriately.
linux-next MAINTAINERS section:
9325 MELLANOX ETHERNET INNOVA IPSEC DRIVER
9326 R: Boris Pismenny <borisp@mellanox.com>
9327 L: netdev@vger.kernel.org
9328 S: Supported
9329 W: http://www.mellanox.com
9330 Q: http://patchwork.ozlabs.org/project/netdev/list/
9331 F: drivers/net/ethernet/mellanox/mlx5/core/en_ipsec/*
--> 9332 F: drivers/net/ethernet/mellanox/mlx5/core/ipsec*
Commit that introduced this:
commit 547eede070eb981f1442e494f08f4567dcf1d1c7
Author: Ilan Tayari <ilant@mellanox.com>
Date: Tue Apr 18 16:04:28 2017 +0300
net/mlx5e: IPSec, Innova IPSec offload infrastructure
Add Innova IPSec ESP crypto offload configuration paths.
Detect Innova IPSec device and set the NETIF_F_HW_ESP flag.
Configure Security Associations using the API introduced in a previous
patch.
Add Software-parser hardware descriptor layout
Software-Parser (swp) is a hardware feature in ConnectX which allows the
host software to specify protocol header offsets in the TX path, thus
overriding the hardware parser.
This is useful for protocols that the ASIC may not be able to parse on
its own.
Note that due to inline metadata, XDP is not supported in Innova IPSec.
Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Signed-off-by: Yossi Kuperman <yossiku@mellanox.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@mellanox.com>
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
MAINTAINERS | 10 +
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 12 +
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +
drivers/net/ethernet/mellanox/mlx5/core/en.h | 3 +
.../ethernet/mellanox/mlx5/core/en_accel/ipsec.c | 415 +++++++++++++++++++++
.../ethernet/mellanox/mlx5/core/en_accel/ipsec.h | 78 ++++
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 14 +
include/linux/mlx5/mlx5_ifc.h | 8 +-
include/linux/mlx5/qp.h | 14 +-
9 files changed, 552 insertions(+), 4 deletions(-)
No commit with drivers/net/ethernet/mellanox/mlx5/core/ipsec* found
^ permalink raw reply
* Bad MAINTAINERS pattern in section 'MELLANOX ETHERNET INNOVA IPSEC DRIVER'
From: Joe Perches @ 2018-09-28 21:55 UTC (permalink / raw)
To: linux-kernel; +Cc: Boris Pismenny, netdev
Please fix this defect appropriately.
linux-next MAINTAINERS section:
9325 MELLANOX ETHERNET INNOVA IPSEC DRIVER
9326 R: Boris Pismenny <borisp@mellanox.com>
9327 L: netdev@vger.kernel.org
9328 S: Supported
9329 W: http://www.mellanox.com
9330 Q: http://patchwork.ozlabs.org/project/netdev/list/
--> 9331 F: drivers/net/ethernet/mellanox/mlx5/core/en_ipsec/*
9332 F: drivers/net/ethernet/mellanox/mlx5/core/ipsec*
Commit that introduced this:
commit 547eede070eb981f1442e494f08f4567dcf1d1c7
Author: Ilan Tayari <ilant@mellanox.com>
Date: Tue Apr 18 16:04:28 2017 +0300
net/mlx5e: IPSec, Innova IPSec offload infrastructure
Add Innova IPSec ESP crypto offload configuration paths.
Detect Innova IPSec device and set the NETIF_F_HW_ESP flag.
Configure Security Associations using the API introduced in a previous
patch.
Add Software-parser hardware descriptor layout
Software-Parser (swp) is a hardware feature in ConnectX which allows the
host software to specify protocol header offsets in the TX path, thus
overriding the hardware parser.
This is useful for protocols that the ASIC may not be able to parse on
its own.
Note that due to inline metadata, XDP is not supported in Innova IPSec.
Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Signed-off-by: Yossi Kuperman <yossiku@mellanox.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@mellanox.com>
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
MAINTAINERS | 10 +
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 12 +
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +
drivers/net/ethernet/mellanox/mlx5/core/en.h | 3 +
.../ethernet/mellanox/mlx5/core/en_accel/ipsec.c | 415 +++++++++++++++++++++
.../ethernet/mellanox/mlx5/core/en_accel/ipsec.h | 78 ++++
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 14 +
include/linux/mlx5/mlx5_ifc.h | 8 +-
include/linux/mlx5/qp.h | 14 +-
9 files changed, 552 insertions(+), 4 deletions(-)
No commit with drivers/net/ethernet/mellanox/mlx5/core/en_ipsec/* found
^ permalink raw reply
* Bad MAINTAINERS pattern in section 'LANTIQ / INTEL Ethernet drivers'
From: Joe Perches @ 2018-09-28 21:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Hauke Mehrtens, netdev
Please fix this defect appropriately.
linux-next MAINTAINERS section:
8155 LANTIQ / INTEL Ethernet drivers
8156 M: Hauke Mehrtens <hauke@hauke-m.de>
8157 L: netdev@vger.kernel.org
8158 S: Maintained
8159 F: net/dsa/tag_gswip.c
8160 F: drivers/net/ethernet/lantiq_xrx200.c
8161 F: drivers/net/dsa/lantiq_pce.h
--> 8162 F: drivers/net/dsa/intel_gswip.c
Commit that introduced this:
commit 14fceff4771e51b23b4485b575cf9e5b3414b89b
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sun Sep 9 22:20:39 2018 +0200
net: dsa: Add Lantiq / Intel DSA driver for vrx200
This adds the DSA driver for the GSWIP Switch found in the VRX200 SoC.
This switch is integrated in the DSL SoC, this SoC uses a GSWIP version
2.1, there are other SoCs using different versions of this IP block, but
this driver was only tested with the version found in the VRX200.
Currently only the basic features are implemented which will forward all
packages to the CPU and let the CPU do the forwarding. The hardware also
support Layer 2 offloading which is not yet implemented in this driver.
The GPHY FW loaded is now done by this driver and not any more by the
separate driver in drivers/soc/lantiq/gphy.c, I will remove this driver
is a separate patch. to make use of the GPHY this switch driver is
needed anyway. Other SoCs have more embedded GPHYs so this driver should
support a variable number of GPHYs. After the firmware was loaded the
GPHY can be probed on the MDIO bus and it behaves like an external GPHY,
without the firmware it can not be probed on the MDIO bus.
The clock names in the sysctrl.c file have to be changed because the
clocks are now used by a different driver. This should be cleaned up and
a real common clock driver should provide the clocks instead.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
MAINTAINERS | 2 +
arch/mips/lantiq/xway/sysctrl.c | 8 +-
drivers/net/dsa/Kconfig | 8 +
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/lantiq_gswip.c | 1169 +++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/lantiq_pce.h | 153 +++++
6 files changed, 1337 insertions(+), 4 deletions(-)
No commit with drivers/net/dsa/intel_gswip.c found
^ permalink raw reply
* Bad MAINTAINERS pattern in section 'IPX NETWORK LAYER'
From: Joe Perches @ 2018-09-28 21:53 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Greg Kroah-Hartman
Please fix this defect appropriately.
linux-next MAINTAINERS section:
7639 IPX NETWORK LAYER
7640 L: netdev@vger.kernel.org
7641 S: Obsolete
7642 F: include/uapi/linux/ipx.h
--> 7643 F: drivers/staging/ipx/
Commit that introduced this:
commit e02554e9a4338c58e75fdfb0ef908a5adc86cba5
Author: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue Nov 14 08:37:14 2017 -0800
ipx: move Novell IPX protocol support into staging
The Netware IPX protocol is very old and no one should still be using
it. It is time to move it into staging for a while and eventually
decommision it.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MAINTAINERS | 3 +--
drivers/staging/Kconfig | 2 ++
drivers/staging/Makefile | 1 +
{net => drivers/staging}/ipx/Kconfig | 0
{net => drivers/staging}/ipx/Makefile | 0
drivers/staging/ipx/TODO | 4 ++++
{net => drivers/staging}/ipx/af_ipx.c | 0
{net => drivers/staging}/ipx/ipx_proc.c | 0
{net => drivers/staging}/ipx/ipx_route.c | 0
{net => drivers/staging}/ipx/pe2.c | 0
{net => drivers/staging}/ipx/sysctl_net_ipx.c | 0
net/Kconfig | 1 -
net/Makefile | 1 -
13 files changed, 8 insertions(+), 4 deletions(-)
Last commit with drivers/staging/ipx/
commit 7a2e838d28cff6718a0bdf66164465402f8e40ed
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri Jun 1 20:39:54 2018 +0200
staging: ipx: delete it from the tree
The ipx code moved into the staging tree back in November 2017 and no
one has complained or even noticed it was gone. Because of that, let's
just delete it.
Note, the ipx header files are not removed here, that will come later
through the networking tree, as that takes a bit more work to unwind.
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/ipx/Kconfig | 61 -
drivers/staging/ipx/Makefile | 8 -
drivers/staging/ipx/TODO | 4 -
drivers/staging/ipx/af_ipx.c | 2082 ----------------------------------
drivers/staging/ipx/ipx_proc.c | 338 ------
drivers/staging/ipx/ipx_route.c | 293 -----
drivers/staging/ipx/pe2.c | 36 -
drivers/staging/ipx/sysctl_net_ipx.c | 40 -
10 files changed, 2865 deletions(-)
^ permalink raw reply
* Re: [Patch net-next v3] net_sched: change tcf_del_walker() to take idrinfo->lock
From: Ido Schimmel @ 2018-09-28 15:08 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, jiri, jhs, Vlad Buslov
In-Reply-To: <20180928145900.GA17640@splinter>
On Fri, Sep 28, 2018 at 05:59:00PM +0300, Ido Schimmel wrote:
> I'm getting a use-after-free when running tc_chains.sh selftest and I
> believe it's caused by this patch.
BTW, I can't reproduce the issue after reverting the patch.
^ permalink raw reply
* Re: [Patch net-next v3] net_sched: change tcf_del_walker() to take idrinfo->lock
From: Ido Schimmel @ 2018-09-28 14:59 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, jiri, jhs, Vlad Buslov
In-Reply-To: <20180919233729.10951-1-xiyou.wangcong@gmail.com>
On Wed, Sep 19, 2018 at 04:37:29PM -0700, Cong Wang wrote:
> From: Vlad Buslov <vladbu@mellanox.com>
>
> From: Vlad Buslov <vladbu@mellanox.com>
>
> Action API was changed to work with actions and action_idr in concurrency
> safe manner, however tcf_del_walker() still uses actions without taking a
> reference or idrinfo->lock first, and deletes them directly, disregarding
> possible concurrent delete.
>
> Change tcf_del_walker() to take idrinfo->lock while iterating over actions
> and use new tcf_idr_release_unsafe() to release them while holding the
> lock.
>
> And the blocking function fl_hw_destroy_tmplt() could be called when we
> put a filter chain, so defer it to a work queue.
I'm getting a use-after-free when running tc_chains.sh selftest and I
believe it's caused by this patch.
To reproduce:
# cd tools/testing/selftests/net/forwarding
# export TESTS="template_filter_fits"; ./tc_chains.sh veth0 veth1
__tcf_chain_put()
tc_chain_tmplt_del()
fl_tmplt_destroy()
tcf_queue_work(&tmplt->rwork, fl_tmplt_destroy_work)
tcf_chain_destroy()
kfree(chain)
Some time later fl_tmplt_destroy_work() starts executing and
dereferencing 'chain'.
Splat:
[ 48.269074] ==================================================================
[ 48.270186] BUG: KASAN: use-after-free in fl_tmplt_destroy_work+0x289/0x2d0
[ 48.271199] Read of size 8 at addr ffff880067f0d498 by task kworker/u2:1/18
[ 48.272270]
[ 48.272520] CPU: 0 PID: 18 Comm: kworker/u2:1 Not tainted 4.19.0-rc5-custom+ #917
[ 48.273683] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014
[ 48.275495] Workqueue: tc_filter_workqueue fl_tmplt_destroy_work
[ 48.276387] Call Trace:
[ 48.276766] dump_stack+0x10f/0x1d8
[ 48.277302] ? dump_stack_print_info.cold.0+0x20/0x20
[ 48.278080] ? printk+0xac/0xd4
[ 48.278585] ? cpumask_weight.constprop.23+0x39/0x39
[ 48.279360] print_address_description.cold.3+0x9/0x258
[ 48.280186] kasan_report.cold.4+0x6a/0x9d
[ 48.280856] __asan_report_load8_noabort+0x19/0x20
[ 48.281642] fl_tmplt_destroy_work+0x289/0x2d0
[ 48.282331] ? fl_tmplt_destroy+0x30/0x30
[ 48.282966] process_one_work+0xb5d/0x1a10
[ 48.283642] ? kasan_check_write+0x14/0x20
[ 48.284301] ? pwq_dec_nr_in_flight+0x4e0/0x4e0
[ 48.285003] ? lock_repin_lock+0x360/0x360
[ 48.285652] ? __schedule+0x86d/0x2310
[ 48.286256] ? lockdep_hardirqs_on+0x39f/0x580
[ 48.286995] ? __sched_text_start+0x8/0x8
[ 48.287654] ? lock_downgrade+0x740/0x740
[ 48.288292] ? sched_clock_local+0xe0/0x150
[ 48.288969] ? save_trace+0x340/0x340
[ 48.289526] ? save_trace+0x340/0x340
[ 48.290156] ? check_preemption_disabled+0x3b/0x210
[ 48.290937] ? find_held_lock+0x40/0x1d0
[ 48.291598] ? debug_smp_processor_id+0x1c/0x20
[ 48.292290] ? worker_thread+0x3c3/0x12b0
[ 48.292952] ? lock_contended+0x1260/0x1260
[ 48.293606] ? _raw_spin_unlock_irq+0x2c/0x50
[ 48.294311] ? do_raw_spin_trylock+0x121/0x1c0
[ 48.294982] ? do_raw_spin_lock+0x1e0/0x1e0
[ 48.295658] ? trace_hardirqs_on+0x290/0x290
[ 48.296346] worker_thread+0x18e/0x12b0
[ 48.296972] ? lock_repin_lock+0x360/0x360
[ 48.297624] ? process_one_work+0x1a10/0x1a10
[ 48.298332] ? save_trace+0x340/0x340
[ 48.298937] ? kasan_check_write+0x14/0x20
[ 48.299639] ? sched_clock_local+0xe0/0x150
[ 48.300310] ? check_preemption_disabled+0x3b/0x210
[ 48.301064] ? check_preemption_disabled+0x3b/0x210
[ 48.301848] ? find_held_lock+0x40/0x1d0
[ 48.302472] ? debug_smp_processor_id+0x1c/0x20
[ 48.303196] ? _raw_spin_unlock_irqrestore+0x57/0x70
[ 48.304037] ? _raw_spin_unlock_irqrestore+0x57/0x70
[ 48.304862] ? lockdep_hardirqs_on+0x39f/0x580
[ 48.305595] ? trace_hardirqs_on+0xa1/0x290
[ 48.306237] ? do_raw_spin_trylock+0x121/0x1c0
[ 48.306924] ? __kthread_parkme+0xdc/0x1a0
[ 48.307607] ? preempt_schedule_common+0x1f/0xd0
[ 48.308359] ? __kthread_parkme+0x5d/0x1a0
[ 48.309014] ? __kthread_parkme+0xfa/0x1a0
[ 48.309690] ? _raw_spin_unlock_irqrestore+0x60/0x70
[ 48.310461] kthread+0x34d/0x410
[ 48.310970] ? process_one_work+0x1a10/0x1a10
[ 48.311672] ? kthread_delayed_work_timer_fn+0x450/0x450
[ 48.312548] ret_from_fork+0x24/0x30
[ 48.313114]
[ 48.313390] Allocated by task 1239:
[ 48.313983] save_stack+0x43/0xd0
[ 48.314533] kasan_kmalloc+0xc4/0xe0
[ 48.315119] kmem_cache_alloc_trace+0x124/0x280
[ 48.315873] tcf_chain_create+0xa4/0x370
[ 48.316506] tc_ctl_chain+0xe3d/0x1430
[ 48.317114] rtnetlink_rcv_msg+0x3a3/0xa80
[ 48.317799] netlink_rcv_skb+0x152/0x3c0
[ 48.318440] rtnetlink_rcv+0x21/0x30
[ 48.319042] netlink_unicast+0x52f/0x740
[ 48.319675] netlink_sendmsg+0x9c7/0xf50
[ 48.320276] sock_sendmsg+0xcf/0x120
[ 48.320853] ___sys_sendmsg+0x778/0x8f0
[ 48.321445] __sys_sendmsg+0x112/0x270
[ 48.322079] __x64_sys_sendmsg+0x7d/0xc0
[ 48.322687] do_syscall_64+0x15d/0x640
[ 48.323274] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 48.324004]
[ 48.324264] Freed by task 1248:
[ 48.324796] save_stack+0x43/0xd0
[ 48.314533] kasan_kmalloc+0xc4/0xe0
[ 48.315119] kmem_cache_alloc_trace+0x124/0x280
[ 48.315873] tcf_chain_create+0xa4/0x370
[ 48.316506] tc_ctl_chain+0xe3d/0x1430
[ 48.317114] rtnetlink_rcv_msg+0x3a3/0xa80
[ 48.317799] netlink_rcv_skb+0x152/0x3c0
[ 48.318440] rtnetlink_rcv+0x21/0x30
[ 48.319042] netlink_unicast+0x52f/0x740
[ 48.319675] netlink_sendmsg+0x9c7/0xf50
[ 48.320276] sock_sendmsg+0xcf/0x120
[ 48.320853] ___sys_sendmsg+0x778/0x8f0
[ 48.321445] __sys_sendmsg+0x112/0x270
[ 48.322079] __x64_sys_sendmsg+0x7d/0xc0
[ 48.322687] do_syscall_64+0x15d/0x640
[ 48.323274] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 48.324004]
[ 48.324264] Freed by task 1248:
[ 48.324796] save_stack+0x43/0xd0
[ 48.325355] __kasan_slab_free+0x131/0x180
[ 48.326001] kasan_slab_free+0xe/0x10
[ 48.326579] kfree+0xd7/0x2b0
[ 48.327054] __tcf_chain_put+0x339/0x710
[ 48.327654] tc_ctl_chain+0xbde/0x1430
[ 48.328276] rtnetlink_rcv_msg+0x3a3/0xa80
[ 48.328899] netlink_rcv_skb+0x152/0x3c0
[ 48.329556] rtnetlink_rcv+0x21/0x30
[ 48.330170] netlink_unicast+0x52f/0x740
[ 48.330839] netlink_sendmsg+0x9c7/0xf50
[ 48.331491] sock_sendmsg+0xcf/0x120
[ 48.332079] ___sys_sendmsg+0x778/0x8f0
[ 48.332706] __sys_sendmsg+0x112/0x270
[ 48.333334] __x64_sys_sendmsg+0x7d/0xc0
[ 48.333957] do_syscall_64+0x15d/0x640
[ 48.334581] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 48.335362]
[ 48.335645] The buggy address belongs to the object at ffff880067f0d480
[ 48.335645] which belongs to the cache kmalloc-64 of size 64
[ 48.337559] The buggy address is located 24 bytes inside of
[ 48.337559] 64-byte region [ffff880067f0d480, ffff880067f0d4c0)
[ 48.339313] The buggy address belongs to the page:
[ 48.340083] page:ffffea00019fc340 count:1 mapcount:0 mapping:ffff88006cc01780 index:0x0
[ 48.341330] flags: 0x100000000000100(slab)
[ 48.342000] raw: 0100000000000100 ffffea00019fce80 0000001100000011 ffff88006cc01780
[ 48.343163] raw: 0000000000000000 00000000002a002a 00000001ffffffff 0000000000000000
[ 48.344424] page dumped because: kasan: bad access detected
[ 48.345299]
[ 48.345580] Memory state around the buggy address:
[ 48.346356] ffff880067f0d380: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb
[ 48.347477] ffff880067f0d400: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
[ 48.348645] >ffff880067f0d480: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
[ 48.349799] ^
[ 48.350457] ffff880067f0d500: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb
[ 48.351627] ffff880067f0d580: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
[ 48.352802] ==================================================================
^ permalink raw reply
* Re: KASAN: global-out-of-bounds Read in __aa_lookupn_ns
From: Dmitry Vyukov @ 2018-09-28 15:01 UTC (permalink / raw)
To: John Johansen
Cc: syzbot, James Morris, Serge E. Hallyn, linux-security-module,
David Miller, LKML, netdev, syzkaller-bugs
In-Reply-To: <23948464-72d2-7d04-59b5-79606c24ed75@canonical.com>
On Fri, Sep 28, 2018 at 3:19 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/28/2018 01:39 AM, Dmitry Vyukov wrote:
>> On Wed, Sep 26, 2018 at 12:06 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
>>> On Wed, Sep 26, 2018 at 9:54 AM, syzbot
>>> <syzbot+71b6643475f707f93fdc@syzkaller.appspotmail.com> wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following crash on:
>>>>
>>>> HEAD commit: 02214bfc89c7 Merge tag 'media/v4.19-2' of git://git.kernel..
>>>> git tree: upstream
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1456f8a1400000
>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=22a62640793a83c9
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=71b6643475f707f93fdc
>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>>
>>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>
>>> Again misattributed to net. This misattribution should now be fixed by:
>>> https://github.com/google/syzkaller/commit/db716d6653d073b0abfb51186cd4ac2d5418c9c6
>>> Adding security/apparmor/policy_ns.c maintainers explicitly.
>>
>> This is the same as "KASAN: stack-out-of-bounds Read in __aa_lookupn_ns":
>> https://syzkaller.appspot.com/bug?id=f0d603856d8b3cc9b8e09228f2f548c18ef907ac
>> right?
>>
>
> yes it looks like it is
Let's tell syzbot then, otherwise it will consider it as open forever:
#syz dup: KASAN: stack-out-of-bounds Read in __aa_lookupn_ns
>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>> Reported-by: syzbot+71b6643475f707f93fdc@syzkaller.appspotmail.com
>>>>
>>>> sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3038
>>>> __sys_setsockopt+0x1ba/0x3c0 net/socket.c:1902
>>>> __do_sys_setsockopt net/socket.c:1913 [inline]
>>>> __se_sys_setsockopt net/socket.c:1910 [inline]
>>>> __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
>>>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>>> ==================================================================
>>>> BUG: KASAN: global-out-of-bounds in memcmp+0xe3/0x160 lib/string.c:861
>>>> Read of size 1 at addr ffffffff88000008 by task syz-executor0/10914
>>>>
>>>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>>> RIP: 0033:0x457579
>>>> Code: 1d b4 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>>>> RSP: 002b:00007f4c14533c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
>>>> RAX: ffffffffffffffda RBX: 00007f4c14533c90 RCX: 0000000000457579
>>>> RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
>>>> RBP: 000000000072bf00 R08: 0000000000000004 R09: 0000000000000000
>>>> R10: 0000000020000080 R11: 0000000000000246 R12: 00007f4c145346d4
>>>> R13: 00000000004c3ed9 R14: 00000000004d6260 R15: 0000000000000004
>>>> CPU: 0 PID: 10914 Comm: syz-executor0 Not tainted 4.19.0-rc5+ #252
>>>> 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+0x1c4/0x2b4 lib/dump_stack.c:113
>>>> print_address_description.cold.8+0x58/0x1ff mm/kasan/report.c:256
>>>> kasan_report_error mm/kasan/report.c:354 [inline]
>>>> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
>>>> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
>>>> memcmp+0xe3/0x160 lib/string.c:861
>>>> strnstr+0x4b/0x70 lib/string.c:934
>>>> __aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209
>>>> aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240
>>>> aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468
>>>> fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844
>>>> aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908
>>>> aa_label_parse+0x42/0x50 security/apparmor/label.c:1943
>>>> aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362
>>>> apparmor_setprocattr+0xa8b/0x1150 security/apparmor/lsm.c:656
>>>> security_setprocattr+0x66/0xc0 security/security.c:1298
>>>> proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555
>>>> __vfs_write+0x119/0x9f0 fs/read_write.c:485
>>>> vfs_write+0x1fc/0x560 fs/read_write.c:549
>>>> ksys_write+0x101/0x260 fs/read_write.c:598
>>>> __do_sys_write fs/read_write.c:610 [inline]
>>>> __se_sys_write fs/read_write.c:607 [inline]
>>>> __x64_sys_write+0x73/0xb0 fs/read_write.c:607
>>>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>>> RIP: 0033:0x457579
>>>> Code: 1d b4 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>>>> RSP: 002b:00007f5a92ec2c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>>> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457579
>>>> RDX: 000000000000002c RSI: 00000000200000c0 RDI: 0000000000000004
>>>> RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
>>>> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5a92ec36d4
>>>> R13: 00000000004c5454 R14: 00000000004d8c78 R15: 00000000ffffffff
>>>>
>>>> CPU: 1 PID: 10921 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #252
>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>>> Google 01/01/2011
>>>> The buggy address belongs to the variable:
>>>> __start_rodata+0x8/0x1000
>>>> Call Trace:
>>>> __dump_stack lib/dump_stack.c:77 [inline]
>>>> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
>>>>
>>>> Memory state around the buggy address:
>>>> ffffffff87ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> ffffffff87ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> fail_dump lib/fault-inject.c:51 [inline]
>>>> should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149
>>>>>
>>>>> ffffffff88000000: 00 fa fa fa fa fa fa fa 00 01 fa fa fa fa fa fa
>>>>
>>>> ^
>>>> ffffffff88000080: 00 00 00 07 fa fa fa fa 00 04 fa fa fa fa fa fa
>>>> ffffffff88000100: 05 fa fa fa fa fa fa fa 00 00 00 00 05 fa fa fa
>>>> ==================================================================
>>>>
>>>>
>>>> ---
>>>> 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#bug-status-tracking 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/23948464-72d2-7d04-59b5-79606c24ed75%40canonical.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* INVESTMENT!
From: John Rees @ 2018-09-28 14:58 UTC (permalink / raw)
To: Recipients
I'm interested in funding your business project aimed at reaching an agreement.
^ permalink raw reply
* [PATCH v4 bpf-next 10/10] selftests/bpf: cgroup local storage-based network counters
From: Roman Gushchin @ 2018-09-28 14:46 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Kernel Team, Roman Gushchin,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <20180928144452.5284-1-guro@fb.com>
This commit adds a bpf kselftest, which demonstrates how percpu
and shared cgroup local storage can be used for efficient lookup-free
network accounting.
Cgroup local storage provides generic memory area with a very efficient
lookup free access. To avoid expensive atomic operations for each
packet, per-cpu cgroup local storage is used. Each packet is initially
charged to a per-cpu counter, and only if the counter reaches certain
value (32 in this case), the charge is moved into the global atomic
counter. This allows to amortize atomic operations, keeping reasonable
accuracy.
The test also implements a naive network traffic throttling, mostly to
demonstrate the possibility of bpf cgroup--based network bandwidth
control.
Expected output:
./test_netcnt
test_netcnt:PASS
Signed-off-by: Roman Gushchin <guro@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
---
tools/testing/selftests/bpf/Makefile | 6 +-
tools/testing/selftests/bpf/netcnt_common.h | 24 +++
tools/testing/selftests/bpf/netcnt_prog.c | 71 +++++++++
tools/testing/selftests/bpf/test_netcnt.c | 158 ++++++++++++++++++++
4 files changed, 257 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/bpf/netcnt_common.h
create mode 100644 tools/testing/selftests/bpf/netcnt_prog.c
create mode 100644 tools/testing/selftests/bpf/test_netcnt.c
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 059d64a0f897..f802de526f57 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -23,7 +23,8 @@ $(TEST_CUSTOM_PROGS): $(OUTPUT)/%: %.c
TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs \
test_align test_verifier_log test_dev_cgroup test_tcpbpf_user \
test_sock test_btf test_sockmap test_lirc_mode2_user get_cgroup_id_user \
- test_socket_cookie test_cgroup_storage test_select_reuseport test_section_names
+ test_socket_cookie test_cgroup_storage test_select_reuseport test_section_names \
+ test_netcnt
TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test_obj_id.o \
test_pkt_md_access.o test_xdp_redirect.o test_xdp_meta.o sockmap_parse_prog.o \
@@ -35,7 +36,7 @@ TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test
test_get_stack_rawtp.o test_sockmap_kern.o test_sockhash_kern.o \
test_lwt_seg6local.o sendmsg4_prog.o sendmsg6_prog.o test_lirc_mode2_kern.o \
get_cgroup_id_kern.o socket_cookie_prog.o test_select_reuseport_kern.o \
- test_skb_cgroup_id_kern.o bpf_flow.o
+ test_skb_cgroup_id_kern.o bpf_flow.o netcnt_prog.o
# Order correspond to 'make run_tests' order
TEST_PROGS := test_kmod.sh \
@@ -72,6 +73,7 @@ $(OUTPUT)/test_tcpbpf_user: cgroup_helpers.c
$(OUTPUT)/test_progs: trace_helpers.c
$(OUTPUT)/get_cgroup_id_user: cgroup_helpers.c
$(OUTPUT)/test_cgroup_storage: cgroup_helpers.c
+$(OUTPUT)/test_netcnt: cgroup_helpers.c
.PHONY: force
diff --git a/tools/testing/selftests/bpf/netcnt_common.h b/tools/testing/selftests/bpf/netcnt_common.h
new file mode 100644
index 000000000000..81084c1c2c23
--- /dev/null
+++ b/tools/testing/selftests/bpf/netcnt_common.h
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+#ifndef __NETCNT_COMMON_H
+#define __NETCNT_COMMON_H
+
+#include <linux/types.h>
+
+#define MAX_PERCPU_PACKETS 32
+
+struct percpu_net_cnt {
+ __u64 packets;
+ __u64 bytes;
+
+ __u64 prev_ts;
+
+ __u64 prev_packets;
+ __u64 prev_bytes;
+};
+
+struct net_cnt {
+ __u64 packets;
+ __u64 bytes;
+};
+
+#endif
diff --git a/tools/testing/selftests/bpf/netcnt_prog.c b/tools/testing/selftests/bpf/netcnt_prog.c
new file mode 100644
index 000000000000..1198abca1360
--- /dev/null
+++ b/tools/testing/selftests/bpf/netcnt_prog.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/bpf.h>
+#include <linux/version.h>
+
+#include "bpf_helpers.h"
+#include "netcnt_common.h"
+
+#define MAX_BPS (3 * 1024 * 1024)
+
+#define REFRESH_TIME_NS 100000000
+#define NS_PER_SEC 1000000000
+
+struct bpf_map_def SEC("maps") percpu_netcnt = {
+ .type = BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
+ .key_size = sizeof(struct bpf_cgroup_storage_key),
+ .value_size = sizeof(struct percpu_net_cnt),
+};
+
+struct bpf_map_def SEC("maps") netcnt = {
+ .type = BPF_MAP_TYPE_CGROUP_STORAGE,
+ .key_size = sizeof(struct bpf_cgroup_storage_key),
+ .value_size = sizeof(struct net_cnt),
+};
+
+SEC("cgroup/skb")
+int bpf_nextcnt(struct __sk_buff *skb)
+{
+ struct percpu_net_cnt *percpu_cnt;
+ char fmt[] = "%d %llu %llu\n";
+ struct net_cnt *cnt;
+ __u64 ts, dt;
+ int ret;
+
+ cnt = bpf_get_local_storage(&netcnt, 0);
+ percpu_cnt = bpf_get_local_storage(&percpu_netcnt, 0);
+
+ percpu_cnt->packets++;
+ percpu_cnt->bytes += skb->len;
+
+ if (percpu_cnt->packets > MAX_PERCPU_PACKETS) {
+ __sync_fetch_and_add(&cnt->packets,
+ percpu_cnt->packets);
+ percpu_cnt->packets = 0;
+
+ __sync_fetch_and_add(&cnt->bytes,
+ percpu_cnt->bytes);
+ percpu_cnt->bytes = 0;
+ }
+
+ ts = bpf_ktime_get_ns();
+ dt = ts - percpu_cnt->prev_ts;
+
+ dt *= MAX_BPS;
+ dt /= NS_PER_SEC;
+
+ if (cnt->bytes + percpu_cnt->bytes - percpu_cnt->prev_bytes < dt)
+ ret = 1;
+ else
+ ret = 0;
+
+ if (dt > REFRESH_TIME_NS) {
+ percpu_cnt->prev_ts = ts;
+ percpu_cnt->prev_packets = cnt->packets;
+ percpu_cnt->prev_bytes = cnt->bytes;
+ }
+
+ return !!ret;
+}
+
+char _license[] SEC("license") = "GPL";
+__u32 _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/tools/testing/selftests/bpf/test_netcnt.c b/tools/testing/selftests/bpf/test_netcnt.c
new file mode 100644
index 000000000000..7887df693399
--- /dev/null
+++ b/tools/testing/selftests/bpf/test_netcnt.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <errno.h>
+#include <assert.h>
+#include <sys/sysinfo.h>
+#include <sys/time.h>
+
+#include <linux/bpf.h>
+#include <bpf/bpf.h>
+#include <bpf/libbpf.h>
+
+#include "cgroup_helpers.h"
+#include "bpf_rlimit.h"
+#include "netcnt_common.h"
+
+#define BPF_PROG "./netcnt_prog.o"
+#define TEST_CGROUP "/test-network-counters/"
+
+static int bpf_find_map(const char *test, struct bpf_object *obj,
+ const char *name)
+{
+ struct bpf_map *map;
+
+ map = bpf_object__find_map_by_name(obj, name);
+ if (!map) {
+ printf("%s:FAIL:map '%s' not found\n", test, name);
+ return -1;
+ }
+ return bpf_map__fd(map);
+}
+
+int main(int argc, char **argv)
+{
+ struct percpu_net_cnt *percpu_netcnt;
+ struct bpf_cgroup_storage_key key;
+ int map_fd, percpu_map_fd;
+ int error = EXIT_FAILURE;
+ struct net_cnt netcnt;
+ struct bpf_object *obj;
+ int prog_fd, cgroup_fd;
+ unsigned long packets;
+ unsigned long bytes;
+ int cpu, nproc;
+ __u32 prog_cnt;
+
+ nproc = get_nprocs_conf();
+ percpu_netcnt = malloc(sizeof(*percpu_netcnt) * nproc);
+ if (!percpu_netcnt) {
+ printf("Not enough memory for per-cpu area (%d cpus)\n", nproc);
+ goto err;
+ }
+
+ if (bpf_prog_load(BPF_PROG, BPF_PROG_TYPE_CGROUP_SKB,
+ &obj, &prog_fd)) {
+ printf("Failed to load bpf program\n");
+ goto out;
+ }
+
+ if (setup_cgroup_environment()) {
+ printf("Failed to load bpf program\n");
+ goto err;
+ }
+
+ /* Create a cgroup, get fd, and join it */
+ cgroup_fd = create_and_get_cgroup(TEST_CGROUP);
+ if (!cgroup_fd) {
+ printf("Failed to create test cgroup\n");
+ goto err;
+ }
+
+ if (join_cgroup(TEST_CGROUP)) {
+ printf("Failed to join cgroup\n");
+ goto err;
+ }
+
+ /* Attach bpf program */
+ if (bpf_prog_attach(prog_fd, cgroup_fd, BPF_CGROUP_INET_EGRESS, 0)) {
+ printf("Failed to attach bpf program");
+ goto err;
+ }
+
+ assert(system("ping localhost -6 -c 10000 -f -q > /dev/null") == 0);
+
+ if (bpf_prog_query(cgroup_fd, BPF_CGROUP_INET_EGRESS, 0, NULL, NULL,
+ &prog_cnt)) {
+ printf("Failed to query attached programs");
+ goto err;
+ }
+
+ map_fd = bpf_find_map(__func__, obj, "netcnt");
+ if (map_fd < 0) {
+ printf("Failed to find bpf map with net counters");
+ goto err;
+ }
+
+ percpu_map_fd = bpf_find_map(__func__, obj, "percpu_netcnt");
+ if (percpu_map_fd < 0) {
+ printf("Failed to find bpf map with percpu net counters");
+ goto err;
+ }
+
+ if (bpf_map_get_next_key(map_fd, NULL, &key)) {
+ printf("Failed to get key in cgroup storage\n");
+ goto err;
+ }
+
+ if (bpf_map_lookup_elem(map_fd, &key, &netcnt)) {
+ printf("Failed to lookup cgroup storage\n");
+ goto err;
+ }
+
+ if (bpf_map_lookup_elem(percpu_map_fd, &key, &percpu_netcnt[0])) {
+ printf("Failed to lookup percpu cgroup storage\n");
+ goto err;
+ }
+
+ /* Some packets can be still in per-cpu cache, but not more than
+ * MAX_PERCPU_PACKETS.
+ */
+ packets = netcnt.packets;
+ bytes = netcnt.bytes;
+ for (cpu = 0; cpu < nproc; cpu++) {
+ if (percpu_netcnt[cpu].packets > MAX_PERCPU_PACKETS) {
+ printf("Unexpected percpu value: %llu\n",
+ percpu_netcnt[cpu].packets);
+ goto err;
+ }
+
+ packets += percpu_netcnt[cpu].packets;
+ bytes += percpu_netcnt[cpu].bytes;
+ }
+
+ /* No packets should be lost */
+ if (packets != 10000) {
+ printf("Unexpected packet count: %lu\n", packets);
+ goto err;
+ }
+
+ /* Let's check that bytes counter matches the number of packets
+ * multiplied by the size of ipv6 ICMP packet.
+ */
+ if (bytes != packets * 104) {
+ printf("Unexpected bytes count: %lu\n", bytes);
+ goto err;
+ }
+
+ error = 0;
+ printf("test_netcnt:PASS\n");
+
+err:
+ cleanup_cgroup_environment();
+ free(percpu_netcnt);
+
+out:
+ return error;
+}
--
2.17.1
^ permalink raw reply related
* [PATCH iproute2-next] tc: f_flower: add geneve option match support to flower
From: Simon Horman @ 2018-09-28 14:03 UTC (permalink / raw)
To: David Ahern
Cc: Jiri Pirko, Jamal Hadi Salim, Cong Wang, netdev, oss-drivers,
Pieter Jansen van Vuuren, Simon Horman
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Allow matching on options in Geneve tunnel headers.
The options can be described in the form
CLASS:TYPE:DATA/CLASS_MASK:TYPE_MASK:DATA_MASK, where CLASS is
represented as a 16bit hexadecimal value, TYPE as an 8bit
hexadecimal value and DATA as a variable length hexadecimal value.
e.g.
# ip link add name geneve0 type geneve dstport 0 external
# tc qdisc add dev geneve0 ingress
# tc filter add dev geneve0 protocol ip parent ffff: \
flower \
enc_src_ip 10.0.99.192 \
enc_dst_ip 10.0.99.193 \
enc_key_id 11 \
geneve_opts 0102:80:1122334421314151/ffff:ff:ffffffffffffffff \
ip_proto udp \
action mirred egress redirect dev eth1
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
man/man8/tc-flower.8 | 13 ++-
tc/f_flower.c | 282 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 294 insertions(+), 1 deletion(-)
diff --git a/man/man8/tc-flower.8 b/man/man8/tc-flower.8
index 305d7efe046a..8be8882592ea 100644
--- a/man/man8/tc-flower.8
+++ b/man/man8/tc-flower.8
@@ -80,6 +80,8 @@ flower \- flow based traffic control filter
.IR TOS " | "
.B enc_ttl
.IR TTL " | "
+.B geneve_opts
+.IR OPTIONS " | "
.BR ip_flags
.IR IP_FLAGS
.SH DESCRIPTION
@@ -283,6 +285,8 @@ bits is assumed.
.BI enc_tos " NUMBER"
.TQ
.BI enc_ttl " NUMBER"
+.TQ
+.BI geneve_opts " OPTIONS"
Match on IP tunnel metadata. Key id
.I NUMBER
is a 32 bit tunnel key id (e.g. VNI for VXLAN tunnel).
@@ -295,7 +299,14 @@ is a 16 bit UDP dst port. Tos
.I NUMBER
is an 8 bit tos (dscp+ecn) value, ttl
.I NUMBER
-is an 8 bit time-to-live value.
+is an 8 bit time-to-live value. geneve_opts
+.I OPTIONS
+must be a valid list of comma-separated geneve options where each option
+consists of a key optionally followed by a slash and corresponding mask. If
+the masks is missing, \fBtc\fR assumes a full-length match. The options can
+be described in the form CLASS:TYPE:DATA/CLASS_MASK:TYPE_MASK:DATA_MASK,
+where CLASS is represented as a 16bit hexadecimal value, TYPE as an 8bit
+hexadecimal value and DATA as a variable length hexadecimal value.
.TP
.BI ip_flags " IP_FLAGS"
.I IP_FLAGS
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 59e5f572c542..4a8fb984a35a 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -79,6 +79,7 @@ static void explain(void)
" enc_key_id [ KEY-ID ] |\n"
" enc_tos MASKED-IP_TOS |\n"
" enc_ttl MASKED-IP_TTL |\n"
+ " geneve_opts MASKED-OPTIONS |\n"
" ip_flags IP-FLAGS | \n"
" enc_dst_port [ port_number ] }\n"
" FILTERID := X:Y:Z\n"
@@ -589,6 +590,179 @@ static int flower_parse_enc_port(char *str, int type, struct nlmsghdr *n)
return 0;
}
+static int flower_parse_geneve_opts(char *str, struct nlmsghdr *n)
+{
+ struct rtattr *nest;
+ char *token;
+ int i, err;
+
+ nest = addattr_nest(n, MAX_MSG, TCA_FLOWER_KEY_ENC_OPTS_GENEVE);
+
+ i = 1;
+ token = strsep(&str, ":");
+ while (token) {
+ switch (i) {
+ case TCA_FLOWER_KEY_ENC_OPT_GENEVE_CLASS:
+ {
+ __be16 opt_class;
+
+ if (!strlen(token))
+ break;
+ err = get_be16(&opt_class, token, 16);
+ if (err)
+ return err;
+
+ addattr16(n, MAX_MSG, i, opt_class);
+ break;
+ }
+ case TCA_FLOWER_KEY_ENC_OPT_GENEVE_TYPE:
+ {
+ __u8 opt_type;
+
+ if (!strlen(token))
+ break;
+ err = get_u8(&opt_type, token, 16);
+ if (err)
+ return err;
+
+ addattr8(n, MAX_MSG, i, opt_type);
+ break;
+ }
+ case TCA_FLOWER_KEY_ENC_OPT_GENEVE_DATA:
+ {
+ size_t token_len = strlen(token);
+ __u8 *opts;
+
+ if (!token_len)
+ break;
+ opts = malloc(token_len / 2);
+ if (!opts)
+ return -1;
+ if (hex2mem(token, opts, token_len / 2) < 0) {
+ free(opts);
+ return -1;
+ }
+ addattr_l(n, MAX_MSG, i, opts, token_len / 2);
+ free(opts);
+
+ break;
+ }
+ default:
+ fprintf(stderr, "Unknown \"geneve_opts\" type\n");
+ return -1;
+ }
+
+ token = strsep(&str, ":");
+ i++;
+ }
+ addattr_nest_end(n, nest);
+
+ return 0;
+}
+
+static int flower_parse_enc_opt_part(char *str, struct nlmsghdr *n)
+{
+ char *token;
+ int err;
+
+ token = strsep(&str, ",");
+ while (token) {
+ err = flower_parse_geneve_opts(token, n);
+ if (err)
+ return err;
+
+ token = strsep(&str, ",");
+ }
+
+ return 0;
+}
+
+static int flower_check_enc_opt_key(char *key)
+{
+ int key_len, col_cnt = 0;
+
+ key_len = strlen(key);
+ while ((key = strchr(key, ':'))) {
+ if (strlen(key) == key_len)
+ return -1;
+
+ key_len = strlen(key) - 1;
+ col_cnt++;
+ key++;
+ }
+
+ if (col_cnt != 2 || !key_len)
+ return -1;
+
+ return 0;
+}
+
+static int flower_parse_enc_opts(char *str, struct nlmsghdr *n)
+{
+ char key[XATTR_SIZE_MAX], mask[XATTR_SIZE_MAX];
+ int data_len, key_len, mask_len, err;
+ char *token, *slash;
+ struct rtattr *nest;
+
+ key_len = 0;
+ mask_len = 0;
+ token = strsep(&str, ",");
+ while (token) {
+ slash = strchr(token, '/');
+ if (slash)
+ *slash = '\0';
+
+ if ((key_len + strlen(token) > XATTR_SIZE_MAX) ||
+ flower_check_enc_opt_key(token))
+ return -1;
+
+ strcpy(&key[key_len], token);
+ key_len += strlen(token) + 1;
+ key[key_len - 1] = ',';
+
+ if (!slash) {
+ /* Pad out mask when not provided */
+ if (mask_len + strlen(token) > XATTR_SIZE_MAX)
+ return -1;
+
+ data_len = strlen(rindex(token, ':'));
+ sprintf(&mask[mask_len], "ffff:ff:");
+ mask_len += 8;
+ memset(&mask[mask_len], 'f', data_len - 1);
+ mask_len += data_len;
+ mask[mask_len - 1] = ',';
+ token = strsep(&str, ",");
+ continue;
+ }
+
+ if (mask_len + strlen(slash + 1) > XATTR_SIZE_MAX)
+ return -1;
+
+ strcpy(&mask[mask_len], slash + 1);
+ mask_len += strlen(slash + 1) + 1;
+ mask[mask_len - 1] = ',';
+
+ *slash = '/';
+ token = strsep(&str, ",");
+ }
+ key[key_len - 1] = '\0';
+ mask[mask_len - 1] = '\0';
+
+ nest = addattr_nest(n, MAX_MSG, TCA_FLOWER_KEY_ENC_OPTS);
+ err = flower_parse_enc_opt_part(key, n);
+ if (err)
+ return err;
+ addattr_nest_end(n, nest);
+
+ nest = addattr_nest(n, MAX_MSG, TCA_FLOWER_KEY_ENC_OPTS_MASK);
+ err = flower_parse_enc_opt_part(mask, n);
+ if (err)
+ return err;
+ addattr_nest_end(n, nest);
+
+ return 0;
+}
+
static int flower_parse_opt(struct filter_util *qu, char *handle,
int argc, char **argv, struct nlmsghdr *n)
{
@@ -1041,6 +1215,13 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
fprintf(stderr, "Illegal \"enc_ttl\"\n");
return -1;
}
+ } else if (matches(*argv, "geneve_opts") == 0) {
+ NEXT_ARG();
+ ret = flower_parse_enc_opts(*argv, n);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"geneve_opts\"\n");
+ return -1;
+ }
} else if (matches(*argv, "action") == 0) {
NEXT_ARG();
ret = parse_action(&argc, &argv, TCA_FLOWER_ACT, n);
@@ -1340,6 +1521,105 @@ static void flower_print_key_id(const char *name, struct rtattr *attr)
print_uint(PRINT_ANY, name, namefrm, rta_getattr_be32(attr));
}
+static void flower_print_geneve_opts(const char *name, struct rtattr *attr,
+ char *strbuf)
+{
+ struct rtattr *tb[TCA_FLOWER_KEY_ENC_OPT_GENEVE_MAX + 1];
+ int ii, data_len, offset = 0, slen = 0;
+ struct rtattr *i = RTA_DATA(attr);
+ int rem = RTA_PAYLOAD(attr);
+ __u8 type, data_r[rem];
+ char data[rem * 2 + 1];
+ __u16 class;
+
+ open_json_array(PRINT_JSON, name);
+ while (rem) {
+ parse_rtattr(tb, TCA_FLOWER_KEY_ENC_OPT_GENEVE_MAX, i, rem);
+ class = rta_getattr_be16(tb[TCA_FLOWER_KEY_ENC_OPT_GENEVE_CLASS]);
+ type = rta_getattr_u8(tb[TCA_FLOWER_KEY_ENC_OPT_GENEVE_TYPE]);
+ data_len = RTA_PAYLOAD(tb[TCA_FLOWER_KEY_ENC_OPT_GENEVE_DATA]);
+ hexstring_n2a(RTA_DATA(tb[TCA_FLOWER_KEY_ENC_OPT_GENEVE_DATA]),
+ data_len, data, sizeof(data));
+ hex2mem(data, data_r, data_len);
+ offset += data_len + 20;
+ rem -= data_len + 20;
+ i = RTA_DATA(attr) + offset;
+
+ open_json_object(NULL);
+ print_uint(PRINT_JSON, "class", NULL, class);
+ print_uint(PRINT_JSON, "type", NULL, type);
+ open_json_array(PRINT_JSON, "data");
+ for (ii = 0; ii < data_len; ii++)
+ print_uint(PRINT_JSON, NULL, NULL, data_r[ii]);
+ close_json_array(PRINT_JSON, "data");
+ close_json_object();
+
+ slen += sprintf(strbuf + slen, "%04x:%02x:%s",
+ class, type, data);
+ if (rem)
+ slen += sprintf(strbuf + slen, ",");
+ }
+ close_json_array(PRINT_JSON, name);
+}
+
+static void flower_print_geneve_parts(const char *name, struct rtattr *attr,
+ char *key, char *mask)
+{
+ char *namefrm = "\n geneve_opt %s";
+ char *key_token, *mask_token, *out;
+ int len;
+
+ out = malloc(RTA_PAYLOAD(attr) * 4 + 3);
+ if (!out)
+ return;
+
+ len = 0;
+ key_token = strsep(&key, ",");
+ mask_token = strsep(&mask, ",");
+ while (key_token) {
+ len += sprintf(&out[len], "%s/%s,", key_token, mask_token);
+ mask_token = strsep(&mask, ",");
+ key_token = strsep(&key, ",");
+ }
+
+ out[len - 1] = '\0';
+ print_string(PRINT_FP, name, namefrm, out);
+ free(out);
+}
+
+static void flower_print_enc_opts(const char *name, struct rtattr *attr,
+ struct rtattr *mask_attr)
+{
+ struct rtattr *key_tb[TCA_FLOWER_KEY_ENC_OPTS_MAX + 1];
+ struct rtattr *msk_tb[TCA_FLOWER_KEY_ENC_OPTS_MAX + 1];
+ char *key, *msk;
+
+ if (!attr)
+ return;
+
+ key = malloc(RTA_PAYLOAD(attr) * 2 + 1);
+ if (!key)
+ return;
+
+ msk = malloc(RTA_PAYLOAD(attr) * 2 + 1);
+ if (!msk)
+ goto err_key_free;
+
+ parse_rtattr_nested(key_tb, TCA_FLOWER_KEY_ENC_OPTS_MAX, attr);
+ flower_print_geneve_opts("geneve_opt_key",
+ key_tb[TCA_FLOWER_KEY_ENC_OPTS_GENEVE], key);
+
+ parse_rtattr_nested(msk_tb, TCA_FLOWER_KEY_ENC_OPTS_MAX, mask_attr);
+ flower_print_geneve_opts("geneve_opt_mask",
+ msk_tb[TCA_FLOWER_KEY_ENC_OPTS_GENEVE], msk);
+
+ flower_print_geneve_parts(name, attr, key, msk);
+
+ free(msk);
+err_key_free:
+ free(key);
+}
+
static void flower_print_masked_u8(const char *name, struct rtattr *attr,
struct rtattr *mask_attr,
const char *(*value_to_str)(__u8 value))
@@ -1570,6 +1850,8 @@ static int flower_print_opt(struct filter_util *qu, FILE *f,
tb[TCA_FLOWER_KEY_ENC_IP_TOS_MASK]);
flower_print_ip_attr("enc_ttl", tb[TCA_FLOWER_KEY_ENC_IP_TTL],
tb[TCA_FLOWER_KEY_ENC_IP_TTL_MASK]);
+ flower_print_enc_opts("enc_opt", tb[TCA_FLOWER_KEY_ENC_OPTS],
+ tb[TCA_FLOWER_KEY_ENC_OPTS_MASK]);
flower_print_matching_flags("ip_flags", FLOWER_IP_FLAGS,
tb[TCA_FLOWER_KEY_FLAGS],
--
2.11.0
^ permalink raw reply related
* Re: [PATCHv3 bpf-next 01/12] bpf: Add iterator for spilled registers
From: Daniel Borkmann @ 2018-09-28 13:41 UTC (permalink / raw)
To: Joe Stringer
Cc: netdev, ast, john.fastabend, tgraf, kafai, nitin.hande,
mauricio.vasquez
In-Reply-To: <20180927232659.14348-2-joe@wand.net.nz>
On 09/28/2018 01:26 AM, Joe Stringer wrote:
> Add this iterator for spilled registers, it concentrates the details of
> how to get the current frame's spilled registers into a single macro
> while clarifying the intention of the code which is calling the macro.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
> include/linux/bpf_verifier.h | 11 +++++++++++
> kernel/bpf/verifier.c | 16 +++++++---------
> 2 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index b42b60a83e19..af262b97f586 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -131,6 +131,17 @@ struct bpf_verifier_state {
> u32 curframe;
> };
>
> +#define __get_spilled_reg(slot, frame) \
> + (((slot < frame->allocated_stack / BPF_REG_SIZE) && \
> + (frame->stack[slot].slot_type[0] == STACK_SPILL)) \
> + ? &frame->stack[slot].spilled_ptr : NULL)
> +
> +/* Iterate over 'frame', setting 'reg' to either NULL or a spilled register. */
> +#define for_each_spilled_reg(iter, frame, reg) \
> + for (iter = 0, reg = __get_spilled_reg(iter, frame); \
> + iter < frame->allocated_stack / BPF_REG_SIZE; \
> + iter++, reg = __get_spilled_reg(iter, frame))
> +
(Just a very small nit: please make sure this has a bpf_ prefix given this
is a global kernel header.)
^ permalink raw reply
* Re: [PATCHv3 bpf-next 04/12] bpf: Add PTR_TO_SOCKET verifier type
From: Daniel Borkmann @ 2018-09-28 13:38 UTC (permalink / raw)
To: Joe Stringer
Cc: netdev, ast, john.fastabend, tgraf, kafai, nitin.hande,
mauricio.vasquez
In-Reply-To: <20180927232659.14348-5-joe@wand.net.nz>
On 09/28/2018 01:26 AM, Joe Stringer wrote:
> Teach the verifier a little bit about a new type of pointer, a
> PTR_TO_SOCKET. This pointer type is accessed from BPF through the
> 'struct bpf_sock' structure.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
[...]
> +/* Return true if it's OK to have the same insn return a different type. */
> +static bool reg_type_mismatch_ok(enum bpf_reg_type type)
> +{
> + switch (type) {
> + case PTR_TO_CTX:
> + case PTR_TO_SOCKET:
> + case PTR_TO_SOCKET_OR_NULL:
> + return false;
> + default:
> + return true;
> + }
> +}
> +
> +/* If an instruction was previously used with particular pointer types, then we
> + * need to be careful to avoid cases such as the below, where it may be ok
> + * for one branch accessing the pointer, but not ok for the other branch:
> + *
> + * R1 = sock_ptr
> + * goto X;
> + * ...
> + * R1 = some_other_valid_ptr;
> + * goto X;
> + * ...
> + * R2 = *(u32 *)(R1 + 0);
> + */
> +static bool reg_type_mismatch(enum bpf_reg_type src, enum bpf_reg_type prev)
> +{
> + return src != prev && (!reg_type_mismatch_ok(src) ||
> + !reg_type_mismatch_ok(prev));
> +}
> +
> static int do_check(struct bpf_verifier_env *env)
> {
> struct bpf_verifier_state *state;
> @@ -4812,9 +4894,7 @@ static int do_check(struct bpf_verifier_env *env)
> */
> *prev_src_type = src_reg_type;
>
> - } else if (src_reg_type != *prev_src_type &&
> - (src_reg_type == PTR_TO_CTX ||
> - *prev_src_type == PTR_TO_CTX)) {
> + } else if (reg_type_mismatch(src_reg_type, *prev_src_type)) {
> /* ABuser program is trying to use the same insn
> * dst_reg = *(u32*) (src_reg + off)
> * with different pointer types:
> @@ -4859,9 +4939,7 @@ static int do_check(struct bpf_verifier_env *env)
>
> if (*prev_dst_type == NOT_INIT) {
> *prev_dst_type = dst_reg_type;
> - } else if (dst_reg_type != *prev_dst_type &&
> - (dst_reg_type == PTR_TO_CTX ||
> - *prev_dst_type == PTR_TO_CTX)) {
> + } else if (reg_type_mismatch(dst_reg_type, *prev_dst_type)) {
> verbose(env, "same insn cannot be used with different pointers\n");
> return -EINVAL;
Can also be as follow-up later on, but it would be crucial to also have
test_verifier tests on this logic here with mixing these pointer types
from different branches (right now we only cover ctx there).
Thanks,
Daniel
^ permalink raw reply
* Re: [RFC PATCH v2 bpf-next 0/2] verifier liveness simplification
From: Edward Cree @ 2018-09-28 13:36 UTC (permalink / raw)
To: Jiong Wang, ast, daniel; +Cc: netdev
In-Reply-To: <0252cca7-82e4-24d3-8682-e1a613d6cd78@netronome.com>
On 26/09/18 23:16, Jiong Wang wrote:
> On 22/08/2018 20:00, Edward Cree wrote:
>> In the future this idea may be extended to form use-def chains.
>
> 1. instruction level use->def chain
>
> - new use->def chains for each instruction. one eBPF insn could have two
> uses at maximum.
I was thinking of something a lot weaker/simpler, just making
ld rX, rY
copy rY.parent into rX.parent and not read-mark rY (whereas actual
arithmetic, pointer deref etc. would still create read marks).
But what you've described sounds interesting; perhaps it would also
help later with loop-variable handling?
-Ed
^ permalink raw reply
* Re: [PATCHv3 bpf-next 04/12] bpf: Add PTR_TO_SOCKET verifier type
From: Daniel Borkmann @ 2018-09-28 13:34 UTC (permalink / raw)
To: Joe Stringer
Cc: netdev, ast, john.fastabend, tgraf, kafai, nitin.hande,
mauricio.vasquez
In-Reply-To: <20180927232659.14348-5-joe@wand.net.nz>
On 09/28/2018 01:26 AM, Joe Stringer wrote:
> Teach the verifier a little bit about a new type of pointer, a
> PTR_TO_SOCKET. This pointer type is accessed from BPF through the
> 'struct bpf_sock' structure.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
[...]
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 72db8afb7cb6..057af3dc9f08 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5394,23 +5394,29 @@ static bool __sock_filter_check_size(int off, int size,
> return size == size_default;
> }
>
> -static bool sock_filter_is_valid_access(int off, int size,
> - enum bpf_access_type type,
> - const struct bpf_prog *prog,
> - struct bpf_insn_access_aux *info)
> +bool bpf_sock_is_valid_access(int off, int size, enum bpf_access_type type,
> + struct bpf_insn_access_aux *info)
> {
> if (off < 0 || off >= sizeof(struct bpf_sock))
> return false;
> if (off % size != 0)
> return false;
> - if (!__sock_filter_check_attach_type(off, type,
> - prog->expected_attach_type))
> - return false;
> if (!__sock_filter_check_size(off, size, info))
> return false;
> return true;
> }
>
> +static bool sock_filter_is_valid_access(int off, int size,
> + enum bpf_access_type type,
> + const struct bpf_prog *prog,
> + struct bpf_insn_access_aux *info)
> +{
> + if (!__sock_filter_check_attach_type(off, type,
> + prog->expected_attach_type))
> + return false;
> + return bpf_sock_is_valid_access(off, size, type, info);
> +}
This one here should also be swapped to make it more robust, meaning the
__sock_filter_check_attach_type() should come in a second step after basic
sanity checks have been completed, not before them. E.g. out of bounds read
access would then indicate a "good" access in the first one.
^ permalink raw reply
* Re: [PATCHv3 bpf-next 04/12] bpf: Add PTR_TO_SOCKET verifier type
From: Daniel Borkmann @ 2018-09-28 13:29 UTC (permalink / raw)
To: Joe Stringer
Cc: netdev, ast, john.fastabend, tgraf, kafai, nitin.hande,
mauricio.vasquez
In-Reply-To: <20180927232659.14348-5-joe@wand.net.nz>
Hi Joe,
On 09/28/2018 01:26 AM, Joe Stringer wrote:
> Teach the verifier a little bit about a new type of pointer, a
> PTR_TO_SOCKET. This pointer type is accessed from BPF through the
> 'struct bpf_sock' structure.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
[...]
> }
> @@ -1726,6 +1755,14 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> err = check_flow_keys_access(env, off, size);
> if (!err && t == BPF_READ && value_regno >= 0)
> mark_reg_unknown(env, regs, value_regno);
> + } else if (reg->type == PTR_TO_SOCKET) {
> + if (t == BPF_WRITE) {
> + verbose(env, "cannot write into socket\n");
> + return -EACCES;
> + }
> + err = check_sock_access(env, regno, off, size, t);
> + if (!err && value_regno >= 0)
> + mark_reg_unknown(env, regs, value_regno);
Not an issue today, but this is quite fragile and very easy to miss, if we
allow to enable writes into ptr_to_socket in future e.g. mark or others,
then lifting above will not be enough. E.g. see check_xadd() and friends,
this rejects writes to ctx via f37a8cb84cce ("bpf: reject stores into ctx
via st and xadd") as otherwise this would bypass the context rewriter. So
I think we should add PTR_TO_SOCKET to is_ctx_reg() as well to have a full
guarantee this won't happen.
> } else {
> verbose(env, "R%d invalid mem access '%s'\n", regno,
> reg_type_str[reg->type]);
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: support combinations of FEC modes
From: Edward Cree @ 2018-09-28 12:58 UTC (permalink / raw)
To: Ariel Almog
Cc: linville, Linux Netdev List, ganeshgr, jakub.kicinski, dustin,
dirk.vandermerwe, shayag, ariela
In-Reply-To: <CABvr3-Hvq4nsNEfJH+ic_pFGup2iAUGjcDfXni33a6LZoSZOYw@mail.gmail.com>
On 26/09/18 09:47, Ariel Almog wrote:
> I was won
Truncated sentence? ("... wondering"?)
> I find the ability to set off, auto and specific FEC mode in the same
> command confusing.
I didn't try to define semantics here since each driver currently does
something slightly different. Probably the configuration space that's
meaningful is different for each piece of hardware anyway.
> Here are some examples
>
> 1. What is the expected result of 'off' & other FEC mode such as 'RS'?
> -'off'?
> -'RS'?
> -automatic selection {'off','RS'}? w/o setting of auto?
In sfc, 'off' overrides everything else.
The meaning (again, in sfc) of a combination of 'auto' and a specific mode
(e.g. 'rs') is "prefer the specified mode, but fall back to autoneg if
it's not supported". The combination {'rs', 'baser'} (with or without
'auto') means "use the strongest FEC supported", i.e. it will attempt to
negotiate FEC even if the cable & link partner don't request it (e.g. a
short cable).
For us, those semantics make sense (our HW has a notion of 'supported'
and 'requested' bits for each FEC type for each of local-device, cable
and link-partner, and uses the strongest FEC mode that's supported by
everyone and requested by anyone); but if something else is a better fit
for your hardware I wouldn't worry too much about the inconsistency —
people using this functionality will hopefully have read the hardware's
user manual...
-Ed
^ permalink raw reply
* Fwd: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
From: Chris Clayton @ 2018-09-28 12:54 UTC (permalink / raw)
To: netdev
In-Reply-To: <af1b08f1-1280-ff66-4a43-70fa4487838c@googlemail.com>
Forwarding to corrected netdev address.
-------- Forwarded Message --------
Subject: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
Date: Fri, 28 Sep 2018 13:14:35 +0100
From: Chris Clayton <chris2553@googlemail.com>
To: linux-netdev@vger.kernel.org
CC: David Miller <davem@davemloft.net>, a3at.mail@gmail.com, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
hkallweit1@gmail.com, nic_swsd@realtek.com
Hi,
I upgraded my kernel to 4.18.10 recently and have since been experiencing network problems after resuming from a
suspend to RAM or disk. I previously had 4.18.6 and that was OK.
The pattern of the problem is that when I first boot, the network is fine. But, after resume from suspend I find that
the time taken for a ping of one of my ISP's nameservers increases from 14-15ms to more than 1000ms. Moreover, when I
open a browser (chromium or firefox), it fails to retrieve my home page (https://www.google.co.uk) and pings of the
nameserver fail with the message "Destination Host Unreachable". Often, I can revive the network by stopping it with
/sbin/if(down,up} but sometimes it is necessary to also remove the r8169 module and load it again.
My investigation show that 4.18.7 is also OK, but 4.18.8 has the problem. So I cloned the stable tree and bisected
between 4.18.7 and 4.18.8. The outcome was:
$ git bisect bad
e366979eb8f0c3ad6446abbd81bcb3d4ac569cb3 is the first bad commit
commit e366979eb8f0c3ad6446abbd81bcb3d4ac569cb3
Author: Azat Khuzhin <a3at.mail@gmail.com>
Date: Sun Aug 26 17:03:09 2018 +0300
r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices
[ Upstream commit 05212ba8132b42047ab5d63d759c6f9c28e7eab5 ]
I have two Ethernet adapters:
r8169 0000:03:01.0 eth0: RTL8169sb/8110sb, 00:14:d1:14:2d:49, XID 10000000, IRQ 18
r8169 0000:01:00.0 eth0: RTL8168e/8111e, 64:66:b3:11:14:5d, XID 2c200000, IRQ 30
And after upgrading from linux 4.15 [1] to linux 4.18+ [2] RTL8169sb failed to
receive any packets. tcpdump shows a lot of checksum mismatch.
[1]: a0f79386a4968b4925da6db2d1daffd0605a4402
[2]: 0519359784328bfa92bf0931bf0cff3b58c16932 (4.19 merge window opened)
I started bisecting and the found that [3] breaks it. According to [4]:
"For 8110S, 8110SB, and 8110SC series, the initial value of RxConfig
needs to be set after the tx/rx is enabled."
So I moved rtl_init_rxcfg() after enabling tx/rs and now my adapter works
(RTL8168e works too).
[3]: 3559d81e76bfe3803e89f2e04cf6ef7ab4f3aace
[4]: e542a2269f232d61270ceddd42b73a4348dee2bb ("r8169: adjust the RxConfig
settings.")
Also drop "rx" from rtl_set_rx_tx_config_registers(), since it does nothing
with it already.
Fixes: 3559d81e76bfe3803e89f2e04cf6ef7ab4f3aace ("r8169: simplify
rtl_hw_start_8169")
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
Signed-off-by: Azat Khuzhin <a3at.mail@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
:040000 040000 d95481376500f1bc5569fc486bc7573ea201b617 7985ef7b56e340312fe647c7c6e2a24998981304 M drivers
Ignoring the renaming of a function, the patch added a call to rtl_init_rxcfg() to rtl_hw_start(). If I remove that call
from 4.18.10, my network no longer fails after a resume from suspend.
I should add that I get the same problem with the current 4.19 development kernel, but I haven't tried removing the call
to rtl_init_rxcfg() from the driver. I'll do that later today and report back.
Details of my ethernet device from lspci are:
05:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
(rev 0a)
Subsystem: CLEVO/KAPOK Computer RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at f0004000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at f0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
AtomicOpsCtl: ReqEn-
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Input/output error
Not readable
Kernel driver in use: r8169
Kernel modules: r8169
I'm more then happy to provide any additional diagnostics are needed to solve this and to apply diagnostic patches and
proposed fixes.
Thanks
Chris
^ permalink raw reply
* Re: [PATCH net] vxlan: use nla_put_flag for ttl inherit
From: Hangbin Liu @ 2018-09-28 12:38 UTC (permalink / raw)
To: David Miller; +Cc: Phil Sutter, netdev, Stephen Hemminger, David Ahern
In-Reply-To: <20180928103700.GC14666@orbyte.nwl.cc>
On Fri, Sep 28, 2018 at 12:37:00PM +0200, Phil Sutter wrote:
> On Fri, Sep 28, 2018 at 09:08:26AM +0800, Hangbin Liu wrote:
> > Phil pointed out that there is a mismatch between vxlan and geneve ttl inherit.
> > We should define it as a flag and use nla_put_flag to export this opiton.
>
> s/opiton/option/
>
> Apart from that, LGTM!
>
> Thanks, Phil
Opps, sorry...
Hi David,
Should I re-send a patch or will you help fix it directly?
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH net-next 00/10] Cleanups, minor additions & fixes for HNS3 driver
From: Eric Dumazet @ 2018-09-28 18:56 UTC (permalink / raw)
To: David Miller, salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm
In-Reply-To: <20180928.103826.486456665561471777.davem@davemloft.net>
On 09/28/2018 10:38 AM, David Miller wrote:
> From: Salil Mehta <salil.mehta@huawei.com>
> Date: Wed, 26 Sep 2018 19:28:30 +0100
>
>> This patch-set contains cleans-ups, minor changes and fixes to the HNS3 driver.
>
> Series applied, thank you.
>
Something seems wrong
# git grep -n HNS3_SELF_TEST_TYPE_NUM
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c:278: int st_param[HNS3_SELF_TEST_TYPE_NUM][2];
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c:316: for (i = 0; i < HNS3_SELF_TEST_TYPE_NUM; i++) {
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c: In function 'hns3_self_test':
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c:278:15: error: 'HNS3_SELF_TEST_TYPE_NUM' undeclared (first use in this function)
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c:278:15: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c:278:6: error: unused variable 'st_param' [-Werror=unused-variable]
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: permit CGROUP_DEVICE programs accessing helper bpf_get_current_cgroup_id()
From: Daniel Borkmann @ 2018-09-28 12:16 UTC (permalink / raw)
To: Roman Gushchin, Yonghong Song; +Cc: ast, netdev, kernel-team
In-Reply-To: <20180928095310.GA9018@castle.DHCP.thefacebook.com>
On 09/28/2018 11:53 AM, Roman Gushchin wrote:
> On Thu, Sep 27, 2018 at 02:37:30PM -0700, Yonghong Song wrote:
>> Currently, helper bpf_get_current_cgroup_id() is not permitted
>> for CGROUP_DEVICE type of programs. If the helper is used
>> in such cases, the verifier will log the following error:
>>
>> 0: (bf) r6 = r1
>> 1: (69) r7 = *(u16 *)(r6 +0)
>> 2: (85) call bpf_get_current_cgroup_id#80
>> unknown func bpf_get_current_cgroup_id#80
>>
>> The bpf_get_current_cgroup_id() is useful for CGROUP_DEVICE
>> type of programs in order to customize action based on cgroup id.
>> This patch added such a support.
>>
>> Cc: Roman Gushchin <guro@fb.com>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>
> Acked-by: Roman Gushchin <guro@fb.com>
Applied to bpf-next, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: fix flags check in bpf_percpu_cgroup_storage_update()
From: Daniel Borkmann @ 2018-09-28 12:11 UTC (permalink / raw)
To: Roman Gushchin, netdev; +Cc: linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <20180928110648.22973-1-guro@fb.com>
On 09/28/2018 01:06 PM, Roman Gushchin wrote:
> Fix an issue in bpf_percpu_cgroup_storage_update(): it should return
> -EINVAL on an attempt to pass BPF_NOEXIST rather than BPF_EXIST.
>
> Cgroup local storage is automatically created on attaching of a bpf
> program to a cgroup, and it can't be done from the userspace.
>
> Fixes: 0daef9b42374 ("bpf: introduce per-cpu cgroup local storage")
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
> ---
> kernel/bpf/local_storage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> index c739f6dcc3c2..190535f6d5e2 100644
> --- a/kernel/bpf/local_storage.c
> +++ b/kernel/bpf/local_storage.c
> @@ -191,7 +191,7 @@ int bpf_percpu_cgroup_storage_update(struct bpf_map *_map, void *_key,
> int cpu, off = 0;
> u32 size;
>
> - if (unlikely(map_flags & BPF_EXIST))
> + if (map_flags & BPF_NOEXIST)
> return -EINVAL;
Hmm, this is also incorrect as any future reserved flag would be accepted here and
couldn't be extended anymore. :/ And it looks like cgroup_storage_update_elem() is
doing the same today, given the cgroups local storage is still early, we should route
a patch to stable for fixing this.
Wrt this series, given the series is top of tree right now, I would prefer a fresh
respin so we have the fix integrated properly w/o follow-up. Perhaps this could also
incorporate Alexei's previous cleanup suggestions as well from today if you have a
chance.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] qed: fix spelling mistake "b_cb_registred" -> "b_cb_registered"
From: David Miller @ 2018-09-28 18:15 UTC (permalink / raw)
To: colin.king
Cc: Ariel.Elior, everest-linux-l2, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180927170454.7829-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 27 Sep 2018 18:04:54 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake struct field name, rename it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next, thanks Colin.
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix an extack message in tcf_block_find()
From: Vlad Buslov @ 2018-09-28 11:36 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, jiri, jhs
In-Reply-To: <20180927204219.17846-1-xiyou.wangcong@gmail.com>
On Thu 27 Sep 2018 at 20:42, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> It is clearly a copy-n-paste.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/sched/cls_api.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 3de47e99b788..8dd7f8af6d54 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -655,7 +655,7 @@ static struct tcf_block *tcf_block_find(struct net *net, struct Qdisc **q,
>
> *q = qdisc_refcount_inc_nz(*q);
> if (!*q) {
> - NL_SET_ERR_MSG(extack, "Parent Qdisc doesn't exists");
> + NL_SET_ERR_MSG(extack, "Can't increase Qdisc refcount");
> err = -EINVAL;
> goto errout_rcu;
> }
Is there a benefit in exposing this info to user?
For all intents and purposes Qdisc is gone at that point.
^ permalink raw reply
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Ard Biesheuvel @ 2018-09-28 17:47 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Eric Biggers, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman
In-Reply-To: <CAHmME9rJ4CewfDEqWh00ZowjWg9TaYpksVSzKSSxoKya-M8_LA@mail.gmail.com>
On 28 September 2018 at 07:46, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hi Eric,
>
> On Fri, Sep 28, 2018 at 6:55 AM Eric Biggers <ebiggers@kernel.org> wrote:
>> And you still haven't answered my question about adding a new algorithm that is
>> useful to have in both APIs. You're proposing that in most cases the crypto API
>> part will need to go through Herbert while the implementation will need to go
>> through you/Greg, right? Or will you/Greg be taking both? Or will Herbert take
>> both?
>
> If an implementation enters Zinc, it will go through my tree. If it
> enters the crypto API, it will go through Herbert's tree. If there
> wind up being messy tree dependency and merge timing issues, I can
> work this out in the usual way with Herbert. I'll be sure to discuss
> these edge cases with him when we discuss. I think there's a way to
> handle that with minimum friction.
>
>> A documentation file for Zinc is a good idea. Some of the information in your
>> commit messages should be moved there too.
>
> Will do.
>
>> I'm not trying to "politicize" this, but rather determine your criteria for
>> including algorithms in Zinc, which you haven't made clear. Since for the
>> second time you've avoided answering my question about whether you'd allow the
>> SM4 cipher in Zinc, and you designed WireGuard to be "cryptographically
>> opinionated", and you were one of the loudest voices calling for the Speck
>> cipher to be removed, and your justification for Zinc complains about cipher
>> modes from "90s cryptographers", I think it's reasonable for people to wonder
>> whether as the Zinc (i.e. Linux crypto library) maintainer you will restrict the
>> inclusion of crypto algorithms to the ones you prefer, rather than the ones that
>> users need. Note that the kernel is used by people all over the world and needs
>> to support various standards, protocols, and APIs that use different crypto
>> algorithms, not always the ones we'd like; and different users have different
>> preferences. People need to know whether the Linux kernel's crypto library will
>> meet (or be allowed to meet) their crypto needs.
>
> WireGuard is indeed quite opinionated in its primitive choices, but I
> don't think it'd be wise to apply the same design to Zinc. There are
> APIs where the goal is to have a limited set of high-level functions,
> and have those implemented in only a preferred set of primitives. NaCl
> is a good example of this -- functions like "crypto_secretbox" that
> are actually xsalsapoly under the hood. Zinc doesn't intend to become
> an API like those, but rather to provide the actual primitives for use
> cases where that specific primitive is used. Sometimes the kernel is
> in the business of being able to pick its own crypto -- random.c, tcp
> sequence numbers, big_key.c, etc -- but most of the time the kernel is
> in the business of implementing other people's crypto, for specific
> devices/protocols/diskformats. And for those use cases we need not
> some high-level API like NaCl, but rather direct access to the
> primitives that are required to implement those drivers. WireGuard is
> one such example, but so would be Bluetooth, CIFS/SMB, WiFi, and so
> on. We're in the business of writing drivers, after all. So, no, I
> don't think I'd knock down the addition of a primitive because of a
> simple preference for a different primitive, if it was clearly the
> case that the driver requiring it really benefited from having
> accessible via the plain Zinc function calls. Sorry if I hadn't made
> this clear earlier -- I thought Ard had asked more or less the same
> thing about DES and I answered accordingly, but maybe that wasn't made
> clear enough there.
>
CRC32 is another case study that I would like to bring up:
- the current status is a bit of a mess, where we treat crc32() and
crc32c() differently - the latter is exposed by libcrc32.ko as a
wrapper around the crypto API, and there is some networking code (SCTP
iirc) that puts another kludge on top of that to ensure that the code
is not used before the module is loaded
- we have C versions, scalar hw instruction based versions and
carryless multiplication based versions for various architectures
- on ST platforms, we have a synchronous hw accelerator that is 10x
faster than C code on the same platform.
AFAICT none of its current users rely on the async interface or
runtime dispatch of the 'hash'.
CRC32/c is an area that I would *really* like to clean up (and am
already doing for arm64) - just having a function call interface would
be a huge improvement but it seems to me that the choice for
monolithic modules per algo/architecture implies that we will have to
leave ST behind in this case.
On the one hand, disregarding this seems fair, at least for the
moment. On the other hand, fixing this in the crypto API, e.g., by
permitting direct function calls to synchronous hashes and without the
need to allocate a transform/request etc, blurs the line even more
where different pieces should live.
Any thoughts?
^ permalink raw reply
* Re: [PATCH net-next 00/10] Cleanups, minor additions & fixes for HNS3 driver
From: David Miller @ 2018-09-28 17:38 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm
In-Reply-To: <20180926182840.28392-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Wed, 26 Sep 2018 19:28:30 +0100
> This patch-set contains cleans-ups, minor changes and fixes to the HNS3 driver.
Series applied, thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox