Bug 208301

This bug is present *very* likely on older stable kernels as well. It should be easy to test.

As part of the work to fix korg#205713 a series of fixes are now merged on the block branch, scheduled to be merged for v5.9. Despite these fixes there is still one lingering issue, if one runs break-blktrace [1] run_0004.sh, even with all the fixes as of linux-next tag 20200622, one still observes the following on the kernel log:

[235530.144343] debugfs: Directory 'loop0' with parent 'block' already present![235530.149477] blktrace: debugfs_dir not present for loop0 so skipping
[235530.232328] debugfs: Directory 'loop0' with parent 'block' already present![235530.238962] blktrace: debugfs_dir not present for loop0 so skipping

I have inspected the block layer locking and the only thing I can think of is that there is a discrepancy / race in between a sysfs addition of a block device name Vs the creation / removal of the respective debugfs_dir for make_request drivers (multiqueue). After the fixes were merged, this would imply this should also be possible as a race with request-based block devices as well, as of the future v5.9 or on linux-next, as we now create the debugfs_dir also on initialization for them as well, however I have not confirmed this.

When this happens the dentry returned should be:

dentry = ERR_PTR(-EEXIST);

Given:

static struct dentry *start_creating(const char *name, struct dentry *parent)   
{
   ...
        if (!IS_ERR(dentry) && d_really_is_positive(dentry)) {                  
                if (d_is_dir(dentry))                                           
                        pr_err("Directory '%s' with parent '%s' already present!\n",
                               name, parent->d_name.name);                      
                else                                                            
                        pr_err("File '%s' in directory '%s' already present!\n",
                               name, parent->d_name.name);                      
                dput(dentry);                                                   
                dentry = ERR_PTR(-EEXIST);                                      
        } 
        if (IS_ERR(dentry)) {                                                   
                inode_unlock(d_inode(parent));                                  
                simple_release_fs(&debugfs_mount, &debugfs_mount_count);        
        }                                                                       
                                                                                
        return dentry; 
}                                                                      

Since we now check for the debugfs_dir early, but not on initialization this should mean we simply disable blktrace for the life time of that device. Prior to the fixes merged, I *suspect* it may have been possible for dentries to be populated on the debugfs root directory instead of the debugfs_dir and cleaned up upon removal, but I have no confirmed this.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=205713
[1] https://github.com/mcgrof/break-blktrace