From: Jeff Mahoney <jeffm@suse.com>
To: Andi Drebes <lists-receive@programmierforen.de>
Cc: Diego Calleja <diegocg@gmail.com>,
linux-btrfs@vger.kernel.org, Andi Kleen <andi@firstfloor.org>
Subject: Re: Proper error handling on NULL pointers
Date: Fri, 23 Oct 2009 14:08:48 -0400 [thread overview]
Message-ID: <4AE1F130.9070807@suse.com> (raw)
In-Reply-To: <200910221215.59623.lists-receive@programmierforen.de>
On 10/22/2009 06:15 AM, Andi Drebes wrote:
>> I don't know what is the developer plan to fix that - apparently it's
>> not in the high-priority list (but it must be certainly in the priority
>> list, anyone who gets out of memory using btrfs will have some chances of
>> getting an oops [...]).
> I'd really appreciate to see a TODO section somewhere in the wiki. All the stuff that doesn't have a very high priority, but that should be done sometime in the future, could be put there. Even the simplest things like search and replace operations. This would be a good point for people not yet familiar with the btrfs code (like me) to get involved and main developers would get rid of the things that don't have a high priority.
>
>> [...] Passing the error to the callers and handling
>> all that properly is the real fix, but since it requires auditing the whole
>> FS it's probably not an easy task. I tried to do that with a couple of
>> functions, but Kleen's mail made me realize that it isn't that easy.
> Maybe it would be easier if we found some people helping us to fix this. In this case it would also be really helpful if one of the main developers reviewed the work with a "btrfs expert eye".
>
> For now I'm going to analyze some dependencies and see how many and *which* functions are affected.
>
> What about the main developers? How do you see things? I'd really like to hear your opinion before messing around in the project.
Hi Andi -
I actually have a patch set that addresses these. I submitted it several
months ago, but nothing happened. The problem with fixes like these is
that they change context *everywhere* so the best time to add them is
really when there is a lull in the project. Otherwise, you end up
forcing people working on other features or fixes to redo a bunch of
work. When's the last time you saw a lull in btrfs development? :)
I'll refresh it when I get a chance either today or early next week and
post it again.
-Jeff
--
Jeff Mahoney
SUSE Labs
next prev parent reply other threads:[~2009-10-23 18:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-19 10:36 Proper error handling on NULL pointers Andi Drebes
2009-10-21 17:43 ` 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 [this message]
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=4AE1F130.9070807@suse.com \
--to=jeffm@suse.com \
--cc=andi@firstfloor.org \
--cc=diegocg@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists-receive@programmierforen.de \
/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