lkml.org 
[lkml]   [2008]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.25-git2: BUG: unable to handle kernel paging request at ffffffffffffffff
On Tue, Apr 22, 2008 at 09:03:04AM +0800, Herbert Xu wrote:
> On Mon, Apr 21, 2008 at 08:49:58AM -0700, Linus Torvalds wrote:
> >
> > That is *not* the main problem.
> >
> > If you use "rcu_dereference()" on the wrong access, it not only loses the
> > "smp_read_barrier_depends()" (which is a no-op on all sane architectures
> > anyway), but it loses the ACCESS_ONCE() thing *entirely*.
>
> Actually rcu_dereference didn't have ACCESS_ONCE when I did this.
> That only appearaed later with the preemptible RCU work.

Yep, ACCESS_ONCE() is quite recent -- within the last year. So I should
have modified the list_for_each.*rcu() macros when I made that change.

> The original purpose of rcu_dereference was exactly to replace the
> explicit barriers that people were using for RCU, nothing more,
> nothing less.
>
> Oh and I totally agree that the compiler is going to generate insane
> code whenever ACCESS_ONCE is used. In this case we may have avoided
> it by rearranging the code, but in general the introduction of ACCESS_ONCE
> in rcu_dereference is likely to have a negative impact on the code
> generated.
>
> Remember that "volatile" discussion? I think this is where it all came
> from.

And I still have the bug in to gcc:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102

Interesting, currently in status "unconfirmed"... I guess I should
supply a test case.

Thanx, Paul


\
 
 \ /
  Last update: 2008-04-22 15:39    [W:0.543 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site