public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Tejun Heo <tj@kernel.org>
Cc: akpm@linuxfoundation.org, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Eric Dumazet <edumazet@google.com>
Subject: [PATCH 5/6] net: __this_cpu_inc in route.c
Date: Tue, 15 Oct 2013 12:47:27 -0500	[thread overview]
Message-ID: <20131015174747.307585124@linux.com> (raw)
In-Reply-To: 20131015174722.615394057@linux.com

[-- Attachment #1: preempt_rt_cache_stat --]
[-- Type: text/plain, Size: 3343 bytes --]

The RT_CACHE_STAT_INC macro triggers the new preemption checks
for __this_cpu ops

I do not see any other synchronization that would allow the use
of a __this_cpu operation here however in commit
dbd2915ce87e811165da0717f8e159276ebb803e Andrew justifies
the use of raw_smp_processor_id() here because "we do not care"
about races.

So lets use raw_cpu ops here and hope for the best. The use of
__this_cpu op improves the situation already from what commit
dbd2915ce87e811165da0717f8e159276ebb803e did since the single instruction
emitted on x86 does not allow the race to occur anymore. However,
non x86 platforms could still experience a race here.

Trace:

[ 1277.189084] __this_cpu_add operation in preemptible [00000000] code: avahi-daemon/1193
[ 1277.189085] caller is __this_cpu_preempt_check+0x38/0x60
[ 1277.189086] CPU: 1 PID: 1193 Comm: avahi-daemon Tainted: GF            3.12.0-rc4+ #187
[ 1277.189087] Hardware name: FUJITSU CELSIUS W530 Power/D3227-A1, BIOS V4.6.5.4 R1.10.0 for D3227-A1x 09/16/2013
[ 1277.189088]  0000000000000001 ffff8807ef78fa00 ffffffff816d5a57 ffff8807ef78ffd8
[ 1277.189089]  ffff8807ef78fa30 ffffffff8137359c ffff8807ef78fba0 ffff88079f822b40
[ 1277.189091]  0000000020000000 ffff8807ee32c800 ffff8807ef78fa70 ffffffff813735f8
[ 1277.189093] Call Trace:
[ 1277.189094]  [<ffffffff816d5a57>] dump_stack+0x4e/0x82
[ 1277.189096]  [<ffffffff8137359c>] check_preemption_disabled+0xec/0x110
[ 1277.189097]  [<ffffffff813735f8>] __this_cpu_preempt_check+0x38/0x60
[ 1277.189098]  [<ffffffff81610d65>] __ip_route_output_key+0x575/0x8c0
[ 1277.189100]  [<ffffffff816110d7>] ip_route_output_flow+0x27/0x70
[ 1277.189101]  [<ffffffff81616c80>] ? ip_copy_metadata+0x1a0/0x1a0
[ 1277.189102]  [<ffffffff81640b15>] udp_sendmsg+0x825/0xa20
[ 1277.189104]  [<ffffffff811b4aa9>] ? do_sys_poll+0x449/0x5d0
[ 1277.189105]  [<ffffffff8164c695>] inet_sendmsg+0x85/0xc0
[ 1277.189106]  [<ffffffff815c6e3c>] sock_sendmsg+0x9c/0xd0
[ 1277.189108]  [<ffffffff813735f8>] ? __this_cpu_preempt_check+0x38/0x60
[ 1277.189109]  [<ffffffff815c7550>] ? move_addr_to_kernel+0x40/0xa0
[ 1277.189111]  [<ffffffff815c71ec>] ___sys_sendmsg+0x37c/0x390
[ 1277.189112]  [<ffffffff8136613a>] ? string.isra.3+0x3a/0xd0
[ 1277.189113]  [<ffffffff8136613a>] ? string.isra.3+0x3a/0xd0
[ 1277.189115]  [<ffffffff81367b54>] ? vsnprintf+0x364/0x650
[ 1277.189116]  [<ffffffff81367ee9>] ? snprintf+0x39/0x40
[ 1277.189118]  [<ffffffff813735f8>] ? __this_cpu_preempt_check+0x38/0x60
[ 1277.189119]  [<ffffffff815c7ff9>] __sys_sendmsg+0x49/0x90
[ 1277.189121]  [<ffffffff815c8052>] SyS_sendmsg+0x12/0x20
[ 1277.189122]  [<ffffffff816e4fd3>] tracesys+0xe1/0xe6

Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Christoph Lameter <cl@linux.com>

Index: linux/net/ipv4/route.c
===================================================================
--- linux.orig/net/ipv4/route.c	2013-10-07 10:27:25.000000000 -0500
+++ linux/net/ipv4/route.c	2013-10-07 12:41:23.993823743 -0500
@@ -197,7 +197,7 @@ const __u8 ip_tos2prio[16] = {
 EXPORT_SYMBOL(ip_tos2prio);
 
 static DEFINE_PER_CPU(struct rt_cache_stat, rt_cache_stat);
-#define RT_CACHE_STAT_INC(field) __this_cpu_inc(rt_cache_stat.field)
+#define RT_CACHE_STAT_INC(field) raw_cpu_inc(rt_cache_stat.field)
 
 #ifdef CONFIG_PROC_FS
 static void *rt_cache_seq_start(struct seq_file *seq, loff_t *pos)


  parent reply	other threads:[~2013-10-15 17:55 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15 17:47 [PATCH 0/6] percpu: Implement Preemption checks for __this_cpu operations V4b Christoph Lameter
2013-10-15 17:47 ` [PATCH 1/6] net: ip4_datagram_connect: Use correct form of statistics update Christoph Lameter
2013-10-15 18:36   ` Eric Dumazet
2013-10-16  6:09     ` Ingo Molnar
2013-10-16  8:35   ` Peter Zijlstra
2013-10-16  9:14     ` Eric Dumazet
2013-10-16  9:26       ` Ingo Molnar
2013-10-16 14:27         ` Christoph Lameter
2013-10-16 14:37           ` Eric Dumazet
2013-10-15 17:47 ` [PATCH 2/6] percpu: Add raw_cpu_ops Christoph Lameter
2013-10-15 17:47 ` [PATCH 3/6] mm: Use raw_cpu ops for determining current NUMA node Christoph Lameter
2013-10-16  8:38   ` Peter Zijlstra
2013-10-16 14:22     ` Christoph Lameter
2013-10-15 17:47 ` [PATCH 4/6] Use raw_cpu_write for initialization of per cpu refcount Christoph Lameter
2013-10-16  8:43   ` Peter Zijlstra
2013-10-15 17:47 ` Christoph Lameter [this message]
2013-10-16  8:46   ` [PATCH 5/6] net: __this_cpu_inc in route.c Peter Zijlstra
2013-10-16  9:22     ` Eric Dumazet
2013-10-16 10:25       ` Peter Zijlstra
2013-10-16 15:07         ` Christoph Lameter
2013-10-15 17:47 ` [PATCH 6/6] percpu: Add preemption checks to __this_cpu ops Christoph Lameter
2013-10-16  8:49   ` Peter Zijlstra
2013-10-16 15:09     ` Christoph Lameter
2013-10-16 15:36       ` Peter Zijlstra
2013-10-16 15:55         ` Christoph Lameter
2013-10-16 16:25           ` Peter Zijlstra
2013-10-16 16:52             ` Steven Rostedt
2013-10-16 17:11               ` Peter Zijlstra
2013-10-16 17:39                 ` Steven Rostedt
2013-10-16 18:38             ` Peter Zijlstra
2013-10-17 19:22               ` Christoph Lameter
2013-10-17 21:13                 ` Peter Zijlstra
     [not found] <20131011175518.634285474@linux.com>
2013-10-11 17:54 ` [PATCH 5/6] net: __this_cpu_inc in route.c Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131015174747.307585124@linux.com \
    --to=cl@linux.com \
    --cc=akpm@linuxfoundation.org \
    --cc=edumazet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox