Menu
▾
▴
user-mode-linux-user
|
From: Toralf F. <tor...@gm...> - 2013-05-10 21:52:35
|
The bisected commit introduced this WARNING: on a user mode linux guest
if the UML guest is fuzz tested with trinity :
2013-05-10T22:38:42.191+02:00 trinity kernel: ------------[ cut here ]------------
2013-05-10T22:38:42.191+02:00 trinity kernel: WARNING: at mm/slab_common.c:376 kmalloc_slab+0x33/0x80()
2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fda8: [<08336928>] dump_stack+0x22/0x24
2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fdc0: [<0807c2da>] warn_slowpath_common+0x5a/0x80
2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fde8: [<0807c3a3>] warn_slowpath_null+0x23/0x30
2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fdf8: [<080dfc93>] kmalloc_slab+0x33/0x80
2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fe0c: [<080f8beb>] __kmalloc_track_caller+0x1b/0x110
2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fe30: [<080dc866>] memdup_user+0x26/0x70
2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fe4c: [<080dca6e>] strndup_user+0x3e/0x60
2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fe68: [<0811ba60>] copy_mount_string+0x30/0x50
2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2fe7c: [<0811c46a>] sys_mount+0x1a/0xe0
2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2feac: [<08062b32>] handle_syscall+0x82/0xb0
2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2fef4: [<0807520d>] userspace+0x46d/0x590
2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2ffec: [<0805f7fc>] fork_handler+0x6c/0x70
2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2fffc: [<00000000>] 0x0
2013-05-10T22:38:42.195+02:00 trinity kernel:
2013-05-10T22:38:42.195+02:00 trinity kernel: ---[ end trace 17e5931469d0697d ]---
Tested with host kernel 3.9.1, host and client were 32bit stable Gentoo Linux.
6286ae97d10ea2b5cd90532163797ab217bfdbdf is the first bad commit
commit 6286ae97d10ea2b5cd90532163797ab217bfdbdf
Author: Christoph Lameter <cl...@li...>
Date: Fri May 3 15:43:18 2013 +0000
slab: Return NULL for oversized allocations
The inline path seems to have changed the SLAB behavior for very large
kmalloc allocations with commit e3366016 ("slab: Use common
kmalloc_index/kmalloc_size functions"). This patch restores the old
behavior but also adds diagnostics so that we can figure where in the
code these large allocations occur.
Reported-and-tested-by: Tetsuo Handa <pen...@I-...>
Signed-off-by: Christoph Lameter <cl...@li...>
Link: http://lkml.kernel.org/r/201...@I-...
[ pe...@ke...: use WARN_ON_ONCE ]
Signed-off-by: Pekka Enberg <pe...@ke...>
-- MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
|
|
From: Toralf F. <tor...@gm...> - 2013-05-11 08:19:45
|
On 05/10/2013 11:52 PM, Toralf Förster wrote: > The bisected commit introduced this WARNING: on a user mode linux guest > if the UML guest is fuzz tested with trinity : Well, the behaviour is much older, a test with an UML guest kernel 3.7.10 showed a similar thing : Sry for the noise. 2013-05-11T10:16:30.841+02:00 trinity kernel: ------------[ cut here ]------------ 2013-05-11T10:16:30.841+02:00 trinity kernel: WARNING: at mm/page_alloc.c:2384 __alloc_pages_nodemask+0x13c/0x740() 2013-05-11T10:16:30.841+02:00 trinity kernel: 3fda7d10: [<08332bd8>] dump_stack+0x22/0x24 2013-05-11T10:16:30.841+02:00 trinity kernel: 3fda7d28: [<0807d6ca>] warn_slowpath_common+0x5a/0x80 2013-05-11T10:16:30.841+02:00 trinity kernel: 3fda7d50: [<0807d793>] warn_slowpath_null+0x23/0x30 2013-05-11T10:16:30.841+02:00 trinity kernel: 3fda7d60: [<080d43ac>] __alloc_pages_nodemask+0x13c/0x740 2013-05-11T10:16:30.841+02:00 trinity kernel: 3fda7df0: [<080d49d8>] __get_free_pages+0x28/0x50 2013-05-11T10:16:30.841+02:00 trinity kernel: 3fda7e08: [<080fc28d>] __kmalloc_track_caller+0x3d/0x170 2013-05-11T10:16:30.841+02:00 trinity kernel: 3fda7e30: [<080dfbe6>] memdup_user+0x26/0x70 2013-05-11T10:16:30.841+02:00 trinity kernel: 3fda7e4c: [<080dfdee>] strndup_user+0x3e/0x60 2013-05-11T10:16:30.856+02:00 trinity kernel: 3fda7e68: [<0811ae70>] copy_mount_string+0x30/0x50 2013-05-11T10:16:30.856+02:00 trinity kernel: 3fda7e7c: [<0811b6ba>] sys_mount+0x1a/0xe0 2013-05-11T10:16:30.856+02:00 trinity kernel: 3fda7eac: [<08062c32>] handle_syscall+0x82/0xb0 2013-05-11T10:16:30.856+02:00 trinity kernel: 3fda7ef4: [<0807503d>] userspace+0x46d/0x590 2013-05-11T10:16:30.856+02:00 trinity kernel: 3fda7fec: [<0805f80c>] fork_handler+0x6c/0x70 2013-05-11T10:16:30.856+02:00 trinity kernel: 3fda7ffc: [<00000000>] 0x0 2013-05-11T10:16:30.856+02:00 trinity kernel: 2013-05-11T10:16:30.856+02:00 trinity kernel: ---[ end trace db5193a4984ce93f ]--- -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: richard -r. w. <ric...@gm...> - 2013-05-11 08:20:13
|
On Fri, May 10, 2013 at 11:52 PM, Toralf Förster <tor...@gm...> wrote:
> The bisected commit introduced this WARNING: on a user mode linux guest
> if the UML guest is fuzz tested with trinity :
>
>
> 2013-05-10T22:38:42.191+02:00 trinity kernel: ------------[ cut here ]------------
> 2013-05-10T22:38:42.191+02:00 trinity kernel: WARNING: at mm/slab_common.c:376 kmalloc_slab+0x33/0x80()
> 2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fda8: [<08336928>] dump_stack+0x22/0x24
> 2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fdc0: [<0807c2da>] warn_slowpath_common+0x5a/0x80
> 2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fde8: [<0807c3a3>] warn_slowpath_null+0x23/0x30
> 2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fdf8: [<080dfc93>] kmalloc_slab+0x33/0x80
> 2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fe0c: [<080f8beb>] __kmalloc_track_caller+0x1b/0x110
> 2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fe30: [<080dc866>] memdup_user+0x26/0x70
> 2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fe4c: [<080dca6e>] strndup_user+0x3e/0x60
> 2013-05-10T22:38:42.191+02:00 trinity kernel: 40e2fe68: [<0811ba60>] copy_mount_string+0x30/0x50
> 2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2fe7c: [<0811c46a>] sys_mount+0x1a/0xe0
> 2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2feac: [<08062b32>] handle_syscall+0x82/0xb0
> 2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2fef4: [<0807520d>] userspace+0x46d/0x590
> 2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2ffec: [<0805f7fc>] fork_handler+0x6c/0x70
> 2013-05-10T22:38:42.195+02:00 trinity kernel: 40e2fffc: [<00000000>] 0x0
> 2013-05-10T22:38:42.195+02:00 trinity kernel:
> 2013-05-10T22:38:42.195+02:00 trinity kernel: ---[ end trace 17e5931469d0697d ]---
>
>
> Tested with host kernel 3.9.1, host and client were 32bit stable Gentoo Linux.
>
>
> 6286ae97d10ea2b5cd90532163797ab217bfdbdf is the first bad commit
> commit 6286ae97d10ea2b5cd90532163797ab217bfdbdf
> Author: Christoph Lameter <cl...@li...>
> Date: Fri May 3 15:43:18 2013 +0000
>
> slab: Return NULL for oversized allocations
>
> The inline path seems to have changed the SLAB behavior for very large
> kmalloc allocations with commit e3366016 ("slab: Use common
> kmalloc_index/kmalloc_size functions"). This patch restores the old
> behavior but also adds diagnostics so that we can figure where in the
> code these large allocations occur.
>
> Reported-and-tested-by: Tetsuo Handa <pen...@I-...>
> Signed-off-by: Christoph Lameter <cl...@li...>
> Link: http://lkml.kernel.org/r/201...@I-...
> [ pe...@ke...: use WARN_ON_ONCE ]
> Signed-off-by: Pekka Enberg <pe...@ke...>
>
So, we trigger "if (WARN_ON_ONCE(size > KMALLOC_MAX_SIZE))".
Now I'm wondering what kind of argument string trinity gave to mount().
How long is it?
BTW: Toralf, why are you sending this to user-mode-linux-*user*@lists...?
We also have a -devel list. Please at least CC me.
Otherwise it is most likely that I miss such reports...
--
Thanks,
//richard
|
Thanks for helping keep SourceForge clean.
X