* RE: [PATCH] mwifiex: remove unnecessary call to memset
From: Xinming Hu @ 2017-09-12 1:36 UTC (permalink / raw)
To: Himanshu Jha, amitkarwar@gmail.com
Cc: Nishant Sarmukadam, Ganapathi Bhat, kvalo@codeaurora.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Hi Himanshu,
> -----Original Message-----
> From: Himanshu Jha [mailto:himanshujha199640@gmail.com]
> Sent: 2017年9月11日 20:46
> To: amitkarwar@gmail.com
> Cc: Nishant Sarmukadam <nishants@marvell.com>; Ganapathi Bhat
> <gbhat@marvell.com>; Xinming Hu <huxm@marvell.com>;
> kvalo@codeaurora.org; linux-wireless@vger.kernel.org;
> netdev@vger.kernel.org; Himanshu Jha <himanshujha199640@gmail.com>
> Subject: [EXT] [PATCH] mwifiex: remove unnecessary call to memset
>
> External Email
>
> ----------------------------------------------------------------------
> call to memset to assign 0 value immediately after allocating memory with
> kzalloc is unnecesaary as kzalloc allocates the memory filled with 0 value.
>
Looks find to me, Thanks.
Regards,
Simon
> Semantic patch used to resolve this issue:
>
> @@
> expression e,e2; constant c;
> statement S;
> @@
>
> e = kzalloc(e2, c);
> if(e == NULL) S
> - memset(e, 0, e2);
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
> ---
> drivers/net/wireless/marvell/mwifiex/scan.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
> b/drivers/net/wireless/marvell/mwifiex/scan.c
> index c9d41ed..8838b88 100644
> --- a/drivers/net/wireless/marvell/mwifiex/scan.c
> +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
> @@ -1936,8 +1936,6 @@ mwifiex_active_scan_req_for_passive_chan(struct
> mwifiex_private *priv)
> if (!user_scan_cfg)
> return -ENOMEM;
>
> - memset(user_scan_cfg, 0, sizeof(*user_scan_cfg));
> -
> for (id = 0; id < MWIFIEX_USER_SCAN_CHAN_MAX; id++) {
> if (!priv->hidden_chan[id].chan_number)
> break;
> --
> 2.7.4
^ permalink raw reply
* RE: [PATCH] e1000e: changed some expensive calls of udelay to usleep_range
From: Brown, Aaron F @ 2017-09-12 1:34 UTC (permalink / raw)
To: Kardonik Michael, leoyang.li@nxp.com, Kirsher, Jeffrey T,
Brandeburg, Jesse, Shannon Nelson, Wyborny, Carolyn,
Skidmore, Donald C, Vick, Matthew, John Ronciak,
Williams, Mitch A, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Matthew Tan
In-Reply-To: <1504643244-9233-1-git-send-email-Michael.Kardonik@nxp.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Kardonik Michael
> Sent: Tuesday, September 5, 2017 1:27 PM
> To: leoyang.li@nxp.com; michael.kardonik@nxp.com; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Shannon Nelson
> <shannon.nelson@intel.com>; Wyborny, Carolyn
> <carolyn.wyborny@intel.com>; Skidmore, Donald C
> <donald.c.skidmore@intel.com>; Vick, Matthew <matthew.vick@intel.com>;
> John Ronciak <john.ronciak@intel.com>; Williams, Mitch A
> <mitch.a.williams@intel.com>; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: Matthew Tan <matthew.tan_1@nxp.com>
> Subject: [PATCH] e1000e: changed some expensive calls of udelay to
> usleep_range
>
> Calls to udelay are not preemtable by userspace so userspace
> applications experience a large (~200us) latency when running on core0.
> Instead usleep_range can be used to be more friendly to userspace
> since it is preemtable. This is due to udelay using busy-wait loops
> while usleep_rang uses hrtimers instead. It is recommended to use
> udelay when the delay is <10us since at that precision overhead of
> usleep_range hrtimer setup causes issues. However, the replaced calls
> are for 50us and 100us so this should not be not an issue.
> There is no open bug that this patch is fixing, but we see a good
> boost in zero loss performance of specific user space application
> (dpdk l3fwd) when this patch is applied: we get from 32% of 10Gb line
> to 49%.
>
> Signed-off-by: Matthew Tan <matthew.tan_1@nxp.com>
> Signed-off-by: Michael Kardonik <michael.kardonik@nxp.com>
>
> ---
> drivers/net/ethernet/intel/e1000e/phy.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
This version continues to crash the same systems as the last (an 82577 and an i218.) As before, when link partner is a lower speed (autoneg set for 100 half for this instance) and I simply bring up the interface I start getting stuck CPU messages:
----------------------------------------------------------------------------
Message from syslogd@u1459 at Sep 11 17:16:25 ...
kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kworker/2:0:4204]
Message from syslogd@u1459 at Sep 11 17:16:53 ...
kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kworker/2:0:4204]
----------------------------------------------------------------------------
System becomes unresponsive and on a reboot I am able to pull out a trace file:
----------------------------------------------------------------------------
Sep 11 17:16:00 u1459 kernel: INFO: rcu_sched self-detected stall on CPU
Sep 11 17:16:00 u1459 kernel: 2-...: (20999 ticks this GP) idle=a5a/140000000000001/0 softirq=8232/8232 fqs=5250
Sep 11 17:16:00 u1459 kernel: (t=21000 jiffies g=4013 c=4012 q=616)
Sep 11 17:16:00 u1459 kernel: NMI backtrace for cpu 2
Sep 11 17:16:00 u1459 kernel: CPU: 2 PID: 4204 Comm: kworker/2:0 Tainted: G E 4.13.0_next-queue_dev-queue_41b1c97 #39
Sep 11 17:16:00 u1459 kernel: Hardware name: /NUC5i5MYBE, BIOS MYBDWi5v.86A.0030.2016.0527.1657 05/27/2016
Sep 11 17:16:00 u1459 kernel: Workqueue: events linkwatch_event
Sep 11 17:16:00 u1459 kernel: Call Trace:
Sep 11 17:16:00 u1459 kernel: <IRQ>
Sep 11 17:16:00 u1459 kernel: dump_stack+0x51/0x78
Sep 11 17:16:00 u1459 kernel: nmi_cpu_backtrace+0xd3/0xe0
Sep 11 17:16:00 u1459 kernel: ? hw_nmi_get_sample_period+0x20/0x20
Sep 11 17:16:00 u1459 kernel: nmi_trigger_cpumask_backtrace+0xf5/0x130
Sep 11 17:16:00 u1459 kernel: arch_trigger_cpumask_backtrace+0x19/0x20
Sep 11 17:16:00 u1459 kernel: rcu_dump_cpu_stacks+0xb7/0xe0
Sep 11 17:16:00 u1459 kernel: print_cpu_stall+0xfa/0x170
Sep 11 17:16:00 u1459 kernel: ? __update_load_avg_cfs_rq+0x183/0x190
Sep 11 17:16:00 u1459 kernel: ? sched_slice+0x55/0xa0
Sep 11 17:16:00 u1459 kernel: check_cpu_stall+0x110/0x120
Sep 11 17:16:00 u1459 kernel: ? check_preempt_curr+0x73/0x90
Sep 11 17:16:00 u1459 kernel: ? ttwu_do_wakeup+0x2b/0x170
Sep 11 17:16:00 u1459 kernel: ? cpu_needs_another_gp+0x7b/0x80
Sep 11 17:16:00 u1459 kernel: ? notifier_call_chain+0x56/0x80
Sep 11 17:16:00 u1459 kernel: rcu_pending+0x5f/0x180
Sep 11 17:16:00 u1459 kernel: ? raw_notifier_call_chain+0x16/0x20
Sep 11 17:16:00 u1459 kernel: ? timekeeping_update+0xd9/0x130
Sep 11 17:16:00 u1459 kernel: rcu_check_callbacks+0x8a/0x1b0
Sep 11 17:16:00 u1459 kernel: ? account_system_index_time+0x6b/0x80
Sep 11 17:16:00 u1459 kernel: update_process_times+0x39/0x70
Sep 11 17:16:00 u1459 kernel: tick_sched_handle+0x37/0x70
Sep 11 17:16:00 u1459 kernel: tick_sched_timer+0x52/0xa0
Sep 11 17:16:00 u1459 kernel: __run_hrtimer+0x77/0x1b0
Sep 11 17:16:00 u1459 kernel: ? tick_nohz_handler+0xc0/0xc0
Sep 11 17:16:00 u1459 kernel: ? ktime_get+0x5a/0xd0
Sep 11 17:16:00 u1459 kernel: __hrtimer_run_queues+0x67/0x90
Sep 11 17:16:00 u1459 kernel: hrtimer_interrupt+0xa4/0x1d0
Sep 11 17:16:00 u1459 kernel: smp_apic_timer_interrupt+0x6b/0x140
Sep 11 17:16:00 u1459 kernel: ? irq_exit+0xa2/0xc0
Sep 11 17:16:00 u1459 kernel: ? do_IRQ+0x60/0xf0
Sep 11 17:16:00 u1459 kernel: apic_timer_interrupt+0x90/0xa0
Sep 11 17:16:00 u1459 kernel: </IRQ>
Sep 11 17:16:00 u1459 kernel: RIP: 0010:queued_spin_lock_slowpath+0x56/0x1d0
Sep 11 17:16:00 u1459 kernel: RSP: 0018:ffffc9000223f8c8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff10
Sep 11 17:16:00 u1459 kernel: RAX: 0000000000000101 RBX: ffff8802399f8000 RCX: 0000000000000101
Sep 11 17:16:00 u1459 kernel: RDX: ffffc9000223f948 RSI: 0000000000000001 RDI: ffff8802399fb1a0
Sep 11 17:16:00 u1459 kernel: RBP: ffffc9000223f968 R08: 0000000000000001 R09: ffff88024a1cf1a4
Sep 11 17:16:00 u1459 kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8802399f8840
Sep 11 17:16:00 u1459 kernel: R13: ffff88024a1cf0e4 R14: ffff88024a1cf0e4 R15: ffffc9000223fa48
Sep 11 17:16:00 u1459 kernel: ? __schedule+0x2ba/0x6d0
Sep 11 17:16:00 u1459 kernel: ? netlink_broadcast_filtered+0x15b/0x1a0
Sep 11 17:16:00 u1459 kernel: _raw_spin_lock+0x21/0x30
Sep 11 17:16:00 u1459 kernel: e1000e_get_stats64+0x2b/0x140 [e1000e]
Sep 11 17:16:00 u1459 kernel: dev_get_stats+0x3d/0xc0
Sep 11 17:16:00 u1459 kernel: ? __nla_reserve+0x53/0x70
Sep 11 17:16:00 u1459 kernel: rtnl_fill_stats+0x6b/0x150
Sep 11 17:16:00 u1459 kernel: rtnl_fill_ifinfo+0x542/0x920
Sep 11 17:16:00 u1459 kernel: ? if_nlmsg_size+0xae/0x180
Sep 11 17:16:00 u1459 kernel: rtmsg_ifinfo_build_skb+0x90/0xe0
Sep 11 17:16:00 u1459 kernel: rtmsg_ifinfo_event+0x35/0x60
Sep 11 17:16:00 u1459 kernel: rtmsg_ifinfo+0x13/0x20
Sep 11 17:16:00 u1459 kernel: netdev_state_change+0x46/0x50
Sep 11 17:16:00 u1459 kernel: linkwatch_do_dev+0x3c/0x60
Sep 11 17:16:00 u1459 kernel: __linkwatch_run_queue+0x13a/0x210
Sep 11 17:16:00 u1459 kernel: ? put_prev_entity+0x32/0x530
Sep 11 17:16:00 u1459 kernel: linkwatch_event+0x25/0x30
Sep 11 17:16:00 u1459 kernel: process_one_work+0x193/0x410
Sep 11 17:16:00 u1459 kernel: ? __schedule+0x2ba/0x6d0
Sep 11 17:16:00 u1459 kernel: ? activate_task+0x4e/0xc0
Sep 11 17:16:00 u1459 kernel: ? idle_balance+0x9d/0x2f0
Sep 11 17:16:00 u1459 kernel: ? schedule+0x3a/0xa0
Sep 11 17:16:00 u1459 kernel: worker_thread+0x7c/0x420
Sep 11 17:16:00 u1459 kernel: ? do_task_dead+0x41/0x50
Sep 11 17:16:00 u1459 kernel: ? default_wake_function+0x12/0x20
Sep 11 17:16:00 u1459 kernel: ? maybe_create_worker+0x110/0x110
Sep 11 17:16:00 u1459 kernel: ? schedule+0x3a/0xa0
Sep 11 17:16:00 u1459 kernel: ? maybe_create_worker+0x110/0x110
Sep 11 17:16:00 u1459 kernel: kthread+0x111/0x150
Sep 11 17:16:00 u1459 kernel: ? __kthread_init_worker+0x40/0x40
Sep 11 17:16:00 u1459 kernel: ret_from_fork+0x22/0x30
Sep 11 17:16:25 u1459 kernel: watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kworker/2:0:4204]
Sep 11 17:16:25 u1459 kernel: Modules linked in: e1000e ptp pps_core ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc nfsd lockd grace nfs_acl auth_rpcgss sunrpc autofs4 ipv6 crc_ccitt dm_mirror dm_region_hash dm_log vhost_net vhost tap tun kvm_intel kvm irqbypass uinput joydev ax88179_178a usbnet mii iTCO_wdt iTCO_vendor_support sg i2c_i801 lpc_ich mfd_core xhci_pci snd_hda_codec_realtek xhci_hcd snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore dm_mod(E) dax(E) ext4(E) jbd2(E) mbcache(E) sd_mod(E) ahci(E) libahci(E) i915(E) drm_kms_helper
(E) drm(E) fb_sys_fops(E)
Sep 11 17:16:25 u1459 kernel: sysimgblt(E) sysfillrect(E) syscopyarea(E) i2c_algo_bit(E) i2c_core(E) iosf_mbi(E) video(E)
Sep 11 17:16:25 u1459 kernel: CPU: 2 PID: 4204 Comm: kworker/2:0 Tainted: G E 4.13.0_next-queue_dev-queue_41b1c97 #39
Sep 11 17:16:25 u1459 kernel: Hardware name: /NUC5i5MYBE, BIOS MYBDWi5v.86A.0030.2016.0527.1657 05/27/2016
Sep 11 17:16:25 u1459 kernel: Workqueue: events linkwatch_event
Sep 11 17:16:25 u1459 kernel: task: ffff880239810080 task.stack: ffffc9000223c000
Sep 11 17:16:25 u1459 kernel: RIP: 0010:queued_spin_lock_slowpath+0x58/0x1d0
Sep 11 17:16:25 u1459 kernel: RSP: 0018:ffffc9000223f8c8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff10
Sep 11 17:16:25 u1459 kernel: RAX: 0000000000000101 RBX: ffff8802399f8000 RCX: 0000000000000101
Sep 11 17:16:25 u1459 kernel: RDX: ffffc9000223f948 RSI: 0000000000000001 RDI: ffff8802399fb1a0
Sep 11 17:16:25 u1459 kernel: RBP: ffffc9000223f968 R08: 0000000000000001 R09: ffff88024a1cf1a4
Sep 11 17:16:25 u1459 kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8802399f8840
Sep 11 17:16:25 u1459 kernel: R13: ffff88024a1cf0e4 R14: ffff88024a1cf0e4 R15: ffffc9000223fa48
Sep 11 17:16:25 u1459 kernel: FS: 0000000000000000(0000) GS:ffff880255d00000(0000) knlGS:0000000000000000
Sep 11 17:16:25 u1459 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 11 17:16:25 u1459 kernel: CR2: 00000030d7e03088 CR3: 000000024a932002 CR4: 00000000003606e0
Sep 11 17:16:25 u1459 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep 11 17:16:25 u1459 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Sep 11 17:16:25 u1459 kernel: Call Trace:
Sep 11 17:16:25 u1459 kernel: ? netlink_broadcast_filtered+0x15b/0x1a0
Sep 11 17:16:25 u1459 kernel: _raw_spin_lock+0x21/0x30
Sep 11 17:16:25 u1459 kernel: e1000e_get_stats64+0x2b/0x140 [e1000e]
Sep 11 17:16:25 u1459 kernel: dev_get_stats+0x3d/0xc0
Sep 11 17:16:25 u1459 kernel: ? __nla_reserve+0x53/0x70
Sep 11 17:16:25 u1459 kernel: rtnl_fill_stats+0x6b/0x150
Sep 11 17:16:25 u1459 kernel: rtnl_fill_ifinfo+0x542/0x920
Sep 11 17:16:25 u1459 kernel: ? if_nlmsg_size+0xae/0x180
Sep 11 17:16:25 u1459 kernel: rtmsg_ifinfo_build_skb+0x90/0xe0
Sep 11 17:16:25 u1459 kernel: rtmsg_ifinfo_event+0x35/0x60
Sep 11 17:16:25 u1459 kernel: rtmsg_ifinfo+0x13/0x20
Sep 11 17:16:25 u1459 kernel: netdev_state_change+0x46/0x50
Sep 11 17:16:25 u1459 kernel: linkwatch_do_dev+0x3c/0x60
Sep 11 17:16:25 u1459 kernel: __linkwatch_run_queue+0x13a/0x210
Sep 11 17:16:25 u1459 kernel: ? put_prev_entity+0x32/0x530
Sep 11 17:16:25 u1459 kernel: linkwatch_event+0x25/0x30
Sep 11 17:16:25 u1459 kernel: process_one_work+0x193/0x410
Sep 11 17:16:25 u1459 kernel: ? __schedule+0x2ba/0x6d0
Sep 11 17:16:25 u1459 kernel: ? activate_task+0x4e/0xc0
Sep 11 17:16:25 u1459 kernel: ? idle_balance+0x9d/0x2f0
Sep 11 17:16:25 u1459 kernel: ? schedule+0x3a/0xa0
Sep 11 17:16:25 u1459 kernel: worker_thread+0x7c/0x420
Sep 11 17:16:25 u1459 kernel: ? do_task_dead+0x41/0x50
Sep 11 17:16:25 u1459 kernel: ? default_wake_function+0x12/0x20
Sep 11 17:16:25 u1459 kernel: ? maybe_create_worker+0x110/0x110
Sep 11 17:16:25 u1459 kernel: ? schedule+0x3a/0xa0
Sep 11 17:16:25 u1459 kernel: ? maybe_create_worker+0x110/0x110
Sep 11 17:16:25 u1459 kernel: kthread+0x111/0x150
Sep 11 17:16:25 u1459 kernel: ? __kthread_init_worker+0x40/0x40
Sep 11 17:16:25 u1459 kernel: ret_from_fork+0x22/0x30
Sep 11 17:16:25 u1459 kernel: Code: 75 57 83 fe 01 89 ca 89 f0 41 0f 45 d0 f0 0f b1 17 39 f0 75 e3 83 fa 01 74 1c 8b 07 48 8d 55 e0 84 c0 89 45 e0 74 0a f3 90 8b 07 <84> c0 89 02 75 f6 66 c7 07 01 00 c9 c3 8b 37 48 8d 45 a0 81 fe
...
And repeats untill rebooted.
^ permalink raw reply
* [net-next] dummy: declare dummy devices as enumerated devices
From: Zhang Shengju @ 2017-09-12 1:32 UTC (permalink / raw)
To: davem, netdev, ezegomez
Dummy device name is enumerated by the kernel, let user space be aware
of the naming scheme used by dummy devices:
(visible in /sys/class/net/<iface>/name_assign_type).
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
---
drivers/net/dummy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index d0a1f9c..e31ab3b 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -388,7 +388,7 @@ static int __init dummy_init_one(void)
int err;
dev_dummy = alloc_netdev(sizeof(struct dummy_priv),
- "dummy%d", NET_NAME_UNKNOWN, dummy_setup);
+ "dummy%d", NET_NAME_ENUM, dummy_setup);
if (!dev_dummy)
return -ENOMEM;
--
1.8.3.1
^ permalink raw reply related
* Re: [patch net] net: sched: fix memleak for chain zero
From: Cong Wang @ 2017-09-11 23:43 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Linux Kernel Network Developers, Jamal Hadi Salim,
Jakub Kicinski, mlxsw
In-Reply-To: <20170910140338.GA1860@nanopsycho>
On Sun, Sep 10, 2017 at 7:03 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Sat, Sep 09, 2017 at 08:46:42PM CEST, xiyou.wangcong@gmail.com wrote:
>>On Thu, Sep 7, 2017 at 7:18 PM, David Miller <davem@davemloft.net> wrote:
>>>
>>> This doesn't apply cleanly any more, please respin.
>>>
>>
>>Sigh, you applied this patch despite of strong objections from me.
>>
>>I seriously doubt your tastes now, David. Fine, this code does not
>>deserve a good taste at all, let bugs stay there.
>
> Actually, the reported bug is resolved by this patch. I like your
> approach Cong, we can make it work and follow-up on this patch.
> Please stay calm and be patient...
OK. I already rebased my patches and sent v3.
^ permalink raw reply
* [Patch net v3 3/3] net_sched: carefully handle tcf_block_put()
From: Cong Wang @ 2017-09-11 23:33 UTC (permalink / raw)
To: netdev; +Cc: jiri, jakub.kicinski, jhs, Cong Wang
In-Reply-To: <20170911233332.7594-1-xiyou.wangcong@gmail.com>
As pointed out by Jiri, there is still a race condition between
tcf_block_put() and tcf_chain_destroy() in a RCU callback. There
is no way to make it correct without proper locking or synchronization,
because both operate on a shared list.
Locking is hard, because the only lock we can pick here is a spinlock,
however, in tc_dump_tfilter() we iterate this list with a sleeping
function called (tcf_chain_dump()), which makes using a lock to protect
chain_list almost impossible.
Jiri suggested the idea of holding a refcnt before flushing, this works
because it guarantees us there would be no parallel tcf_chain_destroy()
during the loop, therefore the race condition is gone. But we have to
be very careful with proper synchronization with RCU callbacks.
Suggested-by: Jiri Pirko <jiri@mellanox.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/sched/cls_api.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index d29e79d98a69..0b2219adf520 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -275,15 +275,27 @@ void tcf_block_put(struct tcf_block *block)
/* XXX: Standalone actions are not allowed to jump to any chain, and
* bound actions should be all removed after flushing. However,
- * filters are destroyed in RCU callbacks, we have to flush and wait
- * for them inside the loop, otherwise we race with RCU callbacks on
- * this list.
+ * filters are destroyed in RCU callbacks, we have to hold the chains
+ * first, otherwise we would always race with RCU callbacks on this list
+ * without proper locking.
*/
- list_for_each_entry_safe(chain, tmp, &block->chain_list, list) {
+
+ /* Wait for existing RCU callbacks to cool down. */
+ rcu_barrier();
+
+ /* Hold a refcnt for all chains, except 0, in case they are gone. */
+ list_for_each_entry(chain, &block->chain_list, list)
+ if (chain->index)
+ tcf_chain_hold(chain);
+
+ /* No race on the list, because no chain could be destroyed. */
+ list_for_each_entry(chain, &block->chain_list, list)
tcf_chain_flush(chain);
- rcu_barrier();
- }
+ /* Wait for RCU callbacks to release the reference count. */
+ rcu_barrier();
+
+ /* At this point, all the chains should have refcnt == 1. */
list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
tcf_chain_put(chain);
kfree(block);
--
2.13.0
^ permalink raw reply related
* [Patch net v3 2/3] net_sched: fix reference counting of tc filter chain
From: Cong Wang @ 2017-09-11 23:33 UTC (permalink / raw)
To: netdev; +Cc: jiri, jakub.kicinski, jhs, Cong Wang
In-Reply-To: <20170911233332.7594-1-xiyou.wangcong@gmail.com>
This patch fixes the following ugliness of tc filter chain refcnt:
a) tp proto should hold a refcnt to the chain too. This significantly
simplifies the logic.
b) Chain 0 is no longer special, it is created with refcnt=1 like any
other chains. All the ugliness in tcf_chain_put() can be gone!
c) No need to handle the flushing oddly, because block still holds
chain 0, it can not be released, this guarantees block is the last
user.
d) The race condition with RCU callbacks is easier to handle with just
a rcu_barrier(). Much easier to understand, nothing to hide. Thanks
to the previous patch. Please see also the comments in code.
e) Make the code understandable by humans, much less error-prone.
Fixes: 744a4cf63e52 ("net: sched: fix use after free when tcf_chain_destroy is called multiple times")
Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters")
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/sched/cls_api.c | 47 ++++++++++++++++++++++++++---------------------
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index c743f03cfebd..d29e79d98a69 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -182,7 +182,7 @@ static struct tcf_chain *tcf_chain_create(struct tcf_block *block,
list_add_tail(&chain->list, &block->chain_list);
chain->block = block;
chain->index = chain_index;
- chain->refcnt = 0;
+ chain->refcnt = 1;
return chain;
}
@@ -194,21 +194,20 @@ static void tcf_chain_flush(struct tcf_chain *chain)
RCU_INIT_POINTER(*chain->p_filter_chain, NULL);
while ((tp = rtnl_dereference(chain->filter_chain)) != NULL) {
RCU_INIT_POINTER(chain->filter_chain, tp->next);
+ tcf_chain_put(chain);
tcf_proto_destroy(tp);
}
}
static void tcf_chain_destroy(struct tcf_chain *chain)
{
- /* May be already removed from the list by the previous call. */
- if (!list_empty(&chain->list))
- list_del_init(&chain->list);
+ list_del(&chain->list);
+ kfree(chain);
+}
- /* There might still be a reference held when we got here from
- * tcf_block_put. Wait for the user to drop reference before free.
- */
- if (!chain->refcnt)
- kfree(chain);
+static void tcf_chain_hold(struct tcf_chain *chain)
+{
+ ++chain->refcnt;
}
struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
@@ -217,24 +216,19 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
struct tcf_chain *chain;
list_for_each_entry(chain, &block->chain_list, list) {
- if (chain->index == chain_index)
- goto incref;
+ if (chain->index == chain_index) {
+ tcf_chain_hold(chain);
+ return chain;
+ }
}
- chain = create ? tcf_chain_create(block, chain_index) : NULL;
-incref:
- if (chain)
- chain->refcnt++;
- return chain;
+ return create ? tcf_chain_create(block, chain_index) : NULL;
}
EXPORT_SYMBOL(tcf_chain_get);
void tcf_chain_put(struct tcf_chain *chain)
{
- /* Destroy unused chain, with exception of chain 0, which is the
- * default one and has to be always present.
- */
- if (--chain->refcnt == 0 && !chain->filter_chain && chain->index != 0)
+ if (--chain->refcnt == 0)
tcf_chain_destroy(chain);
}
EXPORT_SYMBOL(tcf_chain_put);
@@ -279,10 +273,19 @@ void tcf_block_put(struct tcf_block *block)
if (!block)
return;
+ /* XXX: Standalone actions are not allowed to jump to any chain, and
+ * bound actions should be all removed after flushing. However,
+ * filters are destroyed in RCU callbacks, we have to flush and wait
+ * for them inside the loop, otherwise we race with RCU callbacks on
+ * this list.
+ */
list_for_each_entry_safe(chain, tmp, &block->chain_list, list) {
tcf_chain_flush(chain);
- tcf_chain_destroy(chain);
+ rcu_barrier();
}
+
+ list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
+ tcf_chain_put(chain);
kfree(block);
}
EXPORT_SYMBOL(tcf_block_put);
@@ -360,6 +363,7 @@ static void tcf_chain_tp_insert(struct tcf_chain *chain,
rcu_assign_pointer(*chain->p_filter_chain, tp);
RCU_INIT_POINTER(tp->next, tcf_chain_tp_prev(chain_info));
rcu_assign_pointer(*chain_info->pprev, tp);
+ tcf_chain_hold(chain);
}
static void tcf_chain_tp_remove(struct tcf_chain *chain,
@@ -371,6 +375,7 @@ static void tcf_chain_tp_remove(struct tcf_chain *chain,
if (chain->p_filter_chain && tp == chain->filter_chain)
RCU_INIT_POINTER(*chain->p_filter_chain, next);
RCU_INIT_POINTER(*chain_info->pprev, next);
+ tcf_chain_put(chain);
}
static struct tcf_proto *tcf_chain_tp_find(struct tcf_chain *chain,
--
2.13.0
^ permalink raw reply related
* [Patch net v3 1/3] net_sched: get rid of tcfa_rcu
From: Cong Wang @ 2017-09-11 23:33 UTC (permalink / raw)
To: netdev; +Cc: jiri, jakub.kicinski, jhs, Cong Wang, Eric Dumazet
In-Reply-To: <20170911233332.7594-1-xiyou.wangcong@gmail.com>
gen estimator has been rewritten in commit 1c0d32fde5bd
("net_sched: gen_estimator: complete rewrite of rate estimators"),
the caller is no longer needed to wait for a grace period.
So this patch gets rid of it.
This also completely closes a race condition between action free
path and filter chain add/remove path for the following patch.
Because otherwise the nested RCU callback can't be caught by
rcu_barrier().
Please see also the comments in code.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
include/net/act_api.h | 2 --
net/sched/act_api.c | 17 ++++++++---------
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/include/net/act_api.h b/include/net/act_api.h
index 8f3d5d8b5ae0..b944e0eb93be 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -34,7 +34,6 @@ struct tc_action {
struct gnet_stats_queue tcfa_qstats;
struct net_rate_estimator __rcu *tcfa_rate_est;
spinlock_t tcfa_lock;
- struct rcu_head tcfa_rcu;
struct gnet_stats_basic_cpu __percpu *cpu_bstats;
struct gnet_stats_queue __percpu *cpu_qstats;
struct tc_cookie *act_cookie;
@@ -50,7 +49,6 @@ struct tc_action {
#define tcf_qstats common.tcfa_qstats
#define tcf_rate_est common.tcfa_rate_est
#define tcf_lock common.tcfa_lock
-#define tcf_rcu common.tcfa_rcu
/* Update lastuse only if needed, to avoid dirtying a cache line.
* We use a temp variable to avoid fetching jiffies twice.
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index a306974e2fb4..fcd7dc7b807a 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -53,10 +53,13 @@ static void tcf_action_goto_chain_exec(const struct tc_action *a,
res->goto_tp = rcu_dereference_bh(chain->filter_chain);
}
-static void free_tcf(struct rcu_head *head)
+/* XXX: For standalone actions, we don't need a RCU grace period either, because
+ * actions are always connected to filters and filters are already destroyed in
+ * RCU callbacks, so after a RCU grace period actions are already disconnected
+ * from filters. Readers later can not find us.
+ */
+static void free_tcf(struct tc_action *p)
{
- struct tc_action *p = container_of(head, struct tc_action, tcfa_rcu);
-
free_percpu(p->cpu_bstats);
free_percpu(p->cpu_qstats);
@@ -76,11 +79,7 @@ static void tcf_idr_remove(struct tcf_idrinfo *idrinfo, struct tc_action *p)
idr_remove_ext(&idrinfo->action_idr, p->tcfa_index);
spin_unlock_bh(&idrinfo->lock);
gen_kill_estimator(&p->tcfa_rate_est);
- /*
- * gen_estimator est_timer() might access p->tcfa_lock
- * or bstats, wait a RCU grace period before freeing p
- */
- call_rcu(&p->tcfa_rcu, free_tcf);
+ free_tcf(p);
}
int __tcf_idr_release(struct tc_action *p, bool bind, bool strict)
@@ -259,7 +258,7 @@ void tcf_idr_cleanup(struct tc_action *a, struct nlattr *est)
{
if (est)
gen_kill_estimator(&a->tcfa_rate_est);
- call_rcu(&a->tcfa_rcu, free_tcf);
+ free_tcf(a);
}
EXPORT_SYMBOL(tcf_idr_cleanup);
--
2.13.0
^ permalink raw reply related
* [Patch net v3 0/3] net_sched: fix filter chain reference counting
From: Cong Wang @ 2017-09-11 23:33 UTC (permalink / raw)
To: netdev; +Cc: jiri, jakub.kicinski, jhs, Cong Wang
This patchset fixes tc filter chain reference counting and nasty race
conditions with RCU callbacks. Please see each patch for details.
---
v3: Rebase on the latest -net
Add code comment in patch 1
Improve comment and changelog for patch 2
Add patch 3
v2: Add patch 1
Get rid of more ugly code in patch 2
Cong Wang (3):
net_sched: get rid of tcfa_rcu
net_sched: fix reference counting of tc filter chain
net_sched: carefully handle tcf_block_put()
include/net/act_api.h | 2 --
net/sched/act_api.c | 17 +++++++-------
net/sched/cls_api.c | 63 ++++++++++++++++++++++++++++++++-------------------
3 files changed, 48 insertions(+), 34 deletions(-)
--
2.13.0
^ permalink raw reply
* [PATCH net] tcp/dccp: remove reqsk_put() from inet_child_forget()
From: Eric Dumazet @ 2017-09-11 22:58 UTC (permalink / raw)
To: Shankara Pailoor, David Miller
Cc: Linux Kernel Network Developers, Cong Wang, Andrew Zhu Aday
In-Reply-To: <CAASgV=txONWMR2_au12ASV40mP0mf6O=4DLoq3+FfGubqG4NQQ@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Back in linux-4.4, I inadvertently put a call to reqsk_put() in
inet_child_forget(), forgetting it could be called from two different
points.
In the case it is called from inet_csk_reqsk_queue_add(), we want to
keep the reference on the request socket, since it is released later by
the caller (tcp_v{4|6}_rcv())
This bug never showed up because atomic_dec_and_test() was not signaling
the underflow, and SLAB_DESTROY_BY RCU semantic for request sockets
prevented the request to be put in quarantine.
Recent conversion of socket refcount from atomic_t to refcount_t finally
exposed the bug.
So move the reqsk_put() to inet_csk_listen_stop() to fix this.
Thanks to Shankara Pailoor for using syzkaller and providing
a nice set of .config and C repro.
WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186
refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186
Kernel panic - not syncing: panic_on_warn set ...
CPU: 2 PID: 4277 Comm: syz-executor0 Not tainted 4.13.0-rc7 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xf7/0x1aa lib/dump_stack.c:52
panic+0x1ae/0x3a7 kernel/panic.c:180
__warn+0x1c4/0x1d9 kernel/panic.c:541
report_bug+0x211/0x2d0 lib/bug.c:183
fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190
do_trap_no_signal arch/x86/kernel/traps.c:224 [inline]
do_trap+0x260/0x390 arch/x86/kernel/traps.c:273
do_error_trap+0x118/0x340 arch/x86/kernel/traps.c:310
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323
invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:846
RIP: 0010:refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186
RSP: 0018:ffff88006e006b60 EFLAGS: 00010286
RAX: 0000000000000026 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000026 RSI: 1ffff1000dc00d2c RDI: ffffed000dc00d60
RBP: ffff88006e006bf0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1000dc00d6d
R13: 00000000ffffffff R14: 0000000000000001 R15: ffff88006ce9d340
refcount_dec_and_test+0x1a/0x20 lib/refcount.c:211
reqsk_put+0x71/0x2b0 include/net/request_sock.h:123
tcp_v4_rcv+0x259e/0x2e20 net/ipv4/tcp_ipv4.c:1729
ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216
NF_HOOK include/linux/netfilter.h:248 [inline]
ip_local_deliver+0x1ce/0x6d0 net/ipv4/ip_input.c:257
dst_input include/net/dst.h:477 [inline]
ip_rcv_finish+0x8db/0x19c0 net/ipv4/ip_input.c:397
NF_HOOK include/linux/netfilter.h:248 [inline]
ip_rcv+0xc3f/0x17d0 net/ipv4/ip_input.c:488
__netif_receive_skb_core+0x1fb7/0x31f0 net/core/dev.c:4298
__netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4336
process_backlog+0x1c5/0x6d0 net/core/dev.c:5102
napi_poll net/core/dev.c:5499 [inline]
net_rx_action+0x6d3/0x14a0 net/core/dev.c:5565
__do_softirq+0x2cb/0xb2d kernel/softirq.c:284
do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:898
</IRQ>
do_softirq.part.16+0x63/0x80 kernel/softirq.c:328
do_softirq kernel/softirq.c:176 [inline]
__local_bh_enable_ip+0x84/0x90 kernel/softirq.c:181
local_bh_enable include/linux/bottom_half.h:31 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:705 [inline]
ip_finish_output2+0x8ad/0x1360 net/ipv4/ip_output.c:231
ip_finish_output+0x74e/0xb80 net/ipv4/ip_output.c:317
NF_HOOK_COND include/linux/netfilter.h:237 [inline]
ip_output+0x1cc/0x850 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:471 [inline]
ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124
ip_queue_xmit+0x8c6/0x1810 net/ipv4/ip_output.c:504
tcp_transmit_skb+0x1963/0x3320 net/ipv4/tcp_output.c:1123
tcp_send_ack.part.35+0x38c/0x620 net/ipv4/tcp_output.c:3575
tcp_send_ack+0x49/0x60 net/ipv4/tcp_output.c:3545
tcp_rcv_synsent_state_process net/ipv4/tcp_input.c:5795 [inline]
tcp_rcv_state_process+0x4876/0x4b60 net/ipv4/tcp_input.c:5930
tcp_v4_do_rcv+0x58a/0x820 net/ipv4/tcp_ipv4.c:1483
sk_backlog_rcv include/net/sock.h:907 [inline]
__release_sock+0x124/0x360 net/core/sock.c:2223
release_sock+0xa4/0x2a0 net/core/sock.c:2715
inet_wait_for_connect net/ipv4/af_inet.c:557 [inline]
__inet_stream_connect+0x671/0xf00 net/ipv4/af_inet.c:643
inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:682
SYSC_connect+0x204/0x470 net/socket.c:1628
SyS_connect+0x24/0x30 net/socket.c:1609
entry_SYSCALL_64_fastpath+0x18/0xad
RIP: 0033:0x451e59
RSP: 002b:00007f474843fc08 EFLAGS: 00000216 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 0000000000451e59
RDX: 0000000000000010 RSI: 0000000020002000 RDI: 0000000000000007
RBP: 0000000000000046 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000216 R12: 0000000000000000
R13: 00007ffc040a0f8f R14: 00007f47484409c0 R15: 0000000000000000
Fixes: ebb516af60e1 ("tcp/dccp: fix race at listener dismantle phase")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Shankara Pailoor <sp3485@columbia.edu>
Tested-by: Shankara Pailoor <sp3485@columbia.edu>
---
net/ipv4/inet_connection_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 4089c013cb03b12e31ddffbb7ae903542c012ae0..b9c64b40a83af1e151f553ba0e624fae5060ffd0 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -916,7 +916,6 @@ static void inet_child_forget(struct sock *sk, struct request_sock *req,
tcp_sk(child)->fastopen_rsk = NULL;
}
inet_csk_destroy_sock(child);
- reqsk_put(req);
}
struct sock *inet_csk_reqsk_queue_add(struct sock *sk,
@@ -987,6 +986,7 @@ void inet_csk_listen_stop(struct sock *sk)
sock_hold(child);
inet_child_forget(sk, req, child);
+ reqsk_put(req);
bh_unlock_sock(child);
local_bh_enable();
sock_put(child);
^ permalink raw reply related
* Re: [RFC PATCH] net: Introduce a socket option to enable picking tx queue based on rx queue.
From: Alexander Duyck @ 2017-09-11 22:50 UTC (permalink / raw)
To: Tom Herbert
Cc: Samudrala, Sridhar, Alexander Duyck,
Linux Kernel Network Developers
In-Reply-To: <CALx6S37XvbjcRon6g+gS19wj14SebL4qKFrVeGyagG0K2EStzA@mail.gmail.com>
On Mon, Sep 11, 2017 at 3:07 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Mon, Sep 11, 2017 at 9:49 AM, Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
>> On 9/10/2017 8:19 AM, Tom Herbert wrote:
>>>
>>> On Thu, Aug 31, 2017 at 4:27 PM, Sridhar Samudrala
>>> <sridhar.samudrala@intel.com> wrote:
>>>>
>>>> This patch introduces a new socket option SO_SYMMETRIC_QUEUES that can be
>>>> used
>>>> to enable symmetric tx and rx queues on a socket.
>>>>
>>>> This option is specifically useful for epoll based multi threaded
>>>> workloads
>>>> where each thread handles packets received on a single RX queue . In this
>>>> model,
>>>> we have noticed that it helps to send the packets on the same TX queue
>>>> corresponding to the queue-pair associated with the RX queue specifically
>>>> when
>>>> busy poll is enabled with epoll().
>>>>
>>>> Two new fields are added to struct sock_common to cache the last rx
>>>> ifindex and
>>>> the rx queue in the receive path of an SKB. __netdev_pick_tx() returns
>>>> the cached
>>>> rx queue when this option is enabled and the TX is happening on the same
>>>> device.
>>>>
>>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>>> ---
>>>> include/net/request_sock.h | 1 +
>>>> include/net/sock.h | 17 +++++++++++++++++
>>>> include/uapi/asm-generic/socket.h | 2 ++
>>>> net/core/dev.c | 8 +++++++-
>>>> net/core/sock.c | 10 ++++++++++
>>>> net/ipv4/tcp_input.c | 1 +
>>>> net/ipv4/tcp_ipv4.c | 1 +
>>>> net/ipv4/tcp_minisocks.c | 1 +
>>>> 8 files changed, 40 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/net/request_sock.h b/include/net/request_sock.h
>>>> index 23e2205..c3bc12e 100644
>>>> --- a/include/net/request_sock.h
>>>> +++ b/include/net/request_sock.h
>>>> @@ -100,6 +100,7 @@ static inline struct sock *req_to_sk(struct
>>>> request_sock *req)
>>>> req_to_sk(req)->sk_prot = sk_listener->sk_prot;
>>>> sk_node_init(&req_to_sk(req)->sk_node);
>>>> sk_tx_queue_clear(req_to_sk(req));
>>>> + req_to_sk(req)->sk_symmetric_queues =
>>>> sk_listener->sk_symmetric_queues;
>>>> req->saved_syn = NULL;
>>>> refcount_set(&req->rsk_refcnt, 0);
>>>>
>>>> diff --git a/include/net/sock.h b/include/net/sock.h
>>>> index 03a3625..3421809 100644
>>>> --- a/include/net/sock.h
>>>> +++ b/include/net/sock.h
>>>> @@ -138,11 +138,14 @@ void SOCK_DEBUG(const struct sock *sk, const char
>>>> *msg, ...)
>>>> * @skc_node: main hash linkage for various protocol lookup tables
>>>> * @skc_nulls_node: main hash linkage for TCP/UDP/UDP-Lite protocol
>>>> * @skc_tx_queue_mapping: tx queue number for this connection
>>>> + * @skc_rx_queue_mapping: rx queue number for this connection
>>>> + * @skc_rx_ifindex: rx ifindex for this connection
>>>> * @skc_flags: place holder for sk_flags
>>>> * %SO_LINGER (l_onoff), %SO_BROADCAST, %SO_KEEPALIVE,
>>>> * %SO_OOBINLINE settings, %SO_TIMESTAMPING settings
>>>> * @skc_incoming_cpu: record/match cpu processing incoming packets
>>>> * @skc_refcnt: reference count
>>>> + * @skc_symmetric_queues: symmetric tx/rx queues
>>>> *
>>>> * This is the minimal network layer representation of sockets, the
>>>> header
>>>> * for struct sock and struct inet_timewait_sock.
>>>> @@ -177,6 +180,7 @@ struct sock_common {
>>>> unsigned char skc_reuseport:1;
>>>> unsigned char skc_ipv6only:1;
>>>> unsigned char skc_net_refcnt:1;
>>>> + unsigned char skc_symmetric_queues:1;
>>>> int skc_bound_dev_if;
>>>> union {
>>>> struct hlist_node skc_bind_node;
>>>> @@ -214,6 +218,8 @@ struct sock_common {
>>>> struct hlist_nulls_node skc_nulls_node;
>>>> };
>>>> int skc_tx_queue_mapping;
>>>> + int skc_rx_queue_mapping;
>>>> + int skc_rx_ifindex;
>>>> union {
>>>> int skc_incoming_cpu;
>>>> u32 skc_rcv_wnd;
>>>> @@ -324,6 +330,8 @@ struct sock {
>>>> #define sk_nulls_node __sk_common.skc_nulls_node
>>>> #define sk_refcnt __sk_common.skc_refcnt
>>>> #define sk_tx_queue_mapping __sk_common.skc_tx_queue_mapping
>>>> +#define sk_rx_queue_mapping __sk_common.skc_rx_queue_mapping
>>>> +#define sk_rx_ifindex __sk_common.skc_rx_ifindex
>>>>
>>>> #define sk_dontcopy_begin __sk_common.skc_dontcopy_begin
>>>> #define sk_dontcopy_end __sk_common.skc_dontcopy_end
>>>> @@ -340,6 +348,7 @@ struct sock {
>>>> #define sk_reuseport __sk_common.skc_reuseport
>>>> #define sk_ipv6only __sk_common.skc_ipv6only
>>>> #define sk_net_refcnt __sk_common.skc_net_refcnt
>>>> +#define sk_symmetric_queues __sk_common.skc_symmetric_queues
>>>> #define sk_bound_dev_if __sk_common.skc_bound_dev_if
>>>> #define sk_bind_node __sk_common.skc_bind_node
>>>> #define sk_prot __sk_common.skc_prot
>>>> @@ -1676,6 +1685,14 @@ static inline int sk_tx_queue_get(const struct
>>>> sock *sk)
>>>> return sk ? sk->sk_tx_queue_mapping : -1;
>>>> }
>>>>
>>>> +static inline void sk_mark_rx_queue(struct sock *sk, struct sk_buff
>>>> *skb)
>>>> +{
>>>> + if (sk->sk_symmetric_queues) {
>>>> + sk->sk_rx_ifindex = skb->skb_iif;
>>>> + sk->sk_rx_queue_mapping = skb_get_rx_queue(skb);
>>>> + }
>>>> +}
>>>> +
>>>> static inline void sk_set_socket(struct sock *sk, struct socket *sock)
>>>> {
>>>> sk_tx_queue_clear(sk);
>>>> diff --git a/include/uapi/asm-generic/socket.h
>>>> b/include/uapi/asm-generic/socket.h
>>>> index e47c9e4..f6b416e 100644
>>>> --- a/include/uapi/asm-generic/socket.h
>>>> +++ b/include/uapi/asm-generic/socket.h
>>>> @@ -106,4 +106,6 @@
>>>>
>>>> #define SO_ZEROCOPY 60
>>>>
>>>> +#define SO_SYMMETRIC_QUEUES 61
>>>> +
>>>> #endif /* __ASM_GENERIC_SOCKET_H */
>>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>>> index 270b547..d96cda8 100644
>>>> --- a/net/core/dev.c
>>>> +++ b/net/core/dev.c
>>>> @@ -3322,7 +3322,13 @@ static u16 __netdev_pick_tx(struct net_device
>>>> *dev, struct sk_buff *skb)
>>>>
>>>> if (queue_index < 0 || skb->ooo_okay ||
>>>> queue_index >= dev->real_num_tx_queues) {
>>>> - int new_index = get_xps_queue(dev, skb);
>>>> + int new_index = -1;
>>>> +
>>>> + if (sk && sk->sk_symmetric_queues && dev->ifindex ==
>>>> sk->sk_rx_ifindex)
>>>> + new_index = sk->sk_rx_queue_mapping;
>>>> +
>>>> + if (new_index < 0 || new_index >=
>>>> dev->real_num_tx_queues)
>>>> + new_index = get_xps_queue(dev, skb);
>>>
>>> This enforces that notion of queue pairs which is not universal
>>> concept to NICs. There are many devices and instances where we
>>> purposely avoid having a 1-1 relationship between rx and tx queues.
>>
>>
>> Yes. This patch assumes that TX and RX queues come in pairs.
>>
>>> An alternative might be to create a rx queue to tx queue map, add the
>>> rx queue argument to get_xps_queue, and then that function can
>>> consider the mapping. The administrator can configure the mapping as
>>> appropriate and can select which rx queues are subject to the mapping.
>>
>> This alternative looks much cleaner and doesn't require the apps to
>> configure the
>> queues. Do we need to support 1 to many rx to tx queue mappings?
>> For our symmetric queues usecase, where a single application thread is
>> associated with
>> 1 queue-pair, 1-1 mapping is sufficient.
>> Do you see any usecase where it is useful to support 1-many mappings?
>> I guess i can add a sysfs entry per rx-queue to setup a tx-queue OR
>> tx-queue-map.
>
> There is no reason do disallow 1 to many, XPS already does that. In
> fact, the mapping algorithm in XSP is pretty much what is needed where
> instead of mapping a CPU to a queue set, this just maps a rx queue to
> queue set. ooo handling can still be done, although it might be less
> critical in this case.
>
> Tom
Actually I wonder if we couldn't re-purpose the queue_mapping field
that is already there in the sk_buff for this. It might provide a more
elegant way to deal with the logic for already dealing with the
recorded Rx queue at the start of __skb_tx_hash. Then if the socket
wants this it could send down the packet with the queue_mapping field
set and we would be using some the map to figure out the Rx to Tx
mapping for either routing/bridging or this socket option.
Anyway just a thought.
- Alex
^ permalink raw reply
* Re: broken vlan support on Realtek RTL8111/8168/8411 rev 9
From: Francois Romieu @ 2017-09-11 22:23 UTC (permalink / raw)
To: Benoit Panizzon; +Cc: netdev
In-Reply-To: <20170910191645.549d2a3a@krup.woody.ch>
Benoit Panizzon <benoit.panizzon@imp.ch> :
[...]
> It's not marked as fixed but:
>
> when I try to turn offloading off I get:
>
> # /sbin/ethtool -K eth0 rx-vlan-offload off
> ethtool: bad command line argument(s)
> For more information run ethtool -h
>
> Could anyone give me a hint how to further debug the problem or disable
> vlan offloading completely?
ethtool -K eth0 rxvlan off
For my reward, please send a complete dmesg where the messages from
the vanilla r8169 module appear for the rev 09 card (r81..f ?). I won't
dig it right now.
--
Ueimor
^ permalink raw reply
* Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
From: Paweł Staszewski @ 2017-09-11 22:11 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paolo Abeni, Jesper Dangaard Brouer,
Linux Kernel Network Developers, Alexander Duyck
In-Reply-To: <0123de5c-a7ad-7e62-b7d0-cd19bd34c573@itcare.pl>
Another test for this patch with linux-next tree
with patch:
bwm-ng v0.6.1 (probing every 1.000s), press 'h' for help
input: /proc/net/dev type: rate
- iface Rx Tx Total
==============================================================================
vlan1004: 1.00 P/s 606842.31 P/s 606843.31 P/s
lo: 0.00 P/s 0.00 P/s
0.00 P/s
vlan1016: 0.00 P/s 607730.56 P/s 607730.56 P/s
vlan1020: 0.00 P/s 606891.25 P/s 606891.25 P/s
vlan1018: 0.00 P/s 607580.88 P/s 607580.88 P/s
vlan1014: 0.00 P/s 607606.81 P/s 607606.81 P/s
vlan1005: 0.00 P/s 606788.44 P/s 606788.44 P/s
enp2s0f0: 2.00 P/s 2.00 P/s
3.99 P/s
vlan1017: 0.00 P/s 607643.75 P/s 607643.75 P/s
enp132s0: 13079658.00 P/s 0.00 P/s 13079658.00 P/s
vlan1000: 0.00 P/s 604409.19 P/s 604409.19 P/s
vlan1010: 0.00 P/s 606984.06 P/s 606984.06 P/s
vlan1019: 0.00 P/s 607452.12 P/s 607452.12 P/s
vlan1008: 0.00 P/s 606803.44 P/s 606803.44 P/s
vlan1011: 0.00 P/s 607048.94 P/s 607048.94 P/s
vlan1001: 0.00 P/s 606773.50 P/s 606773.50 P/s
vlan1006: 0.00 P/s 606811.38 P/s 606811.38 P/s
vlan1012: 0.00 P/s 607051.94 P/s 607051.94 P/s
vlan1013: 0.00 P/s 607067.88 P/s 607067.88 P/s
enp4s0: 2.00 P/s 13020803.00 P/s 13020805.00 P/s
vlan1007: 0.00 P/s 606798.44 P/s 606798.44 P/s
vlan1002: 0.00 P/s 606840.31 P/s 606840.31 P/s
vlan1009: 0.00 P/s 606809.38 P/s 606809.38 P/s
enp2s0f1: 100.80 P/s 0.00 P/s
100.80 P/s
vlan1015: 0.00 P/s 607089.81 P/s 607089.81 P/s
vlan1003: 1.00 P/s 606928.19 P/s 606929.19 P/s
------------------------------------------------------------------------------
total: 13079765.00 P/s 25766758.00 P/s 38846524.00 P/s
13Mpps forwarded (32cores active for two mlx5 nics)
80% cpu load (20%idle all cores)
PerfTop: 126552 irqs/sec kernel:99.3% exact: 0.0% [4000Hz
cycles], (all, 32 CPUs)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
8.25% [kernel] [k] fib_table_lookup
7.98% [kernel] [k] do_raw_spin_lock
6.20% [kernel] [k] mlx5e_handle_rx_cqe_mpwrq
4.21% [kernel] [k] mlx5e_xmit
3.37% [kernel] [k] __dev_queue_xmit
2.95% [kernel] [k] ip_rcv
2.72% [kernel] [k] ipt_do_table
2.24% [kernel] [k] ip_finish_output2
2.22% [kernel] [k] __netif_receive_skb_core
2.17% [kernel] [k] ip_forward
2.15% [kernel] [k] __build_skb
1.99% [kernel] [k] ip_route_input_rcu
1.70% [kernel] [k] mlx5e_txwqe_complete
1.54% [kernel] [k] dev_gro_receive
1.45% [kernel] [k] mlx5_cqwq_get_cqe
1.38% [kernel] [k] udp_v4_early_demux
1.35% [kernel] [k] netif_skb_features
1.33% [kernel] [k] inet_gro_receive
1.29% [kernel] [k] dev_hard_start_xmit
1.27% [kernel] [k] ip_rcv_finish
1.19% [kernel] [k] mlx5e_build_rx_skb
1.15% [kernel] [k] __netdev_pick_tx
1.11% [kernel] [k] kmem_cache_alloc
1.09% [kernel] [k] mlx5e_poll_tx_cq
1.07% [kernel] [k] mlx5e_txwqe_build_dsegs
1.00% [kernel] [k] vlan_dev_hard_start_xmit
0.90% [kernel] [k] __napi_alloc_skb
0.87% [kernel] [k] validate_xmit_skb
0.87% [kernel] [k] read_tsc
0.83% [kernel] [k] napi_gro_receive
0.79% [kernel] [k] skb_network_protocol
0.79% [kernel] [k] sch_direct_xmit
0.78% [kernel] [k] __local_bh_enable_ip
0.78% [kernel] [k] netdev_pick_tx
0.75% [kernel] [k] __udp4_lib_lookup
0.72% [kernel] [k] netif_receive_skb_internal
0.71% [kernel] [k] page_frag_free
0.71% [kernel] [k] deliver_ptype_list_skb
0.70% [kernel] [k] fib_validate_source
0.69% [kernel] [k] mlx5_cqwq_get_cqe
0.69% [kernel] [k] __netif_receive_skb
0.68% [kernel] [k] vlan_passthru_hard_header
0.61% [kernel] [k] rt_cache_valid
0.59% [kernel] [k] iptable_filter_hook
Without patch:
12,7Mpps forwarded (32cores active for two mlx5 nics)
100% cpu load ( rx drops on receiving side )
TX is about 13.05Mpps from pktgen
bwm-ng v0.6.1 (probing every 1.000s), press 'h' for help
input: /proc/net/dev type: rate
/ iface Rx Tx Total
==============================================================================
vlan1004: 0.00 P/s 589709.31 P/s 589709.31 P/s
lo: 0.00 P/s 0.00 P/s
0.00 P/s
vlan1016: 0.00 P/s 589495.50 P/s 589495.50 P/s
vlan1020: 0.00 P/s 589968.06 P/s 589968.06 P/s
vlan1018: 0.00 P/s 589896.12 P/s 589896.12 P/s
vlan1014: 0.00 P/s 589496.50 P/s 589496.50 P/s
vlan1005: 0.00 P/s 589502.50 P/s 589502.50 P/s
enp2s0f0: 42.96 P/s 2.00 P/s
44.96 P/s
vlan1017: 0.00 P/s 589508.50 P/s 589508.50 P/s
enp132s0: 12700689.00 P/s 0.00 P/s 12700689.00 P/s
vlan1000: 0.00 P/s 587671.38 P/s 587671.38 P/s
vlan1010: 0.00 P/s 589330.69 P/s 589330.69 P/s
vlan1019: 0.00 P/s 589808.19 P/s 589808.19 P/s
vlan1008: 0.00 P/s 589283.75 P/s 589283.75 P/s
vlan1011: 0.00 P/s 589482.56 P/s 589482.56 P/s
vlan1001: 0.00 P/s 589971.06 P/s 589971.06 P/s
vlan1006: 0.00 P/s 589785.25 P/s 589785.25 P/s
vlan1012: 0.00 P/s 589494.50 P/s 589494.50 P/s
vlan1013: 0.00 P/s 589495.50 P/s 589495.50 P/s
enp4s0: 0.00 P/s 12601841.00 P/s 12601841.00 P/s
vlan1007: 0.00 P/s 589537.50 P/s 589537.50 P/s
vlan1002: 0.00 P/s 589943.06 P/s 589943.06 P/s
vlan1009: 0.00 P/s 589306.69 P/s 589306.69 P/s
enp2s0f1: 99.90 P/s 0.00 P/s
99.90 P/s
vlan1015: 0.00 P/s 589553.44 P/s 589553.44 P/s
vlan1003: 0.00 P/s 589823.19 P/s 589823.19 P/s
------------------------------------------------------------------------------
total: 12700832.00 P/s 24981906.00 P/s 37682740.00 P/s
PerfTop: 124056 irqs/sec kernel:99.3% exact: 0.0% [4000Hz
cycles], (all, 32 CPUs)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
7.77% [kernel] [k] fib_table_lookup
7.37% [kernel] [k] do_raw_spin_lock
5.43% [kernel] [k] mlx5e_handle_rx_cqe_mpwrq
3.84% [kernel] [k] mlx5e_xmit
3.52% [kernel] [k] rt_cache_valid
3.46% [kernel] [k] ip_finish_output2
3.45% [kernel] [k] skb_dst_force
2.96% [kernel] [k] dst_release
2.62% [kernel] [k] __dev_queue_xmit
2.54% [kernel] [k] ip_rcv
2.26% [kernel] [k] ipt_do_table
1.97% [kernel] [k] __build_skb
1.94% [kernel] [k] __netif_receive_skb_core
1.94% [kernel] [k] ip_route_input_rcu
1.83% [kernel] [k] ip_forward
1.52% [kernel] [k] mlx5e_txwqe_complete
1.42% [kernel] [k] dev_gro_receive
1.31% [kernel] [k] mlx5_cqwq_get_cqe
1.28% [kernel] [k] netif_skb_features
1.21% [kernel] [k] ip_rcv_finish
1.18% [kernel] [k] inet_gro_receive
1.17% [kernel] [k] udp_v4_early_demux
1.14% [kernel] [k] dev_hard_start_xmit
1.03% [kernel] [k] mlx5e_txwqe_build_dsegs
1.02% [kernel] [k] mlx5e_poll_tx_cq
1.02% [kernel] [k] mlx5e_build_rx_skb
1.00% [kernel] [k] kmem_cache_alloc
0.95% [kernel] [k] __netdev_pick_tx
0.93% [kernel] [k] vlan_dev_hard_start_xmit
0.82% [kernel] [k] __napi_alloc_skb
0.79% [kernel] [k] read_tsc
0.76% [kernel] [k] validate_xmit_skb
0.75% [kernel] [k] napi_gro_receive
0.71% [kernel] [k] __local_bh_enable_ip
0.70% [kernel] [k] sch_direct_xmit
0.67% [kernel] [k] page_frag_free
0.66% [kernel] [k] skb_network_protocol
0.66% [kernel] [k] nf_hook_slow
0.63% [kernel] [k] netif_receive_skb_internal
0.62% [kernel] [k] vlan_passthru_hard_header
0.62% [kernel] [k] deliver_ptype_list_skb
0.62% [kernel] [k] __netif_receive_skb
0.61% [kernel] [k] fib_validate_source
0.61% [kernel] [k] mlx5_cqwq_get_cqe
0.55% [kernel] [k] eth_type_trans
0.55% [kernel] [k] iptable_filter_hook
0.53% [kernel] [k] __udp4_lib_lookup
0.53% [kernel] [k] udp_gro_receive
0.51% [kernel] [k] eth_header
0.49% [kernel] [k] fib_lookup.constprop.49
0.48% [kernel] [k] ip_output
0.44% [kernel] [k] netdev_pick_tx
0.43% [kernel] [k] validate_xmit_skb_list
0.42% [kernel] [k] swiotlb_map_page
0.41% [kernel] [k] dma_sync_single_for_cpu.constprop.36
0.41% [kernel] [k] mlx5_cqwq_get_wqe
0.39% [kernel] [k] eth_type_vlan
0.38% [kernel] [k] udp4_gro_receive
0.37% [kernel] [k] __jhash_nwords
0.37% [kernel] [k] ip_forward_finish
0.33% [kernel] [k] ip_finish_output
0.33% [kernel] [k] neigh_connected_output
0.31% [kernel] [k] mlx5e_features_check
0.29% [kernel] [k] ktime_get_with_offset
0.27% [kernel] [k] __udp4_lib_lookup_skb
0.27% [kernel] [k] napi_consume_skb
0.26% [kernel] [k] page_frag_alloc
0.26% [kernel] [k] get_dma_ops
0.25% [kernel] [k] udp4_portaddr_hash.isra.29
0.24% [kernel] [k] skb_dst_drop.isra.76
0.24% [kernel] [k] neigh_resolve_output
0.24% [kernel] [k] skb_release_data
0.22% [kernel] [k] kmem_cache_free_bulk
0.22% [kernel] [k] get_dma_ops
0.22% [kernel] [k] _kfree_skb_defer
0.21% [kernel] [k] ip_skb_dst_mtu
0.21% [kernel] [k] is_swiotlb_buffer
0.21% [kernel] [k] find_exception
0.21% [kernel] [k] compound_head
0.21% [kernel] [k] __net_timestamp.isra.89
W dniu 2017-09-11 o 18:57, Paweł Staszewski pisze:
> Tested with connectx-5
>
> Without patch
>
> 10Mpps - > 16 cores used
>
> PerfTop: 66258 irqs/sec kernel:99.3% exact: 0.0% [4000Hz
> cycles], (all, 32 CPUs)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
> 10.12% [kernel] [k] do_raw_spin_lock
> 6.31% [kernel] [k] fib_table_lookup
> 6.12% [kernel] [k] mlx5e_handle_rx_cqe_mpwrq
> 4.90% [kernel] [k] rt_cache_valid
> 3.99% [kernel] [k] mlx5e_xmit
> 3.03% [kernel] [k] ip_rcv
> 2.68% [kernel] [k] __netif_receive_skb_core
> 2.54% [kernel] [k] skb_dst_force
> 2.41% [kernel] [k] ip_finish_output2
> 2.21% [kernel] [k] __build_skb
> 2.03% [kernel] [k] __dev_queue_xmit
> 1.96% [kernel] [k] mlx5e_txwqe_complete
> 1.79% [kernel] [k] ipt_do_table
> 1.78% [kernel] [k] inet_gro_receive
> 1.69% [kernel] [k] ip_forward
> 1.66% [kernel] [k] udp_v4_early_demux
> 1.65% [kernel] [k] dst_release
> 1.56% [kernel] [k] ip_rcv_finish
> 1.45% [kernel] [k] dev_gro_receive
> 1.45% [kernel] [k] netif_skb_features
> 1.39% [kernel] [k] mlx5e_poll_tx_cq
> 1.35% [kernel] [k] mlx5e_txwqe_build_dsegs
> 1.35% [kernel] [k] ip_route_input_rcu
> 1.15% [kernel] [k] dev_hard_start_xmit
> 1.12% [kernel] [k] napi_gro_receive
> 1.07% [kernel] [k] netif_receive_skb_internal
> 0.98% [kernel] [k] sch_direct_xmit
> 0.95% [kernel] [k] kmem_cache_alloc
> 0.89% [kernel] [k] read_tsc
> 0.88% [kernel] [k] mlx5e_build_rx_skb
> 0.86% [kernel] [k] mlx5_cqwq_get_cqe
> 0.82% [kernel] [k] page_frag_free
> 0.78% [kernel] [k] __local_bh_enable_ip
> 0.69% [kernel] [k] skb_network_protocol
> 0.68% [kernel] [k] __netif_receive_skb
> 0.67% [kernel] [k] vlan_dev_hard_start_xmit
> 0.65% [kernel] [k] mlx5e_poll_rx_cq
> 0.65% [kernel] [k] validate_xmit_skb
> 0.60% [kernel] [k] eth_type_trans
> 0.60% [kernel] [k] deliver_ptype_list_skb
> 0.60% [kernel] [k] fib_validate_source
> 0.55% [kernel] [k] eth_header
> 0.53% [kernel] [k] netdev_pick_tx
> 0.53% [kernel] [k] __napi_alloc_skb
> 0.51% [kernel] [k] __udp4_lib_lookup
> 0.50% [kernel] [k] eth_type_vlan
> 0.49% [kernel] [k] ip_output
> 0.49% [kernel] [k] page_frag_alloc
> 0.49% [kernel] [k] ip_finish_output
> 0.48% [kernel] [k] neigh_connected_output
> 0.45% [kernel] [k] nf_hook_slow
> 0.44% [kernel] [k] udp4_gro_receive
> 0.39% [kernel] [k] mlx5e_features_check
> 0.39% [kernel] [k] mlx5e_napi_poll
> 0.37% [kernel] [k] __jhash_nwords
> 0.37% [kernel] [k] udp_gro_receive
> 0.36% [kernel] [k] swiotlb_map_page
> 0.33% [kernel] [k] mlx5_cqwq_get_wqe
> 0.33% [kernel] [k] __netdev_pick_tx
> 0.29% [kernel] [k] ktime_get_with_offset
> 0.29% [kernel] [k] get_dma_ops
> 0.29% [kernel] [k] validate_xmit_skb_list
> 0.26% [kernel] [k] vlan_passthru_hard_header
> 0.26% [kernel] [k] __udp4_lib_lookup_skb
> 0.24% [kernel] [k] get_dma_ops
> 0.24% [kernel] [k] skb_release_data
> 0.23% [kernel] [k] ip_forward_finish
> 0.23% [kernel] [k] kmem_cache_free_bulk
> 0.23% [kernel] [k] timekeeping_get_ns
> 0.22% [kernel] [k] ip_skb_dst_mtu
> 0.21% [kernel] [k] compound_head
> 0.20% [kernel] [k] skb_gro_reset_offset
> 0.20% [kernel] [k] is_swiotlb_buffer
> 0.19% [kernel] [k] __net_timestamp.isra.90
> 0.19% [kernel] [k] dst_metric.constprop.61
> 0.18% [kernel] [k] skb_orphan_frags.constprop.126
> 0.18% [kernel] [k] _kfree_skb_defer
> 0.18% [kernel] [k] irq_entries_start
> 0.17% [kernel] [k] dev_hard_header.constprop.54
> 0.17% [kernel] [k] dma_mapping_error
> 0.17% [kernel] [k] neigh_resolve_output
>
>
>
>
> With patch
>
> 12Mpps -> 16 cores
>
> PerfTop: 66209 irqs/sec kernel:99.3% exact: 0.0% [4000Hz
> cycles], (all, 32 CPUs)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
> 10.67% [kernel] [k] do_raw_spin_lock
> 6.96% [kernel] [k] fib_table_lookup
> 6.53% [kernel] [k] mlx5e_handle_rx_cqe_mpwrq
> 4.17% [kernel] [k] mlx5e_xmit
> 3.22% [kernel] [k] ip_rcv
> 3.07% [kernel] [k] __netif_receive_skb_core
> 2.86% [kernel] [k] __dev_queue_xmit
> 2.36% [kernel] [k] __build_skb
> 2.33% [kernel] [k] ip_forward
> 2.05% [kernel] [k] mlx5e_txwqe_complete
> 2.02% [kernel] [k] ip_finish_output2
> 2.00% [kernel] [k] ipt_do_table
> 1.84% [kernel] [k] ip_rcv_finish
> 1.83% [kernel] [k] inet_gro_receive
> 1.80% [kernel] [k] udp_v4_early_demux
> 1.61% [kernel] [k] dev_gro_receive
> 1.55% [kernel] [k] netif_skb_features
> 1.52% [kernel] [k] mlx5e_txwqe_build_dsegs
> 1.47% [kernel] [k] mlx5e_poll_tx_cq
> 1.39% [kernel] [k] ip_route_input_rcu
> 1.38% [kernel] [k] dev_hard_start_xmit
> 1.17% [kernel] [k] netif_receive_skb_internal
> 1.16% [kernel] [k] napi_gro_receive
> 1.03% [kernel] [k] kmem_cache_alloc
> 1.02% [kernel] [k] sch_direct_xmit
> 0.97% [kernel] [k] read_tsc
> 0.94% [kernel] [k] page_frag_free
> 0.91% [kernel] [k] mlx5_cqwq_get_cqe
> 0.90% [kernel] [k] mlx5e_build_rx_skb
> 0.89% [kernel] [k] skb_network_protocol
> 0.83% [kernel] [k] __local_bh_enable_ip
> 0.79% [kernel] [k] validate_xmit_skb
> 0.77% [kernel] [k] vlan_dev_hard_start_xmit
> 0.74% [kernel] [k] __netif_receive_skb
> 0.72% [kernel] [k] mlx5e_poll_rx_cq
> 0.70% [kernel] [k] netdev_pick_tx
> 0.69% [kernel] [k] eth_type_vlan
> 0.68% [kernel] [k] __netdev_pick_tx
> 0.66% [kernel] [k] nf_hook_slow
> 0.65% [kernel] [k] deliver_ptype_list_skb
> 0.62% [kernel] [k] fib_validate_source
> 0.61% [kernel] [k] eth_header
> 0.60% [kernel] [k] eth_type_trans
> 0.59% [kernel] [k] __udp4_lib_lookup
> 0.58% [kernel] [k] __napi_alloc_skb
> 0.53% [kernel] [k] ip_finish_output
> 0.51% [kernel] [k] neigh_connected_output
> 0.50% [kernel] [k] ip_output
> 0.50% [kernel] [k] rt_cache_valid
> 0.44% [kernel] [k] udp4_gro_receive
> 0.43% [kernel] [k] mlx5e_napi_poll
> 0.40% [kernel] [k] udp_gro_receive
> 0.40% [kernel] [k] page_frag_alloc
> 0.40% [kernel] [k] __jhash_nwords
> 0.39% [kernel] [k] swiotlb_map_page
> 0.38% [kernel] [k] mlx5_cqwq_get_wqe
> 0.36% [kernel] [k] mlx5e_features_check
> 0.32% [kernel] [k] get_dma_ops
> 0.31% [kernel] [k] ktime_get_with_offset
> 0.31% [kernel] [k] validate_xmit_skb_list
> 0.28% [kernel] [k] vlan_passthru_hard_header
> 0.28% [kernel] [k] get_dma_ops
> 0.27% [kernel] [k] __udp4_lib_lookup_skb
> 0.26% [kernel] [k] skb_gro_reset_offset
> 0.25% [kernel] [k] skb_release_data
> 0.25% [kernel] [k] timekeeping_get_ns
> 0.24% [kernel] [k] kmem_cache_free_bulk
> 0.24% [kernel] [k] ip_forward_finish
> 0.23% [kernel] [k] compound_head
> 0.23% [kernel] [k] ip_skb_dst_mtu
> 0.22% [kernel] [k] __net_timestamp.isra.90
> 0.22% [kernel] [k] is_swiotlb_buffer
> 0.21% [kernel] [k] neigh_resolve_output
> 0.21% [kernel] [k] dst_metric.constprop.61
> 0.20% [kernel] [k] skb_orphan_frags.constprop.126
> 0.20% [kernel] [k] irq_entries_start
> 0.19% [kernel] [k] mlx5e_calc_min_inline
> 0.19% [kernel] [k] dev_hard_header.constprop.54
> 0.19% [kernel] [k] _kfree_skb_defer
> 0.18% [kernel] [k] _raw_spin_lock
> 0.18% [kernel] [k] ip_route_input_noref
>
>
>
>
>
> W dniu 2017-09-09 o 11:03, Paweł Staszewski pisze:
>> Hi
>>
>>
>> Are there any plans to have this fix normally in kernel ?
>>
>> Or it is mostly only hack - not longterm fix and need to be different ?
>>
>>
>> All tests that was done shows that without this patch there is about
>> 20-30% network forwarding performance degradation when using vlan
>> interfaces
>>
>>
>> Thanks
>> Paweł
>>
>>
>>
>> W dniu 2017-08-15 o 03:17, Eric Dumazet pisze:
>>> On Mon, 2017-08-14 at 18:07 -0700, Eric Dumazet wrote:
>>>
>>>> Or try to hack the IFF_XMIT_DST_RELEASE flag on the vlan netdev.
>>> Something like :
>>>
>>> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
>>> index
>>> 5e831de3103e2f7092c7fa15534def403bc62fb4..9472de846d5c0960996261cb2843032847fa4bf7
>>> 100644
>>> --- a/net/8021q/vlan_netlink.c
>>> +++ b/net/8021q/vlan_netlink.c
>>> @@ -143,6 +143,7 @@ static int vlan_newlink(struct net *src_net,
>>> struct net_device *dev,
>>> vlan->vlan_proto = proto;
>>> vlan->vlan_id = nla_get_u16(data[IFLA_VLAN_ID]);
>>> vlan->real_dev = real_dev;
>>> + dev->priv_flags |= (real_dev->priv_flags & IFF_XMIT_DST_RELEASE);
>>> vlan->flags = VLAN_FLAG_REORDER_HDR;
>>> err = vlan_check_real_dev(real_dev, vlan->vlan_proto,
>>> vlan->vlan_id);
>>>
>>>
>>>
>>>
>>
>>
>
>
^ permalink raw reply
* Re: [RFC PATCH] net: Introduce a socket option to enable picking tx queue based on rx queue.
From: Tom Herbert @ 2017-09-11 22:07 UTC (permalink / raw)
To: Samudrala, Sridhar; +Cc: Alexander Duyck, Linux Kernel Network Developers
In-Reply-To: <f98198c4-16f2-5271-3e12-7984a03bd6db@intel.com>
On Mon, Sep 11, 2017 at 9:49 AM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
> On 9/10/2017 8:19 AM, Tom Herbert wrote:
>>
>> On Thu, Aug 31, 2017 at 4:27 PM, Sridhar Samudrala
>> <sridhar.samudrala@intel.com> wrote:
>>>
>>> This patch introduces a new socket option SO_SYMMETRIC_QUEUES that can be
>>> used
>>> to enable symmetric tx and rx queues on a socket.
>>>
>>> This option is specifically useful for epoll based multi threaded
>>> workloads
>>> where each thread handles packets received on a single RX queue . In this
>>> model,
>>> we have noticed that it helps to send the packets on the same TX queue
>>> corresponding to the queue-pair associated with the RX queue specifically
>>> when
>>> busy poll is enabled with epoll().
>>>
>>> Two new fields are added to struct sock_common to cache the last rx
>>> ifindex and
>>> the rx queue in the receive path of an SKB. __netdev_pick_tx() returns
>>> the cached
>>> rx queue when this option is enabled and the TX is happening on the same
>>> device.
>>>
>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>> ---
>>> include/net/request_sock.h | 1 +
>>> include/net/sock.h | 17 +++++++++++++++++
>>> include/uapi/asm-generic/socket.h | 2 ++
>>> net/core/dev.c | 8 +++++++-
>>> net/core/sock.c | 10 ++++++++++
>>> net/ipv4/tcp_input.c | 1 +
>>> net/ipv4/tcp_ipv4.c | 1 +
>>> net/ipv4/tcp_minisocks.c | 1 +
>>> 8 files changed, 40 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/net/request_sock.h b/include/net/request_sock.h
>>> index 23e2205..c3bc12e 100644
>>> --- a/include/net/request_sock.h
>>> +++ b/include/net/request_sock.h
>>> @@ -100,6 +100,7 @@ static inline struct sock *req_to_sk(struct
>>> request_sock *req)
>>> req_to_sk(req)->sk_prot = sk_listener->sk_prot;
>>> sk_node_init(&req_to_sk(req)->sk_node);
>>> sk_tx_queue_clear(req_to_sk(req));
>>> + req_to_sk(req)->sk_symmetric_queues =
>>> sk_listener->sk_symmetric_queues;
>>> req->saved_syn = NULL;
>>> refcount_set(&req->rsk_refcnt, 0);
>>>
>>> diff --git a/include/net/sock.h b/include/net/sock.h
>>> index 03a3625..3421809 100644
>>> --- a/include/net/sock.h
>>> +++ b/include/net/sock.h
>>> @@ -138,11 +138,14 @@ void SOCK_DEBUG(const struct sock *sk, const char
>>> *msg, ...)
>>> * @skc_node: main hash linkage for various protocol lookup tables
>>> * @skc_nulls_node: main hash linkage for TCP/UDP/UDP-Lite protocol
>>> * @skc_tx_queue_mapping: tx queue number for this connection
>>> + * @skc_rx_queue_mapping: rx queue number for this connection
>>> + * @skc_rx_ifindex: rx ifindex for this connection
>>> * @skc_flags: place holder for sk_flags
>>> * %SO_LINGER (l_onoff), %SO_BROADCAST, %SO_KEEPALIVE,
>>> * %SO_OOBINLINE settings, %SO_TIMESTAMPING settings
>>> * @skc_incoming_cpu: record/match cpu processing incoming packets
>>> * @skc_refcnt: reference count
>>> + * @skc_symmetric_queues: symmetric tx/rx queues
>>> *
>>> * This is the minimal network layer representation of sockets, the
>>> header
>>> * for struct sock and struct inet_timewait_sock.
>>> @@ -177,6 +180,7 @@ struct sock_common {
>>> unsigned char skc_reuseport:1;
>>> unsigned char skc_ipv6only:1;
>>> unsigned char skc_net_refcnt:1;
>>> + unsigned char skc_symmetric_queues:1;
>>> int skc_bound_dev_if;
>>> union {
>>> struct hlist_node skc_bind_node;
>>> @@ -214,6 +218,8 @@ struct sock_common {
>>> struct hlist_nulls_node skc_nulls_node;
>>> };
>>> int skc_tx_queue_mapping;
>>> + int skc_rx_queue_mapping;
>>> + int skc_rx_ifindex;
>>> union {
>>> int skc_incoming_cpu;
>>> u32 skc_rcv_wnd;
>>> @@ -324,6 +330,8 @@ struct sock {
>>> #define sk_nulls_node __sk_common.skc_nulls_node
>>> #define sk_refcnt __sk_common.skc_refcnt
>>> #define sk_tx_queue_mapping __sk_common.skc_tx_queue_mapping
>>> +#define sk_rx_queue_mapping __sk_common.skc_rx_queue_mapping
>>> +#define sk_rx_ifindex __sk_common.skc_rx_ifindex
>>>
>>> #define sk_dontcopy_begin __sk_common.skc_dontcopy_begin
>>> #define sk_dontcopy_end __sk_common.skc_dontcopy_end
>>> @@ -340,6 +348,7 @@ struct sock {
>>> #define sk_reuseport __sk_common.skc_reuseport
>>> #define sk_ipv6only __sk_common.skc_ipv6only
>>> #define sk_net_refcnt __sk_common.skc_net_refcnt
>>> +#define sk_symmetric_queues __sk_common.skc_symmetric_queues
>>> #define sk_bound_dev_if __sk_common.skc_bound_dev_if
>>> #define sk_bind_node __sk_common.skc_bind_node
>>> #define sk_prot __sk_common.skc_prot
>>> @@ -1676,6 +1685,14 @@ static inline int sk_tx_queue_get(const struct
>>> sock *sk)
>>> return sk ? sk->sk_tx_queue_mapping : -1;
>>> }
>>>
>>> +static inline void sk_mark_rx_queue(struct sock *sk, struct sk_buff
>>> *skb)
>>> +{
>>> + if (sk->sk_symmetric_queues) {
>>> + sk->sk_rx_ifindex = skb->skb_iif;
>>> + sk->sk_rx_queue_mapping = skb_get_rx_queue(skb);
>>> + }
>>> +}
>>> +
>>> static inline void sk_set_socket(struct sock *sk, struct socket *sock)
>>> {
>>> sk_tx_queue_clear(sk);
>>> diff --git a/include/uapi/asm-generic/socket.h
>>> b/include/uapi/asm-generic/socket.h
>>> index e47c9e4..f6b416e 100644
>>> --- a/include/uapi/asm-generic/socket.h
>>> +++ b/include/uapi/asm-generic/socket.h
>>> @@ -106,4 +106,6 @@
>>>
>>> #define SO_ZEROCOPY 60
>>>
>>> +#define SO_SYMMETRIC_QUEUES 61
>>> +
>>> #endif /* __ASM_GENERIC_SOCKET_H */
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index 270b547..d96cda8 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -3322,7 +3322,13 @@ static u16 __netdev_pick_tx(struct net_device
>>> *dev, struct sk_buff *skb)
>>>
>>> if (queue_index < 0 || skb->ooo_okay ||
>>> queue_index >= dev->real_num_tx_queues) {
>>> - int new_index = get_xps_queue(dev, skb);
>>> + int new_index = -1;
>>> +
>>> + if (sk && sk->sk_symmetric_queues && dev->ifindex ==
>>> sk->sk_rx_ifindex)
>>> + new_index = sk->sk_rx_queue_mapping;
>>> +
>>> + if (new_index < 0 || new_index >=
>>> dev->real_num_tx_queues)
>>> + new_index = get_xps_queue(dev, skb);
>>
>> This enforces that notion of queue pairs which is not universal
>> concept to NICs. There are many devices and instances where we
>> purposely avoid having a 1-1 relationship between rx and tx queues.
>
>
> Yes. This patch assumes that TX and RX queues come in pairs.
>
>> An alternative might be to create a rx queue to tx queue map, add the
>> rx queue argument to get_xps_queue, and then that function can
>> consider the mapping. The administrator can configure the mapping as
>> appropriate and can select which rx queues are subject to the mapping.
>
> This alternative looks much cleaner and doesn't require the apps to
> configure the
> queues. Do we need to support 1 to many rx to tx queue mappings?
> For our symmetric queues usecase, where a single application thread is
> associated with
> 1 queue-pair, 1-1 mapping is sufficient.
> Do you see any usecase where it is useful to support 1-many mappings?
> I guess i can add a sysfs entry per rx-queue to setup a tx-queue OR
> tx-queue-map.
There is no reason do disallow 1 to many, XPS already does that. In
fact, the mapping algorithm in XSP is pretty much what is needed where
instead of mapping a CPU to a queue set, this just maps a rx queue to
queue set. ooo handling can still be done, although it might be less
critical in this case.
Tom
^ permalink raw reply
* Re: WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186
From: Eric Dumazet @ 2017-09-11 21:58 UTC (permalink / raw)
To: Shankara Pailoor
Cc: LKML, syzkaller, David Miller, Linux Kernel Network Developers,
Cong Wang, Andrew Zhu Aday
In-Reply-To: <CAASgV=txONWMR2_au12ASV40mP0mf6O=4DLoq3+FfGubqG4NQQ@mail.gmail.com>
On Mon, 2017-09-11 at 17:43 -0400, Shankara Pailoor wrote:
> Hi Eric,
>
> I applied your patch and I no longer observed the warning. Thanks! I
> will let you know if any further problems show up during fuzzing.
Great, I also verified this fixed the problem, I will send the official
patch shortly.
Thanks !
^ permalink raw reply
* Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain
From: Cong Wang @ 2017-09-11 21:58 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Linux Kernel Network Developers, Jakub Kicinski, Jiri Pirko
In-Reply-To: <CAM_iQpV2p25iZg7sd7jpcN0nuAPmwVUa3-J8F_oGC26aTTPtWw@mail.gmail.com>
On Mon, Sep 11, 2017 at 2:14 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> Looks like all due to the lack of locking on block->chain_list.
> I thought the rcu_barrier() could properly handle this,
> but seems still not, probably I need to move it in the loop,
> I am still not 100% sure if it is totally safe with
> list_for_each_safe():
>
>
> - list_for_each_entry(chain, &block->chain_list, list)
> + list_for_each_entry_safe(chain, tmp, &block->chain_list, list) {
> tcf_chain_flush(chain);
> - rcu_barrier();
> + rcu_barrier(); // are we safe now???
> + }
>
Answer myself: No, this is not safe either, because we may
list_del() the next node, and apparently _safe() can't guarantee
that...
So either we have to use locking or use the trick you suggested.
^ permalink raw reply
* Re: WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186
From: Shankara Pailoor @ 2017-09-11 21:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: LKML, syzkaller, David Miller, Linux Kernel Network Developers,
Cong Wang, Andrew Zhu Aday
In-Reply-To: <1505100843.15310.113.camel@edumazet-glaptop3.roam.corp.google.com>
Hi Eric,
I applied your patch and I no longer observed the warning. Thanks! I
will let you know if any further problems show up during fuzzing.
Regards,
Shankara
On Sun, Sep 10, 2017 at 11:34 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2017-09-08 at 11:46 -0700, Eric Dumazet wrote:
>> On Fri, 2017-09-08 at 10:21 -0700, Cong Wang wrote:
>> > (Cc'ing netdev)
>> >
>> > On Fri, Sep 8, 2017 at 5:59 AM, Shankara Pailoor <sp3485@columbia.edu> wrote:
>> > > Hi,
>> > >
>> > > I found a warning while fuzzing with Syzkaller on linux 4.13-rc7 on
>> > > x86_64. The full stack trace is below:
>> > >
>> > > WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186
>> > > refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186
>> > > Kernel panic - not syncing: panic_on_warn set ...
>> > >
>> > > CPU: 2 PID: 4277 Comm: syz-executor0 Not tainted 4.13.0-rc7 #3
>> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> > > Ubuntu-1.8.2-1ubuntu1 04/01/2014
>> > > Call Trace:
>> > > <IRQ>
>> > > __dump_stack lib/dump_stack.c:16 [inline]
>> > > dump_stack+0xf7/0x1aa lib/dump_stack.c:52
>> > > panic+0x1ae/0x3a7 kernel/panic.c:180
>> > > __warn+0x1c4/0x1d9 kernel/panic.c:541
>> > > report_bug+0x211/0x2d0 lib/bug.c:183
>> > > fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190
>> > > do_trap_no_signal arch/x86/kernel/traps.c:224 [inline]
>> > > do_trap+0x260/0x390 arch/x86/kernel/traps.c:273
>> > > do_error_trap+0x118/0x340 arch/x86/kernel/traps.c:310
>> > > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323
>> > > invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:846
>> > > RIP: 0010:refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186
>> > > RSP: 0018:ffff88006e006b60 EFLAGS: 00010286
>> > > RAX: 0000000000000026 RBX: 0000000000000000 RCX: 0000000000000000
>> > > RDX: 0000000000000026 RSI: 1ffff1000dc00d2c RDI: ffffed000dc00d60
>> > > RBP: ffff88006e006bf0 R08: 0000000000000001 R09: 0000000000000000
>> > > R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1000dc00d6d
>> > > R13: 00000000ffffffff R14: 0000000000000001 R15: ffff88006ce9d340
>> > > refcount_dec_and_test+0x1a/0x20 lib/refcount.c:211
>> > > reqsk_put+0x71/0x2b0 include/net/request_sock.h:123
>> > > tcp_v4_rcv+0x259e/0x2e20 net/ipv4/tcp_ipv4.c:1729
>> > > ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216
>> > > NF_HOOK include/linux/netfilter.h:248 [inline]
>> > > ip_local_deliver+0x1ce/0x6d0 net/ipv4/ip_input.c:257
>> > > dst_input include/net/dst.h:477 [inline]
>> > > ip_rcv_finish+0x8db/0x19c0 net/ipv4/ip_input.c:397
>> > > NF_HOOK include/linux/netfilter.h:248 [inline]
>> > > ip_rcv+0xc3f/0x17d0 net/ipv4/ip_input.c:488
>> > > __netif_receive_skb_core+0x1fb7/0x31f0 net/core/dev.c:4298
>> > > __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4336
>> > > process_backlog+0x1c5/0x6d0 net/core/dev.c:5102
>> > > napi_poll net/core/dev.c:5499 [inline]
>> > > net_rx_action+0x6d3/0x14a0 net/core/dev.c:5565
>> > > __do_softirq+0x2cb/0xb2d kernel/softirq.c:284
>> > > do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:898
>> > > </IRQ>
>> > > do_softirq.part.16+0x63/0x80 kernel/softirq.c:328
>> > > do_softirq kernel/softirq.c:176 [inline]
>> > > __local_bh_enable_ip+0x84/0x90 kernel/softirq.c:181
>> > > local_bh_enable include/linux/bottom_half.h:31 [inline]
>> > > rcu_read_unlock_bh include/linux/rcupdate.h:705 [inline]
>> > > ip_finish_output2+0x8ad/0x1360 net/ipv4/ip_output.c:231
>> > > ip_finish_output+0x74e/0xb80 net/ipv4/ip_output.c:317
>> > > NF_HOOK_COND include/linux/netfilter.h:237 [inline]
>> > > ip_output+0x1cc/0x850 net/ipv4/ip_output.c:405
>> > > dst_output include/net/dst.h:471 [inline]
>> > > ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124
>> > > ip_queue_xmit+0x8c6/0x1810 net/ipv4/ip_output.c:504
>> > > tcp_transmit_skb+0x1963/0x3320 net/ipv4/tcp_output.c:1123
>> > > tcp_send_ack.part.35+0x38c/0x620 net/ipv4/tcp_output.c:3575
>> > > tcp_send_ack+0x49/0x60 net/ipv4/tcp_output.c:3545
>> > > tcp_rcv_synsent_state_process net/ipv4/tcp_input.c:5795 [inline]
>> > > tcp_rcv_state_process+0x4876/0x4b60 net/ipv4/tcp_input.c:5930
>> > > tcp_v4_do_rcv+0x58a/0x820 net/ipv4/tcp_ipv4.c:1483
>> > > sk_backlog_rcv include/net/sock.h:907 [inline]
>> > > __release_sock+0x124/0x360 net/core/sock.c:2223
>> > > release_sock+0xa4/0x2a0 net/core/sock.c:2715
>> > > inet_wait_for_connect net/ipv4/af_inet.c:557 [inline]
>> > > __inet_stream_connect+0x671/0xf00 net/ipv4/af_inet.c:643
>> > > inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:682
>> > > SYSC_connect+0x204/0x470 net/socket.c:1628
>> > > SyS_connect+0x24/0x30 net/socket.c:1609
>> > > entry_SYSCALL_64_fastpath+0x18/0xad
>> > > RIP: 0033:0x451e59
>> > > RSP: 002b:00007f474843fc08 EFLAGS: 00000216 ORIG_RAX: 000000000000002a
>> > > RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 0000000000451e59
>> > > RDX: 0000000000000010 RSI: 0000000020002000 RDI: 0000000000000007
>> > > RBP: 0000000000000046 R08: 0000000000000000 R09: 0000000000000000
>> > > R10: 0000000000000000 R11: 0000000000000216 R12: 0000000000000000
>> > > R13: 00007ffc040a0f8f R14: 00007f47484409c0 R15: 0000000000000000
>> > >
>> > >
>> > >
>> > >
>> > > I found that the following program is able to reproduce the warning:
>> > >
>> > >
>> > > Pastebin: https://pastebin.com/B75BdYKz
>> > >
>> > > Here are my configs: https://pastebin.com/zRYCXbak
>> > >
>> > > Regards,
>> > > Shankara
>> > >
>>
>> Sweet, thanks for the report, I will have a look.
>>
>> It seems one reqsk_put(req); is missing, but that would lead to a memory
>> leak, not a double reqsk_put(req) :/
>
> OK, it seems the following patch should fix the issue, can you try it ?
>
> (not compiled yet, I will test this tomorrow)
>
> I will have to double check this wont bring other problems :/
>
> Thanks.
>
> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index 4089c013cb03b12e31ddffbb7ae903542c012ae0..b9c64b40a83af1e151f553ba0e624fae5060ffd0 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -916,7 +916,6 @@ static void inet_child_forget(struct sock *sk, struct request_sock *req,
> tcp_sk(child)->fastopen_rsk = NULL;
> }
> inet_csk_destroy_sock(child);
> - reqsk_put(req);
> }
>
> struct sock *inet_csk_reqsk_queue_add(struct sock *sk,
> @@ -987,6 +986,7 @@ void inet_csk_listen_stop(struct sock *sk)
> sock_hold(child);
>
> inet_child_forget(sk, req, child);
> + reqsk_put(req);
> bh_unlock_sock(child);
> local_bh_enable();
> sock_put(child);
>
>
^ permalink raw reply
* Re: [PATCH] net/sched: fix pointer check in gen_handle
From: David Miller @ 2017-09-11 21:35 UTC (permalink / raw)
To: johunt; +Cc: jhs, xiyou.wangcong, jiri, netdev
In-Reply-To: <1505072930-13049-1-git-send-email-johunt@akamai.com>
From: Josh Hunt <johunt@akamai.com>
Date: Sun, 10 Sep 2017 15:48:50 -0400
> Fixes sparse warning about pointer in gen_handle:
> net/sched/cls_rsvp.h:392:40: warning: Using plain integer as NULL pointer
>
> Fixes: 8113c095672f6 ("net_sched: use void pointer for filter handle")
> Signed-off-by: Josh Hunt <johunt@akamai.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: sr: remove duplicate routing header type check
From: David Miller @ 2017-09-11 21:34 UTC (permalink / raw)
To: dav.lebrun; +Cc: netdev
In-Reply-To: <20170910132201.15576-1-dav.lebrun@gmail.com>
From: David Lebrun <dav.lebrun@gmail.com>
Date: Sun, 10 Sep 2017 14:22:01 +0100
> From: David Lebrun <dlebrun@google.com>
>
> As seg6_validate_srh() already checks that the Routing Header type is
> correct, it is not necessary to do it again in get_srh().
>
> Fixes: 5829d70b ("ipv6: sr: fix get_srh() to comply with IPv6 standard "RFC 8200")
> Signed-off-by: David Lebrun <dlebrun@google.com>
Applied thanks.
^ permalink raw reply
* Re: [V3 PATCH net] xdp: implement xdp_redirect_map for generic XDP
From: David Miller @ 2017-09-11 21:33 UTC (permalink / raw)
To: brouer; +Cc: netdev, john.fastabend, andy
In-Reply-To: <150502962259.28817.7472180087690436639.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Sun, 10 Sep 2017 09:47:02 +0200
> Using bpf_redirect_map is allowed for generic XDP programs, but the
> appropriate map lookup was never performed in xdp_do_generic_redirect().
>
> Instead the map-index is directly used as the ifindex. For the
> xdp_redirect_map sample in SKB-mode '-S', this resulted in trying
> sending on ifindex 0 which isn't valid, resulting in getting SKB
> packets dropped. Thus, the reported performance numbers are wrong in
> commit 24251c264798 ("samples/bpf: add option for native and skb mode
> for redirect apps") for the 'xdp_redirect_map -S' case.
>
> Before commit 109980b894e9 ("bpf: don't select potentially stale
> ri->map from buggy xdp progs") it could crash the kernel. Like this
> commit also check that the map_owner owner is correct before
> dereferencing the map pointer. But make sure that this API misusage
> can be caught by a tracepoint. Thus, allowing userspace via
> tracepoints to detect misbehaving bpf_progs.
>
> Fixes: 6103aa96ec07 ("net: implement XDP_REDIRECT for xdp generic")
> Fixes: 24251c264798 ("samples/bpf: add option for native and skb mode for redirect apps")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied, thanks Jesper.
^ permalink raw reply
* Re: Extended IDR API
From: David Miller @ 2017-09-11 21:31 UTC (permalink / raw)
To: willy; +Cc: chrism, jiri, tj, linux-kernel, netdev, aquannie
In-Reply-To: <20170911211408.GA26747@bombadil.infradead.org>
From: Matthew Wilcox <willy@infradead.org>
Date: Mon, 11 Sep 2017 14:14:08 -0700
> I really don't like your new API. I wish you'd discussed it before
> merging it.
If I recall correctly, linux-kernel was CC:'d and nobody engaged.
I could be wrong, and if I am then my bad, I should have enforced that.
Thanks.
^ permalink raw reply
* Re: [PATCH] tipc: Use bsearch library function
From: David Miller @ 2017-09-11 21:30 UTC (permalink / raw)
To: thomas; +Cc: jon.maloy, ying.xue, netdev, tipc-discussion, linux-kernel
In-Reply-To: <20170909031819.13622-1-thomas@m3y3r.de>
From: Thomas Meyer <thomas@m3y3r.de>
Date: Sat, 9 Sep 2017 05:18:19 +0200
> @@ -168,6 +169,18 @@ static struct name_seq *tipc_nameseq_create(u32 type, struct hlist_head *seq_hea
> return nseq;
> }
>
> +static int nameseq_find_subseq_cmp(const void *key, const void *elt)
> +{
> + u32 instance = *(u32 *)key;
> + struct sub_seq *sseq = (struct sub_seq *)elt;
Please order local variables from longest to shortest (ie. reverse
christmas tree).
Thank you.
^ permalink raw reply
* Re: [PATCH net] perf/bpf: fix a clang compilation issue
From: David Miller @ 2017-09-11 21:28 UTC (permalink / raw)
To: yhs; +Cc: peterz, rostedt, ast, daniel, ndesaulniers, netdev, kernel-team
In-Reply-To: <20170908013615.973478-1-yhs@fb.com>
From: Yonghong Song <yhs@fb.com>
Date: Thu, 7 Sep 2017 18:36:15 -0700
> clang does not support variable length array for structure member.
> It has the following error during compilation:
>
> kernel/trace/trace_syscalls.c:568:17: error: fields must have a constant size:
> 'variable length array in structure' extension will never be supported
> unsigned long args[sys_data->nb_args];
> ^
>
> The fix is to use a fixed array length instead.
>
> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Yonghong Song <yhs@fb.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs
From: David Miller @ 2017-09-11 21:26 UTC (permalink / raw)
To: tatsu; +Cc: j.vosburgh, vfalico, andy, netdev, linux-kernel, r
In-Reply-To: <17EC94B0A072C34B8DCF0D30AD16044A02985CB5@BPXM09GP.gisp.nec.co.jp>
From: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Date: Wed, 6 Sep 2017 22:47:59 +0000
> Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in
> balance-alb mode") tried to fix transmit dynamic load balancing in
> balance-alb mode, which wasn't working after commit 8b426dc54cf4
> ("bonding: remove hardcoded value").
>
> It turned out that my previous patch only fixed the case when
> balance-alb was specified as bonding module parameter, and not when
> balance-alb mode was set using /sys/class/net/*/bonding/mode (the most
> common usage). In the latter case, tlb_dynamic_lb was set up according
> to the default mode of the bonding interface, which happens to be
> balance-rr.
>
> This additional patch addresses this issue by setting up tlb_dynamic_lb
> to 1 if "mode" is set to balance-alb through the sysfs interface.
>
> I didn't add code to change tlb_balance_lb back to the default value for
> other modes, because "mode" is usually set up only once during
> initialization, and it's not worthwhile to change the static variable
> bonding_defaults in bond_main.c to a global variable just for this
> purpose.
>
> Commit 8b426dc54cf4 also changes the value of tlb_dynamic_lb for
> balance-tlb mode if it is set up using the sysfs interface. I didn't
> change that behavior, because the value of tlb_balance_lb can be changed
> using the sysfs interface for balance-tlb, and I didn't like changing
> the default value back and forth for balance-tlb.
>
> As for balance-alb, /sys/class/net/*/bonding/tlb_balance_lb cannot be
> written to. However, I think balance-alb with tlb_dynamic_lb set to 0
> is not an intended usage, so there is little use making it writable at
> this moment.
>
> Fixes: 8b426dc54cf4 ("bonding: remove hardcoded value")
> Reported-by: Reinis Rozitis <r@roze.lv>
> Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
> Cc: stable@vger.kernel.org # v4.12+
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] hv_netvsc: avoid unnecessary wakeups on subchannel creation
From: David Miller @ 2017-09-11 21:21 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20170906205306.10541-3-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 6 Sep 2017 13:53:06 -0700
> Only need to wakeup the initiator after all sub-channels
> are opened.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] hv_netvsc: fix deadlock on hotplug
From: David Miller @ 2017-09-11 21:21 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20170906205306.10541-2-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 6 Sep 2017 13:53:05 -0700
> When a virtual device is added dynamically (via host console), then
> the vmbus sends an offer message for the primary channel. The processing
> of this message for networking causes the network device to then
> initialize the sub channels.
>
> The problem is that setting up the sub channels needs to wait until
> the subsequent subchannel offers have been processed. These offers
> come in on the same ring buffer and work queue as where the primary
> offer is being processed; leading to a deadlock.
>
> This did not happen in older kernels, because the sub channel waiting
> logic was broken (it wasn't really waiting).
>
> The solution is to do the sub channel setup in its own work queue
> context that is scheduled by the primary channel setup; and then
> happens later.
>
> Fixes: 732e49850c5e ("netvsc: fix race on sub channel creation")
> Reported-by: Dexuan Cui <decui@microsoft.com>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> v2 - fix module removal race with new work queue
Applied.
^ 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