lkml.org 
[lkml]   [2010]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: memory barrier question
From
Date
On Sun, 19 Sep 2010, Paul E. McKenney wrote:
> Give it a few years. There are reportedly already other compilers that do
> this, which is not too surprising given that the perception of insanity
> is limited to lockless parallel code. If you have single-threaded code,
> such as code and data under a lock (where the data is never accessed
> without holding that lock), then this sort of optimization is pretty safe.
> I still don't like it, but the compiler guys would argue that this is
> because I am one of those insane parallel-programming guys.
>
> Furthermore, there are other ways to get into trouble. If the code
> continued as follows:
>
> LOAD inode = next.dentry->inode
> if (inode != NULL)
> LOAD inode->f_op
> do_something_using_lots_of_registers();
> LOAD inode->some_other_field
>
> and if the code expected ->f_op and ->some_other_field to be from the
> same inode structure, severe disappointment could ensue. This is because
> the compiler is within its rights to reload from next.dentry->inode,
> especially given register pressure. In fact, the compiler would be within
> its rights to reload from next.dentry->inode in the "LOAD inode->f_op"
> statement. And it might well get NULL from such a reload.

Except the VFS doesn't allow that. dentry->inode can go from NULL to
non-NULL anytime but will only go from non-NULL to NULL when there are
no possible external references to the dentry.

The compiler and the CPU cannot move the "LOAD inode->some_field"
before the "LOAD dentry->inode", because of the conditional, right?

Thanks,
Miklos


\
 
 \ /
  Last update: 2010-09-19 22:19    [W:1.380 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site