On Fri, Feb 29, 2008 at 08:34:37AM +0800, Peter Teoh wrote: > 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. Instructions are restarted (re-executed) after a interrupt, so it's not a problem. -- -------------- Diego Woitasen -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
