From: Joe Buehler <aspam@cox.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: kernel panic in fib_rules_lookup [2.6.27.7 vendor-patched]
Date: Tue, 26 Oct 2010 09:29:48 -0400 [thread overview]
Message-ID: <4CC6D7CC.5040608@cox.net> (raw)
In-Reply-To: <1287851745.2658.364.camel@edumazet-laptop>
Eric Dumazet wrote:
> With a normal workload, on a dual cpu machine, a missing memory barrier
> can stay un-noticed for quite a long time. The race window is so small
> that probability for the bug might be 0.0000001 % or something like
> that :(
I'm looking at the LINUX source at the moment and not liking what I see
in include/asm-mips/barrier.h:
#define smp_mb() __asm__ __volatile__(__WEAK_ORDERING_MB : : :"memory")
#ifdef CONFIG_CPU_CAVIUM_OCTEON
#define smp_rmb() barrier()
#define smp_wmb() barrier()
#else
#define smp_rmb() __asm__ __volatile__(__WEAK_ORDERING_MB : : :"memory")
#define smp_wmb() __asm__ __volatile__(__WEAK_ORDERING_MB : : :"memory")
#endif
The Octeon documentation explicitly says that neither loads nor stores
need execute in program order, so the definitions for smp_rmb and
smp_wmb appear to be wrong wrong wrong.
It appears that smp_wmb should be making use of SYNCW and smp_rmb should
be making use of SYNC.
Should I pursue this question on the main LINUX kernel list?
Joe Buehler
next prev parent reply other threads:[~2010-10-26 13:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-12 17:14 kernel panic in fib_rules_lookup [2.6.27.7 vendor-patched] Joe Buehler
2010-10-12 17:40 ` Eric Dumazet
2010-10-13 11:18 ` Joe Buehler
2010-10-20 17:43 ` Joe Buehler
2010-10-20 22:05 ` Eric Dumazet
2010-10-22 20:30 ` Joe Buehler
2010-10-23 3:44 ` Eric Dumazet
2010-10-23 15:11 ` Eric Dumazet
2010-10-23 15:24 ` Eric Dumazet
2010-10-23 15:40 ` Joe Buehler
2010-10-23 16:07 ` Eric Dumazet
2010-10-23 15:33 ` Joe Buehler
2010-10-23 16:35 ` Eric Dumazet
2010-10-23 17:37 ` "Oleg A. Arkhangelsky"
2010-10-23 19:44 ` Eric Dumazet
2010-10-26 18:43 ` David Miller
2010-10-26 13:29 ` Joe Buehler [this message]
2010-10-26 13:36 ` Eric Dumazet
2010-10-26 13:53 ` Joe Buehler
2010-10-26 13:58 ` Eric Dumazet
2010-10-26 14:33 ` Eric Dumazet
2010-10-26 14:41 ` Joe Buehler
2010-10-27 21:01 ` Joe Buehler
2010-10-27 21:05 ` Eric Dumazet
2010-12-02 13:36 ` Joe Buehler
2010-12-02 14:04 ` Eric Dumazet
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=4CC6D7CC.5040608@cox.net \
--to=aspam@cox.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.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 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.