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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox