https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-6918 Lustre <p>Thread 1:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>schedule start_this_handle jbd2_journal_start ldiskfs_journal_start_sb ldiskfs_dquot_drop vfs_dq_drop clear_inode dispose_list shrink_icache_memory shrink_slab zone_reclaim get_page_from_freelist __alloc_pages_nodemask alloc_pages_vma do_huge_pmd_anonymous_page handle_mm_fault __do_page_fault do_page_fault page_fault </pre> </div></div> <p>Thread2:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>__wait_on_freeing_inode find_inode_fast ifind_fast iget_locked ldiskfs_iget osd_iget osd_index_ea_delete out_obj_index_delete out_tx_index_delete_exec out_tx_end out_handle tgt_request_handle ptlrpc_main kthread kernel_thread </pre> </div></div> LU-6918

Deadlock on transaction with iget()/clear_inode()

Bug Major Resolved Duplicate WC Triage Andriy Skulysh Tue, 28 Jul 2015 07:18:40 +0000 Tue, 19 Dec 2017 14:30:17 +0000 Tue, 19 Dec 2017 14:30:17 +0000 Lustre 2.8.0 0 8 <p>iget() waits for cleared I_FREEING flag, but clear_inode()/ldiskfs_dquot_drop() wants to start transaction at first and clears the flag after that.</p> <p>This behavior is common for most of target code. It takes transaction at first, after that locates an object by means of iget(). <br/> Possible solution would be to pin inode before starting transaction in tgt code.</p> <p>no, we shouldn't do this in the target code because the target has no idea of agent inodes and it can't address that inode given an agent inode has no FID assigned. I think the only solution is to postpone inode destroy. this can be done in different ways. the most trivial is to have a list of inode numbers in memory. this can lead to an orphan, but given the number of agent inodes is very small, they don't occupy much space and at some point they will be discovered by LFSCK - probably good enough. if not, then we can do something similar to ext4_orphan_add()..</p> <p>Andriy, how easily can this deadlock be hit, and what is the workload to trigger it?</p> <p>We have several reports from different sites. It isn't easily reproducible.</p> <p><a href="http://review.whamcloud.com/#/c/15924/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/15924/</a></p> <p>Duplicate of <a href="https://jira.whamcloud.com/browse/LU-6969" title="osd_internal.h:1090:osd_trans_exec_check()) LBUG for osd_index_ea_delete()" class="issue-link" data-issue-key="LU-6969"><del>LU-6969</del></a></p> Related LU-6969 Development Rank 1|hzxj6v: Rank (Obsolete) 9223372036854775807 Severity