Re: Proper error handling on NULL pointers
On 10/26/2009 05:14 AM, Chris Mason wrote: On Fri, Oct 23, 2009 at 02:08:48PM -0400, Jeff Mahoney wrote: 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. Hi Jeff, If you're able to refresh this, I'll push it immediately into the .32 queue. That way we won't end up having to rediff it again. I had to push this to next week. It builds and I expect it be stable, but since there's been 6+ months of development on btrfs since I last refreshed it, I want to make sure that I'm not missing call paths. I quick check shows that I am and I just haven't had the time to update it this week. -Jeff -- Jeff Mahoney SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proper error handling on NULL pointers
On Fri, Oct 30, 2009 at 09:27:36AM -0400, Jeff Mahoney wrote: On 10/26/2009 05:14 AM, Chris Mason wrote: On Fri, Oct 23, 2009 at 02:08:48PM -0400, Jeff Mahoney wrote: 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. Hi Jeff, If you're able to refresh this, I'll push it immediately into the .32 queue. That way we won't end up having to rediff it again. I had to push this to next week. It builds and I expect it be stable, but since there's been 6+ months of development on btrfs since I last refreshed it, I want to make sure that I'm not missing call paths. I quick check shows that I am and I just haven't had the time to update it this week. While I'm sure you'll have to update parts of the patch to catch the last 6 months of work, I'd take an incomplete patch as long as it doesn't break things. No sense in needing to update the baseline code over and over again. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proper error handling on NULL pointers
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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proper error handling on NULL pointers
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. Cheers, Andi -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proper error handling on NULL pointers
On Jueves 22 Octubre 2009 12:15:59 Andi Drebes escribió: I'd really appreciate to see a TODO section somewhere in the wiki. [..] There's one (needs updating): http://btrfs.wiki.kernel.org/index.php/Development_timeline Also, http://btrfs.wiki.kernel.org/index.php/Project_ideas has some ideas. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
