Menu
▾
▴
user-mode-linux-user
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(6) |
Feb
(1) |
Mar
(39) |
Apr
(13) |
May
(24) |
Jun
(11) |
Jul
(23) |
Aug
(85) |
Sep
(12) |
Oct
(103) |
Nov
(79) |
Dec
(112) |
| 2001 |
Jan
(52) |
Feb
(82) |
Mar
(84) |
Apr
(65) |
May
(105) |
Jun
(188) |
Jul
(174) |
Aug
(182) |
Sep
(103) |
Oct
(137) |
Nov
(143) |
Dec
(98) |
| 2002 |
Jan
(258) |
Feb
(236) |
Mar
(386) |
Apr
(307) |
May
(238) |
Jun
(170) |
Jul
(252) |
Aug
(230) |
Sep
(278) |
Oct
(394) |
Nov
(336) |
Dec
(194) |
| 2003 |
Jan
(290) |
Feb
(182) |
Mar
(175) |
Apr
(220) |
May
(209) |
Jun
(286) |
Jul
(279) |
Aug
(164) |
Sep
(208) |
Oct
(324) |
Nov
(204) |
Dec
(380) |
| 2004 |
Jan
(344) |
Feb
(332) |
Mar
(395) |
Apr
(357) |
May
(349) |
Jun
(352) |
Jul
(279) |
Aug
(269) |
Sep
(374) |
Oct
(442) |
Nov
(428) |
Dec
(253) |
| 2005 |
Jan
(225) |
Feb
(219) |
Mar
(245) |
Apr
(249) |
May
(203) |
Jun
(157) |
Jul
(171) |
Aug
(194) |
Sep
(200) |
Oct
(232) |
Nov
(190) |
Dec
(195) |
| 2006 |
Jan
(158) |
Feb
(190) |
Mar
(235) |
Apr
(161) |
May
(134) |
Jun
(169) |
Jul
(117) |
Aug
(161) |
Sep
(170) |
Oct
(297) |
Nov
(230) |
Dec
(205) |
| 2007 |
Jan
(197) |
Feb
(132) |
Mar
(151) |
Apr
(97) |
May
(109) |
Jun
(99) |
Jul
(57) |
Aug
(110) |
Sep
(56) |
Oct
(119) |
Nov
(39) |
Dec
(45) |
| 2008 |
Jan
(101) |
Feb
(116) |
Mar
(141) |
Apr
(98) |
May
(133) |
Jun
(61) |
Jul
(43) |
Aug
(76) |
Sep
(20) |
Oct
(32) |
Nov
(22) |
Dec
(41) |
| 2009 |
Jan
(35) |
Feb
(15) |
Mar
(18) |
Apr
(13) |
May
(13) |
Jun
(26) |
Jul
(12) |
Aug
(32) |
Sep
(21) |
Oct
(41) |
Nov
(35) |
Dec
(12) |
| 2010 |
Jan
(3) |
Feb
(35) |
Mar
(28) |
Apr
(20) |
May
(5) |
Jun
(14) |
Jul
(6) |
Aug
(8) |
Sep
(20) |
Oct
(20) |
Nov
(10) |
Dec
(12) |
| 2011 |
Jan
(14) |
Feb
(10) |
Mar
(14) |
Apr
(14) |
May
(13) |
Jun
(43) |
Jul
(13) |
Aug
(50) |
Sep
(30) |
Oct
(23) |
Nov
(15) |
Dec
(49) |
| 2012 |
Jan
(15) |
Feb
(28) |
Mar
(7) |
Apr
|
May
(12) |
Jun
(13) |
Jul
(28) |
Aug
(11) |
Sep
(19) |
Oct
(27) |
Nov
(5) |
Dec
(25) |
| 2013 |
Jan
(18) |
Feb
(19) |
Mar
(56) |
Apr
(26) |
May
(38) |
Jun
(24) |
Jul
(42) |
Aug
(24) |
Sep
(4) |
Oct
(3) |
Nov
(18) |
Dec
(4) |
| 2014 |
Jan
(10) |
Feb
(9) |
Mar
(3) |
Apr
|
May
(12) |
Jun
(34) |
Jul
(8) |
Aug
(18) |
Sep
(3) |
Oct
(27) |
Nov
(2) |
Dec
(1) |
| 2015 |
Jan
|
Feb
(10) |
Mar
(49) |
Apr
(2) |
May
(4) |
Jun
(7) |
Jul
(1) |
Aug
(17) |
Sep
(7) |
Oct
(35) |
Nov
(40) |
Dec
(4) |
| 2016 |
Jan
(9) |
Feb
|
Mar
(6) |
Apr
|
May
(10) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
(4) |
May
(31) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Han <kee...@gm...> - 2013-03-15 16:38:12
|
On Fri, Mar 15, 2013 at 1:35 AM, richard -rw- weinberger <ric...@gm...> wrote: > On Fri, Mar 15, 2013 at 5:39 AM, Han <kee...@gm...> wrote: >> Hi, >> >> I am trying to build and to install a kernel module into UML. The UML >> kernel is built from linux 2.6.2, 32-bit i386. The rootfs is >> Debian-Squeeze-x86-root_fs. I was able to build the kernel module >> successful. But when I tried to insmod, I got the kernel panic. >> After some debugging, I found the kmalloc() during module init >> returns NULL, and it was dereferenced later, hence the panic. >> >> my question is: is kmalloc() supported in UML (during kernel module >> init)? Is there anything special I need to do? > > kmalloc() and modules work in UML. > But your kernel so damn bloody old that it might contain various bugs. > AFAIK 2.6.2 almost older than a decade... It's 2.6.27. I know it's old. But I am not at liberty to choose kernel version ... thanks Han > > -- > Thanks, > //richard |
|
From: richard -r. w. <ric...@gm...> - 2013-03-15 08:35:37
|
On Fri, Mar 15, 2013 at 5:39 AM, Han <kee...@gm...> wrote: > Hi, > > I am trying to build and to install a kernel module into UML. The UML > kernel is built from linux 2.6.2, 32-bit i386. The rootfs is > Debian-Squeeze-x86-root_fs. I was able to build the kernel module > successful. But when I tried to insmod, I got the kernel panic. > After some debugging, I found the kmalloc() during module init > returns NULL, and it was dereferenced later, hence the panic. > > my question is: is kmalloc() supported in UML (during kernel module > init)? Is there anything special I need to do? kmalloc() and modules work in UML. But your kernel so damn bloody old that it might contain various bugs. AFAIK 2.6.2 almost older than a decade... -- Thanks, //richard |
|
From: Han <kee...@gm...> - 2013-03-15 04:39:07
|
Hi, I am trying to build and to install a kernel module into UML. The UML kernel is built from linux 2.6.2, 32-bit i386. The rootfs is Debian-Squeeze-x86-root_fs. I was able to build the kernel module successful. But when I tried to insmod, I got the kernel panic. After some debugging, I found the kmalloc() during module init returns NULL, and it was dereferenced later, hence the panic. my question is: is kmalloc() supported in UML (during kernel module init)? Is there anything special I need to do? thanks Han |
|
From: richard -r. w. <ric...@gm...> - 2013-03-14 23:10:47
|
On Thu, Mar 14, 2013 at 10:24 PM, Toralf Förster <tor...@gm...> wrote: > On 03/14/2013 10:21 PM, Dave Jones wrote: >> hah, strndup_user taking a signed long instead of a size_t as it's length arg. >> >> either it needs to change, or it needs an explicit check for < 1 >> >> I wonder how many other paths make it possible to pass negative numbers here. > > just for the statistics - currently -14 rules : > > 2013-03-14T22:06:21.618+01:00 trinity kernel: memdup_user: -14 > 2013-03-14T22:06:25.664+01:00 trinity kernel: memdup_user: 28 > 2013-03-14T22:06:25.664+01:00 trinity kernel: memdup_user: -14 > 2013-03-14T22:06:37.533+01:00 trinity kernel: memdup_user: 3 > 2013-03-14T22:08:03.379+01:00 trinity kernel: memdup_user: -14 > 2013-03-14T22:09:34.668+01:00 trinity kernel: memdup_user: -14 > 2013-03-14T22:12:33.277+01:00 trinity kernel: memdup_user: -14 > 2013-03-14T22:13:15.214+01:00 trinity kernel: memdup_user: 2 > 2013-03-14T22:14:18.874+01:00 trinity kernel: trinity-watchdo[1169]: segfault at 244 ip 0804c956 sp bf836c9c error 4 in trinity[8048000+1d000] > 2013-03-14T22:15:10.287+01:00 trinity kernel: memdup_user: 2 > 2013-03-14T22:15:10.287+01:00 trinity kernel: memdup_user: 2 > 2013-03-14T22:17:50.351+01:00 trinity kernel: memdup_user: 2 > 2013-03-14T22:17:59.411+01:00 trinity kernel: memdup_user: -14 > -14 is -EFAULT. Time to look at UML's __get_user(). -- Thanks, //richard |
|
From: Toralf F. <tor...@gm...> - 2013-03-14 21:24:25
|
On 03/14/2013 10:21 PM, Dave Jones wrote: > hah, strndup_user taking a signed long instead of a size_t as it's length arg. > > either it needs to change, or it needs an explicit check for < 1 > > I wonder how many other paths make it possible to pass negative numbers here. just for the statistics - currently -14 rules : 2013-03-14T22:06:21.618+01:00 trinity kernel: memdup_user: -14 2013-03-14T22:06:25.664+01:00 trinity kernel: memdup_user: 28 2013-03-14T22:06:25.664+01:00 trinity kernel: memdup_user: -14 2013-03-14T22:06:37.533+01:00 trinity kernel: memdup_user: 3 2013-03-14T22:08:03.379+01:00 trinity kernel: memdup_user: -14 2013-03-14T22:09:34.668+01:00 trinity kernel: memdup_user: -14 2013-03-14T22:12:33.277+01:00 trinity kernel: memdup_user: -14 2013-03-14T22:13:15.214+01:00 trinity kernel: memdup_user: 2 2013-03-14T22:14:18.874+01:00 trinity kernel: trinity-watchdo[1169]: segfault at 244 ip 0804c956 sp bf836c9c error 4 in trinity[8048000+1d000] 2013-03-14T22:15:10.287+01:00 trinity kernel: memdup_user: 2 2013-03-14T22:15:10.287+01:00 trinity kernel: memdup_user: 2 2013-03-14T22:17:50.351+01:00 trinity kernel: memdup_user: 2 2013-03-14T22:17:59.411+01:00 trinity kernel: memdup_user: -14 :-D -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Dave J. <da...@re...> - 2013-03-14 21:21:26
|
On Thu, Mar 14, 2013 at 09:58:31PM +0100, Toralf Förster wrote: > On 03/14/2013 09:51 PM, richard -rw- weinberger wrote: > > Can you please re-run with the attached patch. > > I'm wondering how much memory is requested. > >>From reading the source I'd say it must be less than PAGE_SIZE. > > But such a small allocation would not trigger the WARN_ON()... > > > 2013-03-14T21:56:58.000+01:00 trinity sshd[1158]: pam_unix(sshd:session): session opened for user tfoerste by (uid=0) > 2013-03-14T21:56:59.852+01:00 trinity kernel: memdup_user: -14 > 2013-03-14T21:56:59.852+01:00 trinity kernel: ------------[ cut here ]------------ > 2013-03-14T21:56:59.852+01:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() > 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbd14: [<08342dd8>] dump_stack+0x22/0x24 > 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbd2c: [<0807d0da>] warn_slowpath_common+0x5a/0x80 > 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbd54: [<0807d1a3>] warn_slowpath_null+0x23/0x30 > 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbd64: [<080d3213>] __alloc_pages_nodemask+0x153/0x750 > 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbdf0: [<080d3838>] __get_free_pages+0x28/0x50 > 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbe08: [<080fc48f>] __kmalloc_track_caller+0x3f/0x180 > 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbe30: [<080dec82>] memdup_user+0x32/0x70 > 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbe4c: [<080dee7e>] strndup_user+0x3e/0x60 > 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbe68: [<0811b440>] copy_mount_string+0x30/0x50 > 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbe7c: [<0811be0a>] sys_mount+0x1a/0xe0 > 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbeac: [<08062a92>] handle_syscall+0x82/0xb0 > 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbef4: [<08074e7d>] userspace+0x46d/0x590 > 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbfec: [<0805f7cc>] fork_handler+0x6c/0x70 > 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbffc: [<5a5a5a5a>] 0x5a5a5a5a > 2013-03-14T21:56:59.853+01:00 trinity kernel: > 2013-03-14T21:56:59.853+01:00 trinity kernel: ---[ end trace 5bf182a223bd623c ]--- > 2013-03-14T21:56:59.853+01:00 trinity kernel: memdup_user: -14 hah, strndup_user taking a signed long instead of a size_t as it's length arg. either it needs to change, or it needs an explicit check for < 1 I wonder how many other paths make it possible to pass negative numbers here. Dave |
|
From: Toralf F. <tor...@gm...> - 2013-03-14 20:58:41
|
On 03/14/2013 09:51 PM, richard -rw- weinberger wrote: > Can you please re-run with the attached patch. > I'm wondering how much memory is requested. >>From reading the source I'd say it must be less than PAGE_SIZE. > But such a small allocation would not trigger the WARN_ON()... 2013-03-14T21:56:58.000+01:00 trinity sshd[1158]: pam_unix(sshd:session): session opened for user tfoerste by (uid=0) 2013-03-14T21:56:59.852+01:00 trinity kernel: memdup_user: -14 2013-03-14T21:56:59.852+01:00 trinity kernel: ------------[ cut here ]------------ 2013-03-14T21:56:59.852+01:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbd14: [<08342dd8>] dump_stack+0x22/0x24 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbd2c: [<0807d0da>] warn_slowpath_common+0x5a/0x80 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbd54: [<0807d1a3>] warn_slowpath_null+0x23/0x30 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbd64: [<080d3213>] __alloc_pages_nodemask+0x153/0x750 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbdf0: [<080d3838>] __get_free_pages+0x28/0x50 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbe08: [<080fc48f>] __kmalloc_track_caller+0x3f/0x180 2013-03-14T21:56:59.852+01:00 trinity kernel: 38bfbe30: [<080dec82>] memdup_user+0x32/0x70 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbe4c: [<080dee7e>] strndup_user+0x3e/0x60 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbe68: [<0811b440>] copy_mount_string+0x30/0x50 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbe7c: [<0811be0a>] sys_mount+0x1a/0xe0 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbeac: [<08062a92>] handle_syscall+0x82/0xb0 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbef4: [<08074e7d>] userspace+0x46d/0x590 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbfec: [<0805f7cc>] fork_handler+0x6c/0x70 2013-03-14T21:56:59.853+01:00 trinity kernel: 38bfbffc: [<5a5a5a5a>] 0x5a5a5a5a 2013-03-14T21:56:59.853+01:00 trinity kernel: 2013-03-14T21:56:59.853+01:00 trinity kernel: ---[ end trace 5bf182a223bd623c ]--- 2013-03-14T21:56:59.853+01:00 trinity kernel: memdup_user: -14 2013-03-14T21:56:59.942+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. 2013-03-14T21:56:59.942+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. 2013-03-14T21:56:59.942+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. 2013-03-14T21:57:01.000+01:00 trinity sshd[1160]: Received disconnect from 192.168.0.254: 11: disconnected by user 2013-03-14T21:57:01.000+01:00 trinity sshd[1158]: pam_unix(sshd:session): session closed for user tfoerste 2013-03-14T21:57:09.087+01:00 trinity kernel: memdup_user: -14 2013-03-14T21:57:18.191+01:00 trinity kernel: memdup_user: 4089 2013-03-14T21:57:26.236+01:00 trinity kernel: memdup_user: 28 -- 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-03-14 20:51:32
|
On Thu, Mar 14, 2013 at 8:07 PM, Toralf Förster <tor...@gm...> wrote: > The following WARNING: can be triggered sometimes with trinity [1] under a user mode linux image > using the SLUB allocator (and not with SLAB) > > > 2013-03-14T19:09:51.071+01:00 trinity kernel: ------------[ cut here ]------------ > 2013-03-14T19:09:51.071+01:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd14: [<08342dd8>] dump_stack+0x22/0x24 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd2c: [<0807d0da>] warn_slowpath_common+0x5a/0x80 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd54: [<0807d1a3>] warn_slowpath_null+0x23/0x30 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd64: [<080d3213>] __alloc_pages_nodemask+0x153/0x750 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fdf0: [<080d3838>] __get_free_pages+0x28/0x50 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe08: [<080fc48f>] __kmalloc_track_caller+0x3f/0x180 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe30: [<080dec76>] memdup_user+0x26/0x70 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe4c: [<080dee7e>] strndup_user+0x3e/0x60 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fe68: [<0811b440>] copy_mount_string+0x30/0x50 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fe7c: [<0811be0a>] sys_mount+0x1a/0xe0 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899feac: [<08062a92>] handle_syscall+0x82/0xb0 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fef4: [<08074e7d>] userspace+0x46d/0x590 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899ffec: [<0805f7cc>] fork_handler+0x6c/0x70 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fffc: [<5a5a5a5a>] 0x5a5a5a5a > 2013-03-14T19:09:51.076+01:00 trinity kernel: > 2013-03-14T19:09:51.076+01:00 trinity kernel: ---[ end trace fd6f346f805efdbe ]--- > > > for an UML guest (stable Gentoo x86) with kernel version 3.9-rc2-.... running at a host > which is a stable x86 Gentoo with kernel 3.7.10 > > The kernel config of the UML guest is attached. Can you please re-run with the attached patch. I'm wondering how much memory is requested. >From reading the source I'd say it must be less than PAGE_SIZE. But such a small allocation would not trigger the WARN_ON()... -- Thanks, //richard |
|
From: richard -r. w. <ric...@gm...> - 2013-03-14 19:53:16
|
On Thu, Mar 14, 2013 at 8:07 PM, Toralf Förster <tor...@gm...> wrote: > The following WARNING: can be triggered sometimes with trinity [1] under a user mode linux image > using the SLUB allocator (and not with SLAB) > > > 2013-03-14T19:09:51.071+01:00 trinity kernel: ------------[ cut here ]------------ > 2013-03-14T19:09:51.071+01:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd14: [<08342dd8>] dump_stack+0x22/0x24 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd2c: [<0807d0da>] warn_slowpath_common+0x5a/0x80 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd54: [<0807d1a3>] warn_slowpath_null+0x23/0x30 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd64: [<080d3213>] __alloc_pages_nodemask+0x153/0x750 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fdf0: [<080d3838>] __get_free_pages+0x28/0x50 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe08: [<080fc48f>] __kmalloc_track_caller+0x3f/0x180 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe30: [<080dec76>] memdup_user+0x26/0x70 > 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe4c: [<080dee7e>] strndup_user+0x3e/0x60 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fe68: [<0811b440>] copy_mount_string+0x30/0x50 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fe7c: [<0811be0a>] sys_mount+0x1a/0xe0 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899feac: [<08062a92>] handle_syscall+0x82/0xb0 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fef4: [<08074e7d>] userspace+0x46d/0x590 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899ffec: [<0805f7cc>] fork_handler+0x6c/0x70 > 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fffc: [<5a5a5a5a>] 0x5a5a5a5a > 2013-03-14T19:09:51.076+01:00 trinity kernel: > 2013-03-14T19:09:51.076+01:00 trinity kernel: ---[ end trace fd6f346f805efdbe ]--- Looks like strndup_user() triggers the issue. In another trace also strndup_user() appeared. -- Thanks, //richard |
|
From: Toralf F. <tor...@gm...> - 2013-03-14 19:08:04
|
The following WARNING: can be triggered sometimes with trinity [1] under a user mode linux image using the SLUB allocator (and not with SLAB) 2013-03-14T19:09:51.071+01:00 trinity kernel: ------------[ cut here ]------------ 2013-03-14T19:09:51.071+01:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd14: [<08342dd8>] dump_stack+0x22/0x24 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd2c: [<0807d0da>] warn_slowpath_common+0x5a/0x80 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd54: [<0807d1a3>] warn_slowpath_null+0x23/0x30 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fd64: [<080d3213>] __alloc_pages_nodemask+0x153/0x750 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fdf0: [<080d3838>] __get_free_pages+0x28/0x50 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe08: [<080fc48f>] __kmalloc_track_caller+0x3f/0x180 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe30: [<080dec76>] memdup_user+0x26/0x70 2013-03-14T19:09:51.071+01:00 trinity kernel: 3899fe4c: [<080dee7e>] strndup_user+0x3e/0x60 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fe68: [<0811b440>] copy_mount_string+0x30/0x50 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fe7c: [<0811be0a>] sys_mount+0x1a/0xe0 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899feac: [<08062a92>] handle_syscall+0x82/0xb0 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fef4: [<08074e7d>] userspace+0x46d/0x590 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899ffec: [<0805f7cc>] fork_handler+0x6c/0x70 2013-03-14T19:09:51.076+01:00 trinity kernel: 3899fffc: [<5a5a5a5a>] 0x5a5a5a5a 2013-03-14T19:09:51.076+01:00 trinity kernel: 2013-03-14T19:09:51.076+01:00 trinity kernel: ---[ end trace fd6f346f805efdbe ]--- for an UML guest (stable Gentoo x86) with kernel version 3.9-rc2-.... running at a host which is a stable x86 Gentoo with kernel 3.7.10 The kernel config of the UML guest is attached. [1] http://codemonkey.org.uk/ -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Toralf F. <tor...@gm...> - 2013-03-13 20:37:10
|
On 03/13/2013 11:15 AM, richard -rw- weinberger wrote: > Do you see this with both slub and slab? With SLAB however (UML kernel v3.9-rc2-188-g6c23cbb-slab) I see those things : 2013-03-13T21:30:01.000+01:00 trinity cron[1142]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons) 2013-03-13T21:32:34.763+01:00 trinity kernel: trinity-watchdo[1165]: segfault at 42c ip 0804c5b6 sp bf90d38c error 4 in trinity[8048000+16000] 2013-03-13T21:34:23.270+01:00 trinity kernel: BUG: Bad page map in process trinity-child0 pte:002fd045 pmd:2ec4c1e1 2013-03-13T21:34:23.270+01:00 trinity kernel: page:0a638fa0 count:1 mapcount:-1 mapping: (null) index:0x0 2013-03-13T21:34:23.270+01:00 trinity kernel: page flags: 0x400(reserved) 2013-03-13T21:34:23.270+01:00 trinity kernel: addr:00100000 vm_flags:00060055 anon_vma: (null) mapping: (null) index:100 2013-03-13T21:34:23.270+01:00 trinity kernel: vma->vm_ops->fault: special_mapping_fault+0x0/0x80 2013-03-13T21:34:23.270+01:00 trinity kernel: 36c9fd1c: [<0833fa68>] dump_stack+0x22/0x24 2013-03-13T21:34:23.270+01:00 trinity kernel: 36c9fd34: [<08340e21>] print_bad_pte+0x17b/0x197 2013-03-13T21:34:23.270+01:00 trinity kernel: 36c9fd78: [<080e5368>] unmap_single_vma+0x268/0x430 2013-03-13T21:34:23.270+01:00 trinity kernel: 36c9fdd8: [<080e5a67>] unmap_vmas+0x37/0x50 2013-03-13T21:34:23.270+01:00 trinity kernel: 36c9fdf4: [<080e8ba0>] unmap_region+0x80/0xe0 2013-03-13T21:34:23.271+01:00 trinity kernel: 36c9fe30: [<080ea8a1>] do_munmap+0x231/0x2a0 2013-03-13T21:34:23.271+01:00 trinity kernel: 36c9fe68: [<080ecd28>] sys_mremap+0x248/0x480 2013-03-13T21:34:23.271+01:00 trinity kernel: 36c9feac: [<08062a82>] handle_syscall+0x82/0xb0 2013-03-13T21:34:23.271+01:00 trinity kernel: 36c9fef4: [<08074d9d>] userspace+0x46d/0x590 2013-03-13T21:34:23.271+01:00 trinity kernel: 36c9ffec: [<0805f7bc>] fork_handler+0x6c/0x70 2013-03-13T21:34:23.271+01:00 trinity kernel: 36c9fffc: [<00000000>] 0x0 2013-03-13T21:34:23.271+01:00 trinity kernel: 2013-03-13T21:34:23.271+01:00 trinity kernel: Disabling lock debugging due to kernel taint 2013-03-13T21:34:23.271+01:00 trinity kernel: BUG: Bad page state in process trinity-child0 pfn:002fd 2013-03-13T21:34:23.271+01:00 trinity kernel: page:0a638fa0 count:0 mapcount:-1 mapping: (null) index:0x0 2013-03-13T21:34:23.272+01:00 trinity kernel: page flags: 0x400(reserved) 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fcd8: [<0833fa68>] dump_stack+0x22/0x24 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fcf0: [<080d1a05>] bad_page+0xb5/0xe0 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fd0c: [<080d1aa3>] free_pages_prepare+0x73/0xb0 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fd28: [<080d2ebd>] free_hot_cold_page+0x1d/0xf0 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fd4c: [<080d566e>] __put_single_page+0x1e/0x30 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fd60: [<080d5967>] put_page+0x27/0x30 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fd68: [<080f28dc>] free_page_and_swap_cache+0x3c/0x50 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fd78: [<080e5385>] unmap_single_vma+0x285/0x430 2013-03-13T21:34:23.272+01:00 trinity kernel: 36c9fdd8: [<080e5a67>] unmap_vmas+0x37/0x50 2013-03-13T21:34:23.273+01:00 trinity kernel: 36c9fdf4: [<080e8ba0>] unmap_region+0x80/0xe0 2013-03-13T21:34:23.273+01:00 trinity kernel: 36c9fe30: [<080ea8a1>] do_munmap+0x231/0x2a0 2013-03-13T21:34:23.273+01:00 trinity kernel: 36c9fe68: [<080ecd28>] sys_mremap+0x248/0x480 2013-03-13T21:34:23.273+01:00 trinity kernel: 36c9feac: [<08062a82>] handle_syscall+0x82/0xb0 2013-03-13T21:34:23.273+01:00 trinity kernel: 36c9fef4: [<08074d9d>] userspace+0x46d/0x590 2013-03-13T21:34:23.273+01:00 trinity kernel: 36c9ffec: [<0805f7bc>] fork_handler+0x6c/0x70 2013-03-13T21:34:23.273+01:00 trinity kernel: 36c9fffc: [<00000000>] 0x0 2013-03-13T21:34:23.273+01:00 trinity kernel: 2013-03-13T21:34:23.273+01:00 trinity kernel: BUG: Bad page map in process trinity-child0 pte:2ed45045 pmd:2ec4c1e1 2013-03-13T21:34:23.273+01:00 trinity kernel: page:0ac0d8a0 count:1 mapcount:-1 mapping: (null) index:0x0 2013-03-13T21:34:23.275+01:00 trinity kernel: page flags: 0x0() 2013-03-13T21:34:23.275+01:00 trinity kernel: addr:00101000 vm_flags:00060055 anon_vma: (null) mapping: (null) index:101 2013-03-13T21:34:23.275+01:00 trinity kernel: vma->vm_ops->fault: special_mapping_fault+0x0/0x80 2013-03-13T21:34:23.275+01:00 trinity kernel: 36c9fd1c: [<0833fa68>] dump_stack+0x22/0x24 2013-03-13T21:34:23.275+01:00 trinity kernel: 36c9fd34: [<08340e21>] print_bad_pte+0x17b/0x197 2013-03-13T21:34:23.275+01:00 trinity kernel: 36c9fd78: [<080e5368>] unmap_single_vma+0x268/0x430 2013-03-13T21:34:23.275+01:00 trinity kernel: 36c9fdd8: [<080e5a67>] unmap_vmas+0x37/0x50 2013-03-13T21:34:23.275+01:00 trinity kernel: 36c9fdf4: [<080e8ba0>] unmap_region+0x80/0xe0 2013-03-13T21:34:23.275+01:00 trinity kernel: 36c9fe30: [<080ea8a1>] do_munmap+0x231/0x2a0 2013-03-13T21:34:23.275+01:00 trinity kernel: 36c9fe68: [<080ecd28>] sys_mremap+0x248/0x480 2013-03-13T21:34:23.276+01:00 trinity kernel: 36c9feac: [<08062a82>] handle_syscall+0x82/0xb0 2013-03-13T21:34:23.276+01:00 trinity kernel: 36c9fef4: [<08074d9d>] userspace+0x46d/0x590 2013-03-13T21:34:23.276+01:00 trinity kernel: 36c9ffec: [<0805f7bc>] fork_handler+0x6c/0x70 2013-03-13T21:34:23.276+01:00 trinity kernel: 36c9fffc: [<00000000>] 0x0 2013-03-13T21:34:23.276+01:00 trinity kernel: 2013-03-13T21:34:23.276+01:00 trinity kernel: BUG: Bad page state in process trinity-child0 pfn:2ed45 2013-03-13T21:34:23.276+01:00 trinity kernel: page:0ac0d8a0 count:0 mapcount:-1 mapping: (null) index:0x0 2013-03-13T21:34:23.276+01:00 trinity kernel: page flags: 0x0() 2013-03-13T21:34:23.276+01:00 trinity kernel: 36c9fcd8: [<0833fa68>] dump_stack+0x22/0x24 2013-03-13T21:34:23.276+01:00 trinity kernel: 36c9fcf0: [<080d1a05>] bad_page+0xb5/0xe0 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fd0c: [<080d1aa3>] free_pages_prepare+0x73/0xb0 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fd28: [<080d2ebd>] free_hot_cold_page+0x1d/0xf0 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fd4c: [<080d566e>] __put_single_page+0x1e/0x30 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fd60: [<080d5967>] put_page+0x27/0x30 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fd68: [<080f28dc>] free_page_and_swap_cache+0x3c/0x50 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fd78: [<080e5385>] unmap_single_vma+0x285/0x430 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fdd8: [<080e5a67>] unmap_vmas+0x37/0x50 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fdf4: [<080e8ba0>] unmap_region+0x80/0xe0 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fe30: [<080ea8a1>] do_munmap+0x231/0x2a0 2013-03-13T21:34:23.277+01:00 trinity kernel: 36c9fe68: [<080ecd28>] sys_mremap+0x248/0x480 2013-03-13T21:34:23.279+01:00 trinity kernel: 36c9feac: [<08062a82>] handle_syscall+0x82/0xb0 2013-03-13T21:34:23.279+01:00 trinity kernel: 36c9fef4: [<08074d9d>] userspace+0x46d/0x590 2013-03-13T21:34:23.279+01:00 trinity kernel: 36c9ffec: [<0805f7bc>] fork_handler+0x6c/0x70 2013-03-13T21:34:23.279+01:00 trinity kernel: 36c9fffc: [<00000000>] 0x0 2013-03-13T21:34:23.279+01:00 trinity kernel: 2013-03-13T21:34:23.279+01:00 trinity kernel: Stub registers - 2013-03-13T21:34:23.279+01:00 trinity kernel: 0 - 100000 2013-03-13T21:34:23.279+01:00 trinity kernel: 1 - 2000 2013-03-13T21:34:23.279+01:00 trinity kernel: 2 - 0 2013-03-13T21:34:23.279+01:00 trinity kernel: 3 - 0 2013-03-13T21:34:23.280+01:00 trinity kernel: 4 - 0 2013-03-13T21:34:23.280+01:00 trinity kernel: 5 - 0 2013-03-13T21:34:23.280+01:00 trinity kernel: 6 - 0 2013-03-13T21:34:23.280+01:00 trinity kernel: 7 - 7b 2013-03-13T21:34:23.280+01:00 trinity kernel: 8 - 7b 2013-03-13T21:34:23.280+01:00 trinity kernel: 9 - 0 2013-03-13T21:34:23.280+01:00 trinity kernel: 10 - 33 2013-03-13T21:34:23.280+01:00 trinity kernel: 11 - ffffffff 2013-03-13T21:34:23.280+01:00 trinity kernel: 12 - 1000c3 2013-03-13T21:34:23.280+01:00 trinity kernel: 13 - 73 2013-03-13T21:34:23.282+01:00 trinity kernel: 14 - 10206 2013-03-13T21:34:23.282+01:00 trinity kernel: 15 - 101028 2013-03-13T21:34:23.282+01:00 trinity kernel: 16 - 7b 2013-03-13T21:34:23.282+01:00 trinity kernel: wait_stub_done : failed to wait for SIGTRAP, pid = 731, n = 731, errno = 0, status = 0xb7f -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Toralf F. <tor...@gm...> - 2013-03-13 19:12:45
|
On 03/13/2013 11:15 AM, richard -rw- weinberger wrote: > On Tue, Mar 12, 2013 at 9:59 PM, Toralf Förster <tor...@gm...> wrote: >> While trying trinity under a UML I often run into this situation : >> >> >> 2013-03-12T21:54:41.934+01:00 trinity kernel: ------------[ cut here ]------------ >> 2013-03-12T21:54:41.934+01:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() >> 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fcfc: [<083426b8>] dump_stack+0x22/0x24 >> 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd14: [<0807d11a>] warn_slowpath_common+0x5a/0x80 >> 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd3c: [<0807d1e3>] warn_slowpath_null+0x23/0x30 >> 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd4c: [<080d2bb3>] __alloc_pages_nodemask+0x153/0x750 >> 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fdd8: [<080d31d8>] __get_free_pages+0x28/0x50 >> 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fdf0: [<080fbe1f>] __kmalloc_track_caller+0x3f/0x180 >> 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fe18: [<080de616>] memdup_user+0x26/0x70 >> 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fe34: [<080de81e>] strndup_user+0x3e/0x60 >> 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fe50: [<0823c493>] sys_request_key+0x53/0x170 >> 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837feac: [<08062a92>] handle_syscall+0x82/0xb0 >> 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fef4: [<08074e7d>] userspace+0x46d/0x590 >> 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837ffec: [<0805f7cc>] fork_handler+0x6c/0x70 >> 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fffc: [<00000000>] 0x0 >> 2013-03-12T21:54:41.935+01:00 trinity kernel: >> 2013-03-12T21:54:41.935+01:00 trinity kernel: ---[ end trace 2e631e8b4588be93 ]--- >> 2013-03-12T21:54:41.935+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. >> 2013-03-12T21:54:41.935+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. > > Do you see this with both slub and slab? > With SLUB (linux-v3.9-rc2-178-g4febd95) I see that behaviour. A recent UML kernel with SLAB (linux-v3.9-rc2-188-g6c23cbb) holds just here in trinity output : [1050] [2174] getrlimit(resource=3, rlim=1) = -1 (Bad address) [1050] [2175] ustat(dev=4096, ubuf=4) = -1 (Invalid argument) [1050] [2176] mremap(addr=0, old_len=0x80000001, new_len=0xffa2, flags=1, new_addr=0) [watchdog] 2177 iterations. [F:1790 S:386] [watchdog] kernel became tainted! Last seed was 2735014321 after that the system hangs. I can still ssh into it from other console and run "ps -ef" , but even a "ps -ef | grep <bla bla>" then hangs too and can't be stopped via Ctrl.C. Furthermore "gdb -p <pid>" could not be run, b/c in the meanwhile the pids are vanished too (at least from /proc). And the syslog and anything else is empty. Host kernel is always 3.7.10. -- 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-03-13 10:16:04
|
On Tue, Mar 12, 2013 at 9:59 PM, Toralf Förster <tor...@gm...> wrote: > While trying trinity under a UML I often run into this situation : > > > 2013-03-12T21:54:41.934+01:00 trinity kernel: ------------[ cut here ]------------ > 2013-03-12T21:54:41.934+01:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() > 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fcfc: [<083426b8>] dump_stack+0x22/0x24 > 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd14: [<0807d11a>] warn_slowpath_common+0x5a/0x80 > 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd3c: [<0807d1e3>] warn_slowpath_null+0x23/0x30 > 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd4c: [<080d2bb3>] __alloc_pages_nodemask+0x153/0x750 > 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fdd8: [<080d31d8>] __get_free_pages+0x28/0x50 > 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fdf0: [<080fbe1f>] __kmalloc_track_caller+0x3f/0x180 > 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fe18: [<080de616>] memdup_user+0x26/0x70 > 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fe34: [<080de81e>] strndup_user+0x3e/0x60 > 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fe50: [<0823c493>] sys_request_key+0x53/0x170 > 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837feac: [<08062a92>] handle_syscall+0x82/0xb0 > 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fef4: [<08074e7d>] userspace+0x46d/0x590 > 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837ffec: [<0805f7cc>] fork_handler+0x6c/0x70 > 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fffc: [<00000000>] 0x0 > 2013-03-12T21:54:41.935+01:00 trinity kernel: > 2013-03-12T21:54:41.935+01:00 trinity kernel: ---[ end trace 2e631e8b4588be93 ]--- > 2013-03-12T21:54:41.935+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. > 2013-03-12T21:54:41.935+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. Do you see this with both slub and slab? -- Thanks, //richard |
|
From: Toralf F. <tor...@gm...> - 2013-03-12 21:00:06
|
While trying trinity under a UML I often run into this situation : 2013-03-12T21:54:41.934+01:00 trinity kernel: ------------[ cut here ]------------ 2013-03-12T21:54:41.934+01:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fcfc: [<083426b8>] dump_stack+0x22/0x24 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd14: [<0807d11a>] warn_slowpath_common+0x5a/0x80 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd3c: [<0807d1e3>] warn_slowpath_null+0x23/0x30 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fd4c: [<080d2bb3>] __alloc_pages_nodemask+0x153/0x750 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fdd8: [<080d31d8>] __get_free_pages+0x28/0x50 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fdf0: [<080fbe1f>] __kmalloc_track_caller+0x3f/0x180 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fe18: [<080de616>] memdup_user+0x26/0x70 2013-03-12T21:54:41.934+01:00 trinity kernel: 3837fe34: [<080de81e>] strndup_user+0x3e/0x60 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fe50: [<0823c493>] sys_request_key+0x53/0x170 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837feac: [<08062a92>] handle_syscall+0x82/0xb0 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fef4: [<08074e7d>] userspace+0x46d/0x590 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837ffec: [<0805f7cc>] fork_handler+0x6c/0x70 2013-03-12T21:54:41.935+01:00 trinity kernel: 3837fffc: [<00000000>] 0x0 2013-03-12T21:54:41.935+01:00 trinity kernel: 2013-03-12T21:54:41.935+01:00 trinity kernel: ---[ end trace 2e631e8b4588be93 ]--- 2013-03-12T21:54:41.935+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. 2013-03-12T21:54:41.935+01:00 trinity kernel: VFS: Warning: trinity-child0 using old stat() call. Recompile your binary. >From the author of trinity I was told: Looks like the "tried to kmalloc more than what kmalloc can do" bug. That shows up from time to time in various places. Not sure how this can happen from this trace, because it looks like we clamp everywhere with PAGE_SIZE. Possibly a UML bug, dunno. The host kernel is 3.7.10 at a 32bit stable Gentoo, the UML guest kernels are 3.8.2 and 3.9-rc2--112-g7c6baa3 from the later the config is attached. -- 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-03-11 22:23:02
|
On Mon, Mar 11, 2013 at 11:17 PM, Dave Jones <da...@re...> wrote: > ah, cool. For some reason I thought there were some uml specific extensions. In UML you run your regular x86 binary. UML uses ptraces() to trap all systemcalls and instead of entering kernel mode you enter the UML kernel... -- Thanks, //richard |
|
From: Dave J. <da...@re...> - 2013-03-11 22:18:00
|
On Mon, Mar 11, 2013 at 10:47:57PM +0100, richard -rw- weinberger wrote: > On Mon, Mar 11, 2013 at 7:01 PM, Toralf Förster <tor...@gm...> wrote: > > On 03/10/2013 10:41 PM, Dave Jones wrote: > >> On Sun, Mar 10, 2013 at 10:25:01PM +0100, Toralf Förster wrote: > >> > ? > >> > >> It would need to be ported due to the different syscall table. > >> I wrote aobut this being fairly easy recently: > >> http://codemonkey.org.uk/2013/03/04/architecture-support-trinity/ > >> > >> There's also a porting doc in Documentation/ > > > > Understood. > > > > I'm rather a I-bother-devs-with-bug-reports-user than a developer, but > > I'm Cc:ing the UML user list - maybe there's a volunteer ? > > Erm, the UML syscall table is identical to x86(_x64). > That's why you can run any x86 program within UML... ah, cool. For some reason I thought there were some uml specific extensions. I stand corrected. In which case, it should be good to go. Dave |
|
From: richard -r. w. <ric...@gm...> - 2013-03-11 21:48:08
|
On Mon, Mar 11, 2013 at 7:01 PM, Toralf Förster <tor...@gm...> wrote: > On 03/10/2013 10:41 PM, Dave Jones wrote: >> On Sun, Mar 10, 2013 at 10:25:01PM +0100, Toralf Förster wrote: >> > ? >> >> It would need to be ported due to the different syscall table. >> I wrote aobut this being fairly easy recently: >> http://codemonkey.org.uk/2013/03/04/architecture-support-trinity/ >> >> There's also a porting doc in Documentation/ > > Understood. > > I'm rather a I-bother-devs-with-bug-reports-user than a developer, but > I'm Cc:ing the UML user list - maybe there's a volunteer ? Erm, the UML syscall table is identical to x86(_x64). That's why you can run any x86 program within UML... -- Thanks, //richard |
|
From: Toralf F. <tor...@gm...> - 2013-03-11 18:01:46
|
On 03/10/2013 10:41 PM, Dave Jones wrote: > On Sun, Mar 10, 2013 at 10:25:01PM +0100, Toralf Förster wrote: > > ? > > It would need to be ported due to the different syscall table. > I wrote aobut this being fairly easy recently: > http://codemonkey.org.uk/2013/03/04/architecture-support-trinity/ > > There's also a porting doc in Documentation/ Understood. I'm rather a I-bother-devs-with-bug-reports-user than a developer, but I'm Cc:ing the UML user list - maybe there's a volunteer ? -- 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-03-11 09:51:02
|
On Thu, Mar 7, 2013 at 6:28 PM, Toralf Förster <tor...@gm...> wrote: > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: WARNING: at drivers/tty/tty_buffer.c:428 flush_to_ldisc+0x51/0x190() > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: tty is NULL > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979fea0: [<08342748>] dump_stack+0x22/0x24 > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979feb8: [<0807d0ea>] warn_slowpath_common+0x5a/0x80 > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979fee0: [<0807d15e>] warn_slowpath_fmt+0x2e/0x30 > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979fef8: [<0827d6a1>] flush_to_ldisc+0x51/0x190 > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979ff2c: [<0809254a>] process_one_work+0x1ba/0x2f0 > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979ff70: [<0809355c>] worker_thread+0x25c/0x360 > 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979ffa4: [<08097fe2>] kthread+0xc2/0xd0 > 2013-03-07T18:23:59.187+01:00 n22stab4 kernel: 3979ffec: [<0805f84a>] new_thread_handler+0x7a/0xa0 > 2013-03-07T18:23:59.187+01:00 n22stab4 kernel: 3979fffc: [<00000000>] 0x0 > 2013-03-07T18:23:59.187+01:00 n22stab4 kernel: > 2013-03-07T18:23:59.187+01:00 n22stab4 kernel: ---[ end trace fe7100411e1ca835 ]--- BTW: This is not UML specific. The WARN_ON() in tty_buffer.c will be removed, it is harmless. -- Thanks, //richard |
|
From: Toralf F. <tor...@gm...> - 2013-03-10 21:42:55
|
Looking at the sizes : tfoerste@n22 ~/tmp $ ls -l /usr/local/bin/* -rwxr-xr-x 1 root root 19470883 Mar 1 20:44 /usr/local/bin/linux-v3.7.10 -rwxr-xr-x 1 root root 19904366 Mar 4 23:00 /usr/local/bin/linux-v3.8.2 -rwxr-xr-x 1 root root 15870361 Mar 9 17:45 /usr/local/bin/linux-v3.9-rc1-277-g0aefda3 -rwxr-xr-x 1 root root 15870377 Mar 10 22:32 /usr/local/bin/linux-v3.9-rc1-283-g7293261 I'm just curious why 3.9 has 20% less (or better why are the older so fat) ? I used the same compiler (4.6.3) and nearly the same .config, the diff stat between 3.8.2 and 3.9-rc1 is : $ diff 382 391 3c3 < # User Mode Linux/i386 3.8.0-rc1 Kernel Configuration --- > # User Mode Linux/x86 3.9.0-rc1 Kernel Configuration 71,72d70 < CONFIG_SELECT_MEMORY_MODEL=y < CONFIG_FLATMEM_MANUAL=y 74a73 > # CONFIG_HAVE_BOOTMEM_INFO_NODE is not set 81d79 < CONFIG_VIRT_TO_BUS=y 101a100 > CONFIG_IRQ_WORK=y 129a129 > # CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set 151a152 > # CONFIG_RCU_STALL_COMMON is not set 171a173 > # CONFIG_USER_NS is not set 173a176,177 > CONFIG_UIDGID_CONVERTED=y > # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set 209a214 > # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set 212d216 < CONFIG_GENERIC_SIGALTSTACK=y 213a218,219 > CONFIG_OLD_SIGSUSPEND3=y > CONFIG_OLD_SIGACTION=y 285a292 > CONFIG_FW_LOADER_USER_HELPER=y 341a349 > # CONFIG_DM_CACHE is not set 390a399 > CONFIG_TTY=y 449a459 > # CONFIG_MAILBOX is not set 453c463 < # Remoteproc drivers (EXPERIMENTAL) --- > # Remoteproc drivers 457c467 < # Rpmsg drivers (EXPERIMENTAL) --- > # Rpmsg drivers 524d533 < # CONFIG_WAN_ROUTER is not set 531a541 > # CONFIG_VSOCKETS is not set 783a794 > # CONFIG_CRYPTO_CRC32 is not set 843d853 < CONFIG_PERCPU_RWSEM=y 900d909 < # CONFIG_SPARSE_RCU_POINTER is not set 917a927,931 > > # > # RCU Debugging > # > # CONFIG_SPARSE_RCU_POINTER is not set t -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Toralf F. <tor...@gm...> - 2013-03-08 22:17:28
|
On 03/07/2013 12:00 AM, richard -rw- weinberger wrote: > Found the issue. A very nasty use-after-free tty issue which happened > only sometimes. > Please test the attached patch. > /me tested x86_64 and x86 successfully. > Today I tested a patched 3.9 kernel for the UML guest several times, host kernel was 3.8.2. Later I realized a core file in my HOME directory. I'm not sure whether this back trace helps : ... warning: Could not load shared library symbols for linux-gate.so.1. Do you need "set solib-search-path" or "set sysroot"? Core was generated by `/usr/local/bin/linux-v3.9-rc1-211-g47b3bc9 earlyprintk ubda=/home/tfoerste/virt'. Program terminated with signal 11, Segmentation fault. #0 constant_test_bit (nr=<optimized out>, addr=<optimized out>) at /home/tfoerste/devel/linux/arch/x86/include/asm/bitops.h:321 321 (addr[nr / BITS_PER_LONG])) != 0; (gdb) bt #0 constant_test_bit (nr=<optimized out>, addr=<optimized out>) at /home/tfoerste/devel/linux/arch/x86/include/asm/bitops.h:321 #1 test_ti_thread_flag (ti=<optimized out>, flag=<optimized out>) at include/linux/thread_info.h:93 #2 test_tsk_thread_flag (flag=<optimized out>, tsk=<optimized out>) at include/linux/sched.h:2522 #3 signal_pending (p=<optimized out>) at include/linux/sched.h:2548 #4 __set_task_blocked (tsk=0x37ec0000, newset=0x37ec2f48) at kernel/signal.c:2524 #5 0x0808d003 in __set_current_blocked (newset=0x37ec2f48) at kernel/signal.c:2552 #6 0x0808d027 in set_current_blocked (newset=0x0) at kernel/signal.c:2544 #7 0x0808e584 in sigsuspend (set=0x0) at kernel/signal.c:3550 #8 0x08064668 in winch_thread (arg=0x0) at arch/um/drivers/chan_user.c:210 #9 0x46a6b41e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 (gdb) quit -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Toralf F. <tor...@gm...> - 2013-03-08 16:13:34
|
On 03/08/2013 11:14 AM, richard -rw- weinberger wrote: > On Thu, Mar 7, 2013 at 6:28 PM, Toralf Förster <tor...@gm...> wrote: >> On 03/07/2013 05:34 PM, richard -rw- weinberger wrote: >>> So, xterm is broken in 3.9-rc1? >>> Please bisect it. >>> >> Cannot be reproduced under host kernel 3.7.10, and host kernel 3.8.2 suffers >> from a complete hang if an (unprivileged) user starts UML and just wait for >> a while (already reported to this list). > > Wait. The _host_ version of Linux plays a role? > Please more details. > Which pairs of UML/Host show this problem? > host kernel 3.8.x shows that problem, reproducible here with uml guests 3.7.10, 3.8.2 and 3.9-rc1+ host kernel 3.7.10 does not suffer from this problem. I reported that to this list already because IMHO it is local exploitable security flaw (if it can be reproduced at others systems too), and neither sudo nor any privileges are necessary to halt a system. FWIW neither sys-rq nor any other key works, nothing in the syslog, at the console or anything seen on the screen. -- 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-03-08 10:14:51
|
On Thu, Mar 7, 2013 at 6:28 PM, Toralf Förster <tor...@gm...> wrote: > On 03/07/2013 05:34 PM, richard -rw- weinberger wrote: >> So, xterm is broken in 3.9-rc1? >> Please bisect it. >> > Cannot be reproduced under host kernel 3.7.10, and host kernel 3.8.2 suffers > from a complete hang if an (unprivileged) user starts UML and just wait for > a while (already reported to this list). Wait. The _host_ version of Linux plays a role? Please more details. Which pairs of UML/Host show this problem? -- Thanks, //richard |
|
From: Toralf F. <tor...@gm...> - 2013-03-07 17:28:49
|
On 03/07/2013 05:34 PM, richard -rw- weinberger wrote: > So, xterm is broken in 3.9-rc1? > Please bisect it. > Cannot be reproduced under host kernel 3.7.10, and host kernel 3.8.2 suffers from a complete hang if an (unprivileged) user starts UML and just wait for a while (already reported to this list). But what I do see under host 3.7.10 and UML 3.9.0-rc1-00108-g9f22578-dirty (dirty == your patch) is that this section is repeated many times in the UML syslog : 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: WARNING: at drivers/tty/tty_buffer.c:428 flush_to_ldisc+0x51/0x190() 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: tty is NULL 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979fea0: [<08342748>] dump_stack+0x22/0x24 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979feb8: [<0807d0ea>] warn_slowpath_common+0x5a/0x80 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979fee0: [<0807d15e>] warn_slowpath_fmt+0x2e/0x30 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979fef8: [<0827d6a1>] flush_to_ldisc+0x51/0x190 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979ff2c: [<0809254a>] process_one_work+0x1ba/0x2f0 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979ff70: [<0809355c>] worker_thread+0x25c/0x360 2013-03-07T18:23:59.185+01:00 n22stab4 kernel: 3979ffa4: [<08097fe2>] kthread+0xc2/0xd0 2013-03-07T18:23:59.187+01:00 n22stab4 kernel: 3979ffec: [<0805f84a>] new_thread_handler+0x7a/0xa0 2013-03-07T18:23:59.187+01:00 n22stab4 kernel: 3979fffc: [<00000000>] 0x0 2013-03-07T18:23:59.187+01:00 n22stab4 kernel: 2013-03-07T18:23:59.187+01:00 n22stab4 kernel: ---[ end trace fe7100411e1ca835 ]--- The command line to start the UML was : /home/tfoerste/workspace/bin/start_uml.sh -r /home/tfoerste/virtual/uml/n22stab4 -l /usr/local/bin/linux-v3.9-rc1-108-g9f22578 Cannot get wake-on-lan settings: Operation not permitted + /usr/local/bin/linux-v3.9-rc1-108-g9f22578 earlyprintk ubda=/home/tfoerste/virtual/uml/n22stab4 ubdb=/mnt/ramdisk/swap_n22stab4 eth0=tuntap,tap0,72:ef:3d:fd:4a:0b mem=768M con=pts con0=fd:0,fd:1 con1=xterm con12=xterm umid=uml -- 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-03-07 16:42:36
|
On Thu, Mar 7, 2013 at 5:11 PM, Toralf Förster <tor...@gm...> wrote: >> issue is fixed here too - thx. > > FWIW something like "con=pts con0=fd:0,fd:1" is now mandatory, > otherwise an xterm is open and user root can login, but I experienced > strange things with my Gentoo : So, xterm is broken in 3.9-rc1? Please bisect it. -- Thanks, //richard |
525 messages has been excluded from this view by a project administrator.
