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: Toralf F. <tor...@gm...> - 2013-04-06 12:55:12
|
On 04/06/2013 02:47 PM, Toralf Förster wrote: > On 04/06/2013 01:43 PM, richard -rw- weinberger wrote: >>> What I get with the this trinity command line >>> >>> gt; trinity --children 2 -c madvise >> >> Does the attached patch fix the problem? > > yes, the issue for this syscall is fixed now. > But now I get - after running this command for a longer time : 2013-04-06T14:49:55.755+02:00 trinity kernel: do_syscall_stub : ret = -12, offset = 1052680, data = 3f2ff008 2013-04-06T14:49:55.755+02:00 trinity kernel: do_syscall_stub: syscall 192 failed, return value = 0xfffffff4, expected return value = 0x280e5000 2013-04-06T14:49:55.755+02:00 trinity kernel: syscall parameters: 0x280e5000 0x1000 0x7 0x11 0x3 0x11cba 2013-04-06T14:49:55.755+02:00 trinity kernel: Failed to flush page for address 0x280e5000 2013-04-06T14:49:57.600+02:00 trinity kernel: do_syscall_stub : ret = -12, offset = 1052680, data = 3f397008 2013-04-06T14:49:57.600+02:00 trinity kernel: do_syscall_stub: syscall 192 failed, return value = 0xfffffff4, expected return value = 0x280e5000 2013-04-06T14:49:57.600+02:00 trinity kernel: syscall parameters: 0x280e5000 0x1000 0x7 0x11 0x3 0x1ad80 2013-04-06T14:49:57.600+02:00 trinity kernel: Failed to flush page for address 0x280e5000 2013-04-06T14:50:01.000+02:00 trinity cron[1071]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons) 2013-04-06T14:51:15.336+02:00 trinity kernel: do_syscall_stub : ret = -12, offset = 1052680, data = 3f2fe008 2013-04-06T14:51:15.336+02:00 trinity kernel: do_syscall_stub: syscall 192 failed, return value = 0xfffffff4, expected return value = 0x280e3000 2013-04-06T14:51:15.336+02:00 trinity kernel: syscall parameters: 0x280e3000 0x1000 0x7 0x11 0x3 0xd561 2013-04-06T14:51:15.336+02:00 trinity kernel: Failed to flush page for address 0x280e3000 2013-04-06T14:51:20.224+02:00 trinity kernel: do_syscall_stub : ret = -12, offset = 1052680, data = 3f394008 2013-04-06T14:51:20.224+02:00 trinity kernel: do_syscall_stub: syscall 192 failed, return value = 0xfffffff4, expected return value = 0x280e5000 2013-04-06T14:51:20.224+02:00 trinity kernel: syscall parameters: 0x280e5000 0x1000 0x7 0x11 0x3 0x29571 2013-04-06T14:51:20.224+02:00 trinity kernel: Failed to flush page for address 0x280e5000 2013-04-06T14:52:34.379+02:00 trinity kernel: do_syscall_stub : ret = -12, offset = 1052680, data = 3f22a008 2013-04-06T14:52:34.379+02:00 trinity kernel: do_syscall_stub: syscall 192 failed, return value = 0xfffffff4, expected return value = 0x280e3000 2013-04-06T14:52:34.379+02:00 trinity kernel: syscall parameters: 0x280e3000 0x1000 0x7 0x11 0x3 0x9b50 2013-04-06T14:52:34.379+02:00 trinity kernel: Failed to flush page for address 0x280e3000 2013-04-06T14:52:40.422+02:00 trinity kernel: do_syscall_stub : ret = -12, offset = 1052680, data = 3f397008 2013-04-06T14:52:40.422+02:00 trinity kernel: do_syscall_stub: syscall 192 failed, return value = 0xfffffff4, expected return value = 0x280e3000 2013-04-06T14:52:40.422+02:00 trinity kernel: syscall parameters: 0x280e3000 0x1000 0x7 0x11 0x3 0xde37 2013-04-06T14:52:40.422+02:00 trinity kernel: Failed to flush page for address 0x280e3000 and the appropriate linux - process at the host process runs at 100% -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Toralf F. <tor...@gm...> - 2013-04-06 12:47:28
|
On 04/06/2013 01:43 PM, richard -rw- weinberger wrote: >> What I get with the this trinity command line >> >> gt; trinity --children 2 -c madvise > > Does the attached patch fix the problem? yes, the issue for this syscall is fixed now. -- 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-04-04 17:23:18
|
>> 2013-04-04T19:00:29.220+02:00 trinity kernel: BUG: Bad page map in process trinity-child1 pte:0032d045 pmd:3932e1e1 >> 2013-04-04T19:00:29.220+02:00 trinity kernel: page:0a73f5a0 count:1 mapcount:-1 mapping: (null) index:0x0 >> 2013-04-04T19:00:29.220+02:00 trinity kernel: page flags: 0x404(referenced|reserved) >> 2013-04-04T19:00:29.220+02:00 trinity kernel: addr:00100000 vm_flags:00040055 anon_vma: (null) mapping: (null) index:100 > > > Okay, there is definitely something wrong with mapping 0x100000 in UML. > We have seen something else with mmap() already... Sending again, stupid gmail is unusable from now on. Anyways, 0x100000 is the start address of the skas stub. /me digs into that maze :-\ -- Thanks, //richard |
|
From: richard -r. w. <ric...@gm...> - 2013-04-04 17:13:18
|
On Thu, Apr 4, 2013 at 7:04 PM, Toralf Förster <tor...@gm...>wrote: > if SLUB is used (SLAB works fine till now with this syscall). > > What I get with the this trinity command line > > $> trinity --children 2 -c madvise > > 2013-04-04T19:00:29.220+02:00 trinity kernel: BUG: Bad page map in process > trinity-child1 pte:0032d045 pmd:3932e1e1 > 2013-04-04T19:00:29.220+02:00 trinity kernel: page:0a73f5a0 count:1 > mapcount:-1 mapping: (null) index:0x0 > 2013-04-04T19:00:29.220+02:00 trinity kernel: page flags: > 0x404(referenced|reserved) > 2013-04-04T19:00:29.220+02:00 trinity kernel: addr:00100000 > vm_flags:00040055 anon_vma: (null) mapping: (null) index:100 > Okay, there is definitely something wrong with mapping 0x100000 in UML. We have seen something else with mmap() already... Thanks, //richard |
|
From: Toralf F. <tor...@gm...> - 2013-04-04 17:04:49
|
if SLUB is used (SLAB works fine till now with this syscall). What I get with the this trinity command line $> trinity --children 2 -c madvise for a 32 bit Gentoo Linux (both as host and as guest) and host kernel 3.8.5 and guest kernel 3.9-rc5 is the following : 2013-04-04T19:00:29.220+02:00 trinity kernel: BUG: Bad page map in process trinity-child1 pte:0032d045 pmd:3932e1e1 2013-04-04T19:00:29.220+02:00 trinity kernel: page:0a73f5a0 count:1 mapcount:-1 mapping: (null) index:0x0 2013-04-04T19:00:29.220+02:00 trinity kernel: page flags: 0x404(referenced|reserved) 2013-04-04T19:00:29.220+02:00 trinity kernel: addr:00100000 vm_flags:00040055 anon_vma: (null) mapping: (null) index:100 2013-04-04T19:00:29.220+02:00 trinity kernel: vma->vm_ops->fault: special_mapping_fault+0x0/0x80 2013-04-04T19:00:29.220+02:00 trinity kernel: 413c7d20: [<0836efd8>] dump_stack+0x22/0x24 2013-04-04T19:00:29.220+02:00 trinity kernel: 413c7d38: [<0837039b>] print_bad_pte+0x17b/0x197 2013-04-04T19:00:29.220+02:00 trinity kernel: 413c7d7c: [<080e2c68>] unmap_single_vma+0x268/0x430 2013-04-04T19:00:29.220+02:00 trinity kernel: 413c7ddc: [<080e33f4>] zap_page_range+0x74/0xb0 2013-04-04T19:00:29.220+02:00 trinity kernel: 413c7e10: [<080e172d>] sys_madvise+0x3bd/0x720 2013-04-04T19:00:29.225+02:00 trinity kernel: 413c7eac: [<08064a92>] handle_syscall+0x82/0xb0 2013-04-04T19:00:29.225+02:00 trinity kernel: 413c7ef4: [<08076f0d>] userspace+0x46d/0x590 2013-04-04T19:00:29.225+02:00 trinity kernel: 413c7fec: [<080617cc>] fork_handler+0x6c/0x70 2013-04-04T19:00:29.225+02:00 trinity kernel: 413c7ffc: [<00000002>] 0x2 2013-04-04T19:00:29.225+02:00 trinity kernel: 2013-04-04T19:00:29.225+02:00 trinity kernel: Disabling lock debugging due to kernel taint 2013-04-04T19:00:29.225+02:00 trinity kernel: BUG: Bad page state in process trinity-child1 pfn:0032d 2013-04-04T19:00:29.225+02:00 trinity kernel: page:0a73f5a0 count:0 mapcount:-1 mapping: (null) index:0x0 2013-04-04T19:00:29.225+02:00 trinity kernel: page flags: 0x404(referenced|reserved) 2013-04-04T19:00:29.225+02:00 trinity kernel: 413c7cd8: [<0836efd8>] dump_stack+0x22/0x24 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7cf0: [<080cf185>] bad_page+0xb5/0xe0 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7d0c: [<080cf223>] free_pages_prepare+0x73/0xb0 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7d28: [<080d064d>] free_hot_cold_page+0x1d/0x100 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7d50: [<080d2fde>] __put_single_page+0x1e/0x30 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7d64: [<080d3107>] put_page+0x27/0x30 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7d6c: [<080f026c>] free_page_and_swap_cache+0x3c/0x50 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7d7c: [<080e2c85>] unmap_single_vma+0x285/0x430 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7ddc: [<080e33f4>] zap_page_range+0x74/0xb0 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7e10: [<080e172d>] sys_madvise+0x3bd/0x720 2013-04-04T19:00:29.230+02:00 trinity kernel: 413c7eac: [<08064a92>] handle_syscall+0x82/0xb0 2013-04-04T19:00:29.234+02:00 trinity kernel: 413c7ef4: [<08076f0d>] userspace+0x46d/0x590 2013-04-04T19:00:29.234+02:00 trinity kernel: 413c7fec: [<080617cc>] fork_handler+0x6c/0x70 2013-04-04T19:00:29.234+02:00 trinity kernel: 413c7ffc: [<00000002>] 0x2 2013-04-04T19:00:29.234+02:00 trinity kernel: 2013-04-04T19:00:30.174+02:00 trinity kernel: BUG: Bad rss-counter state mm:40623600 idx:0 val:-1 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Toralf F. <tor...@gm...> - 2013-04-02 19:51:11
|
Well, fuzzying an UML (32 bit Gentoo Linux) system with SLUB for current git kernel 3.9-rc5-x gives for the mentioned 4 syscalls very quickly a warning like the seen below. What I (as usual) do not know, is, if these warnings are UML architecture specific or if I should Cc: the LKML ? 2013-04-02T21:44:05.800+02:00 trinity kernel: ------------[ cut here ]------------ 2013-04-02T21:44:05.800+02:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() 2013-04-02T21:44:05.800+02:00 trinity kernel: 405dfd14: [<0836f888>] dump_stack+0x22/0x24 2013-04-02T21:44:05.800+02:00 trinity kernel: 405dfd2c: [<0807f14a>] warn_slowpath_common+0x5a/0x80 2013-04-02T21:44:05.800+02:00 trinity kernel: 405dfd54: [<0807f213>] warn_slowpath_null+0x23/0x30 2013-04-02T21:44:05.800+02:00 trinity kernel: 405dfd64: [<080d03a3>] __alloc_pages_nodemask+0x153/0x750 2013-04-02T21:44:05.800+02:00 trinity kernel: 405dfdf0: [<080d09c8>] __get_free_pages+0x28/0x50 2013-04-02T21:44:05.800+02:00 trinity kernel: 405dfe08: [<080f9e0f>] __kmalloc_track_caller+0x3f/0x180 2013-04-02T21:44:05.800+02:00 trinity kernel: 405dfe30: [<080dbee6>] memdup_user+0x26/0x70 2013-04-02T21:44:05.800+02:00 trinity kernel: 405dfe4c: [<080dc0ee>] strndup_user+0x3e/0x60 2013-04-02T21:44:05.801+02:00 trinity kernel: 405dfe68: [<081190f0>] copy_mount_string+0x30/0x50 2013-04-02T21:44:05.801+02:00 trinity kernel: 405dfe7c: [<08119af2>] sys_mount+0x52/0xe0 2013-04-02T21:44:05.801+02:00 trinity kernel: 405dfeac: [<08064a92>] handle_syscall+0x82/0xb0 2013-04-02T21:44:05.801+02:00 trinity kernel: 405dfef4: [<08076edd>] userspace+0x46d/0x590 2013-04-02T21:44:05.801+02:00 trinity kernel: 405dffec: [<080617cc>] fork_handler+0x6c/0x70 2013-04-02T21:44:05.801+02:00 trinity kernel: 405dfffc: [<5a5a5a5a>] 0x5a5a5a5a 2013-04-02T21:44:05.801+02:00 trinity kernel: 2013-04-02T21:44:05.801+02:00 trinity kernel: ---[ end trace c1c5349b53f54f0a ]--- or 2013-04-02T21:47:23.646+02:00 trinity kernel: ------------[ cut here ]------------ 2013-04-02T21:47:23.646+02:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() 2013-04-02T21:47:23.646+02:00 trinity kernel: 40167d1c: [<0836f888>] dump_stack+0x22/0x24 2013-04-02T21:47:23.646+02:00 trinity kernel: 40167d34: [<0807f14a>] warn_slowpath_common+0x5a/0x80 2013-04-02T21:47:23.646+02:00 trinity kernel: 40167d5c: [<0807f213>] warn_slowpath_null+0x23/0x30 2013-04-02T21:47:23.646+02:00 trinity kernel: 40167d6c: [<080d03a3>] __alloc_pages_nodemask+0x153/0x750 2013-04-02T21:47:23.646+02:00 trinity kernel: 40167df8: [<080d09c8>] __get_free_pages+0x28/0x50 2013-04-02T21:47:23.646+02:00 trinity kernel: 40167e10: [<080f9e0f>] __kmalloc_track_caller+0x3f/0x180 2013-04-02T21:47:23.646+02:00 trinity kernel: 40167e38: [<080dbee6>] memdup_user+0x26/0x70 2013-04-02T21:47:23.646+02:00 trinity kernel: 40167e54: [<080dc0ee>] strndup_user+0x3e/0x60 2013-04-02T21:47:23.655+02:00 trinity kernel: 40167e70: [<0823ba63>] keyctl_join_session_keyring+0x23/0x60 2013-04-02T21:47:23.655+02:00 trinity kernel: 40167e88: [<0823ce48>] sys_keyctl+0x58/0x240 2013-04-02T21:47:23.655+02:00 trinity kernel: 40167eac: [<08064a92>] handle_syscall+0x82/0xb0 2013-04-02T21:47:23.655+02:00 trinity kernel: 40167ef4: [<08076edd>] userspace+0x46d/0x590 2013-04-02T21:47:23.655+02:00 trinity kernel: 40167fec: [<080617cc>] fork_handler+0x6c/0x70 2013-04-02T21:47:23.655+02:00 trinity kernel: 40167ffc: [<00000000>] 0x0 2013-04-02T21:47:23.655+02:00 trinity kernel: 2013-04-02T21:47:23.655+02:00 trinity kernel: ---[ end trace e5cc052314f8b4fd ]--- 2013-04-02T21:49:34.162+02:00 trinity kernel: ------------[ cut here ]------------ 2013-04-02T21:49:34.162+02:00 trinity kernel: WARNING: at mm/page_alloc.c:2386 __alloc_pages_nodemask+0x153/0x750() 2013-04-02T21:49:34.162+02:00 trinity kernel: 40197cfc: [<0836f888>] dump_stack+0x22/0x24 2013-04-02T21:49:34.162+02:00 trinity kernel: 40197d14: [<0807f14a>] warn_slowpath_common+0x5a/0x80 2013-04-02T21:49:34.162+02:00 trinity kernel: 40197d3c: [<0807f213>] warn_slowpath_null+0x23/0x30 2013-04-02T21:49:34.162+02:00 trinity kernel: 40197d4c: [<080d03a3>] __alloc_pages_nodemask+0x153/0x750 2013-04-02T21:49:34.162+02:00 trinity kernel: 40197dd8: [<080d09c8>] __get_free_pages+0x28/0x50 2013-04-02T21:49:34.162+02:00 trinity kernel: 40197df0: [<080f9e0f>] __kmalloc_track_caller+0x3f/0x180 2013-04-02T21:49:34.162+02:00 trinity kernel: 40197e18: [<080dbee6>] memdup_user+0x26/0x70 2013-04-02T21:49:34.162+02:00 trinity kernel: 40197e34: [<080dc0ee>] strndup_user+0x3e/0x60 2013-04-02T21:49:34.163+02:00 trinity kernel: 40197e50: [<0823b709>] sys_add_key+0x49/0x1c0 2013-04-02T21:49:34.163+02:00 trinity kernel: 40197eac: [<08064a92>] handle_syscall+0x82/0xb0 2013-04-02T21:49:34.163+02:00 trinity kernel: 40197ef4: [<08076edd>] userspace+0x46d/0x590 2013-04-02T21:49:34.163+02:00 trinity kernel: 40197fec: [<080617cc>] fork_handler+0x6c/0x70 2013-04-02T21:49:34.163+02:00 trinity kernel: 40197ffc: [<00000000>] 0x0 2013-04-02T21:49:34.163+02:00 trinity kernel: 2013-04-02T21:49:34.163+02:00 trinity kernel: ---[ end trace 04c0afacb31314cf ]--- respectively. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Toralf F. <tor...@gm...> - 2013-04-01 17:13:42
|
Is the following back trace another example of signal issue of UML : (gdb) bt #0 0x469fc920 in ?? () #1 0x08071656 in hard_handler (sig=138428456, si=0x840404c <cpu0_irqstack+76>, p=0x84040e0 <cpu0_irqstack+224>) at arch/um/os-Linux/signal.c:162 #2 <signal handler called> #3 0x469fc920 in ?? () #4 0x08071656 in hard_handler (sig=138429736, si=0x840454c <cpu0_irqstack+1356>, p=0x84045e0 <cpu0_irqstack+1504>) at arch/um/os-Linux/signal.c:162 #5 <signal handler called> #6 0x469fc920 in ?? () #7 0x08071656 in hard_handler (sig=138431016, si=0x8404a4c <cpu0_irqstack+2636>, p=0x8404ae0 <cpu0_irqstack+2784>) at arch/um/os-Linux/signal.c:162 #8 <signal handler called> #9 0x469fc920 in ?? () #10 0x08071656 in hard_handler (sig=138432296, si=0x8404f4c <cpu0_irqstack+3916>, p=0x8404fe0 <cpu0_irqstack+4064>) at arch/um/os-Linux/signal.c:162 #11 <signal handler called> #12 0x469fc920 in ?? () #13 0x08071656 in hard_handler (sig=138433576, si=0x840544c <cpu0_irqstack+5196>, p=0x84054e0 <cpu0_irqstack+5344>) at arch/um/os-Linux/signal.c:162 #14 <signal handler called> #15 0x469fc920 in ?? () #16 0x08071656 in hard_handler (sig=138434856, si=0x840594c <cpu0_irqstack+6476>, p=0x84059e0 <cpu0_irqstack+6624>) at arch/um/os-Linux/signal.c:162 #17 <signal handler called> #18 0x469fc920 in ?? () #19 0x08071656 in hard_handler (sig=138436136, si=0x8405e4c <cpu0_irqstack+7756>, p=0x8405ee0 <cpu0_irqstack+7904>) at arch/um/os-Linux/signal.c:162 #20 <signal handler called> #21 0x469fc920 in ?? () #22 0x08071656 in hard_handler (sig=138437416, si=0x840634c <cpu0_irqstack+9036>, p=0x84063e0 <cpu0_irqstack+9184>) at arch/um/os-Linux/signal.c:162 #23 <signal handler called> #24 0x469fc920 in ?? () #25 0x08071656 in hard_handler (sig=138438696, si=0x840684c <cpu0_irqstack+10316>, p=0x84068e0 <cpu0_irqstack+10464>) at arch/um/os-Linux/signal.c:162 #26 <signal handler called> #27 0x469fc920 in ?? () #28 0x08071656 in hard_handler (sig=138439976, si=0x8406d4c <cpu0_irqstack+11596>, p=0x8406de0 <cpu0_irqstack+11744>) at arch/um/os-Linux/signal.c:162 #29 <signal handler called> #30 0x469fc920 in ?? () #31 0x08071656 in hard_handler (sig=138441256, si=0x840724c <cpu0_irqstack+12876>, p=0x84072e0 <cpu0_irqstack+13024>) at arch/um/os-Linux/signal.c:162 #32 <signal handler called> #33 0x46a67d56 in ?? () #34 0x08070888 in os_unmap_memory (addr=0x0, len=0) at arch/um/os-Linux/process.c:178 #35 0x08060f07 in flush_tlb_kernel_range_common (start=0, end=2229522432) at arch/um/kernel/tlb.c:357 #36 0x08061913 in flush_tlb_kernel_vm () at arch/um/kernel/tlb.c:482 #37 0x08061ed1 in segv (fi=<incomplete type>, ip=1185614429, is_user=0, regs=0x840785c <cpu0_irqstack+14428>) at arch/um/kernel/trap.c:204 #38 0x080621c3 in segv_handler (sig=11, unused_si=0x8407b0c <cpu0_irqstack+15116>, regs=0x840785c <cpu0_irqstack+14428>) at arch/um/kernel/trap.c:185 #39 0x080719b8 in sig_handler_common (sig=11, si=0x8407b0c <cpu0_irqstack+15116>, mc=0x8407ba0 <cpu0_irqstack+15264>) at arch/um/os-Linux/signal.c:44 ---Type <return> to continue, or q <return> to quit--- #40 0x08071afd in sig_handler (sig=0, si=0x8407b0c <cpu0_irqstack+15116>, mc=0x8407ba0 <cpu0_irqstack+15264>) at arch/um/os-Linux/signal.c:231 #41 0x0807164b in hard_handler (sig=4096, si=0x8407b0c <cpu0_irqstack+15116>, p=0x8407ba0 <cpu0_irqstack+15264>) at arch/um/os-Linux/signal.c:165 #42 <signal handler called> #43 0x46ab0a5d in ?? () #44 0x0825d130 in is_gpt_valid (state=0x7800, lba=5050309811229425664, gpt=0x4611f400, ptes=0x45c4ac80) at block/partitions/efi.c:388 #45 0x0825bc66 in rescan_partitions (disk=0x4611f400, bdev=0x45c4ac80) at block/partition-generic.c:434 #46 0x08128d2c in __blkdev_get (bdev=0x45c4ac80, mode=1, for_part=0) at fs/block_dev.c:1139 #47 0x081292fc in blkdev_get (bdev=0x45c4ac80, mode=1, holder=0x0) at fs/block_dev.c:1246 #48 0x08259680 in register_disk (disk=<optimized out>) at block/genhd.c:554 #49 add_disk (disk=0x4611f400) at block/genhd.c:616 #50 0x0806a30d in ubd_disk_register (major=138451500, size=7422886281216, unit=0, disk_out=0x0) at arch/um/drivers/ubd_kern.c:835 #51 0x0806aeb2 in ubd_add (n=0, error_out=0x4607ff5c) at arch/um/drivers/ubd_kern.c:871 #52 0x0804b147 in ubd_init () at arch/um/drivers/ubd_kern.c:1072 #53 0x0804977a in do_one_initcall (fn=0x804b0bb <ubd_init>) at init/main.c:690 #54 0x0804993a in do_initcall_level (level=<optimized out>) at init/main.c:761 #55 do_initcalls () at init/main.c:769 #56 do_basic_setup () at init/main.c:788 #57 kernel_init_freeable () at init/main.c:890 #58 0x0833b8cb in kernel_init (unused=0x0) at init/main.c:822 #59 0x0805f83a in new_thread_handler () at arch/um/kernel/process.c:140 #60 0x00000000 in ?? () The command line is : /usr/local/bin/linux-v3.9-rc5 earlyprintk ubda=/home/tfoerste/virtual/uml/trinity ubdb=/mnt/ramdisk/swap_trinity eth0=tuntap,tap0,72:ef:3d:9f:c3:5a mem=970M con=pts con0=fd:0,fd:1 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-27 19:56:01
|
On Wed, Mar 27, 2013 at 12:03 AM, Hugh Dickins <hu...@go...> wrote: > On Tue, 26 Mar 2013, Toralf Foerster wrote: >> On 03/25/2013 11:53 PM, Andrew Morton wrote: >> > On Fri, 22 Mar 2013 18:28:36 +0100 Toralf Foerster <tor...@gm...> wrote: >> > >> >> > Using trinity I often trigger under a user mode linux image with host kernel 3.8.4 >> >> > and guest kernel linux-v3.9-rc3-244-g9217cbb the following : >> >> > (The UML guest is a 32bit stable Gentoo Linux) >> > I assume 3.8 is OK? >> > >> With UML kernel 3.7.10 (host kernel still 3.8.4) I can trigger this >> issue too. >> Just to clarify it - here the bug appears in the UML kernel - the host >> kernel is ok (I can of course crash a host kernel too by trinity'ing an >> UML guest, but that's another thread - see [1]) >> >> >> FWIW he trinity command is just a test of 1 syscall: >> >> $> trinity --children 1 --victims /mnt/nfs/n22/victims -c mremap >> >> >> >> [1] https://lkml.org/lkml/2013/3/24/174 > > I should think it's been like this for five years, or even more: maybe > you are the first person to try unmapping user address 0x100000 on UML; > though it's odd that you find it using mremap than the more common munmap. Sounds sane. I fear trinity will find more "you are the first person to try"-bugs in UML. I'll look at it. > uml_setup_stubs() sets up the special vma with install_special_mapping(), > but instead of then faulting in the two pages concerned, it has preset > the ptes with init_stub_pte(), which did not increment page mapcount. > > munmap() that area (or set up another mapping in that place), and > zap_pte_range() will decrement page mapcount negative, hence the > "Bad page" errors. Whereas UML uses an arch_exit_mmap() hook to > clear the ptes at exit time, to avoid encountering such errors. > > I think that adding VM_PFNMAP to those install_special_mapping() flags > would be enough to fix it (and avoid the need for the arch_exit_mmap(), > and let vm_insert_pfn() do the work of init_stub_pte()); but I'm not > certain that would be the approved way, and I may have missed problems > doing it like this (which would disallow get_user_pages(), e.g. ptrace, > on that area: which might or might not be a good thing, I don't know). > > I'm saying this just by examination, I've not tried any of it at all. > Over to Richard. :-) -- Thanks, //richard |
|
From: Hugh D. <hu...@go...> - 2013-03-26 23:04:20
|
On Tue, 26 Mar 2013, Toralf Foerster wrote: > On 03/25/2013 11:53 PM, Andrew Morton wrote: > > On Fri, 22 Mar 2013 18:28:36 +0100 Toralf Foerster <tor...@gm...> wrote: > > > >> > Using trinity I often trigger under a user mode linux image with host kernel 3.8.4 > >> > and guest kernel linux-v3.9-rc3-244-g9217cbb the following : > >> > (The UML guest is a 32bit stable Gentoo Linux) > > I assume 3.8 is OK? > > > With UML kernel 3.7.10 (host kernel still 3.8.4) I can trigger this > issue too. > Just to clarify it - here the bug appears in the UML kernel - the host > kernel is ok (I can of course crash a host kernel too by trinity'ing an > UML guest, but that's another thread - see [1]) > > > FWIW he trinity command is just a test of 1 syscall: > > $> trinity --children 1 --victims /mnt/nfs/n22/victims -c mremap > > > > [1] https://lkml.org/lkml/2013/3/24/174 I should think it's been like this for five years, or even more: maybe you are the first person to try unmapping user address 0x100000 on UML; though it's odd that you find it using mremap than the more common munmap. uml_setup_stubs() sets up the special vma with install_special_mapping(), but instead of then faulting in the two pages concerned, it has preset the ptes with init_stub_pte(), which did not increment page mapcount. munmap() that area (or set up another mapping in that place), and zap_pte_range() will decrement page mapcount negative, hence the "Bad page" errors. Whereas UML uses an arch_exit_mmap() hook to clear the ptes at exit time, to avoid encountering such errors. I think that adding VM_PFNMAP to those install_special_mapping() flags would be enough to fix it (and avoid the need for the arch_exit_mmap(), and let vm_insert_pfn() do the work of init_stub_pte()); but I'm not certain that would be the approved way, and I may have missed problems doing it like this (which would disallow get_user_pages(), e.g. ptrace, on that area: which might or might not be a good thing, I don't know). I'm saying this just by examination, I've not tried any of it at all. Over to Richard. Hugh |
|
From: Toralf F. <tor...@gm...> - 2013-03-26 16:45:07
|
On 03/25/2013 11:53 PM, Andrew Morton wrote: > On Fri, 22 Mar 2013 18:28:36 +0100 Toralf F__rster <tor...@gm...> wrote: > >> > Using trinity I often trigger under a user mode linux image with host kernel 3.8.4 >> > and guest kernel linux-v3.9-rc3-244-g9217cbb the following : >> > (The UML guest is a 32bit stable Gentoo Linux) > I assume 3.8 is OK? > With UML kernel 3.7.10 (host kernel still 3.8.4) I can trigger this issue too. Just to clarify it - here the bug appears in the UML kernel - the host kernel is ok (I can of course crash a host kernel too by trinity'ing an UML guest, but that's another thread - see [1]) FWIW he trinity command is just a test of 1 syscall: $> trinity --children 1 --victims /mnt/nfs/n22/victims -c mremap [1] https://lkml.org/lkml/2013/3/24/174 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Andrew M. <ak...@li...> - 2013-03-25 22:53:55
|
On Fri, 22 Mar 2013 18:28:36 +0100 Toralf F__rster <tor...@gm...> wrote: > Using trinity I often trigger under a user mode linux image with host kernel 3.8.4 > and guest kernel linux-v3.9-rc3-244-g9217cbb the following : > (The UML guest is a 32bit stable Gentoo Linux) I assume 3.8 is OK? > > 2013-03-22T18:03:01.232+01:00 trinity kernel: BUG: Bad page map in process trinity-child6 pte:002f9045 pmd:29e421e1 > 2013-03-22T18:03:01.232+01:00 trinity kernel: page:0920df20 count:1 mapcount:-1 mapping: (null) index:0x0 mapcount=-1. > 2013-03-22T18:03:01.232+01:00 trinity kernel: page flags: 0x400(reserved) > 2013-03-22T18:03:01.232+01:00 trinity kernel: addr:00100000 vm_flags:00060055 anon_vma: (null) mapping: (null) index:100 > 2013-03-22T18:03:01.232+01:00 trinity kernel: vma->vm_ops->fault: special_mapping_fault+0x0/0x80 > 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87d1c: [<0833b8b8>] dump_stack+0x22/0x24 > 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87d34: [<0833cc71>] print_bad_pte+0x17b/0x197 > 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87d78: [<080e1138>] unmap_single_vma+0x268/0x430 > 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87dd8: [<080e1837>] unmap_vmas+0x37/0x50 > 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87df4: [<080e4970>] unmap_region+0x80/0xe0 > 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87e30: [<080e6661>] do_munmap+0x231/0x2a0 > 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87e68: [<080e8ae8>] sys_mremap+0x248/0x480 > 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87eac: [<08062a82>] handle_syscall+0x82/0xb0 > 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87ef4: [<08074dfd>] userspace+0x46d/0x590 > 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87fec: [<0805f7bc>] fork_handler+0x6c/0x70 > 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87ffc: [<00000000>] 0x0 > 2013-03-22T18:03:01.233+01:00 trinity kernel: 2013-03-22T18:03:01.233+01:00 trinity kernel: Disabling lock debugging due to kernel taint > 2013-03-22T18:03:01.233+01:00 trinity kernel: BUG: Bad page state in process trinity-child6 pfn:002f9 > 2013-03-22T18:03:01.233+01:00 trinity kernel: page:0920df20 count:0 mapcount:-1 mapping: (null) index:0x0 > 2013-03-22T18:03:01.235+01:00 trinity kernel: page flags: 0x400(reserved) > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87cd4: [<0833b8b8>] dump_stack+0x22/0x24 > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87cec: [<080cd755>] bad_page+0xb5/0xe0 > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d08: [<080cd7f3>] free_pages_prepare+0x73/0xb0 > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d24: [<080cec1d>] free_hot_cold_page+0x1d/0x100 > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d4c: [<080d15ae>] __put_single_page+0x1e/0x30 > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d60: [<080d16d7>] put_page+0x27/0x30 > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d68: [<080ee6ec>] free_page_and_swap_cache+0x3c/0x50 > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d78: [<080e1155>] unmap_single_vma+0x285/0x430 > 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87dd8: [<080e1837>] unmap_vmas+0x37/0x50 > 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87df4: [<080e4970>] unmap_region+0x80/0xe0 > 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87e30: [<080e6661>] do_munmap+0x231/0x2a0 > 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87e68: [<080e8ae8>] sys_mremap+0x248/0x480 > 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87eac: [<08062a82>] handle_syscall+0x82/0xb0 > 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87ef4: [<08074dfd>] userspace+0x46d/0x590 > 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87fec: [<0805f7bc>] fork_handler+0x6c/0x70 > 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87ffc: [<00000000>] 0x0 > 2013-03-22T18:03:01.236+01:00 trinity kernel: 2013-03-22T18:03:01.236+01:00 trinity kernel: BUG: Bad page map in process trinity-child6 pte:29e38045 pmd:29e421e1 > 2013-03-22T18:03:01.236+01:00 trinity kernel: page:09744700 count:1 mapcount:-1 mapping: (null) index:0x0 > 2013-03-22T18:03:01.237+01:00 trinity kernel: page flags: 0x0() > 2013-03-22T18:03:01.237+01:00 trinity kernel: addr:00101000 vm_flags:00060055 anon_vma: (null) mapping: (null) index:101 > 2013-03-22T18:03:01.237+01:00 trinity kernel: vma->vm_ops->fault: special_mapping_fault+0x0/0x80 > 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87d1c: [<0833b8b8>] dump_stack+0x22/0x24 > 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87d34: [<0833cc71>] print_bad_pte+0x17b/0x197 > 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87d78: [<080e1138>] unmap_single_vma+0x268/0x430 > 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87dd8: [<080e1837>] unmap_vmas+0x37/0x50 > 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87df4: [<080e4970>] unmap_region+0x80/0xe0 > 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87e30: [<080e6661>] do_munmap+0x231/0x2a0 > 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87e68: [<080e8ae8>] sys_mremap+0x248/0x480 > 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87eac: [<08062a82>] handle_syscall+0x82/0xb0 > 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87ef4: [<08074dfd>] userspace+0x46d/0x590 > 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87fec: [<0805f7bc>] fork_handler+0x6c/0x70 > 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87ffc: [<00000000>] 0x0 > 2013-03-22T18:03:01.238+01:00 trinity kernel: 2013-03-22T18:03:01.238+01:00 trinity kernel: BUG: Bad page state in process trinity-child6 pfn:29e38 > 2013-03-22T18:03:01.238+01:00 trinity kernel: page:09744700 count:0 mapcount:-1 mapping: (null) index:0x0 > 2013-03-22T18:03:01.238+01:00 trinity kernel: page flags: 0x0() > 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87cd4: [<0833b8b8>] dump_stack+0x22/0x24 > 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87cec: [<080cd755>] bad_page+0xb5/0xe0 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d08: [<080cd7f3>] free_pages_prepare+0x73/0xb0 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d24: [<080cec1d>] free_hot_cold_page+0x1d/0x100 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d4c: [<080d15ae>] __put_single_page+0x1e/0x30 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d60: [<080d16d7>] put_page+0x27/0x30 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d68: [<080ee6ec>] free_page_and_swap_cache+0x3c/0x50 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d78: [<080e1155>] unmap_single_vma+0x285/0x430 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87dd8: [<080e1837>] unmap_vmas+0x37/0x50 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87df4: [<080e4970>] unmap_region+0x80/0xe0 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87e30: [<080e6661>] do_munmap+0x231/0x2a0 > 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87e68: [<080e8ae8>] sys_mremap+0x248/0x480 > 2013-03-22T18:03:01.240+01:00 trinity kernel: 31e87eac: [<08062a82>] handle_syscall+0x82/0xb0 > 2013-03-22T18:03:01.240+01:00 trinity kernel: 31e87ef4: [<08074dfd>] userspace+0x46d/0x590 > 2013-03-22T18:03:01.240+01:00 trinity kernel: 31e87fec: [<0805f7bc>] fork_handler+0x6c/0x70 > 2013-03-22T18:03:01.240+01:00 trinity kernel: 31e87ffc: [<00000000>] 0x0 > 2013-03-22T18:03:01.240+01:00 trinity kernel: 2013-03-22T18:03:01.240+01:00 trinity kernel: Stub registers - > 2013-03-22T18:03:01.240+01:00 trinity kernel: 0 - 100000 > 2013-03-22T18:03:01.240+01:00 trinity kernel: 1 - 300000 > 2013-03-22T18:03:01.240+01:00 trinity kernel: 2 - 0 > 2013-03-22T18:03:01.240+01:00 trinity kernel: 3 - 0 > 2013-03-22T18:03:01.243+01:00 trinity kernel: 4 - 0 > 2013-03-22T18:03:01.243+01:00 trinity kernel: 5 - 0 > 2013-03-22T18:03:01.243+01:00 trinity kernel: 6 - 0 > 2013-03-22T18:03:01.243+01:00 trinity kernel: 7 - 7b > 2013-03-22T18:03:01.243+01:00 trinity kernel: 8 - 7b > 2013-03-22T18:03:01.243+01:00 trinity kernel: 9 - 0 > 2013-03-22T18:03:01.243+01:00 trinity kernel: 10 - 33 > 2013-03-22T18:03:01.243+01:00 trinity kernel: 11 - ffffffff > 2013-03-22T18:03:01.243+01:00 trinity kernel: 12 - 1000c3 > 2013-03-22T18:03:01.243+01:00 trinity kernel: 13 - 73 > 2013-03-22T18:03:01.244+01:00 trinity kernel: 14 - 10206 > 2013-03-22T18:03:01.244+01:00 trinity kernel: 15 - 101028 > 2013-03-22T18:03:01.244+01:00 trinity kernel: 16 - 7b > 2013-03-22T18:03:01.244+01:00 trinity kernel: wait_stub_done : failed to wait for SIGTRAP, pid = 3143, n = 3143, 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-23 18:44:02
|
That kernel crashed today at a stable 32 bit Gentoo Linux. The screen shot (just a photo, b/c nothing was in the syslog) can be downloaded here [1]. The last action before I left the machine for a while was to start a user mode linux (stale 32 bit Gentoo, kernel v3.9-rc3-324-g5da273) and run trinity within that system. Please note that the host kernel crashed (UML probably too). To feed trinity with victim files I NFSv4 mounted a directory located at the host system under /tmp onto a mount point of the UML system (all file systems are EXT4). That directory contained 100 files and 100 directory. The trinity command line I used in the UML was : $> trinity --children 4 --victims /mnt/nfs/n22/forT -x mremap -x clock_nanosleep FWIW : mremap gives within an UML guest with kernel 3.9-rcX this [2] using SLAB and with SLUB this [3]; clock_nanosleep only slows down the tests [1] http://ompldr.org/vaHV6YQ [2] http://thread.gmane.org/gmane.linux.kernel/1462272 [3] http://sourceforge.net/mailarchive/forum.php?thread_name=5140E36D.2080606%40gmx.de&forum_name=user-mode-linux-user -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Paul B. <pe...@ti...> - 2013-03-23 11:39:16
|
The only user of Kconfig symbol STDIO_CONSOLE was removed in v2.5.65. Its entry can safely be removed. Signed-off-by: Paul Bolle <pe...@ti...> --- 0) Untested. 1) A short history of STDIO_CONSOLE and CONFIG_STDIO_CONSOLE CONFIG_STDIO_CONSOLE was added in v2.4.9 (August 2001). It wrapped a call of stdio_console_init() in an #ifdef and #endif pair. The Kconfig symbol STDIO_CONSOLE was added in v2.5.35 (September 2002). That release also introduced a definition of stdio_console_init(). Both CONFIG_STDIO_CONSOLE and the call of stdio_console_init() that it guarded were removed in v2.5.65 (March 2003). An instance of the console_initcall() macro was then added for stdio_console_init. arch/um/Kconfig.char | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/um/Kconfig.char b/arch/um/Kconfig.char index b9d7c42..f10738d 100644 --- a/arch/um/Kconfig.char +++ b/arch/um/Kconfig.char @@ -6,10 +6,6 @@ config STDERR_CONSOLE help console driver which dumps all printk messages to stderr. -config STDIO_CONSOLE - bool - default y - config SSL bool "Virtual serial line" help -- 1.7.11.7 |
|
From: Toralf F. <tor...@gm...> - 2013-03-22 17:28:48
|
Using trinity I often trigger under a user mode linux image with host kernel 3.8.4 and guest kernel linux-v3.9-rc3-244-g9217cbb the following : (The UML guest is a 32bit stable Gentoo Linux) 2013-03-22T18:03:01.232+01:00 trinity kernel: BUG: Bad page map in process trinity-child6 pte:002f9045 pmd:29e421e1 2013-03-22T18:03:01.232+01:00 trinity kernel: page:0920df20 count:1 mapcount:-1 mapping: (null) index:0x0 2013-03-22T18:03:01.232+01:00 trinity kernel: page flags: 0x400(reserved) 2013-03-22T18:03:01.232+01:00 trinity kernel: addr:00100000 vm_flags:00060055 anon_vma: (null) mapping: (null) index:100 2013-03-22T18:03:01.232+01:00 trinity kernel: vma->vm_ops->fault: special_mapping_fault+0x0/0x80 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87d1c: [<0833b8b8>] dump_stack+0x22/0x24 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87d34: [<0833cc71>] print_bad_pte+0x17b/0x197 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87d78: [<080e1138>] unmap_single_vma+0x268/0x430 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87dd8: [<080e1837>] unmap_vmas+0x37/0x50 2013-03-22T18:03:01.232+01:00 trinity kernel: 31e87df4: [<080e4970>] unmap_region+0x80/0xe0 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87e30: [<080e6661>] do_munmap+0x231/0x2a0 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87e68: [<080e8ae8>] sys_mremap+0x248/0x480 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87eac: [<08062a82>] handle_syscall+0x82/0xb0 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87ef4: [<08074dfd>] userspace+0x46d/0x590 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87fec: [<0805f7bc>] fork_handler+0x6c/0x70 2013-03-22T18:03:01.233+01:00 trinity kernel: 31e87ffc: [<00000000>] 0x0 2013-03-22T18:03:01.233+01:00 trinity kernel: 2013-03-22T18:03:01.233+01:00 trinity kernel: Disabling lock debugging due to kernel taint 2013-03-22T18:03:01.233+01:00 trinity kernel: BUG: Bad page state in process trinity-child6 pfn:002f9 2013-03-22T18:03:01.233+01:00 trinity kernel: page:0920df20 count:0 mapcount:-1 mapping: (null) index:0x0 2013-03-22T18:03:01.235+01:00 trinity kernel: page flags: 0x400(reserved) 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87cd4: [<0833b8b8>] dump_stack+0x22/0x24 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87cec: [<080cd755>] bad_page+0xb5/0xe0 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d08: [<080cd7f3>] free_pages_prepare+0x73/0xb0 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d24: [<080cec1d>] free_hot_cold_page+0x1d/0x100 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d4c: [<080d15ae>] __put_single_page+0x1e/0x30 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d60: [<080d16d7>] put_page+0x27/0x30 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d68: [<080ee6ec>] free_page_and_swap_cache+0x3c/0x50 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87d78: [<080e1155>] unmap_single_vma+0x285/0x430 2013-03-22T18:03:01.235+01:00 trinity kernel: 31e87dd8: [<080e1837>] unmap_vmas+0x37/0x50 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87df4: [<080e4970>] unmap_region+0x80/0xe0 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87e30: [<080e6661>] do_munmap+0x231/0x2a0 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87e68: [<080e8ae8>] sys_mremap+0x248/0x480 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87eac: [<08062a82>] handle_syscall+0x82/0xb0 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87ef4: [<08074dfd>] userspace+0x46d/0x590 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87fec: [<0805f7bc>] fork_handler+0x6c/0x70 2013-03-22T18:03:01.236+01:00 trinity kernel: 31e87ffc: [<00000000>] 0x0 2013-03-22T18:03:01.236+01:00 trinity kernel: 2013-03-22T18:03:01.236+01:00 trinity kernel: BUG: Bad page map in process trinity-child6 pte:29e38045 pmd:29e421e1 2013-03-22T18:03:01.236+01:00 trinity kernel: page:09744700 count:1 mapcount:-1 mapping: (null) index:0x0 2013-03-22T18:03:01.237+01:00 trinity kernel: page flags: 0x0() 2013-03-22T18:03:01.237+01:00 trinity kernel: addr:00101000 vm_flags:00060055 anon_vma: (null) mapping: (null) index:101 2013-03-22T18:03:01.237+01:00 trinity kernel: vma->vm_ops->fault: special_mapping_fault+0x0/0x80 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87d1c: [<0833b8b8>] dump_stack+0x22/0x24 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87d34: [<0833cc71>] print_bad_pte+0x17b/0x197 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87d78: [<080e1138>] unmap_single_vma+0x268/0x430 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87dd8: [<080e1837>] unmap_vmas+0x37/0x50 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87df4: [<080e4970>] unmap_region+0x80/0xe0 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87e30: [<080e6661>] do_munmap+0x231/0x2a0 2013-03-22T18:03:01.237+01:00 trinity kernel: 31e87e68: [<080e8ae8>] sys_mremap+0x248/0x480 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87eac: [<08062a82>] handle_syscall+0x82/0xb0 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87ef4: [<08074dfd>] userspace+0x46d/0x590 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87fec: [<0805f7bc>] fork_handler+0x6c/0x70 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87ffc: [<00000000>] 0x0 2013-03-22T18:03:01.238+01:00 trinity kernel: 2013-03-22T18:03:01.238+01:00 trinity kernel: BUG: Bad page state in process trinity-child6 pfn:29e38 2013-03-22T18:03:01.238+01:00 trinity kernel: page:09744700 count:0 mapcount:-1 mapping: (null) index:0x0 2013-03-22T18:03:01.238+01:00 trinity kernel: page flags: 0x0() 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87cd4: [<0833b8b8>] dump_stack+0x22/0x24 2013-03-22T18:03:01.238+01:00 trinity kernel: 31e87cec: [<080cd755>] bad_page+0xb5/0xe0 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d08: [<080cd7f3>] free_pages_prepare+0x73/0xb0 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d24: [<080cec1d>] free_hot_cold_page+0x1d/0x100 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d4c: [<080d15ae>] __put_single_page+0x1e/0x30 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d60: [<080d16d7>] put_page+0x27/0x30 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d68: [<080ee6ec>] free_page_and_swap_cache+0x3c/0x50 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87d78: [<080e1155>] unmap_single_vma+0x285/0x430 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87dd8: [<080e1837>] unmap_vmas+0x37/0x50 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87df4: [<080e4970>] unmap_region+0x80/0xe0 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87e30: [<080e6661>] do_munmap+0x231/0x2a0 2013-03-22T18:03:01.239+01:00 trinity kernel: 31e87e68: [<080e8ae8>] sys_mremap+0x248/0x480 2013-03-22T18:03:01.240+01:00 trinity kernel: 31e87eac: [<08062a82>] handle_syscall+0x82/0xb0 2013-03-22T18:03:01.240+01:00 trinity kernel: 31e87ef4: [<08074dfd>] userspace+0x46d/0x590 2013-03-22T18:03:01.240+01:00 trinity kernel: 31e87fec: [<0805f7bc>] fork_handler+0x6c/0x70 2013-03-22T18:03:01.240+01:00 trinity kernel: 31e87ffc: [<00000000>] 0x0 2013-03-22T18:03:01.240+01:00 trinity kernel: 2013-03-22T18:03:01.240+01:00 trinity kernel: Stub registers - 2013-03-22T18:03:01.240+01:00 trinity kernel: 0 - 100000 2013-03-22T18:03:01.240+01:00 trinity kernel: 1 - 300000 2013-03-22T18:03:01.240+01:00 trinity kernel: 2 - 0 2013-03-22T18:03:01.240+01:00 trinity kernel: 3 - 0 2013-03-22T18:03:01.243+01:00 trinity kernel: 4 - 0 2013-03-22T18:03:01.243+01:00 trinity kernel: 5 - 0 2013-03-22T18:03:01.243+01:00 trinity kernel: 6 - 0 2013-03-22T18:03:01.243+01:00 trinity kernel: 7 - 7b 2013-03-22T18:03:01.243+01:00 trinity kernel: 8 - 7b 2013-03-22T18:03:01.243+01:00 trinity kernel: 9 - 0 2013-03-22T18:03:01.243+01:00 trinity kernel: 10 - 33 2013-03-22T18:03:01.243+01:00 trinity kernel: 11 - ffffffff 2013-03-22T18:03:01.243+01:00 trinity kernel: 12 - 1000c3 2013-03-22T18:03:01.243+01:00 trinity kernel: 13 - 73 2013-03-22T18:03:01.244+01:00 trinity kernel: 14 - 10206 2013-03-22T18:03:01.244+01:00 trinity kernel: 15 - 101028 2013-03-22T18:03:01.244+01:00 trinity kernel: 16 - 7b 2013-03-22T18:03:01.244+01:00 trinity kernel: wait_stub_done : failed to wait for SIGTRAP, pid = 3143, n = 3143, errno = 0, status = 0xb7f -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
|
From: Han <kee...@gm...> - 2013-03-22 00:21:51
|
On Wed, Mar 20, 2013 at 7:20 PM, Antoine Martin <an...@na...> wrote: > On 03/21/2013 05:53 AM, Han wrote: >> Hi Richard, >> >> I hit other issues after moving to a recent kernel UML (i.e. cannot >> fully bring up the UML). Now I am back and trying to debug UML >> itself. However, when I started GDB with UML, I would hit a crash >> like the following. >> >> I was wondering if I used the GDB in wrong way. I couldn't find >> detailed info about GDB UML kernel. Any pointers? Note, this is host >> GDB x86_64, the UML kernel is built as 32-bit (SUBARCH=i386). Is >> that a problem? > http://uml.devloop.org.uk/faq.html#gdb > handle SIGSEGV pass nostop noprint Thanks. I tried this but still have issues: 1) compile your kernel with DEBUG_INFO and FRAME_POINTER - I did this. 2) tell gdb to ignore SIGSEGV: handle SIGSEGV noprint nostop pass - I did this. It crashed after making some progress: (gdb) handle SIGSEGV pass nostop noprint Signal Stop Print Pass to program Description SIGSEGV No No Yes Segmentation fault (gdb) handle SIGUSR1 pass nostop noprint Signal Stop Print Pass to program Description SIGUSR1 No No Yes User defined signal 1 (gdb) run mem=128M ubda=cow1,/nobackup/hxu2/uml/Debian-Squeeze-x86-root_fs umid=debian1 Starting program: /nobackup/hxu2/uml/linux-2.6.27/linux mem=128M ubda=cow1,/nobackup/hxu2/uml/Debian-Squeeze-x86-root_fs umid=debian1 <snip> ..... <snip> kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Detaching after fork from child process 17290. Kernel panic - not syncing: Attempted to kill init! EIP: 0023:[<40014660>] CPU: 0 Not tainted ESP: 002b:ff88c194 EFLAGS: 00010282 Not tainted EAX: ff88c1e8 EBX: 4001bff4 ECX: ff88c39c EDX: ff88dfd6 ESI: ff88c1e8 EDI: 400198fd EBP: ff88c198 DS: 002b ES: 002b 0f85ad8c: [<08069b53>] show_regs+0xb4/0xb9 0f85adb8: [<08059426>] panic_exit+0x25/0x3b 0f85adcc: [<080836d6>] notifier_call_chain+0x27/0x4c 0f85adf4: [<08083712>] __atomic_notifier_call_chain+0x17/0x19 0f85ae04: [<08083729>] atomic_notifier_call_chain+0x15/0x17 0f85ae20: [<0806fea3>] panic+0x52/0xd8 0f85ae40: [<08072873>] do_exit+0x5a/0x6aa 0f85ae7c: [<08072f3f>] do_group_exit+0x7c/0xa3 0f85ae98: [<0807ad11>] get_signal_to_deliver+0x295/0x2d7 0f85aebc: [<08057e07>] do_signal+0x1d5/0x27c 0f85af7c: [<08057292>] interrupt_end+0x31/0x35 0f85af8c: [<0806710f>] userspace+0x344/0x353 0f85afe8: [<08057436>] new_thread_handler+0x72/0x7e 0f85affc: [<00000000>] 0x0 Program received signal SIGTERM, Terminated. Should I ignore SIGTERM also ? Thanks Han > > Antoine > > > > >> >> host#/usr/bin/gdb ./linux >> GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2) >> Copyright (C) 2009 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "x86_64-redhat-linux-gnu". >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>... >> Reading symbols from linux...(no debugging symbols found)...done. >> (gdb) run mem=128M ubda=cow1,Debian-Squeeze-x86-root_fs umid=debian1 >> Starting program: linux mem=128M ubda=cow1,Debian-Squeeze-x86-root_fs >> umid=debian1 >> Locating the bottom of the address space ... >> Program received signal SIGSEGV, Segmentation fault. >> 0x080662fb in page_ok (page=<value optimized out>) at >> arch/um/os-Linux/sys-i386/task_size.c:31 >> 31 n = *address; >> (gdb) bt >> #0 0x080662fb in page_ok (page=<value optimized out>) at >> arch/um/os-Linux/sys-i386/task_size.c:31 >> #1 0x08066403 in os_get_top_address () at >> arch/um/os-Linux/sys-i386/task_size.c:100 >> #2 0x0804a271 in linux_main (argc=4, argv=0xffff8ac4) at >> arch/um/kernel/um_arch.c:277 >> #3 0x0804ad3d in main (argc=4, argv=0xffff8ac4, envp=0xffff8ad8) at >> arch/um/os-Linux/main.c:150 >> (gdb) >> >> >> On Fri, Mar 15, 2013 at 11:36 AM, Han <kee...@gm...> wrote: >>> On Fri, Mar 15, 2013 at 11:11 AM, Han <kee...@gm...> wrote: >>>> On Fri, Mar 15, 2013 at 10:50 AM, richard -rw- weinberger >>>> <ric...@gm...> wrote: >>>>> On Fri, Mar 15, 2013 at 6:01 PM, Han <kee...@gm...> wrote: >>>>>> I started UML with "mem=128M", the module init only kmalloc 8 bytes: >>>>>> >>>>>> kmalloc(size, GFP_KERNEL); >>>>>> >>>>>> where "size" is 8. >>>>> >>>>> This has to work. Just in case, please retry with a more recent kernel. >>>> >>>> I will retry to a more recent kernel. On another front, I suspect >>>> that I might be using incorrect compiling/linking for the module. >>>> Because of certain constraints, I was modifying the build command from >>>> existing builds of the module code. The existing build were for x86 >>>> linux, and I modified them to use x86 UML. >>>> >>>> I modified the options for "gcc", and I think the compile is ok. But >>>> I did not modify "ld" command. Is there anything I should do for >>>> "ld" making sure linking was ok for the UML ? Here is example of my >>>> current ld: >>>> >>>> /usr/bin/ld -nostdlib -m elf_i386 -r -o <my_uml_module_name> >>>> <my_c_obj1> <my_c_obj2> >>>> >>>> the "ld" was successful but now I suspect it was only for the host, >>>> not good for UML. Note: my host linux uses different kernel version >>>> from the UML tree. The host kernel version is 2.6.18. >>> >>> Btw, the UML kernel Changes file states the following requirements: >>> >>> o Gnu C 3.2 # gcc --version >>> o Gnu make 3.79.1 # make --version >>> o binutils 2.12 # ld -v >>> >>> and I am using the following versions: >>> >>> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50) >>> GNU Make 3.80 >>> GNU ld version 2.17.50.0.6-14.el5 20061020 >>> >>> Thanks >>> Han >>> >>>> >>>> Thanks >>>> Han >>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> //richard >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> User-mode-linux-user mailing list >> Use...@li... >> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user >> > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user |
|
From: Antoine M. <an...@na...> - 2013-03-21 02:38:44
|
On 03/21/2013 05:53 AM, Han wrote: > Hi Richard, > > I hit other issues after moving to a recent kernel UML (i.e. cannot > fully bring up the UML). Now I am back and trying to debug UML > itself. However, when I started GDB with UML, I would hit a crash > like the following. > > I was wondering if I used the GDB in wrong way. I couldn't find > detailed info about GDB UML kernel. Any pointers? Note, this is host > GDB x86_64, the UML kernel is built as 32-bit (SUBARCH=i386). Is > that a problem? http://uml.devloop.org.uk/faq.html#gdb handle SIGSEGV pass nostop noprint Antoine > > host#/usr/bin/gdb ./linux > GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2) > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from linux...(no debugging symbols found)...done. > (gdb) run mem=128M ubda=cow1,Debian-Squeeze-x86-root_fs umid=debian1 > Starting program: linux mem=128M ubda=cow1,Debian-Squeeze-x86-root_fs > umid=debian1 > Locating the bottom of the address space ... > Program received signal SIGSEGV, Segmentation fault. > 0x080662fb in page_ok (page=<value optimized out>) at > arch/um/os-Linux/sys-i386/task_size.c:31 > 31 n = *address; > (gdb) bt > #0 0x080662fb in page_ok (page=<value optimized out>) at > arch/um/os-Linux/sys-i386/task_size.c:31 > #1 0x08066403 in os_get_top_address () at > arch/um/os-Linux/sys-i386/task_size.c:100 > #2 0x0804a271 in linux_main (argc=4, argv=0xffff8ac4) at > arch/um/kernel/um_arch.c:277 > #3 0x0804ad3d in main (argc=4, argv=0xffff8ac4, envp=0xffff8ad8) at > arch/um/os-Linux/main.c:150 > (gdb) > > > On Fri, Mar 15, 2013 at 11:36 AM, Han <kee...@gm...> wrote: >> On Fri, Mar 15, 2013 at 11:11 AM, Han <kee...@gm...> wrote: >>> On Fri, Mar 15, 2013 at 10:50 AM, richard -rw- weinberger >>> <ric...@gm...> wrote: >>>> On Fri, Mar 15, 2013 at 6:01 PM, Han <kee...@gm...> wrote: >>>>> I started UML with "mem=128M", the module init only kmalloc 8 bytes: >>>>> >>>>> kmalloc(size, GFP_KERNEL); >>>>> >>>>> where "size" is 8. >>>> >>>> This has to work. Just in case, please retry with a more recent kernel. >>> >>> I will retry to a more recent kernel. On another front, I suspect >>> that I might be using incorrect compiling/linking for the module. >>> Because of certain constraints, I was modifying the build command from >>> existing builds of the module code. The existing build were for x86 >>> linux, and I modified them to use x86 UML. >>> >>> I modified the options for "gcc", and I think the compile is ok. But >>> I did not modify "ld" command. Is there anything I should do for >>> "ld" making sure linking was ok for the UML ? Here is example of my >>> current ld: >>> >>> /usr/bin/ld -nostdlib -m elf_i386 -r -o <my_uml_module_name> >>> <my_c_obj1> <my_c_obj2> >>> >>> the "ld" was successful but now I suspect it was only for the host, >>> not good for UML. Note: my host linux uses different kernel version >>> from the UML tree. The host kernel version is 2.6.18. >> >> Btw, the UML kernel Changes file states the following requirements: >> >> o Gnu C 3.2 # gcc --version >> o Gnu make 3.79.1 # make --version >> o binutils 2.12 # ld -v >> >> and I am using the following versions: >> >> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50) >> GNU Make 3.80 >> GNU ld version 2.17.50.0.6-14.el5 20061020 >> >> Thanks >> Han >> >>> >>> Thanks >>> Han >>> >>>> >>>> -- >>>> Thanks, >>>> //richard > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
|
From: Han <kee...@gm...> - 2013-03-20 22:53:06
|
Hi Richard, I hit other issues after moving to a recent kernel UML (i.e. cannot fully bring up the UML). Now I am back and trying to debug UML itself. However, when I started GDB with UML, I would hit a crash like the following. I was wondering if I used the GDB in wrong way. I couldn't find detailed info about GDB UML kernel. Any pointers? Note, this is host GDB x86_64, the UML kernel is built as 32-bit (SUBARCH=i386). Is that a problem? host#/usr/bin/gdb ./linux GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from linux...(no debugging symbols found)...done. (gdb) run mem=128M ubda=cow1,Debian-Squeeze-x86-root_fs umid=debian1 Starting program: linux mem=128M ubda=cow1,Debian-Squeeze-x86-root_fs umid=debian1 Locating the bottom of the address space ... Program received signal SIGSEGV, Segmentation fault. 0x080662fb in page_ok (page=<value optimized out>) at arch/um/os-Linux/sys-i386/task_size.c:31 31 n = *address; (gdb) bt #0 0x080662fb in page_ok (page=<value optimized out>) at arch/um/os-Linux/sys-i386/task_size.c:31 #1 0x08066403 in os_get_top_address () at arch/um/os-Linux/sys-i386/task_size.c:100 #2 0x0804a271 in linux_main (argc=4, argv=0xffff8ac4) at arch/um/kernel/um_arch.c:277 #3 0x0804ad3d in main (argc=4, argv=0xffff8ac4, envp=0xffff8ad8) at arch/um/os-Linux/main.c:150 (gdb) On Fri, Mar 15, 2013 at 11:36 AM, Han <kee...@gm...> wrote: > On Fri, Mar 15, 2013 at 11:11 AM, Han <kee...@gm...> wrote: >> On Fri, Mar 15, 2013 at 10:50 AM, richard -rw- weinberger >> <ric...@gm...> wrote: >>> On Fri, Mar 15, 2013 at 6:01 PM, Han <kee...@gm...> wrote: >>>> I started UML with "mem=128M", the module init only kmalloc 8 bytes: >>>> >>>> kmalloc(size, GFP_KERNEL); >>>> >>>> where "size" is 8. >>> >>> This has to work. Just in case, please retry with a more recent kernel. >> >> I will retry to a more recent kernel. On another front, I suspect >> that I might be using incorrect compiling/linking for the module. >> Because of certain constraints, I was modifying the build command from >> existing builds of the module code. The existing build were for x86 >> linux, and I modified them to use x86 UML. >> >> I modified the options for "gcc", and I think the compile is ok. But >> I did not modify "ld" command. Is there anything I should do for >> "ld" making sure linking was ok for the UML ? Here is example of my >> current ld: >> >> /usr/bin/ld -nostdlib -m elf_i386 -r -o <my_uml_module_name> >> <my_c_obj1> <my_c_obj2> >> >> the "ld" was successful but now I suspect it was only for the host, >> not good for UML. Note: my host linux uses different kernel version >> from the UML tree. The host kernel version is 2.6.18. > > Btw, the UML kernel Changes file states the following requirements: > > o Gnu C 3.2 # gcc --version > o Gnu make 3.79.1 # make --version > o binutils 2.12 # ld -v > > and I am using the following versions: > > gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50) > GNU Make 3.80 > GNU ld version 2.17.50.0.6-14.el5 20061020 > > Thanks > Han > >> >> Thanks >> Han >> >>> >>> -- >>> Thanks, >>> //richard |
|
From: Toralf F. <tor...@gm...> - 2013-03-17 15:32:16
|
with host kernel 3.8.3 and UML guest kernel 3.9-rc2-333-ge204378 /me wonders if this is UML specific or if I should Cc: lkml too ? ... 2013-03-17T16:16:17.942+01:00 trinity kernel: memdup_user: 2 2013-03-17T16:16:17.942+01:00 trinity kernel: memdup_user: 5 2013-03-17T16:16:21.831+01:00 trinity kernel: memdup_user: -14 2013-03-17T16:17:09.299+01:00 trinity kernel: memdup_user: 1 2013-03-17T16:17:55.762+01:00 trinity kernel: memdup_user: 4096 2013-03-17T16:18:23.474+01:00 trinity kernel: BUG: spinlock recursion on CPU#0, rngd/913 2013-03-17T16:18:23.474+01:00 trinity kernel: lock: 0x842d4ac, .magic: dead4ead, .owner: rngd/913, .owner_cpu: 0 2013-03-17T16:18:23.474+01:00 trinity kernel: 386d7984: [<0835bea8>] dump_stack+0x22/0x24 2013-03-17T16:18:23.474+01:00 trinity kernel: 386d799c: [<0835e8dd>] spin_dump+0xa5/0xac 2013-03-17T16:18:23.474+01:00 trinity kernel: 386d79c8: [<0835e8ff>] spin_bug+0x1b/0x1f 2013-03-17T16:18:23.474+01:00 trinity kernel: 386d79d8: [<08285cae>] do_raw_spin_lock+0x4e/0x100 2013-03-17T16:18:23.474+01:00 trinity kernel: 386d79f8: [<083614c1>] _raw_spin_lock+0x11/0x20 2013-03-17T16:18:23.474+01:00 trinity kernel: 386d7a04: [<08061872>] sigio_lock+0x12/0x20 2013-03-17T16:18:23.474+01:00 trinity kernel: 386d7a10: [<080724a4>] add_sigio_fd+0x14/0x100 2013-03-17T16:18:23.474+01:00 trinity kernel: 386d7a38: [<0805fd7a>] reactivate_fd+0x6a/0x80 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7a54: [<080617e7>] sigio_interrupt+0x37/0x40 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7a6c: [<080cc1af>] handle_irq_event_percpu+0x2f/0x150 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7a9c: [<080cc30a>] handle_irq_event+0x3a/0x60 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7ab8: [<080ce720>] handle_edge_irq+0xe0/0x110 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7acc: [<080cbb5b>] generic_handle_irq+0x2b/0x30 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7adc: [<0805fe75>] do_IRQ+0x25/0x40 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7aec: [<0805fef5>] sigio_handler+0x65/0x80 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7b04: [<08072d28>] sig_handler_common+0xb8/0xe0 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7d88: [<08072c4b>] unblock_signals+0x4b/0x70 2013-03-17T16:18:23.475+01:00 trinity kernel: 386d7d94: [<08072dce>] set_signals+0x1e/0x40 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7da0: [<0807237d>] update_thread+0x13d/0x150 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7dc4: [<08072569>] add_sigio_fd+0xd9/0x100 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7dec: [<0805fd7a>] reactivate_fd+0x6a/0x80 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7e08: [<0806f3eb>] rng_dev_read+0x17b/0x270 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7e48: [<08104e6e>] vfs_read+0x9e/0x170 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7e7c: [<08105200>] sys_read+0x50/0x90 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7eac: [<08063b12>] handle_syscall+0x82/0xb0 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7ef4: [<0807616d>] userspace+0x46d/0x590 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7fec: [<080607fc>] fork_handler+0x6c/0x70 2013-03-17T16:18:23.476+01:00 trinity kernel: 386d7ffc: [<aaaaaaaa>] 0xaaaaaaaa 2013-03-17T16:18:23.478+01:00 trinity kernel: 2013-03-17T16:18:23.478+01:00 trinity kernel: BUG: spinlock lockup suspected on CPU#0, rngd/913 2013-03-17T16:18:23.478+01:00 trinity kernel: lock: 0x842d4ac, .magic: dead4ead, .owner: rngd/913, .owner_cpu: 0 2013-03-17T16:18:23.478+01:00 trinity kernel: 386d7994: [<0835bea8>] dump_stack+0x22/0x24 ... -- 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-15 18:44:44
|
On 03/15/2013 12:10 AM, richard -rw- weinberger wrote:
> Time to look at UML's __get_user().
Just FWIW the "memdup_user:" debug-patch-line is not only triggered by trinity.
It happens even if I regularly boot a UML guest (stable Gentoo x86):
$ /usr/local/bin/linux-v3.9-rc2-292-ga2362d2 earlyprintk ubda=/home/tfoerste/virtual/uml/trinity ubdb=/mnt/ramdisk/swap_trinity eth0=tuntap,tap0,72:ef:3d:9f:c3:5a mem=768M con=pts con0=fd:0,fd:1 umid=uml
Locating the bottom of the address space ... 0x1000
Locating the top of the address space ... 0xc0000000
Core dump limits :
soft - NONE
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking for tmpfs mount on /dev/shm...OK
Checking PROT_EXEC mmap in /dev/shm/...OK
Checking for the skas3 patch in the host:
- /proc/mm...not found: No such file or directory
- PTRACE_FAULTINFO...not found
- PTRACE_LDT...not found
UML running in SKAS0 mode
Adding 9842688 bytes to physical memory to account for exec-shield gap
bootconsole [earlycon0] enabled
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 768308k available
SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:15
Calibrating delay loop... 3461.12 BogoMIPS (lpj=17305600)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Checking for host processor cmov support...Yes
Checking that host ptys support output SIGIO...Yes
Checking that host ptys support SIGIO on close...No, enabling workaround
memdup_user: 9
memdup_user: 9
devtmpfs: initialized
Using 2.6 host AIO
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Switching to clocksource itimer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
mconsole (version 2) initialized on /home/tfoerste/.uml/uml/mconsole
Checking host MADV_REMOVE support...OK
UML Audio Relay (host dsp = /dev/sound/dsp, host mixer = /dev/sound/mixer)
Host TLS support detected
Detected host type: i386 (GDT indexes 6 to 9)
audit: initializing netlink socket (disabled)
type=2000 audit(1363372747.842:1): initialized
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
nfs4filelayout_init: NFSv4 File Layout Driver Registering...
Installing knfsd (copyright (C) 1996 ok...@mo...).
msgmni has been set to 1500
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered (default)
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <ma...@qu...>
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-...@re...
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
Initialized stdio console driver
Console initialized on /dev/tty0
console [tty0] enabled, bootconsole disabled
console [tty0] enabled, bootconsole disabled
Initializing software serial port version 1
console [mc-1] enabled
ubda: unknown partition table
ubdb: unknown partition table
Netdevice 0 (72:ef:3d:9f:c3:5a) :
TUN/TAP backend -
memdup_user: 5
memdup_user: 10
EXT3-fs (ubda): error: couldn't mount because of unsupported optional features (240)
memdup_user: 5
memdup_user: 10
EXT2-fs (ubda): error: couldn't mount because of unsupported optional features (244)
memdup_user: 5
memdup_user: 10
EXT4-fs (ubda): INFO: recovery required on readonly filesystem
EXT4-fs (ubda): write access will be enabled during recovery
EXT4-fs (ubda): orphan cleanup on readonly fs
EXT4-fs (ubda): 60 orphan inodes deleted
EXT4-fs (ubda): recovery complete
EXT4-fs (ubda): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 98:0.
memdup_user: 9
memdup_user: 9
devtmpfs: mounted
memdup_user: 2
INIT: version 2.88 booting
OpenRC 0.11.8 is starting up Gentoo Linux (i686) [UML]
* Mounting /proc ...
memdup_user: 5
memdup_user: 5
[ ok ]
* Mounting /run ...
memdup_user: 6
memdup_user: 6
* /run/openrc: creating directory
* /run/lock: creating directory
* /run/lock: correcting owner
* Using /dev mounted from kernel ...
[ ok ]
* Mounting /dev/pts ...
memdup_user: 7
memdup_user: 7
[ ok ]
* Mounting /dev/shm ...
memdup_user: 6
memdup_user: 4
[ ok ]
* Mounting /sys ...
[ ok ]
* Mounting cgroup filesystem ...
[ ok ]
* Starting udev ...
[ ok ]
* Populating /dev with existing devices through uevents ...
[ ok ]
* Waiting for uevents to be processed ...
[ ok ]
* Setting up dm-crypt mappings ...
* crypt-swap using: -c aes -h sha1 -d /dev/urandom create crypt-swap /dev/ubdb ...
[ ok ]
* pre_mount: mkswap ${dev} ...
[ ok ]
[ ok ]
* Checking local filesystems ...
stable: clean, 93039/122160 files, 318314/488281 blocks
[ ok ]
* Remounting root filesystem read/write ...
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
|
|
From: Han <kee...@gm...> - 2013-03-15 18:36:50
|
On Fri, Mar 15, 2013 at 11:11 AM, Han <kee...@gm...> wrote: > On Fri, Mar 15, 2013 at 10:50 AM, richard -rw- weinberger > <ric...@gm...> wrote: >> On Fri, Mar 15, 2013 at 6:01 PM, Han <kee...@gm...> wrote: >>> I started UML with "mem=128M", the module init only kmalloc 8 bytes: >>> >>> kmalloc(size, GFP_KERNEL); >>> >>> where "size" is 8. >> >> This has to work. Just in case, please retry with a more recent kernel. > > I will retry to a more recent kernel. On another front, I suspect > that I might be using incorrect compiling/linking for the module. > Because of certain constraints, I was modifying the build command from > existing builds of the module code. The existing build were for x86 > linux, and I modified them to use x86 UML. > > I modified the options for "gcc", and I think the compile is ok. But > I did not modify "ld" command. Is there anything I should do for > "ld" making sure linking was ok for the UML ? Here is example of my > current ld: > > /usr/bin/ld -nostdlib -m elf_i386 -r -o <my_uml_module_name> > <my_c_obj1> <my_c_obj2> > > the "ld" was successful but now I suspect it was only for the host, > not good for UML. Note: my host linux uses different kernel version > from the UML tree. The host kernel version is 2.6.18. Btw, the UML kernel Changes file states the following requirements: o Gnu C 3.2 # gcc --version o Gnu make 3.79.1 # make --version o binutils 2.12 # ld -v and I am using the following versions: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50) GNU Make 3.80 GNU ld version 2.17.50.0.6-14.el5 20061020 Thanks Han > > Thanks > Han > >> >> -- >> Thanks, >> //richard |
|
From: Han <kee...@gm...> - 2013-03-15 18:11:39
|
On Fri, Mar 15, 2013 at 10:50 AM, richard -rw- weinberger <ric...@gm...> wrote: > On Fri, Mar 15, 2013 at 6:01 PM, Han <kee...@gm...> wrote: >> I started UML with "mem=128M", the module init only kmalloc 8 bytes: >> >> kmalloc(size, GFP_KERNEL); >> >> where "size" is 8. > > This has to work. Just in case, please retry with a more recent kernel. I will retry to a more recent kernel. On another front, I suspect that I might be using incorrect compiling/linking for the module. Because of certain constraints, I was modifying the build command from existing builds of the module code. The existing build were for x86 linux, and I modified them to use x86 UML. I modified the options for "gcc", and I think the compile is ok. But I did not modify "ld" command. Is there anything I should do for "ld" making sure linking was ok for the UML ? Here is example of my current ld: /usr/bin/ld -nostdlib -m elf_i386 -r -o <my_uml_module_name> <my_c_obj1> <my_c_obj2> the "ld" was successful but now I suspect it was only for the host, not good for UML. Note: my host linux uses different kernel version from the UML tree. The host kernel version is 2.6.18. Thanks Han > > -- > Thanks, > //richard |
|
From: richard -r. w. <ric...@gm...> - 2013-03-15 17:50:29
|
On Fri, Mar 15, 2013 at 6:01 PM, Han <kee...@gm...> wrote: > I started UML with "mem=128M", the module init only kmalloc 8 bytes: > > kmalloc(size, GFP_KERNEL); > > where "size" is 8. This has to work. Just in case, please retry with a more recent kernel. -- Thanks, //richard |
|
From: Han <kee...@gm...> - 2013-03-15 17:01:39
|
On Fri, Mar 15, 2013 at 9:56 AM, richard -rw- weinberger <ric...@gm...> wrote: > On Fri, Mar 15, 2013 at 5:38 PM, Han <kee...@gm...> wrote: >> 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 ... > > Okay. 2.6.27 not 2.6.2. ;) > How much memory are you allocating using kmalloc()? I started UML with "mem=128M", the module init only kmalloc 8 bytes: kmalloc(size, GFP_KERNEL); where "size" is 8. thanks. > > -- > Thanks, > //richard |
|
From: richard -r. w. <ric...@gm...> - 2013-03-15 16:56:55
|
On Fri, Mar 15, 2013 at 5:38 PM, Han <kee...@gm...> wrote: > 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 ... Okay. 2.6.27 not 2.6.2. ;) How much memory are you allocating using kmalloc()? -- Thanks, //richard |
|
From: Toralf F. <tor...@gm...> - 2013-03-15 16:43:15
|
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? > something in between 3.8.2 and 3.83 solves the issue, now I can run host with 3.8.3 and UML guest with arbitrary kernel version (but heavily testd just with current 3.9-rc2-... kernels) w/o this issue so far as I can see. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
525 messages has been excluded from this view by a project administrator.
