From: Andi Drebes <lists-receive@programmierforen.de>
To: linux-btrfs@vger.kernel.org
Cc: Diego Calleja <diegocg@gmail.com>, Andi Kleen <andi@firstfloor.org>
Subject: Proper error handling on NULL pointers
Date: Mon, 19 Oct 2009 12:36:13 +0200 [thread overview]
Message-ID: <200910191236.14046.lists-receive@programmierforen.de> (raw)
Hi!
I recently posted a message that addresses the usage of BUG_ON for memory shortages concerning btrfs_alloc_path() (see [1]):
...
path = btrfs_alloc_path();
BUG_ON(!path);
ret = btrfs_search_slot(NULL, root, &search_key, path, 0, 0);
...
It seems that this is not the only place where NULL pointers returned by allocation functions are not handled properly. For instance in start_transaction(), errors are not handled at all:
struct btrfs_trans_handle *h =
kmem_cache_alloc(btrfs_trans_handle_cachep, GFP_NOFS);
...
/* Access h without check */
...
return h;
Repairing this would sometimes require to review a bunch of functions that directly or indirectly refer to it. As pointed out by Andi Kleen two weeks ago in a reply to message by Diego Calleja (see [2] and [3]), this might not be trivial, because these errors are sometimes not handled at all in highlevel functions.
However, is there any interest in patches fixing these problems? If yes: what would be the best strategy? Should we start fixing this "layer by layer" -- the low-level functions first and the high-level functions later on? Or should use come kind of "vertical approach" -- one low-level function and all of its callers at once?
If these issues currently don't have a very high priority, we could collect them in a TODO section in the Wiki or something. Any suggestions?
Cheers,
Andi
[1] http://www.spinics.net/lists/linux-btrfs/msg03221.html
[2] http://www.spinics.net/lists/linux-btrfs/msg03197.html
[3] http://www.spinics.net/lists/linux-btrfs/msg03198.html
next reply other threads:[~2009-10-19 10:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-19 10:36 Andi Drebes [this message]
2009-10-21 17:43 ` Proper error handling on NULL pointers Diego Calleja
2009-10-22 10:15 ` Andi Drebes
2009-10-22 14:10 ` Diego Calleja
2009-10-22 16:23 ` Andi Drebes
2009-10-23 18:08 ` Jeff Mahoney
2009-10-26 9:14 ` Chris Mason
2009-10-26 14:24 ` Jeff Mahoney
2009-10-30 13:27 ` Jeff Mahoney
2009-10-30 13:49 ` Chris Mason
2009-10-26 9:23 ` Chris Mason
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=200910191236.14046.lists-receive@programmierforen.de \
--to=lists-receive@programmierforen.de \
--cc=andi@firstfloor.org \
--cc=diegocg@gmail.com \
--cc=linux-btrfs@vger.kernel.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.