On Sat, Mar 1, 2008 at 1:16 AM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > It's not about registers. i_size_read() is designed to be able to be called > without the i_sem held meaning it needs to guard against i_size changing out > from under it. > > Say process A wants to know inode->i_size. On a 32-bit arch it's going to be > split in two 32-bit loads such as (Intel pseudo-syntax): > > mov eax, [inode->i_size] > mov edx, [inode->i_size + 4] > > Now imagine process A being preempted just between these two loads by > process B and process B changing inode->i_size. When process A resumes it > gets the _new_ upper 32-bits while it already had the _old_ lower 32-bits, > making for a combined 64-bit value which is complete nonsense. > Yes, this is the key idea - modifying a common data with holding any synchronization variable. > Now, mind you, exactly how much point there is to any specific code path in > checking i_size without grabbing i_sem is open for discussion -- even if > with the locking you get a _coherent_ value, it may still be an _outdated_ > value if you're preempted exactly after this sequence, but that's a > higher-level issue. A bit of googling seems to imply stat() wants it Nice and enlightening discussion....I have learned a lot!!! Thank you everyone. -- 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
