From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Oliver O'Halloran <oohall@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>,
Sukadev Bhattiprolu <sukadev@linux.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Anju T Sudhakar <anju@linux.vnet.ibm.com>
Subject: Re: [PATCH 6/6] powerpc: powernv: no need to check return value of debugfs_create functions
Date: Mon, 10 Feb 2020 07:19:15 -0800 [thread overview]
Message-ID: <20200210151915.GA686798@kroah.com> (raw)
In-Reply-To: <CAOSf1CEKwjDkp-=SMjmJfQirxdGCkadougZbdDS6FK1muNNCZw@mail.gmail.com>
On Tue, Feb 11, 2020 at 02:01:53AM +1100, Oliver O'Halloran wrote:
> On Mon, Feb 10, 2020 at 12:12 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something different based on this.
>
> For memtrace debugfs is the only way to actually use the feature. It'd
> be nice if it still printed out *something* if it failed to create the
> files rather than just being mysteriously absent, but maybe debugfs
> itself does that. Looks fine otherwise.
No, debugfs will only spit out an error message to the log if a
file/directory is attempted to be created for an already present
file/directory.
For other failures, no error will be printed, other than the normal
lower-level "out of memory" issues that might rarely happen.
thanks,
greg k-h
next prev parent reply other threads:[~2020-02-10 15:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-09 10:58 [PATCH 1/6] powerpc: kernel: no need to check return value of debugfs_create functions Greg Kroah-Hartman
2020-02-09 10:58 ` [PATCH 2/6] powerpc: kvm: " Greg Kroah-Hartman
2020-02-09 10:58 ` Greg Kroah-Hartman
2020-03-03 7:46 ` Michael Ellerman
2020-03-03 7:46 ` Michael Ellerman
2020-03-03 8:50 ` Greg Kroah-Hartman
2020-03-03 8:50 ` Greg Kroah-Hartman
2020-03-03 9:45 ` Michael Ellerman
2020-03-03 9:45 ` Michael Ellerman
2020-03-03 9:58 ` Greg Kroah-Hartman
2020-03-03 9:58 ` Greg Kroah-Hartman
2020-03-03 10:32 ` Michael Ellerman
2020-03-03 10:32 ` Michael Ellerman
2020-02-09 10:58 ` [PATCH 3/6] powerpc: mm: book3s64: hash_utils: " Greg Kroah-Hartman
2020-02-09 10:58 ` [PATCH 4/6] powerpc: mm: ptdump: " Greg Kroah-Hartman
2020-02-09 10:59 ` [PATCH 5/6] powerpc: cell: axon_msi: " Greg Kroah-Hartman
2020-02-09 10:59 ` [PATCH 6/6] powerpc: powernv: " Greg Kroah-Hartman
2020-02-10 15:01 ` Oliver O'Halloran
2020-02-10 15:19 ` Greg Kroah-Hartman [this message]
2020-03-03 9:52 ` Michael Ellerman
2020-03-06 0:27 ` [PATCH 1/6] powerpc: kernel: " Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200210151915.GA686798@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=anju@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oohall@gmail.com \
--cc=paulus@samba.org \
--cc=sukadev@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.