----- Original Message -----
>
>
> 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?
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
>
>
>
> Thanks,
>
> Martin
>
>
>
> Martin Moore
> Linux/Tru64 RTCC Engineer
>
> CSC Americas
>
> HPE Technology Services
> Hewlett Packard Enterprise
>
>
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
