* Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4
@ 2012-02-21 10:07 Nageswara R Sastry
2012-02-21 12:31 ` Ted Ts'o
0 siblings, 1 reply; 3+ messages in thread
From: Nageswara R Sastry @ 2012-02-21 10:07 UTC (permalink / raw)
To: tytso; +Cc: linux-fsdevel
Hello,
I am trying with 'fsfuzzer - file system fuzzer' on 's390' architecture
and got the following warning:
[ 1469.422770] ------------[ cut here ]------------
[ 1469.422777] WARNING: at
/home/autobuild/BUILD/linux-3.2.4-20120207/mm/page_alloc.c:2096
[ 1469.422780] Modules linked in: loop qeth_l3 vmur qeth ccwgroup ipv6
autofs4 [last unloaded: scsi_wait_scan]
[ 1469.422792] Modules linked in: loop qeth_l3 vmur qeth ccwgroup ipv6
autofs4 [last unloaded: scsi_wait_scan]
[ 1469.422805] CPU: 1 Not tainted 3.2.4-52.x.20120207-s390xdefault #1
[ 1469.422808] Process mount (pid: 22845, task: 00000000355fca50, ksp:
0000000035e37860)
[ 1469.422811] Krnl PSW : 0704100180000000 000000000021256c
(__alloc_pages_nodemask+0x3e0/0xa9c)
[ 1469.422822] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0
CC:1 PM:0 EA:3
[ 1469.422826] Krnl GPRS: 0000000000007500 00000000014b9254
0000000000000000 0000000000000001
[ 1469.422829] 0000000000212374 0000000035e378b0
000000000096ef00 0000000000000000
[ 1469.422832] 0000000000970400 0000000000000000
000000000000000a 000000000000c0d0
[ 1469.422836] 0000000000000001 000000000063b050
0000000000212374 0000000035e37878
[ 1469.422848] Krnl Code: 0000000000212560: 95011000 cli
0(%r1),1
[ 1469.422852] 0000000000212564: a784ff0c brc
8,21237c
[ 1469.422856] #0000000000212568: a7f40001 brc
15,21256a
[ 1469.422861] >000000000021256c: 92011000 mvi 0(%r1),1
[ 1469.422865] 0000000000212570: a7f4ff06 brc
15,21237c
[ 1469.422868] 0000000000212574: a7f40001 brc
15,212576
[ 1469.422872] 0000000000212578: a7f4fe33 brc
15,2121de
[ 1469.422876] 000000000021257c: a7180020 lhi
%r1,32
[ 1469.422880] Call Trace:
[ 1469.422882] ([<0000000000212374>] __alloc_pages_nodemask+0x1e8/0xa9c)
[ 1469.422886] [<0000000000212c62>] __get_free_pages+0x3a/0x78
[ 1469.422890] [<000000000025e81c>] kmalloc_order_trace+0x4c/0x198
[ 1469.422895] [<0000000000263008>] __kmalloc+0x37c/0x40c
[ 1469.422899] [<00000000003648a6>] ext4_kvzalloc+0x32/0x68
[ 1469.422905] [<000000000036a010>] ext4_fill_super+0x1884/0x2ebc
[ 1469.422910] [<0000000000279984>] mount_bdev+0x1dc/0x214
[ 1469.422915] [<0000000000356240>] ext4_mount+0x28/0x38
[ 1469.422919] [<000000000027a69a>] mount_fs+0x5a/0x184
[ 1469.422922] [<0000000000299da6>] vfs_kern_mount+0x66/0xe0
[ 1469.423015] [<000000000029c062>] do_kern_mount+0x52/0x114
[ 1469.423023] [<000000000029dda2>] do_mount+0x2de/0x818
[ 1469.423029] [<000000000029e7aa>] SyS_mount+0xa2/0xf0
[ 1469.423036] [<0000000000621bb4>] sysc_noemu+0x22/0x28
[ 1469.423044] [<000003fffd2789ba>] 0x3fffd2789ba
[ 1469.423053] 1 lock held by mount/22845:
[ 1469.423056] #0: (&type->s_umount_key#35/1){+.+.+.}, at:
[<0000000000279398>] sget+0x31c/0x650
[ 1469.423077] Last Breaking-Event-Address:
[ 1469.423080] [<0000000000212568>] __alloc_pages_nodemask+0x3dc/0xa9c
[ 1469.423088] ---[ end trace c14e2e3b807091a4 ]---
Environment:
Architecture: s390 (64-bit)
Kernel: 3.2.4
Please let me know if you need more information.
Regards
R.Nageswara Sastry
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4
2012-02-21 10:07 Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4 Nageswara R Sastry
@ 2012-02-21 12:31 ` Ted Ts'o
2012-02-22 5:35 ` Nageswara R Sastry
0 siblings, 1 reply; 3+ messages in thread
From: Ted Ts'o @ 2012-02-21 12:31 UTC (permalink / raw)
To: Nageswara R Sastry; +Cc: linux-fsdevel
On Tue, Feb 21, 2012 at 03:37:33PM +0530, Nageswara R Sastry wrote:
> Hello,
>
> I am trying with 'fsfuzzer - file system fuzzer' on 's390'
> architecture and got the following warning:
Yeah, that's harmless. It just means that the file system had some
crazy numbers in the superblock, and as a result ext4 tried to
allocate a large array --- first using kzalloc, which failed, and then
it would have fallen back to vmalloc. Typically if the file system is
that badly corrupted it would have failed some check later on, at
which point the allocated memory (via vmalloc) would be released. Or,
if the amount of memory being request is really ridiculous, the
vmalloc() will fail and then the mount will fail that way.
You can also get the same warning if you mount a sufficiently large
file system.
If you send me the output of dumpe2fs on the fuzzed/corrupted file
system, I can look at it to see if there's additional bullet proofing
we could do before the memory allocation, but from what I can tell
from the stack trace and the warning, there's nothing that we need to
worry about here. (Certainly not form a security perspective.)
We could avoid the warning by having ext4_kvzalloc() do a
get_order(size) check of its argument, and then fall back to vmalloc
immediately if it's >= MAX_ORDER, but that would mainly be to avoid
the warning as a cosmetic issue.
Regards,
- Ted
>
> [ 1469.422770] ------------[ cut here ]------------
> [ 1469.422777] WARNING: at
> /home/autobuild/BUILD/linux-3.2.4-20120207/mm/page_alloc.c:2096
> [ 1469.422780] Modules linked in: loop qeth_l3 vmur qeth ccwgroup
> ipv6 autofs4 [last unloaded: scsi_wait_scan]
> [ 1469.422792] Modules linked in: loop qeth_l3 vmur qeth ccwgroup
> ipv6 autofs4 [last unloaded: scsi_wait_scan]
> [ 1469.422805] CPU: 1 Not tainted 3.2.4-52.x.20120207-s390xdefault #1
> [ 1469.422808] Process mount (pid: 22845, task: 00000000355fca50,
> ksp: 0000000035e37860)
> [ 1469.422811] Krnl PSW : 0704100180000000 000000000021256c
> (__alloc_pages_nodemask+0x3e0/0xa9c)
> [ 1469.422822] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0
> CC:1 PM:0 EA:3
> [ 1469.422826] Krnl GPRS: 0000000000007500 00000000014b9254
> 0000000000000000 0000000000000001
> [ 1469.422829] 0000000000212374 0000000035e378b0
> 000000000096ef00 0000000000000000
> [ 1469.422832] 0000000000970400 0000000000000000
> 000000000000000a 000000000000c0d0
> [ 1469.422836] 0000000000000001 000000000063b050
> 0000000000212374 0000000035e37878
> [ 1469.422848] Krnl Code: 0000000000212560: 95011000 cli
> 0(%r1),1
> [ 1469.422852] 0000000000212564: a784ff0c brc
> 8,21237c
> [ 1469.422856] #0000000000212568: a7f40001 brc
> 15,21256a
> [ 1469.422861] >000000000021256c: 92011000 mvi 0(%r1),1
> [ 1469.422865] 0000000000212570: a7f4ff06 brc
> 15,21237c
> [ 1469.422868] 0000000000212574: a7f40001 brc
> 15,212576
> [ 1469.422872] 0000000000212578: a7f4fe33 brc
> 15,2121de
> [ 1469.422876] 000000000021257c: a7180020 lhi
> %r1,32
> [ 1469.422880] Call Trace:
> [ 1469.422882] ([<0000000000212374>] __alloc_pages_nodemask+0x1e8/0xa9c)
> [ 1469.422886] [<0000000000212c62>] __get_free_pages+0x3a/0x78
> [ 1469.422890] [<000000000025e81c>] kmalloc_order_trace+0x4c/0x198
> [ 1469.422895] [<0000000000263008>] __kmalloc+0x37c/0x40c
> [ 1469.422899] [<00000000003648a6>] ext4_kvzalloc+0x32/0x68
> [ 1469.422905] [<000000000036a010>] ext4_fill_super+0x1884/0x2ebc
> [ 1469.422910] [<0000000000279984>] mount_bdev+0x1dc/0x214
> [ 1469.422915] [<0000000000356240>] ext4_mount+0x28/0x38
> [ 1469.422919] [<000000000027a69a>] mount_fs+0x5a/0x184
> [ 1469.422922] [<0000000000299da6>] vfs_kern_mount+0x66/0xe0
> [ 1469.423015] [<000000000029c062>] do_kern_mount+0x52/0x114
> [ 1469.423023] [<000000000029dda2>] do_mount+0x2de/0x818
> [ 1469.423029] [<000000000029e7aa>] SyS_mount+0xa2/0xf0
> [ 1469.423036] [<0000000000621bb4>] sysc_noemu+0x22/0x28
> [ 1469.423044] [<000003fffd2789ba>] 0x3fffd2789ba
> [ 1469.423053] 1 lock held by mount/22845:
> [ 1469.423056] #0: (&type->s_umount_key#35/1){+.+.+.}, at:
> [<0000000000279398>] sget+0x31c/0x650
> [ 1469.423077] Last Breaking-Event-Address:
> [ 1469.423080] [<0000000000212568>] __alloc_pages_nodemask+0x3dc/0xa9c
> [ 1469.423088] ---[ end trace c14e2e3b807091a4 ]---
>
>
> Environment:
> Architecture: s390 (64-bit)
> Kernel: 3.2.4
> Please let me know if you need more information.
>
> Regards
> R.Nageswara Sastry
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4
2012-02-21 12:31 ` Ted Ts'o
@ 2012-02-22 5:35 ` Nageswara R Sastry
0 siblings, 0 replies; 3+ messages in thread
From: Nageswara R Sastry @ 2012-02-22 5:35 UTC (permalink / raw)
To: Ted Ts'o; +Cc: linux-fsdevel
On ఫిబ్రవరి 21 మంగళవారం 2012 సా. 06:01, Ted Ts'o wrote:
> If you send me the output of dumpe2fs on the fuzzed/corrupted file
> system, I can look at it to see if there's additional bullet proofing
> we could do before the memory allocation,
Thanks a lot Ted for your quick reply and for the explanation about the
warning.
Unable to get the 'dumpe2fs' of the file system image, which test suite
found as a problem creating image. But when tried with that image
couldn't able to re-produce the 'warning'. So guessing like there was a
timing issue with the test suite. Currently in the process of solving
this and as soon as it is re-produced - will provide the output of
'dumpe2fs' for analysis.
Thank you.
Regards,
R.Nageswara Sastry
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-02-22 5:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-21 10:07 Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4 Nageswara R Sastry
2012-02-21 12:31 ` Ted Ts'o
2012-02-22 5:35 ` Nageswara R Sastry
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.