Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4

Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4

[Nageswara R Sastry]

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

Re: Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4

[Ted Ts'o]

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

Re: Warning: at __alloc_pages_nodemask+0x3e0/0xa9c with ext4

[Nageswara R Sastry]

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