Hi Dave, On a recurring series of crashes on kernel 3.10.0-693.17.1.el7.x86_64 (RHEL 7.4), a problem was triggered by deletion of a file by a process with this stack trace: #0 [ffff88115b0ef798] __schedule at ffffffff816ab2ac #1 [ffff88115b0ef828] schedule at ffffffff816ab8a9 #2 [ffff88115b0ef838] jbd2_log_wait_commit at ffffffffc0177455 [jbd2] #3 [ffff88115b0ef8b0] jbd2_log_do_checkpoint at ffffffffc017405f [jbd2] #4 [ffff88115b0ef918] __jbd2_log_wait_for_space at ffffffffc017445f [jbd2] #5 [ffff88115b0ef960] add_transaction_credits at ffffffffc016e3d3 [jbd2] #6 [ffff88115b0ef9c0] start_this_handle at ffffffffc016e5e1 [jbd2] #7 [ffff88115b0efa58] jbd2__journal_restart at ffffffffc016ec9e [jbd2] #8 [ffff88115b0efa98] jbd2_journal_restart at ffffffffc016ed13 [jbd2] #9 [ffff88115b0efaa8] ext4_truncate_restart_trans at ffffffffc027be7e [ext4]: #10 [ffff88115b0efad8] ext4_free_branches at ffffffffc02bc9d7 [ext4] #11 [ffff88115b0efb38] ext4_free_branches at ffffffffc02bc887 [ext4] #12 [ffff88115b0efb98] ext4_free_branches at ffffffffc02bc887 [ext4] #13 [ffff88115b0efbf8] ext4_ind_truncate at ffffffffc02bda5e [ext4] #14 [ffff88115b0efcb8] ext4_truncate at ffffffffc0280ca8 [ext4] #15 [ffff88115b0efcf0] ext4_evict_inode at ffffffffc02818e0 [ext4] #16 [ffff88115b0efd10] evict at ffffffff8121f879 #17 [ffff88115b0efd38] iput at ffffffff81220189 #18 [ffff88115b0efd68] rfs_d_iput at ffffffffc03f7d10 [ redirfs ] #19 [ffff88115b0efe00] dentry_kill at ffffffff8121a90c #20 [ffff88115b0efe30] dput at ffffffff8121a9ce #21 [ffff88115b0efe50] path_put at ffffffff8120d576 #22 [ffff88115b0efe68] gsch_nd_release at ffffffffc043733e [ gsch ] #23 [ffff88115b0efe78] gsch_unlink_hook_fn at ffffffffc043 It was useful for our troubleshooting to identify the file being deleted in each of these crashes, and dentry_kill () takes a dentry pointer as its only argument: struct dentry * dentry_kill ( struct dentry *); Finding the dentry pointer (using ‘ fregs ’ command in PyKdump , or digging it off the stack): #19 dentry_kill called from 0xffffffff8121a9ce <dput+94> +R12: 0xffff880328399858 +R13: 0x0 +R14: 0xffff880a0fb975b8 +RBP: 0xffff88115b0efe48 +RBX: 0xffff880328399800 1 RDI: 0xffff880328399800 arg0 struct dentry * ‘files -d’ on this dentry doesn’t return the path: crash64> files -d 0xffff880328399800 DENTRY INODE SUPERBLK TYPE PATH ffff880328399800 0 0 N/A This is because dentry.d_inode is null; at this point in the removal process, dentry_iput () has cleared it. crash64> dentry.d_inode 0xffff880328399800 d_inode = 0x0 And display_dentry_info () in crash gives up if this is the case: if (! inode || !superblock) goto nopath ; But the dentry still contains all the information needed to find the path: crash64> dentry.d_sb,d_name ffff880328399800 d_sb = 0xffff8817daaf6800 d_name = { { { hash = 3169988838, len = 30 }, hash_len = 132019007718 }, name = 0xffff880328399838 "MRAQ0431_1_10357_982129979.arc" So I modified the following: ( defs.h ) 2069d2068 < long dentry_d_sb ; ( filesys.c ) 1698,1702c1698,1702 < } else { < inode_buf = NULL; < } < < superblock = ULONG( dentry_buf + OFFSET( dentry_d_sb )); --- > superblock = ULONG( inode_buf + OFFSET( inode_i_sb )); > } else { > inode_buf = NULL; > superblock = 0; > } 1704c1704 < if (!superblock) --- > if (! inode || !superblock) 2018d2017 < MEMBER_OFFSET_INIT( dentry_d_sb , " dentry ", " d_sb "); With this patch, ‘files -d’ correctly returns the path: crash> files -d ffff880328399800 DENTRY INODE SUPERBLK TYPE PATH ffff880328399800 0 ffff8817daaf6800 N/A /u02/ oraarch /MRAQ0431/MRAQ0431_1_10357_982129979.arc Can this be included as a patch to crash?

Thanks, Martin Martin Moore Linux/Tru64 RTCC Engineer CSC Americas HPE Technology Services Hewlett Packard Enterprise -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility

[snip] > Rather than making a wholesale switch, can you make it check the > dentry.d_inode first, > and if it's NULL, then check dentry.d_sb? I'm probably being paranoid, but > I'm worried > about unintended consequences. > Thanks, > Dave Sure. Here's the new version:

(defs.h) 2069d2068 < long dentry_d_sb; (filesys.c) 1701c1701 < superblock = ULONG(dentry_buf + OFFSET(dentry_d_sb)); --- > superblock = 0; 1704c1704 < if (!superblock) --- > if (!inode || !superblock) 2018d2017 < MEMBER_OFFSET_INIT(dentry_d_sb, "dentry", "d_sb"); Verification: Problem dentry, without patch: DENTRY INODE SUPERBLK TYPE PATH ffff880328399800 0 0 N/A Problem dentry, with patch: DENTRY INODE SUPERBLK TYPE PATH ffff880328399800 0 ffff8817daaf6800 N/A /u02/oraarch/MRAQ0431/MRAQ0431_1_10357_982129979.arc Here's another (intact) dentry both ways: Without patch: DENTRY INODE SUPERBLK TYPE PATH ffff8817dba87200 ffff880a82d4b940 ffff8817daaf5000 REG /u01/app/oracle/product/12.1.0.2.161018/rdbms/mesg/oraus.msb With patch: DENTRY INODE SUPERBLK TYPE PATH ffff8817dba87200 ffff880a82d4b940 ffff8817daaf5000 REG /u01/app/oracle/product/12.1.0.2.161018/rdbms/mesg/oraus.msb Regards, Martin Martin Moore Linux/Tru64 RTCC Engineer CSC Americas HPE Technology Services Hewlett Packard Enterprise -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility