Does the qstr struct in a kernel dentry hold the filename of a Linux file?

Below is a snippet of the Linux dentry struct from http://lxr.free-electrons.com/source/include/linux/dcache.h#L150. The struct contains a member struct qstr d_name – definition below. I would like to know if this is the name of the particular file that would correspond to this dentry at runtime. What confuses me is that proc/PID/maps uses struct dentry_operations -> d_name (another member of dentry) to generate the file name…so then waht is the purpose of struct qstr d_name? Please note, I am approaching this from a pure memory introspection point of view (libvmi) and thus I will be “walking memory” for these structures and retrieval using C/C++ code is not so straightforward.

 struct dentry {

     /* RCU lookup touched fields */
     unsigned int d_flags;           /* protected by d_lock */
     seqcount_t d_seq;               /* per dentry seqlock */
     struct hlist_bl_node d_hash;    /* lookup hash list */
     struct dentry *d_parent;        /* parent directory */
     struct qstr d_name;

              ....

struct qstr {
     union {
             struct {
                      HASH_LEN_DECLARE;
             };
              u64 hash_len;
      };
     const unsigned char *name;
};

Answer

Dentry’s field d_name is a simple (and mostly used) way for maintain naming of the dentry. In that case filesystem driver needs to specify name of the dentry once, all other work will be done by VFS.

But in some case statically assigned name is not sufficient for filesystems. As you note, this is case for proc filesystem, which exhibits per-process information into the user space. For such cases method ->d_op->d_dname exists.

Implementation of d_path method may help in understanding of d_name and d_op->d_dname:

...
if (path->dentry->d_op && path->dentry->d_op->d_dname &&
    (!IS_ROOT(path->dentry) || path->dentry != path->mnt->mnt_root))
        return path->dentry->d_op->d_dname(path->dentry, buf, buflen);
rcu_read_lock();
get_fs_root_rcu(current->fs, &root);
error = path_with_deleted(path, &root, &res, &buflen);
rcu_read_unlock();
...

As you can see, d_op->d_dname method’s field is checked first. If it is not NULL, then the method is used. Otherwise d_name field is read.