Re: [PATCH v3 6/6] debugfs: rename start_creating() to debugfs_start_creating()

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Sep 15, 2025 at 12:13:46PM +1000, NeilBrown wrote:
> From: NeilBrown <neil@brown.name>
> 
> start_creating() is a generic name which I would like to use for a
> function similar to simple_start_creating(), only not quite so simple.
> 
> debugfs is using this name which, though static, will cause complaints
> if then name is given a different signature in a header file.
> 
> So rename it to debugfs_start_creating().

FWIW, there's one thing that might conflict with.  Take a look at this
in 3 of 4 callers of that thing:

        dentry = start_creating(name, parent);
 
        if (IS_ERR(dentry))
                return dentry;
 
        if (!(debugfs_allow & DEBUGFS_ALLOW_API)) {
                failed_creating(dentry);
                return ERR_PTR(-EPERM);
        }

Now, note that the very first thing start_creating() does is

        if (!(debugfs_allow & DEBUGFS_ALLOW_API))  
                return ERR_PTR(-EPERM);

and that debugfs_allow is assign-once variable - it's set only debugfs_kernel(),
called only via
early_param("debugfs", debugfs_kernel);

So that's dead code and had always been such.  All those checks had been added
at the same point - in a24c6f7bc923 "debugfs: Add access restriction option",
so at a guess the dead ones are rudiments from an earlier version of that patch
that hadn't been taken out by an accident - they should've been taken out and
shot on review, really.

They obviously need to go and that'll be textually close enough to the calls of
start_creating() to cause conflicts.