In message <20080501170819.bdcb9035.akpm@xxxxxxxxxxxxxxxxxxxx>, Andrew Morton writes: > On Thu, 1 May 2008 19:44:18 -0400 > Erez Zadok <ezk@xxxxxxxxxxxxx> wrote: [...] > i_size is much more important because glitches in there can result in > incorrect data being returned from read() and things like that. i_blocks > is just a beancounting curiosity. > > > > > 2. I've rewritten your suggested code a bit to reduce stack use. Modulo > > having 32-bit spin_lock/unlock variants, do you see any problem with this > > code below? My testing of it so far on 32/64-bit SMP/UMP have all > > passed. > > > > void fsstack_copy_inode_size(struct inode *dst, struct inode *src) > > { > > #if BITS_PER_LONG == 32 > > blkcnt_t i_blocks; > > > > spin_lock(&src->i_lock); > > i_blocks = src->i_blocks; > > spin_unlock(&src->i_lock); > > spin_lock(&dst->i_lock); > > dst->i_blocks = i_blocks; > > spin_unlock(&dst->i_lock); > > #else > > dst->i_blocks = src->i_blocks; > > #endif > > i_size_write(dst, i_size_read(src)); > > } > > That looks sane, as long as we don't care about i_size-vs-i_blocks > coherency. > However I expect that approximately zero of the sites which modify i_blocks > are taking i_lock to do so. If i_blocks is indeed less important than i_size, then we can live with some incoherency b/t i_size and i_blocks, for now. Nevertheless, I propose adding this to linux/fs.h: static inline blkcnt_t i_blocks_read(const struct inode *inode) { #if BITS_PER_LONG == 32 blkcnt_t i_blocks; spin_lock(&src->i_lock); i_blocks = src->i_blocks; spin_unlock(&src->i_lock); return i_blocks; #else return src->i_blocks; #endif } and a matching i_blocks_write function. We can then gradually convert those "unsafe" users of i_blocks to use the new i_blocks_read/write helpers. The nice thing about these two helpers is fsstack_copy_inode_size becomes a lot cleaner and more elegant: void fsstack_copy_inode_size(struct inode *dst, struct inode *src) { i_blocks_write(dst, i_blocks_read(src)); i_size_write(dst, i_size_read(src)); } And, if we ever wanted to ensure coherency b/t i_blocks and i_size, we'll need to create helpers that merge the functionality of i_size_read/write and i_blocks_read/write. What do you think? Erez. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html