Message ID | 20190317142524.GA5136@nautica |
---|---|
State | Not Applicable |
Delegated to: | David Miller |
Headers | show |
Series | [GIT,PULL] 9p updates for 5.1 | expand |
On Sun, Mar 17, 2019 at 7:25 AM Dominique Martinet <asmadeus@codewreck.org> wrote: > > Two fixes (leak on invalid mount argument and possible deadlock on > i_size update on 32bit smp) and a fall-through warning cleanup 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... Anyway, pulled, but just surprised... Linus
The pull request you sent on Sun, 17 Mar 2019 15:25:24 +0100:
> git://github.com/martinetd/linux tags/9p-for-5.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/db77bef53ba6ba5205ac1788bb8b66ce141ab020
Thank you!
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,