On Fri, 25 May 2007, young dave wrote:
> I can't call it oops, right?
Yes sure. This is a problem in the NTFS layer. It writes 2 bytes
after the allocated size.
> I navagated the ntfs inode.c, and found a possible bug, replaced
> kmalloc with kzalloc,
> because the ntfschar size is 2. then the kernel doesn't warning
> again. and the slub debug info also disappeared.
The kzalloc does not increase the size. So I suspect that the bug
did not trigger again after the change.
>
> This patch works for me:
>
> diff -udr linux/fs/ntfs/inode.c linux.new/fs/ntfs/inode.c
> --- linux/fs/ntfs/inode.c 2007-05-25 12:46:27.000000000 +0000
> +++ linux.new/fs/ntfs/inode.c 2007-05-25 12:45:31.000000000 +0000
> @@ -136,11 +136,10 @@
>
> BUG_ON(!na->name);
> i = na->name_len * sizeof(ntfschar);
> - ni->name = kmalloc(i + sizeof(ntfschar), GFP_ATOMIC);
> + ni->name = kzalloc(i + sizeof(ntfschar), GFP_ATOMIC);
Is this ntfs_init_locked_inode?
> Bytes b4 0xc2959e28: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a
> Object 0xc2959e38: 24 00 51 00 00 00 6b a5
> Redzone 0xc2959e40: 00 00 cc cc
First two bytes after the object overwritten. The allocation for this
object should have been two bytes longer.
> Last alloc: ntfs_init_locked_inode+0x9e/0x110 jiffies_ago=5140 cpu=0 pid=1604
This is the function that allocated a too short object.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
