Re: [PATCH] Adjust reiser4 for 3.15: replace truncate_inode_pages(..., 0) with truncate_inode_pages_final(...).

[Ivan Shapovalov <intelfx@intelfx.name>]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]