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