All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Tom Parkin <tparkin@katalix.com>,
	netdev@vger.kernel.org, David.Laight@ACULAB.COM,
	James Chapman <jchapman@katalix.com>
Subject: Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
Date: Wed, 27 Jun 2012 13:21:56 -0700	[thread overview]
Message-ID: <4FEB6B64.5060708@hp.com> (raw)
In-Reply-To: <1340823810.26242.81.camel@edumazet-glaptop>

On 06/27/2012 12:03 PM, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 13:00 +0100, Tom Parkin wrote:
>> This patch fixes a race condition in l2tp when updating tunnel and
>> session statistics.  Previously it was possible for multiple threads
>> to concurrently call u64_stats_update*(), which lead to statistics
>> readers blocking forever.
>>
>> This race was discovered on an AMD64 SMP machine running a 32bit
>> kernel.  Running "ip l2tp" while sending data over an Ethernet
>> pseudowire resulted in an occasional soft lockup in
>> u64_stats_fetch_begin() called from l2tp_nl_session_send().
>>
>> For safe lockless update of l2tp stats, data is now stored in per-cpu
>> variables.  These per-cpu datasets are then summed at read time via.
>> an extra helper function l2tp_stats_copy() which has been added to
>> l2tp_core.c.
>>
>
> Do we really need 64bits stats on 32bit arches for l2tp ?

It is a question of the speed of the communications more than the 
bitness of the processor no?

rick jones

  reply	other threads:[~2012-06-27 20:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 12:00 [PATCH v2] l2tp: use per-cpu variables for u64_stats updates Tom Parkin
2012-06-27 19:03 ` Eric Dumazet
2012-06-27 20:21   ` Rick Jones [this message]
2012-06-27 20:39     ` Eric Dumazet
2012-06-27 20:50       ` Stephen Hemminger
2012-06-27 20:58         ` Ben Greear
2012-06-27 21:20           ` Eric Dumazet
2012-06-27 21:31             ` Ben Greear
2012-06-27 21:35               ` Eric Dumazet
2012-06-27 23:01                 ` Rick Jones
2012-06-27 23:09                   ` David Miller
2012-06-27 23:39                     ` Rick Jones
2012-06-28  5:00                   ` Eric Dumazet
2012-06-28  8:24                     ` Tom Parkin
2012-06-28  8:46                     ` David Laight
2012-06-28 18:17                       ` Ben Hutchings
2012-06-27 21:32             ` Eric Dumazet
2012-06-27 21:40               ` Ben Greear
2012-06-27 21:50                 ` Eric Dumazet
2012-06-27 21:00       ` Rick Jones
2012-06-27 22:21       ` David Miller

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=4FEB6B64.5060708@hp.com \
    --to=rick.jones2@hp.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=eric.dumazet@gmail.com \
    --cc=jchapman@katalix.com \
    --cc=netdev@vger.kernel.org \
    --cc=tparkin@katalix.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.