All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Morris <don.morris@hp.com>
To: linux-mm@kvack.org
Subject: Re: [PATCH] remove BUG() in possible but rare condition
Date: Wed, 11 Apr 2012 12:48:52 -0700	[thread overview]
Message-ID: <4F85E024.3070407@hp.com> (raw)
In-Reply-To: <20120411192052.GB24831@tiehlicka.suse.cz>

On 04/11/2012 12:20 PM, Michal Hocko wrote:
> On Wed 11-04-12 11:57:56, Linus Torvalds wrote:
>> On Wed, Apr 11, 2012 at 11:48 AM, Michal Hocko <mhocko@suse.cz> wrote:
>>>
>>> I am not familiar with the code much but a trivial call chain walk up to
>>> write_dev_supers (in btrfs) shows that we do not check for the return value
>>> from __getblk so we would nullptr and there might be more.
>>> I guess these need some treat before the BUG might be removed, right?
>>
>> Well, realistically, isn't BUG() as bad as a NULL pointer dereference?
>>
>> Do you care about the exact message on the screen when your machine dies?
> 
> I personally do not care as I do not allow anything to map at that area.
> 
> It just seems that there are some callers who do not expect that the
> allocation fails. BUG at the allocation failure which dates back when it
> replaced buffer_error might have let to some assumptions (not good of
> course but we should better fix them.
> 
> That being said I am not against the patch. BUG on an allocation failure
> just doesn't feel right...

Apologies in advance for the relatively wide distribution for what may
be an obvious/stupid question, but if this is in a Documentation/vm
file, I don't see it.

Unless I'm really missing something, the allocation in question uses
GFP_NOFS flags, resulting in a "Wait Ok" request to the underlying
allocators. Other than gotchas like force failures returning a fail
even for Wait-safe allocations... is it actually expected for Wait-safe
kernel allocations to fail? Certainly page requests for user memory
can run afoul of OOM or other mechanisms, and certainly any request
for special/hard memory could be failed... but wouldn't a general small
kernel allocation should generally sleep until satisfied?

That's what the current code looks like to me -- but I could easily
be missing something in the reading, so I'm mainly asking if there's
a general policy to the API here. If it is that non-special kernel
allocations wait until they're satisfied... I'm wondering, why the
test/force mode that seems guaranteed to light off BUG() statements
such as this which are simply validating the allocation contract?

Don Morris

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-04-11 19:48 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11 18:10 [PATCH] remove BUG() in possible but rare condition Glauber Costa
2012-04-11 18:10 ` Glauber Costa
2012-04-11 18:10 ` Glauber Costa
2012-04-11 20:26 ` Andrew Morton
2012-04-11 20:26   ` Andrew Morton
2012-04-11 20:51   ` Glauber Costa
2012-04-11 20:51     ` Glauber Costa
     [not found]     ` <4F85EEED.1090906-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-11 21:12       ` Andrew Morton
2012-04-11 21:12         ` Andrew Morton
2012-04-11 21:12         ` Andrew Morton
     [not found]         ` <20120411141244.2839d9a8.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2012-04-11 21:26           ` Michal Hocko
2012-04-11 21:26             ` Michal Hocko
2012-04-11 21:26             ` Michal Hocko
     [not found] ` <1334167824-19142-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-11 18:48   ` Michal Hocko
2012-04-11 18:48     ` Michal Hocko
2012-04-11 18:48     ` Michal Hocko
     [not found]     ` <20120411184845.GA24831-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-04-11 18:57       ` Linus Torvalds
2012-04-11 18:57         ` Linus Torvalds
2012-04-11 18:57         ` Linus Torvalds
     [not found]         ` <CA+55aFx1GMWGgh0sTAzvvVSzPQsQ_4NKeaNv1zpKrP4fg1dG+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-04-11 19:02           ` Glauber Costa
2012-04-11 19:02             ` Glauber Costa
2012-04-11 19:02             ` Glauber Costa
     [not found]             ` <4F85D53B.1070806-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-11 19:25               ` Michal Hocko
2012-04-11 19:25                 ` Michal Hocko
2012-04-11 19:25                 ` Michal Hocko
2012-04-11 19:20           ` Michal Hocko
2012-04-11 19:20             ` Michal Hocko
2012-04-11 19:20             ` Michal Hocko
2012-04-11 19:48             ` Don Morris [this message]
2012-04-11 21:33           ` Jiri Kosina
2012-04-11 21:33             ` Jiri Kosina
2012-04-11 21:33             ` Jiri Kosina
2012-04-11 18:59       ` Glauber Costa
2012-04-11 18:59         ` Glauber Costa
2012-04-11 18:59         ` Glauber Costa
2012-04-12  9:24   ` Michal Hocko
2012-04-12  9:24     ` Michal Hocko
2012-04-12  9:24     ` Michal Hocko

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=4F85E024.3070407@hp.com \
    --to=don.morris@hp.com \
    --cc=linux-mm@kvack.org \
    /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.