On Fri, Feb 29, 2008 at 10:38 PM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > I thought we were talking about inode->i_size here? In this case, > inode itself might be a local variable -- but it's a pointer pointing > to an object that may be accessed from other tasks. > > Vegard > Ok, now I realized something - all of us are right in this entire thread - Rene, Vegard etc. (btw, who will say he is wrong?) First look at the origin (or almost?) of the patch: http://lkml.org/lkml/2003/6/19/168 - loff_t size = lo->lo_backing_file->f_dentry->d_inode->i_mapping->host->i_size; + loff_t size = i_size_read(lo->lo_backing_file->f_dentry->d_inode->i_mapping->host); There are so many dereferencing, that while traversing the tree of pointers, some may get changed, by other threads. Problem is that many times in the kernel, spinlocks are not implemented, so as to prevent deadlock, and racy situation allowed as a compromise. The above is a classic example. So instead of holding 6 or more spinlocks for 6 pointers, ONE IRQ preemption locks are held, to prevent modification of the variables if the current CPU switch to interrupt context. BUT the compromising situation that another CPU can modify any of the variable (if it is accessible to them) above (since no spinlock are held) is allowed. The i_size_read() above, to follow the conventional kernel norms, should be something like atomic_xxxx(), (include/asm-x86/atomic*.h) as it is all to solve the same problem - implementing something, that is atomic (which have no waits), without the use of locks (which cause waits). (eg, cmpexchg instruction) Next is this elimination of waits: http://www.cs.helsinki.fi/linux/linux-kernel/2003-18/1577.html The atomic operation is also a reader/writer consistency problem. Reader should not need any lock (reader never block writer), for fast operation, but just make sure that it has a consistent view - either before the variable got changed, or after it was changed. And i_size_read() is invented for this atomic operation, to save from using locks. -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
