Re: [PATCH] Avoid a NULL pointer in btrfs
δΊ 2011-1-19 23:52, Chris Mason ει: Excerpts from Josef Bacik's message of 2011-01-19 09:14:02 -0500: On Wed, Jan 19, 2011 at 10:08:13PM +0800, Liuwenyi wrote: In Yang Ruirui's mail, the btrfs will create a oops. This is caused by a null pointer in test_range_bit() while lock the spinlock. So, It is necessary to add a pointer check into test_range_bit() NAK, the tree shouldn't be null coming into this function, something else is going wrong. What oops is this? Thanks, The mail is here http://lkml.org/lkml/2011/1/19/24 another mesg is here http://www.aei.mpg.de/~crmafra/dmesg-2.6.35.3.txt What was your metadata blocksize for this oops? This call should never happen. It is rare and hard to reproduced. So, I update this patch, just avoid a null pointer calling. I think there is a larger problem, probably in the IO error handling code since the trace had io errors beforehand. Yes, I agree. This situation is too strange to happen. -chris --- Best Regards, Liu Wenyi -- 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: [PATCH] Avoid a NULL pointer in btrfs
On Wed, Jan 19, 2011 at 10:08:13PM +0800, Liuwenyi wrote: In Yang Ruirui's mail, the btrfs will create a oops. This is caused by a null pointer in test_range_bit() while lock the spinlock. So, It is necessary to add a pointer check into test_range_bit() NAK, the tree shouldn't be null coming into this function, something else is going wrong. What oops is this? Thanks, Josef -- 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: [PATCH] Avoid a NULL pointer in btrfs
Excerpts from Josef Bacik's message of 2011-01-19 09:14:02 -0500: On Wed, Jan 19, 2011 at 10:08:13PM +0800, Liuwenyi wrote: In Yang Ruirui's mail, the btrfs will create a oops. This is caused by a null pointer in test_range_bit() while lock the spinlock. So, It is necessary to add a pointer check into test_range_bit() NAK, the tree shouldn't be null coming into this function, something else is going wrong. What oops is this? Thanks, What was your metadata blocksize for this oops? This call should never happen. I think there is a larger problem, probably in the IO error handling code since the trace had io errors beforehand. -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
