Sorry this part really puzzled me.... On Sat, Feb 9, 2008 at 8:10 AM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > On 09-02-08 00:22, Diego Woitasen wrote: > > > I was reading the code of include/linux/fs.h and saw a comment > > before i_size_read() that says: > > > > /* > > * NOTE: in a 32bit arch with a preemptable kernel and an UP > > * compile the i_size_read/write must be atomic with respect to > > * the local cpu (unlike with preempt disabled), but they don't > > * need to be atomic with respect to other cpus like in true SMP > > * (so they need either to either locally disable irq around the > > * read or for example on x86 they can be still implemented as a > > * cmpxchg8b without the need of the lock prefix). For SMP > > * compiles and 64bit archs it makes no difference if preempt is > > * enabled or not. > > */ > > > > I don't understand why this funcion shouldn't be atomic in a 64 > > bit arch or why it isn't locked. Where is the race condition > > prevented? > > In the CPU's ALU. inode->i_size is a 64_bit integer, and access to it is > atomic on 64-bit. On a 32-bit arch though, a 64-bit load will be split in > two 32-bit ones where you can get an incoherent value if you're interrupted > between getting the low and the high 32-bit. > > Rene. > I understood what u are saying, as i_size is loff_t, and loff_t is defined as "long long". But the fact is this, of the thousands of assembly instructions in the kernel, in between any two, it can always be interrupted, so long as u ensure that the interrupt handler ensure that all the registers that it modified has been restored back to its original value upon returning. So I don't quite understand why it cannot be interrupted between the upper and lower half of the 32bit processing. Thank for the explanation. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
