On Linux, how can I get the file name from the "struct file" structure, and through the kernel with kgdb?

Question

I am trying to view the file name via kgdb, so I cannot call functions and macros to get it programmatically. I need to find it by manually checking the data structures.

As if I had a breakpoint here in gdb, how could I look around with gdb and find the file name?

I tried looking around at filp.f_path , filp.f_inode , etc. I can not see the file name anywhere.

 ssize_t do_sync_write(struct file *filp, const char __user *buf, size_t len, loff_t *ppos) { struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len }; struct kiocb kiocb; ssize_t ret; init_sync_kiocb(&kiocb, filp); kiocb.ki_pos = *ppos; kiocb.ki_left = len; kiocb.ki_nbytes = len; ret = filp->f_op->aio_write(&kiocb, &iov, 1, kiocb.ki_pos); if (-EIOCBQUEUED == ret) ret = wait_on_sync_kiocb(&kiocb); *ppos = kiocb.ki_pos; return ret; } 

Answer 1

In the Linux kernel, the file structure is essentially how the kernel “sees” the file. The kernel is not interested in the file name, just the inode of the open file. This means that all other information that is important to the user is lost.

---

EDIT: This answer is incorrect. You can get dentry with filp->f_path.dentry . From there, you can get the name of the sleepers or the full path using the appropriate FS flags.

Answer 2

You can get the file name from struct file *filp with filp->f_path.dentry->d_iname .

To get a full call to the dentry_path_raw(filp->f_path.dentry,buf,buflen) path dentry_path_raw(filp->f_path.dentry,buf,buflen) .

Answer 3

The path is stored in the file-> f_path structure, as the name implies. It’s just not in the form of flat text, but analyzed for objects that are more useful for the kernel to work, namely, a chain of denting structures and a vfsmount structure that points to the root of the current subtree.

You can use the d_path function to regenerate the name for human reading for the structure path, for example file-> f_path. Please note that, however, this is not a cheap operation, and this can significantly slow down your workload.

The above issues with open but unrelated files, multiple hard links, etc. valid for matching and inode with the path name, and the open file always has a path associated with it. If the file was detached, d_path will add "(deleted)" to the name, and if the name of the file that it was open was changed to another, using renaming from the moment it was opened. D_path will not print the original name, but the current name of the record that was used to open it.