We saw the same issue. My point of view and analyze below.
1) LASSERT at ll_delete_inode, after truncate we have non zero ->nrpages for address_space.
2) File for this inode is already closed.
3) issue happened in the file per process access, so this is no race between the client threads. (form psfio.c)
4) nrpages have decreased between LASSERT and crash time(for example crash №3 have 381 and 0), so someone do truncate pages.
5) The page which exist at address space after truncate and LASSERT looks valid for lustre
No dirty, no lock, no writeback.
lapp_origin = 3 LLAP_ORIGIN_COMMIT_WRITE - simple write.
Root cause.
The first thread with LASSERT is ldlm_bl_61 - trace
the second is ldlm_bl_67 - trace
From the stack of ldlm_bl_67 I got ldlm_lock pointer
So we can see inode from ldlm_lock is the same as LASSERT inode ffff88011f44c210.
Now, how race happend:
1) ll_mdc_blocking_ast()>iput()>...>ll_delete_inode()>truncate_inode_pages()
2) osc_extent_blocking_cb()>...>ll_page_removal_cb()>ll_truncate_complete_page()>truncate_complete_page()
Close old ticket.