On 2016-10-03 at 17:40 +0300, Ivan Shapovalov wrote: > On 2016-10-03 at 16:29 +0200, Edward Shishkin wrote: > > On 09/30/2016 08:47 AM, Ivan Shapovalov wrote: > > > On 2016-09-30 at 09:43 +0300, Ivan Shapovalov wrote: > > > > [...] > > > > > > BTW, this raises a question: in the ->evict_inode path, are we > > > ever > > > allowed to call plain truncate_inode_pages() (i. e. not > > > *_final())? > > > > Actually, I would like to see a kind of assertion 1487 instead: > > everything should be already truncated at that point. > > Do you mean that the assertion should go instead of > truncate_inode_pages_final()? Doesn't that function contain extra > logic, beyond removing pages? > > Moreover, that function seems to contain extra logic _before_ > actually > going off and truncating pages. This makes me wonder: doesn't this > mean > that we _must not ever_ call regular truncate_inode_pages() from > inside ->evict_inode()? > > I do not know VFS enough to answer these kinds of stupid questions... Looks like the answer is "no, everything is OK". If ->evict_inode() races with remove_mapping() and shadow entries are installed into the radix tree, the *_final() call will still catch them. By association this means that this call is still needed. (However, now I wonder how does this work with regular truncate and whether the radix tree can hold shadow entries for already truncated pages during an inode's lifetime, but this is a purely VFS/mm question.) -- Ivan Shapovalov / intelfx /
Attachment:
signature.asc
Description: This is a digitally signed message part
