linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Alastair D'Silva <alastair@d-silva.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pavel Tatashin <pasha.tatashin@oracle.com>,
	Oscar Salvador <osalvador@suse.de>,
	Mike Rapoport <rppt@linux.ibm.com>, Baoquan He <bhe@redhat.com>,
	Wei Yang <richard.weiyang@gmail.com>,
	Logan Gunthorpe <logang@deltatee.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v2 1/3] mm: Trigger bug on if a section is not found in __section_nr
Date: Thu, 27 Jun 2019 10:10:29 +0200	[thread overview]
Message-ID: <20190627080724.GK17798@dhcp22.suse.cz> (raw)
In-Reply-To: <e66e43b1fdfbff94ab23a23c48aa6cbe210a3131.camel@d-silva.org>

On Thu 27-06-19 10:50:57, Alastair D'Silva wrote:
> On Wed, 2019-06-26 at 08:57 +0200, Michal Hocko wrote:
> > On Wed 26-06-19 16:27:30, Alastair D'Silva wrote:
> > > On Wed, 2019-06-26 at 08:21 +0200, Michal Hocko wrote:
> > > > On Wed 26-06-19 16:11:21, Alastair D'Silva wrote:
> > > > > From: Alastair D'Silva <alastair@d-silva.org>
> > > > > 
> > > > > If a memory section comes in where the physical address is
> > > > > greater
> > > > > than
> > > > > that which is managed by the kernel, this function would not
> > > > > trigger the
> > > > > bug and instead return a bogus section number.
> > > > > 
> > > > > This patch tracks whether the section was actually found, and
> > > > > triggers the
> > > > > bug if not.
> > > > 
> > > > Why do we want/need that? In other words the changelog should
> > > > contina
> > > > WHY and WHAT. This one contains only the later one.
> > > >  
> > > 
> > > Thanks, I'll update the comment.
> > > 
> > > During driver development, I tried adding peristent memory at a
> > > memory
> > > address that exceeded the maximum permissable address for the
> > > platform.
> > > 
> > > This caused __section_nr to silently return bogus section numbers,
> > > rather than complaining.
> > 
> > OK, I see, but is an additional code worth it for the non-development
> > case? I mean why should we be testing for something that shouldn't
> > happen normally? Is it too easy to get things wrong or what is the
> > underlying reason to change it now?
> > 
> 
> It took me a while to identify what the problem was - having the BUG_ON
> would have saved me a few hours.
> 
> I'm happy to just have the BUG_ON 'nd drop the new error return (I
> added that in response to Mike Rapoport's comment that the original
> patch would still return a bogus section number).

Well, BUG_ON is about the worst way to handle an incorrect input. You
really do not want to put a production environment down just because
there is a bug in a driver, right? There are still many {VM_}BUG_ONs
in the tree and there is a general trend to get rid of many of them
rather than adding new ones.

Now back to your patch. You are adding an error handling where we simply
do not expect invalid data. This is often the case for the core kernel
functionality because we do expect consumers of the code to do the right
thing. E.g. __section_nr already takes a pointer to struct section which
assumes that this core data structure is already valid. Adding a check
here adds an unnecessary overhead so this doesn't really sound like a
good idea to me.
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2019-06-27  8:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-26  6:11 [PATCH v2 0/3] mm: Cleanup & allow modules to hotplug memory Alastair D'Silva
2019-06-26  6:11 ` [PATCH v2 1/3] mm: Trigger bug on if a section is not found in __section_nr Alastair D'Silva
2019-06-26  6:21   ` Michal Hocko
2019-06-26  6:27     ` Alastair D'Silva
2019-06-26  6:57       ` Michal Hocko
2019-06-27  0:50         ` Alastair D'Silva
2019-06-27  8:10           ` Michal Hocko [this message]
2019-06-28  0:46             ` Alastair D'Silva
2019-07-01 10:46               ` Michal Hocko
2019-07-02  4:13                 ` Alastair D'Silva
2019-07-02  6:13                   ` Michal Hocko
2019-07-02  6:16                     ` Alastair D'Silva
2019-06-28 11:37             ` David Hildenbrand
2019-06-28 11:58               ` Michal Hocko
2019-06-26  6:11 ` [PATCH v2 2/3] mm: don't hide potentially null memmap pointer in sparse_remove_one_section Alastair D'Silva
2019-06-26  6:23   ` Michal Hocko
2019-06-26  6:30     ` Alastair D'Silva
2019-06-26  6:59       ` Michal Hocko
2019-06-28 11:29   ` David Hildenbrand
2019-06-26  6:11 ` [PATCH v2 3/3] mm: Don't manually decrement num_poisoned_pages Alastair D'Silva
2019-06-26  6:24   ` Michal Hocko
2019-06-28 11:29   ` David Hildenbrand
2019-06-26  7:57 ` [PATCH v2 0/3] mm: Cleanup & allow modules to hotplug memory Christoph Hellwig
2019-06-27  0:51   ` Alastair D'Silva

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=20190627080724.GK17798@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alastair@d-silva.org \
    --cc=bhe@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@oracle.com \
    --cc=rafael@kernel.org \
    --cc=richard.weiyang@gmail.com \
    --cc=rppt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox