From: Andrew Morton <akpm@linux-foundation.org>
To: Alexander Kuleshov <kuleshovmail@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>,
Pekka Enberg <penberg@kernel.org>, Mel Gorman <mgorman@suse.de>,
Baoquan He <bhe@redhat.com>, Tang Chen <tangchen@cn.fujitsu.com>,
Robin Holt <holt@sgi.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] mm/memblock: validate the creation of debugfs files
Date: Sat, 15 Aug 2015 00:38:30 -0700 [thread overview]
Message-ID: <20150815003830.c87afaff.akpm@linux-foundation.org> (raw)
In-Reply-To: <20150815072636.GA2539@localhost>
On Sat, 15 Aug 2015 13:26:36 +0600 Alexander Kuleshov <kuleshovmail@gmail.com> wrote:
> Hello Andrew,
>
> On 08-14-15, Andrew Morton wrote:
> > On Sat, 15 Aug 2015 01:03:31 +0600 Alexander Kuleshov <kuleshovmail@gmail.com> wrote:
> >
> > > Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> >
> > There's no changelog.
>
> Yes, will add it if there will be sense in the patch.
>
> >
> > Why? Ignoring the debugfs API return values is standard practice.
> >
>
> Yes, but I saw many places where this practice is applicable (for example
> in the kernel/kprobes and etc.), besides this, the memblock API is used
> mostly at early stage, so we will have some output if something going wrong.
The debugfs error-handling rules are something Greg cooked up after one
too many beers. I've never understood them, but maybe I continue to
miss the point.
Yes, I agree that if memblock's debugfs_create_file() fails, we want to
know about it because something needs fixing. But that's true of
all(?) debugfs_create_file callsites, so it's a bit silly to add
warnings to them all. Why not put the warning into
debugfs_create_file() itself? And add a debugfs_create_file_no_warn()
if there are callsites which have reason to go it alone. Or add a
debugfs_create_file_warn() wrapper.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Alexander Kuleshov <kuleshovmail@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>,
Pekka Enberg <penberg@kernel.org>, Mel Gorman <mgorman@suse.de>,
Baoquan He <bhe@redhat.com>, Tang Chen <tangchen@cn.fujitsu.com>,
Robin Holt <holt@sgi.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] mm/memblock: validate the creation of debugfs files
Date: Sat, 15 Aug 2015 00:38:30 -0700 [thread overview]
Message-ID: <20150815003830.c87afaff.akpm@linux-foundation.org> (raw)
In-Reply-To: <20150815072636.GA2539@localhost>
On Sat, 15 Aug 2015 13:26:36 +0600 Alexander Kuleshov <kuleshovmail@gmail.com> wrote:
> Hello Andrew,
>
> On 08-14-15, Andrew Morton wrote:
> > On Sat, 15 Aug 2015 01:03:31 +0600 Alexander Kuleshov <kuleshovmail@gmail.com> wrote:
> >
> > > Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> >
> > There's no changelog.
>
> Yes, will add it if there will be sense in the patch.
>
> >
> > Why? Ignoring the debugfs API return values is standard practice.
> >
>
> Yes, but I saw many places where this practice is applicable (for example
> in the kernel/kprobes and etc.), besides this, the memblock API is used
> mostly at early stage, so we will have some output if something going wrong.
The debugfs error-handling rules are something Greg cooked up after one
too many beers. I've never understood them, but maybe I continue to
miss the point.
Yes, I agree that if memblock's debugfs_create_file() fails, we want to
know about it because something needs fixing. But that's true of
all(?) debugfs_create_file callsites, so it's a bit silly to add
warnings to them all. Why not put the warning into
debugfs_create_file() itself? And add a debugfs_create_file_no_warn()
if there are callsites which have reason to go it alone. Or add a
debugfs_create_file_warn() wrapper.
next prev parent reply other threads:[~2015-08-15 7:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-14 19:03 [PATCH] mm/memblock: validate the creation of debugfs files Alexander Kuleshov
2015-08-14 19:03 ` Alexander Kuleshov
2015-08-14 21:19 ` Andrew Morton
2015-08-14 21:19 ` Andrew Morton
2015-08-15 7:26 ` Alexander Kuleshov
2015-08-15 7:26 ` Alexander Kuleshov
2015-08-15 7:38 ` Andrew Morton [this message]
2015-08-15 7:38 ` Andrew Morton
2015-08-15 7:48 ` Alexander Kuleshov
2015-08-15 7:48 ` Alexander Kuleshov
2015-08-15 7:52 ` Andrew Morton
2015-08-15 7:52 ` Andrew Morton
2015-08-15 16:07 ` Greg Kroah-Hartman
2015-08-15 16:07 ` Greg Kroah-Hartman
2015-08-17 22:05 ` Andrew Morton
2015-08-17 22:05 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2015-08-14 19:08 Alexander Kuleshov
2015-08-14 19:13 ` Alexander Kuleshov
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=20150815003830.c87afaff.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=holt@sgi.com \
--cc=kuleshovmail@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=penberg@kernel.org \
--cc=tangchen@cn.fujitsu.com \
--cc=tony.luck@intel.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.