linux-kernel - Re: [PATCH] debugfs: New debugfs interface for creation of files, directory and symlinks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120502220417.GA2667@kroah.com>
Date:	Wed, 2 May 2012 15:04:17 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Sasikanth babu <sasikanth.v19@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] debugfs: New debugfs interface for creation of files,
 directory and symlinks

On Thu, May 03, 2012 at 03:28:17AM +0530, Sasikanth babu wrote:
> On Wed, May 2, 2012 at 9:01 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Wed, May 02, 2012 at 06:20:54PM +0530, Sasikantha babu wrote:
> >> As we know the current debugfs file or directory or symlink creation
> >> doesn't return proper error codes to the caller on failure. Because
> >> of this caller and user could not able to find the exact reason of
> >> the failure.
> >
> > And what is the problem with this?  Either the file is created or not,
> > you really shouldn't care anymore than that.  It's not like you are
> > going to retry the creation, or are you?
> >
> > Who really cares if the file is failed to be created?
> 
>  In most of cases I had observed caller of debufs_create_file or
>  debufs_create_dir always returns -ENOMEM on failure, which is not true.

Where does that happen?  And why would the creation of a debugfs file
fail?

>  I felt returning proper error code will help in figuring out the actual
>  reason of the failure (for eg: it can be -EEXISTS based on the error
>  caller can change the name of the file or dir)

Why would it ever conflict in the first place?

What files in the kernel have this problem today that they would create
conflicting files/dirs?

> >> As Andrew Morton suggested (http://www.spinics.net/lists/linux-mm/msg33617.html)
> >> introduced new debugfs interface to create debugfs entries. Newer APIs
> >> returns proper error codes(ERR_PTR) on failure.
> >
> > Again, why?  What root problem are you trying to solve here?
> 
>    The usage of debugfs throughout the kernel is not uniform especially the
>    error handling scenarios. Some place it is IS_ERR validations , other place
>    against NULL and some place ignoring the return value. Just tried to make it
>    uniform.

You can fixup the callers to make it uniform, the api is uniform in what
it returns today, right?

Again, I see no real benifit for returning the "true" error as no one
really cares about that, all that matters is if it worked or not, and
even then, no one should really care about that either, as remember,
this is debugfs, whose one rule is, "there is no rules."

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/