Re: XFS Bug null pointer dereference in xfs_free_ag_extent
From: Joe Jin
Date: Mon Jul 31 2006 - 04:39:46 EST
At XFS have a debug option, but I wonder why why it was not opened,
and you may open the option with follow patch, rebuild kernel, you
maybe get more information of it.
And when I trace the code, I also found at some function should check
the return value, it also include the patch.
Hope help for you.
On 7/31/06, kernel <linux@xxxxxxxxxxxx> wrote:
I format the same partition and restart the testing server before each
testing.
I'vs tested on each format at least twenty times.
With XFS and SAN, This crash happens on every bonnie++ testing.
And I have tested such things on another mathine, results are same.
Nathan Scott wrote:
> On Mon, Jul 31, 2006 at 02:21:10PM +0800, kernel wrote:
>
>> Test again......very strange.
>> I can easily reproduce it on the XFS with SAN(FLX380) connected with a
>> qlogic 2400 FC card.
>>
>
> Eggshellent... can you reproduce it with each of those changes
> (below) backed out of your tree please? Else, git bisect is our
> next best bet. Thanks!
>
>
>>> Is this easily reproducible for you? I've not seen it before, and
>>> the only possibly related recent changes I can think of are these:
>>>
>>> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e63a3690013a475746ad2cea998ebb534d825704
>>>
>>> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d210a28cd851082cec9b282443f8cc0e6fc09830
>>>
>>> Could you try reverting each of those to see if either is the cause?
>>>
>
> cheers.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Regards,
Joe.Jin
--- linux-2.6.18-rc3/fs/xfs/Kconfig 2006-07-30 14:15:36.000000000 +0800
+++ linux.new/fs/xfs/Kconfig 2006-07-31 16:22:32.000000000 +0800
@@ -17,6 +17,15 @@
system of your root partition is compiled as a module, you'll need
to use an initial ramdisk (initrd) to boot.
+config XFS_DEBUG
+ bool "XFS debugging"
+ depends on XFS_FS
+ help
+ If you are experiencing any problems with the XFS filesystem, say
+ Y here. This will result in additional debugging messages to be
+ written to the system log. Under normal circumstances, this
+ results in very little overhead.
+
config XFS_QUOTA
bool "XFS Quota support"
depends on XFS_FS
--- linux-2.6.18-rc3/fs/xfs/xfs_btree.c 2006-07-30 14:15:36.000000000 +0800
+++ linux.new/fs/xfs/xfs_btree.c 2006-07-31 15:39:43.000000000 +0800
@@ -586,6 +586,9 @@
* Allocate a new cursor.
*/
cur = kmem_zone_zalloc(xfs_btree_cur_zone, KM_SLEEP);
+ if(!cur)
+ return NULL;
+
/*
* Deduce the number of btree levels from the arguments.
*/
--- linux-2.6.18-rc3/fs/xfs/xfs_alloc.c 2006-07-30 14:15:36.000000000 +0800
+++ linux.new/fs/xfs/xfs_alloc.c 2006-07-31 16:09:04.000000000 +0800
@@ -649,6 +649,9 @@
*/
bno_cur = xfs_btree_init_cursor(args->mp, args->tp, args->agbp,
args->agno, XFS_BTNUM_BNO, NULL, 0);
+ if(!bno_cur)
+ return XFS_ERROR(ENOMEM);
+
/*
* Lookup bno and minlen in the btree (minlen is irrelevant, really).
* Look for the closest free block <= bno, it must contain bno