Linus Torvalds wrote on Sun, Mar 17, 2019: > Hmm. I wonder what makes it valid to have concurrent updates to > i_size? Yes, yes, you added that spinlock to make the update itself > atomic on 32-bit, but it sounds a bit odd in the first place to have > two things possibly changing the size of a file at the same time...
If the inode attributes are currently invalid (for example after v9fs_invalidate_inode_attr()) then two concurrent user getattr requests for the same inode will send two network requests which can both update the i_size. With cache=fscache or loose a write could also be concurrent with such an update. I plan on improving the first case with some "being revalidated" logic now this pattern got reported but I don't think the second one can be avoided, so that fix is still necessary in the long run afaict. Thanks, -- Dominique
