gmane.linux.uml.devel
http://blog.gmane.org/gmane.linux.uml.devel
hourly11901-01-01T00:00+00:00Gmanehttp://gmane.org/img/gmane-25t.png
http://gmane.org
UML vs ptrace_scope
http://comments.gmane.org/gmane.linux.uml.devel/13911
<pre>
I have been trying to bring the openswan nightly build system up again
on a newish system. I started these scripts back in 2002, and it has been running
on and off for many years, and many kernel revisions.
I started this most recent effort work when 3.5 was stable, so my guest
kernel is a 3.5 kernel running on a debian squeeze host with a 2.6.26
kernel. I compile things fine.
With 2.6.26, I got:
...
Checking that ptrace can change system call numbers...ptrace: Operation
not permitted
check_ptrace : expected SIGSTOP, got status = 9
I upgraded to wheezy (needed to be done anyway), and then felt that I
ran run into the ptrace_scope problem. At least, that's what I thought.
I installed a 3.8 debian kernel tree, patched it to enable YAMA, and
booted that finally. I set:
kernel.yama.ptrace_scope = 0
but this does not affect the above error. Is there something else I am
missing? I tried adding the capability, but it doesn't help.
curley-[~] mcr 10001 %sudo /sbin/setcap cap_sys_ptrace+ep
/btmp/build/HEAD/2013_05_12/openswan-2/UMLPOOL/plain26/linux
[sudo] password for mcr:
curley-[~] mcr 10002 %sudo /sbin/getcap
/btmp/build/HEAD/2013_05_12/openswan-2/UMLPOOL/plain26/linux
/btmp/build/HEAD/2013_05_12/openswan-2/UMLPOOL/plain26/linux =
cap_sys_ptrace+ep
No I suspect the problem is elsewhere.
Is there something else I am missing?
</pre>Michael Richardson2013-05-17T10:43:03trinity fuzzying gave : BUG anon_vma (Not tainted):Redzone overwritten
http://comments.gmane.org/gmane.linux.uml.devel/13902
<pre>Although it just happens for the first time I'd like to share this.
Got by fuzzyinga 32bit stable Gentoo guest with trinity,
guest kernel is linux-v3.10-rc1-36 (strnlen + stub4 patch included) :
2013-05-14T18:06:15.405+02:00 trinity kernel: =============================================================================
2013-05-14T18:06:15.405+02:00 trinity kernel: BUG anon_vma (Not tainted): Redzone overwritten
2013-05-14T18:06:15.405+02:00 trinity kernel: -----------------------------------------------------------------------------
2013-05-14T18:06:15.405+02:00 trinity kernel:
2013-05-14T18:06:15.405+02:00 trinity kernel: Disabling lock debugging due to kernel taint
2013-05-14T18:06:15.405+02:00 trinity kernel: INFO: 0x405084f8-0x405084fb. First byte 0xe8 instead of 0xcc
2013-05-14T18:06:15.405+02:00 trinity kernel: INFO: Allocated in anon_vma_prepare+0x6a/0x160 age=1631 cpu=0 pid=856
2013-05-14T18:06:15.405+02:00 trinity kernel: INFO: Freed in __put_anon_vma+0x93/0xa0 age=1651 cpu=0 pid=854
2013-05-14T18:06:15.405+02:00 trinity kernel: INFO: Slab 0x0ae47800 objects=46 used=7 fp=0x40508108 flags=0x0081
2013-05-14T18:06:15.405+02:00 trinity kernel: INFO: Object 0x405084d0 < at >offset=1232 fp=0x405084e8
2013-05-14T18:06:15.410+02:00 trinity kernel:
2013-05-14T18:06:15.410+02:00 trinity kernel: Bytes b4 405084c0: 59 03 00 00 00 99 ff ff 5a 5a 5a 5a 5a 5a 5a 5a Y.......ZZZZZZZZ
2013-05-14T18:06:15.410+02:00 trinity kernel: Object 405084d0: d0 84 50 40 00 00 00 00 01 00 00 00 ad 4e ad de ..P< at >.........N..
2013-05-14T18:06:15.410+02:00 trinity kernel: Object 405084e0: ff ff ff ff ff ff ff ff e8 84 50 40 e8 84 50 40 ..........P< at >..P< at >
2013-05-14T18:06:15.410+02:00 trinity kernel: Object 405084f0: 00 00 00 00 00 00 00 00 ........
2013-05-14T18:06:15.410+02:00 trinity kernel: Redzone 405084f8: e8 84 50 40 ..P< at >
2013-05-14T18:06:15.410+02:00 trinity kernel: Padding 40508520: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
2013-05-14T18:06:15.410+02:00 trinity kernel: CPU: 0 PID: 856 Comm: rc Tainted: G B 3.10.0-rc1-00036-g05d129d #9
2013-05-14T18:06:15.410+02:00 trinity kernel: 416a7c1c 416a7c48 080f9da0 083db92c 405084d0 000004d0 405084e8 0ae47800
2013-05-14T18:06:15.410+02:00 trinity kernel: 405084f8 00000004 405084fb 416a7c80 080fa378 083dba0c 405084f8 405084fb
2013-05-14T18:06:15.411+02:00 trinity kernel: 000000e8 000000cc 0000005a 405084d0 0ae47800 414496c0 414496c0 405084d0 416a7bf0: [<08060cff>] show_stack+0xcf/0x100
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7c14: [<0835ed79>] dump_stack+0x26/0x28
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7c24: [<080f9da0>] print_trailer+0xe0/0xf0
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7c4c: [<080fa378>] check_bytes_and_report+0xa8/0x100
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7c84: [<080fa41f>] check_object+0x4f/0x210
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7cc0: [<0835d4c9>] free_debug_processing+0xd0/0x216
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7cec: [<0835d6fd>] __slab_free+0x2d/0x282
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7d50: [<080fba79>] kmem_cache_free+0xe9/0x100
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7d74: [<080ee373>] __put_anon_vma+0x93/0xa0
2013-05-14T18:06:15.411+02:00 trinity kernel: 416a7d8c: [<080ee61c>] unlink_anon_vmas+0x13c/0x1a0
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7db4: [<080e4355>] free_pgtables+0x55/0xe0
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7ddc: [<080eb84e>] exit_mmap+0xbe/0x170
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7e14: [<0807991d>] mmput+0x3d/0xb0
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7e28: [<08081086>] do_exit+0x2f6/0x880
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7e78: [<080816f9>] do_group_exit+0xa9/0xf0
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7ea0: [<08081759>] SyS_exit_group+0x19/0x20
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7eac: [<08062ac2>] handle_syscall+0x82/0xb0
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7ef4: [<0807519d>] userspace+0x46d/0x590
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7fec: [<0805f7fc>] fork_handler+0x6c/0x70
2013-05-14T18:06:15.413+02:00 trinity kernel: 416a7ffc: [<00000000>] 0x0
2013-05-14T18:06:15.414+02:00 trinity kernel:
2013-05-14T18:06:15.414+02:00 trinity kernel: FIX anon_vma: Restoring 0x405084f8-0x405084fb=0xcc
2013-05-14T18:06:15.414+02:00 trinity kernel:
2013-05-14T18:06:22.639+02:00 trinity kernel: INFO: 0x405084f8-0x405084fb. First byte 0xcc instead of 0xbb
2013-05-14T18:06:22.639+02:00 trinity kernel: INFO: Allocated in anon_vma_prepare+0x6a/0x160 age=2360 cpu=0 pid=856
2013-05-14T18:06:22.639+02:00 trinity kernel: INFO: Freed in __put_anon_vma+0x93/0xa0 age=2380 cpu=0 pid=854
2013-05-14T18:06:22.639+02:00 trinity kernel: INFO: Slab 0x0ae47800 objects=46 used=46 fp=0x (null) flags=0x0080
2013-05-14T18:06:22.639+02:00 trinity kernel: INFO: Object 0x405084d0 < at >offset=1232 fp=0x40508108
2013-05-14T18:06:22.639+02:00 trinity kernel:
2013-05-14T18:06:22.644+02:00 trinity kernel: Bytes b4 405084c0: 59 03 00 00 00 99 ff ff 5a 5a 5a 5a 5a 5a 5a 5a Y.......ZZZZZZZZ
2013-05-14T18:06:22.644+02:00 trinity kernel: Object 405084d0: d0 84 50 40 00 00 00 00 01 00 00 00 ad 4e ad de ..P< at >.........N..
2013-05-14T18:06:22.644+02:00 trinity kernel: Object 405084e0: ff ff ff ff ff ff ff ff e8 84 50 40 e8 84 50 40 ..........P< at >..P< at >
2013-05-14T18:06:22.644+02:00 trinity kernel: Object 405084f0: 00 00 00 00 00 00 00 00 ........
2013-05-14T18:06:22.644+02:00 trinity kernel: Redzone 405084f8: cc cc cc cc ....
2013-05-14T18:06:22.644+02:00 trinity kernel: Padding 40508520: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
2013-05-14T18:06:22.644+02:00 trinity kernel: CPU: 0 PID: 964 Comm: sshd Tainted: G B 3.10.0-rc1-00036-g05d129d #9
2013-05-14T18:06:22.644+02:00 trinity kernel: 41837c0c 41837c38 080f9da0 083db92c 405084d0 000004d0 40508108 0ae47800
2013-05-14T18:06:22.644+02:00 trinity kernel: 405084f8 00000004 405084fb 41837c70 080fa378 083dba0c 405084f8 405084fb
2013-05-14T18:06:22.644+02:00 trinity kernel: 000000cc 000000bb 0000005a 405084d0 0ae47800 414496c0 414496c0 405084d0 41837be0: [<08060cff>] show_stack+0xcf/0x100
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837c04: [<0835ed79>] dump_stack+0x26/0x28
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837c14: [<080f9da0>] print_trailer+0xe0/0xf0
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837c3c: [<080fa378>] check_bytes_and_report+0xa8/0x100
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837c74: [<080fa41f>] check_object+0x4f/0x210
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837cb0: [<0835d368>] alloc_debug_processing+0x7d/0x10e
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837cd4: [<0835ddd9>] __slab_alloc.constprop.66+0x3ca/0x41c
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837d68: [<080fb833>] kmem_cache_alloc+0x33/0xf0
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837d94: [<080ee85a>] anon_vma_fork+0x4a/0x110
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837db4: [<08079e61>] dup_mm+0x261/0x490
2013-05-14T18:06:22.653+02:00 trinity kernel: 41837e04: [<0807aa7a>] copy_process+0x9aa/0x11c0
2013-05-14T18:06:22.658+02:00 trinity kernel: 41837e4c: [<0807b375>] do_fork+0x95/0x250
2013-05-14T18:06:22.658+02:00 trinity kernel: 41837e90: [<0807b61e>] SyS_clone+0x2e/0x30
2013-05-14T18:06:22.658+02:00 trinity kernel: 41837eac: [<08062ac2>] handle_syscall+0x82/0xb0
2013-05-14T18:06:22.658+02:00 trinity kernel: 41837ef4: [<0807519d>] userspace+0x46d/0x590
2013-05-14T18:06:22.658+02:00 trinity kernel: 41837fec: [<0805f7fc>] fork_handler+0x6c/0x70
2013-05-14T18:06:22.658+02:00 trinity kernel: 41837ffc: [<00000000>] 0x0
2013-05-14T18:06:22.658+02:00 trinity kernel:
2013-05-14T18:06:22.658+02:00 trinity kernel: FIX anon_vma: Restoring 0x405084f8-0x405084fb=0xbb
2013-05-14T18:06:22.658+02:00 trinity kernel:
2013-05-14T18:06:22.658+02:00 trinity kernel: FIX anon_vma: Marking all objects used
</pre>Toralf Förster2013-05-14T16:15:27WARNING: at mm/mmap.c:2757 exit_mmap+0x161/0x170()
http://comments.gmane.org/gmane.linux.uml.devel/13877
<pre>With recent host and guest kernel trinity often triggers that warning
which refers to this line
WARN_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
/me wonders if (and how) I can help to identify the root cause (if it is
not already known).
</pre>Toralf Förster2013-05-12T15:47:06oom-killer forced by syscall add_key
http://comments.gmane.org/gmane.linux.uml.devel/13876
<pre>With
$> trinity --children 2 -c add_key --quiet
it takes only 2 minutes to force an oom-killer at a user mode linux guest.
I'm just wondering if this is a wanted behaviour of the kernel.
2013-05-12T16:26:22.662+02:00 trinity kernel: trinity-child0 invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=500
2013-05-12T16:26:22.662+02:00 trinity kernel: CPU: 0 PID: 1018 Comm: trinity-child0 Not tainted 3.10.0-rc1-00002-gcaec151 #5
2013-05-12T16:26:22.662+02:00 trinity kernel: 3eb07bd0 3eb07c2c 0835c7bd 3f5a3b3c 3f5a37b0 000200da 00000000 000001f4
2013-05-12T16:26:22.662+02:00 trinity kernel: 08443920 3eb07c00 08071dfe 00000000 3eb07c0c 083614dc 00000001 3eb07c2c
2013-05-12T16:26:22.662+02:00 trinity kernel: 08278d45 08443920 00000001 3eb00000 3f5a3600 3f5a3600 3f5a3600 3eb07c70 3eb07ba4: [<08060d2f>] show_stack+0xcf/0x100
2013-05-12T16:26:22.662+02:00 trinity kernel: 3eb07bc8: [<0835ed99>] dump_stack+0x26/0x28
2013-05-12T16:26:22.662+02:00 trinity kernel: 3eb07bd8: [<0835c7bd>] dump_header.isra.12+0x93/0x1c8
2013-05-12T16:26:22.662+02:00 trinity kernel: 3eb07c30: [<080ce620>] oom_kill_process+0x60/0x310
2013-05-12T16:26:22.662+02:00 trinity kernel: 3eb07c74: [<080cedcd>] out_of_memory+0x2bd/0x320
2013-05-12T16:26:22.662+02:00 trinity kernel: 3eb07cc0: [<080d2258>] __alloc_pages_nodemask+0x628/0x750
2013-05-12T16:26:22.678+02:00 trinity kernel: 3eb07d4c: [<080e6750>] handle_pte_fault+0x130/0x780
2013-05-12T16:26:22.678+02:00 trinity kernel: 3eb07da4: [<080e6e6c>] handle_mm_fault+0xcc/0xe0
2013-05-12T16:26:22.678+02:00 trinity kernel: 3eb07dd8: [<08061d87>] handle_page_fault+0x127/0x280
2013-05-12T16:26:22.678+02:00 trinity kernel: 3eb07e1c: [<08061fb6>] segv+0xa6/0x2b0
2013-05-12T16:26:22.678+02:00 trinity kernel: 3eb07ecc: [<08062233>] segv_handler+0x73/0x80
2013-05-12T16:26:22.678+02:00 trinity kernel: 3eb07ef4: [<0807503a>] userspace+0x30a/0x590
2013-05-12T16:26:22.678+02:00 trinity kernel: 3eb07fec: [<0805f82c>] fork_handler+0x6c/0x70
2013-05-12T16:26:22.678+02:00 trinity kernel: 3eb07ffc: [<00000000>] 0x0
2013-05-12T16:26:22.678+02:00 trinity kernel:
2013-05-12T16:26:22.678+02:00 trinity kernel: Mem-Info:
2013-05-12T16:26:22.679+02:00 trinity kernel: Normal per-cpu:
2013-05-12T16:26:22.679+02:00 trinity kernel: CPU 0: hi: 186, btch: 31 usd: 37
2013-05-12T16:26:22.679+02:00 trinity kernel: active_anon:109976 inactive_anon:109982 isolated_anon:0
2013-05-12T16:26:22.679+02:00 trinity kernel: active_file:28 inactive_file:330 isolated_file:0
2013-05-12T16:26:22.679+02:00 trinity kernel: unevictable:0 dirty:1 writeback:0 unstable:0
2013-05-12T16:26:22.679+02:00 trinity kernel: free:928 slab_reclaimable:803 slab_unreclaimable:959
2013-05-12T16:26:22.679+02:00 trinity kernel: mapped:429 shmem:373 pagetables:1683 bounce:0
2013-05-12T16:26:22.679+02:00 trinity kernel: free_cma:0
2013-05-12T16:26:22.679+02:00 trinity kernel: Normal free:3712kB min:3796kB low:4744kB high:5692kB active_anon:439904kB inactive_anon:439928kB active_file:112kB inactive_file:1320kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:928056kB managed:901248kB mlocked:0kB dirty:4kB writeback:0kB mapped:1716kB shmem:1492kB slab_reclaimable:3212kB slab_unreclaimable:3836kB kernel_stack:1536kB pagetables:6732kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:4258 all_unreclaimable? yes
2013-05-12T16:26:22.679+02:00 trinity kernel: lowmem_reserve[]: 0 0
2013-05-12T16:26:22.680+02:00 trinity kernel: Normal: 0*4kB 0*8kB 2*16kB (R) 3*32kB (R) 0*64kB 0*128kB 0*256kB 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 3712kB
2013-05-12T16:26:22.680+02:00 trinity kernel: 899 total pagecache pages
2013-05-12T16:26:22.680+02:00 trinity kernel: 168 pages in swap cache
2013-05-12T16:26:22.680+02:00 trinity kernel: Swap cache stats: add 65784, delete 65616, find 448/478
2013-05-12T16:26:22.680+02:00 trinity kernel: Free swap = 0kB
2013-05-12T16:26:22.680+02:00 trinity kernel: Total swap = 262140kB
2013-05-12T16:26:22.680+02:00 trinity kernel: 232014 pages RAM
2013-05-12T16:26:22.680+02:00 trinity kernel: 6702 pages reserved
2013-05-12T16:26:22.680+02:00 trinity kernel: 263109 pages shared
2013-05-12T16:26:22.680+02:00 trinity kernel: 223418 pages non-shared
2013-05-12T16:26:22.681+02:00 trinity kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 445] 0 445 2273 0 5 107 -1000 udevd
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 870] 0 870 1074 0 3 39 0 syslog-ng
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 871] 0 871 1825 0 4 137 0 syslog-ng
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 885] 0 885 1332 0 4 805 0 haveged
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 899] 0 899 529 5 3 10 0 rngd
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 946] 0 946 594 0 3 28 0 dhcpcd
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 962] 0 962 1287 0 4 84 -1000 sshd
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 990] 0 990 1131 9 4 22 0 cron
2013-05-12T16:26:22.681+02:00 trinity kernel: [ 1007] 0 1007 597 0 3 27 0 agetty
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1009] 0 1009 2086 0 4 147 0 sshd
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1011] 0 1011 543 0 3 17 0 tail
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1012] 0 1012 2086 0 4 145 0 sshd
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1014] 1000 1014 2086 27 4 126 0 sshd
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1015] 1000 1015 3628 2 5 1049 0 trinity
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1016] 1000 1016 3628 11 4 1041 0 trinity-watchdo
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1017] 1000 1017 3749 2 4 1138 0 trinity-main
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1018] 1000 1018 290362 111694 284 33276 500 trinity-child0
2013-05-12T16:26:22.682+02:00 trinity kernel: [ 1019] 1000 1019 281146 108749 275 31440 500 trinity-child1
2013-05-12T16:26:22.682+02:00 trinity kernel: Out of memory: Kill process 1018 (trinity-child0) score 997 or sacrifice child
2013-05-12T16:26:22.683+02:00 trinity kernel: Killed process 1018 (trinity-child0) total-vm:1161448kB, anon-rss:445060kB, file-rss:1716kB
</pre>Toralf Förster2013-05-12T14:28:50trinity triggers often "WARNING: at mm/mmap.c:2757exit_mmap+0x164/0x170()"
http://comments.gmane.org/gmane.linux.uml.devel/13875
<pre>at an UML guest (32 bit stable Gentoo both at host and guest,
host has kernel version 3.9.2, guest has kernel version 3.10-rc1 + 2 patches from -rw-).
The syslog says :
2013-05-12T13:45:38.381+02:00 trinity kernel: ------------[ cut here ]------------
2013-05-12T13:45:38.381+02:00 trinity kernel: WARNING: at mm/mmap.c:2757 exit_mmap+0x164/0x170()
2013-05-12T13:45:38.381+02:00 trinity kernel: CPU: 0 PID: 1193 Comm: trinity-child0 Not tainted 3.10.0-rc1-00002-gcaec151 #5
2013-05-12T13:45:38.381+02:00 trinity kernel: 3f68fd9c 3f68fdc8 0807bfca 083d51bc 083d9a7a 00000ac5 080eb914 080eb914
2013-05-12T13:45:38.381+02:00 trinity kernel: 000004f0 3f59b8c0 3eaafb3c 3f68fdd8 0807c093 00000009 00000000 3f68fe10
2013-05-12T13:45:38.381+02:00 trinity kernel: 080eb914 083d9a7a 00000ac5 c0000000 00000000 40716660 3f59b8c0 00000000 3f68fd70: [<08060d2f>] show_stack+0xcf/0x100
2013-05-12T13:45:38.381+02:00 trinity kernel: 3f68fd94: [<0835ed99>] dump_stack+0x26/0x28
2013-05-12T13:45:38.381+02:00 trinity kernel: 3f68fda4: [<0807bfca>] warn_slowpath_common+0x5a/0x80
2013-05-12T13:45:38.381+02:00 trinity kernel: 3f68fdcc: [<0807c093>] warn_slowpath_null+0x23/0x30
2013-05-12T13:45:38.381+02:00 trinity kernel: 3f68fddc: [<080eb914>] exit_mmap+0x164/0x170
2013-05-12T13:45:38.386+02:00 trinity kernel: 3f68fe14: [<0807991d>] mmput+0x3d/0xb0
2013-05-12T13:45:38.386+02:00 trinity kernel: 3f68fe28: [<08081086>] do_exit+0x2f6/0x880
2013-05-12T13:45:38.386+02:00 trinity kernel: 3f68fe78: [<080816f9>] do_group_exit+0xa9/0xf0
2013-05-12T13:45:38.386+02:00 trinity kernel: 3f68fea0: [<08081759>] SyS_exit_group+0x19/0x20
2013-05-12T13:45:38.386+02:00 trinity kernel: 3f68feac: [<08062ac2>] handle_syscall+0x82/0xb0
2013-05-12T13:45:38.386+02:00 trinity kernel: 3f68fef4: [<0807519d>] userspace+0x46d/0x590
2013-05-12T13:45:38.386+02:00 trinity kernel: 3f68ffec: [<0805f82c>] fork_handler+0x6c/0x70
2013-05-12T13:45:38.386+02:00 trinity kernel: 3f68fffc: [<00000000>] 0x0
2013-05-12T13:45:38.386+02:00 trinity kernel:
2013-05-12T13:45:38.386+02:00 trinity kernel: ---[ end trace ae0a9ee7fbe3a27c ]---
and that's correlated to this trinity log:
...
[1193] [63] getrusage(who=0x39b6c710, ru=0) = -1 (Invalid argument)
[1193] [64] fchmodat(dfd=10, filename="/mnt/n22/v/victims/f08", mode=2) = -1 (Permission denied)
[1193] [65] pipe2(fildes=0, flags=0x80800) = -1 (Bad address)
[1193] [66] setgroups(gidsetsize=4096, grouplist=1) = -1 (Operation not permitted)
[1193] [67] uselib(library=1) = -1 (Bad address)
[1193] [68] sigpending(set=0) = -1 (Bad address)
[1193] [69] readv(fd=9, vec=0x80c59e0, vlen=1) = -1 (Bad file descriptor)
[1193] [70] preadv(fd=9, vec=0x80c5bd8, vlen=3, pos_l=4096, pos_h=0x45ab84d0) = -1 (Illegal seek)
[1193] [71] rmdir(pathname="<D9> <U+0487><D9> <U+0487><D9> <U+0487><D9> <U+0487><D9> <U+0487><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0>
<E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><B8><E0><U+0ABB><EF>ҩ <88><88><D2><D2>
<88><BB><EF>ҩ <88><88><D2><D2>
<88>
<BF>܉̈ҿ̈ҿ
<BF>܉<89><B9>
<BF>܉<89><B9><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89>
<89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><89><B9><B8><E0><E0><AA>̈ҿ̈ҿ̈ҿ<89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0><89><89><B9><B9><E0><E0>
<89><BB><EF>ҩ <88><88><D2><D2>
<88>̈ҿ̈ҿ̈ҿ<B8><E0><E0><AA>T̫̺̳o̬̜ ì̬͎̲̟nv̖̗̻̣̹̕o͖̗̠̜̤k͍͚̹͖̼e̦̗̪͍̪͍ ̬ͅt̕h̠͙̮͕͓e̱̜̗͙̭ ̥͔̫͙̪͍̣͝ḥi̼̦͈̼v̩̟͚̞͎e͈̟̻͙̦̤-m̷̘̝̱í͚̞̦̳n̝̲̯̙̮͞d̴̺̦͕̫ ̗̭̘͎͖r̞͎̜̜͖͎̫͢ep͇r̝̯̝͖͉͎̺e̴s̥e̵̖̳͉͍̩̗n̢͓̪͕̜̰̠̦t̺̞̰i͟n̮̦̖̟g̮͍̱̻͍̜̳ ̳c̖̮̙̣̰̠̩h̷̗͍̖͙̭͇͈a̧͎̯̹̲̺̫ó̭̞̜̣̯͕s̶̤̮̩̘.̨̻̪̖͔ ̳̭̦̭̭̦̞́I̠͍̮n͇̹̪̬v̴͖̭̗̖o̸k̬̤͓͚̠͍i͜n̛̩̹͉̘̹g͙ ̠̥ͅt̰͖͞h̫̼̪e̟̩̝ ̭̠̲̫͔fe̤͇̝̱e͖̮̠̹̭͖͕l͖̲̘͖̠̪i̢̖͎̮̗̯͓̩n̸̰g̙̱̘̗͚̬ͅ ͍o͍͍̩̮͢f̖͓̦̥ ̘͘c̵̫̱̗͚") = -1 (File name too long)
[1019] Random reseed: 212204951
= -1 (Invalid argument)
...
[watchdog] kernel became tainted! Last seed was 212204951
child 1194 exiting
[1018] Watchdog exiting
Ran 85915 syscalls. Successes: 14336 Failures: 71564
</pre>Toralf Förster2013-05-12T14:04:15Good afternoon!
http://comments.gmane.org/gmane.linux.uml.devel/13856
<pre>http://showgeki.info/wp-content/plugins/tv1mod/brain.php?zmuuxra792fdawg
.........................
Adam was the only man who, when he said a good thing, knew that nobody had said it before him. -- Mark Twain------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
</pre>Sebastian b2013-05-01T14:56:57UML Hardware Virt Support
http://comments.gmane.org/gmane.linux.uml.devel/13850
<pre>The book (2004) states that work was going on for hardware assisted virt.
Has there been progress on it? Where do I find information on it?
The UML source tree still comes with the original modes of operation.
-Earlence
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
</pre>Earlence Fernandes2013-04-30T16:12:24SKAS mode and UML code
http://comments.gmane.org/gmane.linux.uml.devel/13848
<pre>placed in a reserved memory section in every process it virtualizes. Is
this a correct interpretation?
-Earlence
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
</pre>Earlence Fernandes2013-04-29T23:23:24Code for tracing thread
http://comments.gmane.org/gmane.linux.uml.devel/13844
<pre>I keep reading that there is a tracing thread that intercepts process
syscalls and I've been grepping thru the kernel sources to find this.
Can anyone point me in the right direction?
I've looked at os-Linux/ and arch/um/kernel/
-Earlence
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
</pre>Earlence Fernandes2013-04-28T15:43:33[PATCH] um: Use generic idle loop
http://comments.gmane.org/gmane.linux.uml.devel/13841
<pre>Signed-off-by: Richard Weinberger <richard< at >nod.at>
---
arch/um/Kconfig.common | 1 +
arch/um/kernel/process.c | 27 ++-------------------------
2 files changed, 3 insertions(+), 25 deletions(-)
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..5783406 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
< at >< at > -12,6 +12,7 < at >< at > config UML
select GENERIC_CPU_DEVICES
select GENERIC_IO
select GENERIC_CLOCKEVENTS
+select GENERIC_IDLE_LOOP
select TTY # Needed for line.c
config MMU
diff --git a/arch/um/kernel/process.c b/arch/um/kernel/process.c
index b462b13..4d64860 100644
--- a/arch/um/kernel/process.c
+++ b/arch/um/kernel/process.c
< at >< at > -210,33 +210,10 < at >< at > void initial_thread_cb(void (*proc)(void *), void *arg)
kmalloc_ok = save_kmalloc_ok;
}
-void default_idle(void)
-{
-unsigned long long nsecs;
-
-while (1) {
-/* endless idle loop with no priority at all */
-
-/*
- * although we are an idle CPU, we do not want to
- * get into the scheduler unnecessarily.
- */
-if (need_resched())
-schedule();
-
-tick_nohz_idle_enter();
-rcu_idle_enter();
-nsecs = disable_timer();
-idle_sleep(nsecs);
-rcu_idle_exit();
-tick_nohz_idle_exit();
-}
-}
-
-void cpu_idle(void)
+void arch_cpu_idle(void)
{
cpu_tasks[current_thread_info()->cpu].pid = os_getpid();
-default_idle();
+local_irq_enable();
}
int __cant_sleep(void) {
</pre>Richard Weinberger2013-04-15T17:53:25Endless page fault for the same miss address in my UML
http://comments.gmane.org/gmane.linux.uml.devel/13825
<pre>Hello guys,
Is there any available resource that explains how user-mode-linux maps the
pages of a task in UML to the host kernel?
In my UML, I modified a task's page table when forking it. Then I ran into
a situation where the page fault happens over and over again for the same
address in the forked task. I use gdb debugger and find out that when the
page fault happens for the first time, the kernel calls do_wp_page() to
fault in the page and marks the page present. This should prevent the next
page fault for the same address from happening again. I checked the PTE in
UML, they are marked as present so is it possible that the page is not
being allocated properly on the host kernel so that the page fault keeps
happening for the same address even though UML thinks the page is present.
Any suggestions?
Thank!
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
</pre>Terry Hsu2013-04-06T19:23:07BUG: failure atblock/blk-core.c:2985/blk_flush_plug_list()
http://comments.gmane.org/gmane.linux.uml.devel/13816
<pre>Running UML from vanilla kernel 3.8.5 compiled with default kernel
configuration and booted with Fedora 18 root fs (as downloaded from
http://fs.devloop.org.uk/). Boots fine about 3/4 of the time, the rest of
the time it crashes - see output below for an example.
command line:
./linux ubd0=Fedora18-AMD64-root_fs rw mem=4096M con0=fd:0,fd:1
source code BUG() line:
BUG_ON(plug->magic != PLUG_MAGIC);
console output:
.
.
.
.
[ OK ] Started Load Random Seed.
[ OK ] Started Configure read-only root support.
[ OK ] Started udev Coldplug all Devices.
Starting udev Wait for Complete Device Initialization...
Starting Show Plymouth Boot Screen...
BUG: failure at block/blk-core.c:2985/blk_flush_plug_list()!
Kernel panic - not syncing: BUG!
Call Trace:
15f4a7d70: [<6024769a>] panic+0x145/0x2a7
15f4a7da8: [<60247555>] panic+0x0/0x2a7
15f4a7de8: [<602477fc>] printk+0x0/0xa0
15f4a7e60: [<600182c0>] _init+0x7e0/0x8b0
15f4a7e80: [<6018ae95>] blk_flush_plug_list+0x19f/0x260
15f4a7ec0: [<6004678f>] sigsuspend+0x0/0x9e
15f4a7ed0: [<600182c0>] _init+0x7e0/0x8b0
15f4a7ef0: [<6024bb90>] schedule+0x6a/0x78
15f4a7f00: [<6004532e>] set_current_blocked+0x17/0x19
15f4a7f10: [<600467eb>] sigsuspend+0x5c/0x9e
15f4a7f30: [<6001e726>] winch_thread+0x204/0x242
15f4a7fd0: [<6001e522>] winch_thread+0x0/0x242
Modules linked in: autofs4
Pid: 1598706048, comm: Not tainted 3.8.5
RIP: 6c28:[<000000015f4a5818>]
RSP: 0000000000000000 EFLAGS: 16096d530
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 000000015f4a53a8 RSI: 000000015f4a53a8 RDI: 000000015f4a53b8
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000015f4a5380
R10: 000000015f4a5380 R11: 0000000000000001 R12: 0000000c00000000
R13: 0000000015b9ad10 R14: 00000000515ba557 R15: 0000000015b9ad10
Call Trace:
15f4a7cc8: [<6006bba2>] __module_text_address+0x14/0x5a
15f4a7ce0: [<6001c4af>] panic_exit+0x3a/0x58
15f4a7cf0: [<6004e962>] __kernel_text_address+0x30/0x5c
15f4a7d10: [<60056554>] notifier_call_chain+0x32/0x5c
15f4a7d38: [<600182c0>] _init+0x7e0/0x8b0
15f4a7d50: [<6005658e>] __atomic_notifier_call_chain+0x10/0x12
15f4a7d60: [<600565a6>] atomic_notifier_call_chain+0x16/0x18
15f4a7d70: [<602476cd>] panic+0x178/0x2a7
15f4a7da8: [<60247555>] panic+0x0/0x2a7
15f4a7de8: [<602477fc>] printk+0x0/0xa0
15f4a7e60: [<600182c0>] _init+0x7e0/0x8b0
15f4a7e80: [<6018ae95>] blk_flush_plug_list+0x19f/0x260
15f4a7ec0: [<6004678f>] sigsuspend+0x0/0x9e
15f4a7ed0: [<600182c0>] _init+0x7e0/0x8b0
15f4a7ef0: [<6024bb90>] schedule+0x6a/0x78
15f4a7f00: [<6004532e>] set_current_blocked+0x17/0x19
15f4a7f10: [<600467eb>] sigsuspend+0x5c/0x9e
15f4a7f30: [<6001e726>] winch_thread+0x204/0x242
15f4a7fd0: [<6001e522>] winch_thread+0x0/0x242
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
</pre>Peter Butler2013-04-03T04:11:18[PATCH] UM: fix make headers_install after UAPI headerinstallation
http://comments.gmane.org/gmane.linux.uml.devel/13799
<pre>Commit 10b63956 (UAPI: Plumb the UAPI Kbuilds into the user
header installation and checking) breaks UML make headers_install with
the following:
$ ARCH=um make headers_install
CHK include/generated/uapi/linux/version.h
UPD include/generated/uapi/linux/version.h
HOSTCC scripts/basic/fixdep
WRAP arch/um/include/generated/asm/bug.h
[snip]
WRAP arch/um/include/generated/asm/trace_clock.h
SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_64.h
SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_x32.h
SYSTBL arch/x86/syscalls/../include/generated/asm/syscalls_32.h
HOSTCC scripts/unifdef
Makefile:912: *** Headers not exportable for the um architecture. Stop.
zsh: exit 2 ARCH=um make headers_install
The reason for that is because the top-level Makefile does the
following:
$(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \
$(error Headers not exportable for the $(SRCARCH) architecture))
we end-up in the else part of the $(if) statement because UML still uses
the old path in arch/um/include/asm/Kbuild. This patch fixes the issue
by moving the header files to be in arch/um/include/uapi/asm/ thus
making headers_install (and other make targets checking for uapi) to
succeed.
Signed-off-by: Florian Fainelli <florian< at >openwrt.org>
---
Richard, this is applicable to 3.7 onwards, I will submit per-version patches
if you want to. Thanks!
arch/um/include/{ => uapi}/asm/Kbuild | 0
arch/um/include/{ => uapi}/asm/a.out-core.h | 0
arch/um/include/{ => uapi}/asm/bugs.h | 0
arch/um/include/{ => uapi}/asm/cache.h | 0
arch/um/include/{ => uapi}/asm/common.lds.S | 0
arch/um/include/{ => uapi}/asm/dma.h | 0
arch/um/include/{ => uapi}/asm/fixmap.h | 0
arch/um/include/{ => uapi}/asm/irq.h | 0
arch/um/include/{ => uapi}/asm/irqflags.h | 0
arch/um/include/{ => uapi}/asm/kmap_types.h | 0
arch/um/include/{ => uapi}/asm/kvm_para.h | 0
arch/um/include/{ => uapi}/asm/mmu.h | 0
arch/um/include/{ => uapi}/asm/mmu_context.h | 0
arch/um/include/{ => uapi}/asm/page.h | 0
arch/um/include/{ => uapi}/asm/pgalloc.h | 0
arch/um/include/{ => uapi}/asm/pgtable-2level.h | 0
arch/um/include/{ => uapi}/asm/pgtable-3level.h | 0
arch/um/include/{ => uapi}/asm/pgtable.h | 0
arch/um/include/{ => uapi}/asm/processor-generic.h | 0
arch/um/include/{ => uapi}/asm/ptrace-generic.h | 0
arch/um/include/{ => uapi}/asm/setup.h | 0
arch/um/include/{ => uapi}/asm/smp.h | 0
arch/um/include/{ => uapi}/asm/sysrq.h | 0
arch/um/include/{ => uapi}/asm/thread_info.h | 0
arch/um/include/{ => uapi}/asm/timex.h | 0
arch/um/include/{ => uapi}/asm/tlb.h | 0
arch/um/include/{ => uapi}/asm/tlbflush.h | 0
arch/um/include/{ => uapi}/asm/uaccess.h | 0
28 files changed, 0 insertions(+), 0 deletions(-)
rename arch/um/include/{ => uapi}/asm/Kbuild (100%)
rename arch/um/include/{ => uapi}/asm/a.out-core.h (100%)
rename arch/um/include/{ => uapi}/asm/bugs.h (100%)
rename arch/um/include/{ => uapi}/asm/cache.h (100%)
rename arch/um/include/{ => uapi}/asm/common.lds.S (100%)
rename arch/um/include/{ => uapi}/asm/dma.h (100%)
rename arch/um/include/{ => uapi}/asm/fixmap.h (100%)
rename arch/um/include/{ => uapi}/asm/irq.h (100%)
rename arch/um/include/{ => uapi}/asm/irqflags.h (100%)
rename arch/um/include/{ => uapi}/asm/kmap_types.h (100%)
rename arch/um/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/um/include/{ => uapi}/asm/mmu.h (100%)
rename arch/um/include/{ => uapi}/asm/mmu_context.h (100%)
rename arch/um/include/{ => uapi}/asm/page.h (100%)
rename arch/um/include/{ => uapi}/asm/pgalloc.h (100%)
rename arch/um/include/{ => uapi}/asm/pgtable-2level.h (100%)
rename arch/um/include/{ => uapi}/asm/pgtable-3level.h (100%)
rename arch/um/include/{ => uapi}/asm/pgtable.h (100%)
rename arch/um/include/{ => uapi}/asm/processor-generic.h (100%)
rename arch/um/include/{ => uapi}/asm/ptrace-generic.h (100%)
rename arch/um/include/{ => uapi}/asm/setup.h (100%)
rename arch/um/include/{ => uapi}/asm/smp.h (100%)
rename arch/um/include/{ => uapi}/asm/sysrq.h (100%)
rename arch/um/include/{ => uapi}/asm/thread_info.h (100%)
rename arch/um/include/{ => uapi}/asm/timex.h (100%)
rename arch/um/include/{ => uapi}/asm/tlb.h (100%)
rename arch/um/include/{ => uapi}/asm/tlbflush.h (100%)
rename arch/um/include/{ => uapi}/asm/uaccess.h (100%)
diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/uapi/asm/Kbuild
similarity index 100%
rename from arch/um/include/asm/Kbuild
rename to arch/um/include/uapi/asm/Kbuild
diff --git a/arch/um/include/asm/a.out-core.h b/arch/um/include/uapi/asm/a.out-core.h
similarity index 100%
rename from arch/um/include/asm/a.out-core.h
rename to arch/um/include/uapi/asm/a.out-core.h
diff --git a/arch/um/include/asm/bugs.h b/arch/um/include/uapi/asm/bugs.h
similarity index 100%
rename from arch/um/include/asm/bugs.h
rename to arch/um/include/uapi/asm/bugs.h
diff --git a/arch/um/include/asm/cache.h b/arch/um/include/uapi/asm/cache.h
similarity index 100%
rename from arch/um/include/asm/cache.h
rename to arch/um/include/uapi/asm/cache.h
diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/uapi/asm/common.lds.S
similarity index 100%
rename from arch/um/include/asm/common.lds.S
rename to arch/um/include/uapi/asm/common.lds.S
diff --git a/arch/um/include/asm/dma.h b/arch/um/include/uapi/asm/dma.h
similarity index 100%
rename from arch/um/include/asm/dma.h
rename to arch/um/include/uapi/asm/dma.h
diff --git a/arch/um/include/asm/fixmap.h b/arch/um/include/uapi/asm/fixmap.h
similarity index 100%
rename from arch/um/include/asm/fixmap.h
rename to arch/um/include/uapi/asm/fixmap.h
diff --git a/arch/um/include/asm/irq.h b/arch/um/include/uapi/asm/irq.h
similarity index 100%
rename from arch/um/include/asm/irq.h
rename to arch/um/include/uapi/asm/irq.h
diff --git a/arch/um/include/asm/irqflags.h b/arch/um/include/uapi/asm/irqflags.h
similarity index 100%
rename from arch/um/include/asm/irqflags.h
rename to arch/um/include/uapi/asm/irqflags.h
diff --git a/arch/um/include/asm/kmap_types.h b/arch/um/include/uapi/asm/kmap_types.h
similarity index 100%
rename from arch/um/include/asm/kmap_types.h
rename to arch/um/include/uapi/asm/kmap_types.h
diff --git a/arch/um/include/asm/kvm_para.h b/arch/um/include/uapi/asm/kvm_para.h
similarity index 100%
rename from arch/um/include/asm/kvm_para.h
rename to arch/um/include/uapi/asm/kvm_para.h
diff --git a/arch/um/include/asm/mmu.h b/arch/um/include/uapi/asm/mmu.h
similarity index 100%
rename from arch/um/include/asm/mmu.h
rename to arch/um/include/uapi/asm/mmu.h
diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/uapi/asm/mmu_context.h
similarity index 100%
rename from arch/um/include/asm/mmu_context.h
rename to arch/um/include/uapi/asm/mmu_context.h
diff --git a/arch/um/include/asm/page.h b/arch/um/include/uapi/asm/page.h
similarity index 100%
rename from arch/um/include/asm/page.h
rename to arch/um/include/uapi/asm/page.h
diff --git a/arch/um/include/asm/pgalloc.h b/arch/um/include/uapi/asm/pgalloc.h
similarity index 100%
rename from arch/um/include/asm/pgalloc.h
rename to arch/um/include/uapi/asm/pgalloc.h
diff --git a/arch/um/include/asm/pgtable-2level.h b/arch/um/include/uapi/asm/pgtable-2level.h
similarity index 100%
rename from arch/um/include/asm/pgtable-2level.h
rename to arch/um/include/uapi/asm/pgtable-2level.h
diff --git a/arch/um/include/asm/pgtable-3level.h b/arch/um/include/uapi/asm/pgtable-3level.h
similarity index 100%
rename from arch/um/include/asm/pgtable-3level.h
rename to arch/um/include/uapi/asm/pgtable-3level.h
diff --git a/arch/um/include/asm/pgtable.h b/arch/um/include/uapi/asm/pgtable.h
similarity index 100%
rename from arch/um/include/asm/pgtable.h
rename to arch/um/include/uapi/asm/pgtable.h
diff --git a/arch/um/include/asm/processor-generic.h b/arch/um/include/uapi/asm/processor-generic.h
similarity index 100%
rename from arch/um/include/asm/processor-generic.h
rename to arch/um/include/uapi/asm/processor-generic.h
diff --git a/arch/um/include/asm/ptrace-generic.h b/arch/um/include/uapi/asm/ptrace-generic.h
similarity index 100%
rename from arch/um/include/asm/ptrace-generic.h
rename to arch/um/include/uapi/asm/ptrace-generic.h
diff --git a/arch/um/include/asm/setup.h b/arch/um/include/uapi/asm/setup.h
similarity index 100%
rename from arch/um/include/asm/setup.h
rename to arch/um/include/uapi/asm/setup.h
diff --git a/arch/um/include/asm/smp.h b/arch/um/include/uapi/asm/smp.h
similarity index 100%
rename from arch/um/include/asm/smp.h
rename to arch/um/include/uapi/asm/smp.h
diff --git a/arch/um/include/asm/sysrq.h b/arch/um/include/uapi/asm/sysrq.h
similarity index 100%
rename from arch/um/include/asm/sysrq.h
rename to arch/um/include/uapi/asm/sysrq.h
diff --git a/arch/um/include/asm/thread_info.h b/arch/um/include/uapi/asm/thread_info.h
similarity index 100%
rename from arch/um/include/asm/thread_info.h
rename to arch/um/include/uapi/asm/thread_info.h
diff --git a/arch/um/include/asm/timex.h b/arch/um/include/uapi/asm/timex.h
similarity index 100%
rename from arch/um/include/asm/timex.h
rename to arch/um/include/uapi/asm/timex.h
diff --git a/arch/um/include/asm/tlb.h b/arch/um/include/uapi/asm/tlb.h
similarity index 100%
rename from arch/um/include/asm/tlb.h
rename to arch/um/include/uapi/asm/tlb.h
diff --git a/arch/um/include/asm/tlbflush.h b/arch/um/include/uapi/asm/tlbflush.h
similarity index 100%
rename from arch/um/include/asm/tlbflush.h
rename to arch/um/include/uapi/asm/tlbflush.h
diff --git a/arch/um/include/asm/uaccess.h b/arch/um/include/uapi/asm/uaccess.h
similarity index 100%
rename from arch/um/include/asm/uaccess.h
rename to arch/um/include/uapi/asm/uaccess.h
</pre>Florian Fainelli2013-03-17T19:43:10[PATCH] Linux 3.9-rc2, ARCH=um does not build
http://comments.gmane.org/gmane.linux.uml.devel/13797
<pre>Hi,
$ make ARCH=um defconfig
$ make ARCH=um
...
arch/um/os-Linux/signal.c:18:8: error: conflicting types for ‘sig_info’
In file included from arch/um/os-Linux/signal.c:12:0:
/repos/linux/arch/um/include/shared/as-layout.h:64:15: note: previous declaration of ‘sig_info’ was here
arch/um/os-Linux/signal.c:19:2: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:19:2: warning: (near initialization for ‘sig_info[5]’) [enabled by default]
arch/um/os-Linux/signal.c:20:2: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:20:2: warning: (near initialization for ‘sig_info[8]’) [enabled by default]
arch/um/os-Linux/signal.c:21:2: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:21:2: warning: (near initialization for ‘sig_info[4]’) [enabled by default]
arch/um/os-Linux/signal.c:22:2: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:22:2: warning: (near initialization for ‘sig_info[28]’) [enabled by default]
arch/um/os-Linux/signal.c:23:2: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:23:2: warning: (near initialization for ‘sig_info[7]’) [enabled by default]
arch/um/os-Linux/signal.c:24:2: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:24:2: warning: (near initialization for ‘sig_info[11]’) [enabled by default]
arch/um/os-Linux/signal.c:25:2: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:25:2: warning: (near initialization for ‘sig_info[29]’) [enabled by default]
arch/um/os-Linux/signal.c:26:2: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:26:2: warning: (near initialization for ‘sig_info[26]’) [enabled by default]
arch/um/os-Linux/signal.c:133:1: warning: initialization from incompatible pointer type [enabled by default]
arch/um/os-Linux/signal.c:133:1: warning: (near initialization for ‘handlers[26]’) [enabled by default]
make[1]: *** [arch/um/os-Linux/signal.o] Error 1
Configuration
=============
$ gcc --version
gcc (GCC) 4.7.2
$ pacman -Q glibc
glibc 2.17-3
$ git rev-parse HEAD
f6161aa153581da4a3867a2d1a7caf4be19b6ec9
Patch
=====
This problem (and the fix) was already known in October, 2012. Any ideas why the patch
wasn't merged upstream?
The following patch is borrowed from Arch Linux AUR.
(https://aur.archlinux.org/packages/li/linux-usermode/PKGBUILD)
diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
index b1469fe..788d685 100644
--- a/arch/um/os-Linux/signal.c
+++ b/arch/um/os-Linux/signal.c
< at >< at > -15,7 +15,7 < at >< at >
#include <sysdep/mcontext.h>
#include "internal.h"
-void (*sig_info[NSIG])(int, siginfo_t *, struct uml_pt_regs *) = {
+void (*sig_info[NSIG])(int, struct siginfo *, struct uml_pt_regs *) = {
[SIGTRAP] = relay_signal,
[SIGFPE] = relay_signal,
[SIGILL] = relay_signal,
< at >< at > -25,7 +25,7 < at >< at > void (*sig_info[NSIG])(int, siginfo_t *, struct uml_pt_regs *) = {
[SIGIO] = sigio_handler,
[SIGVTALRM] = timer_handler };
-static void sig_handler_common(int sig, siginfo_t *si, mcontext_t *mc)
+static void sig_handler_common(int sig, struct siginfo *si, mcontext_t *mc)
{
struct uml_pt_regs r;
int save_errno = errno;
< at >< at > -61,7 +61,7 < at >< at > static void sig_handler_common(int sig, siginfo_t *si, mcontext_t *mc)
static int signals_enabled;
static unsigned int signals_pending;
-void sig_handler(int sig, siginfo_t *si, mcontext_t *mc)
+void sig_handler(int sig, struct siginfo *si, mcontext_t *mc)
{
int enabled;
< at >< at > -120,7 +120,7 < at >< at > void set_sigstack(void *sig_stack, int size)
panic("enabling signal stack failed, errno = %d\n", errno);
}
-static void (*handlers[_NSIG])(int sig, siginfo_t *si, mcontext_t *mc) = {
+static void (*handlers[_NSIG])(int sig, struct siginfo *si, mcontext_t *mc) = {
[SIGSEGV] = sig_handler,
[SIGBUS] = sig_handler,
[SIGILL] = sig_handler,
< at >< at > -133,7 +133,7 < at >< at > static void (*handlers[_NSIG])(int sig, siginfo_t *si, mcontext_t *mc) = {
};
-static void hard_handler(int sig, siginfo_t *si, void *p)
+static void hard_handler(int sig, struct siginfo *si, void *p)
{
struct ucontext *uc = p;
mcontext_t *mc = &uc->uc_mcontext;
diff --git a/arch/um/os-Linux/start_up.c b/arch/um/os-Linux/start_up.c
index da4b9e9..f9f6041 100644
--- a/arch/um/os-Linux/start_up.c
+++ b/arch/um/os-Linux/start_up.c
< at >< at > -1,3 +1,4 < at >< at >
+#include <sys/resource.h>
/*
* Copyright (C) 2000 - 2007 Jeff Dike (jdike< at >{addtoit,linux.intel}.com)
* Licensed under the GPL
--
Dhiru
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
</pre>Dhiru Kholia2013-03-11T08:53:21Adding support for YAFFS2 rootfs
http://comments.gmane.org/gmane.linux.uml.devel/13791
<pre>Hi,
I am interested in adding support for using YAFFS2 images as a rootfs.
Any pointers on how to get started on this?
-Earlence
------------------------------------------------------------------------------
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_feb_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
</pre>Earlence Fernandes2013-02-19T03:28:09[PATCH 1/1] um: Fix broken IRQs if SPARSE_IRQ isselected
http://comments.gmane.org/gmane.linux.uml.devel/13790
<pre>um: Kconfig.common: enabled SPARSE_IRQ.
um: kernel/irq: arch_probe_nr_irqs is implemented to prevent use of the default.
Signed-off-by: Sinan Nalkaya <sardok< at >gmail.com>
---
arch/um/Kconfig.common | 1 +
arch/um/kernel/irq.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 648121b..8335fdd 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
< at >< at > -12,6 +12,7 < at >< at > config UML
select GENERIC_CPU_DEVICES
select GENERIC_IO
select GENERIC_CLOCKEVENTS
+select SPARSE_IRQ
config MMU
bool
diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index 36e12f0..93615f0 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
< at >< at > -356,6 +356,13 < at >< at > void __init init_IRQ(void)
irq_set_chip_and_handler(i, &normal_irq_type, handle_edge_irq);
}
+#ifdef CONFIG_SPARSE_IRQ
+int __init arch_probe_nr_irqs(void)
+{
+return NR_IRQS;
+}
+#endif
+
/*
* IRQ stack entry and exit:
*
</pre>Sinan Nalkaya2013-02-06T23:39:00[PATCH] uml: Always use 3_LEVEL_PGTABLES on x86_64
http://comments.gmane.org/gmane.linux.uml.devel/13783
<pre>From: Tristan Schmelcher <tschmelcher< at >google.com>
Use 3_LEVEL_PGTABLES on x86_64 even if EXPERIMENTAL is off, since
otherwise UML does not work. Applies to 3.7.1.
Signed-off-by: Tristan Schmelcher <tschmelcher< at >google.com>
---
I'm not clear on the patch procedure for UML. Assuming you guys like
this, do I send it directly to Linus?
--- linux-3.7.1/arch/x86/um/Kconfig.orig 2013-01-23
15:50:12.671408478 -0800
+++ linux-3.7.1/arch/x86/um/Kconfig 2013-01-23 15:44:38.321878377 -0800
< at >< at > -39,7 +39,7 < at >< at > config RWSEM_GENERIC_SPINLOCK
config 3_LEVEL_PGTABLES
bool "Three-level pagetables (EXPERIMENTAL)" if !64BIT
default 64BIT
- depends on EXPERIMENTAL
+ depends on EXPERIMENTAL || 64BIT
help
Three-level pagetables will let UML have more than 4G of physical
memory. All the memory that can't be mapped directly will be treated
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
</pre>Tristan Schmelcher2013-01-24T00:22:43UML Network Related Crashing
http://comments.gmane.org/gmane.linux.uml.devel/13780
<pre>
I have experimented further with the network related crashing problem that I
have had for some time with UML.
I have been using 3.8.0-rc3 UML kernels with Debian root filesystems.
I have been running two UML instances side-by-side on the same host and
communicationg via mcast networking.
My current testing uses a 64 bit UML from which i copy data using rsync
(because this is how I found the original problem).
I seem to be able to copy from 64 bit to 64 bit, but when I copy from 64 bit
to 32 bit I get a crash.
The oringinal problem that I had was a 32 bit UML that I access via a real
ethernet network connection and it crashes occasionally. i find that I can
crash it regularly bu rsyncing data from it.
I can therefore say that the problem does not seems to occur when using both
mcast and tuntap networking; and when the bulk of the network traffic is
received or transmitted.
It does appear to be a problem with the 32 bit variant and not the 64 bit.
As an aside, I also find that I can crash the 32 bit UML by rsyncing between
the UML and the host via a hostfs mount. I have a copy of the crash output for
this if it is of any interest. I mention this in case there could be a link,
but my current principle concern is to cure the networking problem.
Here is what happens when it crashes:
map/< at >DEB1-32:~# rsync --archive --delete --progress 10.0.10.30:/var/imap/
/var/imap/
The authenticity of host '10.0.10.30 (10.0.10.30)' can't be established.
RSA key fingerprint is b8:5d:e0:69:bc:61:d9:88:e4:12:80:84:c9:94:81:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.10.30' (RSA) to the list of known hosts.
receiving incremental file list
./
.bash_history
1970 100% 1.88MB/s 0:00:00 (xfer#1, to-check=1005/1007)
config/
config/annotations.db
144 100% 3.70kB/s 0:00:00 (xfer#2, to-check=1356/1362)
config/deliver.db
0 0% 0.00kB/s 0:00:00 ------------[ cut here ]------------
WARNING: at net/core/skbuff.c:573 skb_release_head_state+0x60/0x6c()
Modules linked in:
2367232c: [<082050f7>] dump_stack+0x16/0x1a
23672340: [<08070515>] warn_slowpath_common+0x48/0x5e
23672358: [<08070540>] warn_slowpath_null+0x15/0x19
23672368: [<081a1f93>] skb_release_head_state+0x60/0x6c
23672380: [<081a3705>] __kfree_skb+0xe/0x72
2367238c: [<081a3791>] consume_skb+0x28/0x2b
23672398: [<080615e2>] uml_net_start_xmit+0xd5/0xdf
236723b8: [<081ac85b>] dev_hard_start_xmit+0x26c/0x374
236723e4: [<081bac2c>] sch_direct_xmit+0x35/0x10d
23672408: [<081acb0b>] dev_queue_xmit+0xd6/0x203
23672438: [<081c519a>] ip_finish_output+0x272/0x2d9
23672470: [<081c5f9b>] ip_output+0x4b/0x50
23672484: [<081c5a18>] ip_local_out+0x1d/0x23
23672494: [<081c5ccd>] ip_queue_xmit+0x2af/0x2f7
236724d0: [<081d70a7>] tcp_transmit_skb+0x697/0x6fb
23672520: [<081d8e65>] tcp_send_ack+0xcc/0xd4
23672534: [<081cfabb>] __tcp_ack_snd_check+0x42/0x7a
23672548: [<081d47f1>] tcp_rcv_established+0x36e/0x594
23672570: [<081da56f>] tcp_v4_do_rcv+0x5d/0x18e
2367259c: [<081dcbcc>] tcp_v4_rcv+0x6a0/0x6f7
236725d4: [<081c2195>] ip_local_deliver+0x11d/0x1b8
236725f0: [<081c25f7>] ip_rcv+0x3c7/0x410
23672608: [<081aa94e>] __netif_receive_skb+0x34a/0x3e4
23672650: [<081aaa47>] process_backlog+0x5f/0xe1
2367266c: [<081aadd5>] net_rx_action+0x49/0x121
23672690: [<080757c9>] __do_softirq+0x84/0x129
236726b8: [<080758d0>] do_softirq+0x30/0x3c
236726c8: [<08075a6a>] irq_exit+0x35/0x6d
236726d4: [<0805af16>] do_IRQ+0x24/0x34
236726e4: [<0805af68>] sigio_handler+0x42/0x56
236726f8: [<08068db7>] sig_handler_common+0x79/0x8c
23672978: [<08068d2d>] unblock_signals+0x48/0x59
23672984: [<0808accf>] finish_task_switch.isra.63+0x1b/0x51
2367299c: [<08208103>] __schedule+0x234/0x28a
236729c0: [<08208250>] schedule+0x57/0x59
236729cc: [<082078ce>] schedule_hrtimeout_range_clock+0x33/0x128
23672a18: [<082079d6>] schedule_hrtimeout_range+0x13/0x15
23672a30: [<080d497f>] poll_schedule_timeout+0x2a/0x51
23672a4c: [<080d5136>] do_select+0x4cd/0x504
23672d3c: [<080d539b>] core_sys_select+0x22e/0x24b
23672e7c: [<080d5416>] sys_select+0x5e/0x86
23672eb0: [<0805d742>] handle_syscall+0x6a/0x80
23672ef4: [<0806aee8>] userspace+0x362/0x488
23672fe4: [<0805b3d6>] fork_handler+0x56/0x5b
23672ffc: [<00746f6f>] 0x746f6f
---[ end trace 8e9ba3f2efd7a2c6 ]---
------------[ cut here ]------------
WARNING: at kernel/softirq.c:160 local_bh_enable+0x2f/0x83()
Modules linked in:
236723f4: [<082050f7>] dump_stack+0x16/0x1a
23672408: [<08070515>] warn_slowpath_common+0x48/0x5e
23672420: [<08070540>] warn_slowpath_null+0x15/0x19
23672430: [<0807598e>] local_bh_enable+0x2f/0x83
23672444: [<081c51b1>] ip_finish_output+0x289/0x2d9
23672470: [<081c5f9b>] ip_output+0x4b/0x50
23672484: [<081c5a18>] ip_local_out+0x1d/0x23
23672494: [<081c5ccd>] ip_queue_xmit+0x2af/0x2f7
236724d0: [<081d70a7>] tcp_transmit_skb+0x697/0x6fb
23672520: [<081d8e65>] tcp_send_ack+0xcc/0xd4
23672534: [<081cfabb>] __tcp_ack_snd_check+0x42/0x7a
23672548: [<081d47f1>] tcp_rcv_established+0x36e/0x594
23672570: [<081da56f>] tcp_v4_do_rcv+0x5d/0x18e
2367259c: [<081dcbcc>] tcp_v4_rcv+0x6a0/0x6f7
236725d4: [<081c2195>] ip_local_deliver+0x11d/0x1b8
236725f0: [<081c25f7>] ip_rcv+0x3c7/0x410
23672608: [<081aa94e>] __netif_receive_skb+0x34a/0x3e4
23672650: [<081aaa47>] process_backlog+0x5f/0xe1
2367266c: [<081aadd5>] net_rx_action+0x49/0x121
23672690: [<080757c9>] __do_softirq+0x84/0x129
236726b8: [<080758d0>] do_softirq+0x30/0x3c
236726c8: [<08075a6a>] irq_exit+0x35/0x6d
236726d4: [<0805af16>] do_IRQ+0x24/0x34
236726e4: [<0805af68>] sigio_handler+0x42/0x56
236726f8: [<08068db7>] sig_handler_common+0x79/0x8c
23672978: [<08068d2d>] unblock_signals+0x48/0x59
23672984: [<0808accf>] finish_task_switch.isra.63+0x1b/0x51
2367299c: [<08208103>] __schedule+0x234/0x28a
236729c0: [<08208250>] schedule+0x57/0x59
236729cc: [<082078ce>] schedule_hrtimeout_range_clock+0x33/0x128
23672a18: [<082079d6>] schedule_hrtimeout_range+0x13/0x15
23672a30: [<080d497f>] poll_schedule_timeout+0x2a/0x51
23672a4c: [<080d5136>] do_select+0x4cd/0x504
23672d3c: [<080d539b>] core_sys_select+0x22e/0x24b
23672e7c: [<080d5416>] sys_select+0x5e/0x86
23672eb0: [<0805d742>] handle_syscall+0x6a/0x80
23672ef4: [<0806aee8>] userspace+0x362/0x488
23672fe4: [<0805b3d6>] fork_handler+0x56/0x5b
23672ffc: [<00746f6f>] 0x746f6f
---[ end trace 8e9ba3f2efd7a2c7 ]---
huh, entered softirq 3 NET_RX 081aad8c preempt_count 00000100, exited with
fffffe01?
EIP: 0023:[<080d9e01>] CPU: 0 Tainted: G W ESP: 002b:23672a44
EFLAGS: 00010202
Tainted: G W
EAX: 00082a40 EBX: 23672ac4 ECX: 00fffffe EDX: 00000003
ESI: 00000005 EDI: 23672d54 EBP: 23672a50 DS: 002b ES: 002b
082a4750: [<0806d29a>] show_regs+0xc0/0xc6
082a477c: [<0805ceef>] segv+0x57/0x218
082a481c: [<0805d102>] segv_handler+0x52/0x5d
082a4848: [<08068db7>] sig_handler_common+0x79/0x8c
082a4ac8: [<08068ea5>] sig_handler+0x34/0x43
082a4ad4: [<08068b3a>] hard_handler+0x5a/0x88
082a4afc: [<ffffe410>] 0xffffe410
Kernel panic - not syncing: Segfault with no mm
082a474c: [<082050f7>] dump_stack+0x16/0x1a
082a4760: [<08205181>] panic+0x67/0x149
082a4778: [<0805cef9>] segv+0x61/0x218
082a481c: [<0805d102>] segv_handler+0x52/0x5d
082a4848: [<08068db7>] sig_handler_common+0x79/0x8c
082a4ac8: [<08068ea5>] sig_handler+0x34/0x43
082a4ad4: [<08068b3a>] hard_handler+0x5a/0x88
082a4afc: [<ffffe410>] 0xffffe410
EIP: 0000:[<00000000>] CPU: 0 Tainted: G W EFLAGS: 00000000
Tainted: G W
EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
082a46bc: [<0806d29a>] show_regs+0xc0/0xc6
082a46e8: [<0805d32b>] panic_exit+0x20/0x36
082a46fc: [<08088c3b>] notifier_call_chain+0x20/0x4b
082a4724: [<08088c7d>] __atomic_notifier_call_chain+0x17/0x19
082a4734: [<08088c94>] atomic_notifier_call_chain+0x15/0x17
082a4750: [<08205199>] panic+0x7f/0x149
082a4778: [<0805cef9>] segv+0x61/0x218
082a481c: [<0805d102>] segv_handler+0x52/0x5d
082a4848: [<08068db7>] sig_handler_common+0x79/0x8c
082a4ac8: [<08068ea5>] sig_handler+0x34/0x43
082a4ad4: [<08068b3a>] hard_handler+0x5a/0x88
082a4afc: [<ffffe410>] 0xffffe410
Terminated
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
</pre>Dave Humphreys (Bob2013-01-19T18:59:14"Couldn't grant pty"
http://comments.gmane.org/gmane.linux.uml.devel/13768
<pre>Maybe someone can help me with this...
I have been trying to tie down an issue that I have with "UML Network
Related Crashing" so that Richard can reproduce my problem.
I am currently trying to use both a 32 bit UML and a 64 bit UML to run
Debian root filesystems, 32 bit and 64 bit respectively.
I am running on a 64 bit machine, with 64 bit kernel incorporating 32
bit compatibility.
The 32 bit environment that I am working in for the compilation of 32
bit UML kernels and running them is a place to which I bind mount /dev,
/sys, /proc to their primary locations; chroot to the top of this
structure; execute 'linux32'; and then work as though I was on a 32 bit
machine.
When I try to run the 32 bit UML kernel with the 32 bit Debian root
filesystem image, it boots to the login prompt, but I can't type
anything at the prompt. The UML kernel is displaying messages:
"Couldn't grant pty - errno = -2"
I have looked into this and I see that this message comes from
'arch/um/os-Linux/tty.c'; due to a non-zero result from
'initial_thread_cb( ... )', which is in 'arch/um/kernel/process.c';
which calls 'initial_thread_cb_skas( ... )', which is in
'arch/um/os-Linux/skas/process.c'.
The structure that contains the original non-zero result is not directly
manipulated, so I can see that this result comes from some different
thread and the working of this is not evident to the uninitiated like
myself.
Clearly, the 32 bit UML kernel must work with the 32 bit Debian
filesystem image for other people.
Therefore there must be something about the environment that I am
working in that causes this problem.
Is this a result of a UML bug that makes it dependent on something
unexpected? Or is it something that I'm doing wrong?
What should "Couldn't grant pty - errno = -2" be telling me?
Regards,
David
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
</pre>Dave (Bob2013-01-12T09:55:05File corruption with hostfs and GNU Gold linker
http://comments.gmane.org/gmane.linux.uml.devel/13758
<pre>Hello,
I am using UML as part of a hermetic build system and I have encountered an
odd file corruption problem with the GNU Gold linker. When linking a binary
inside a UML VM with Gold, if the output path is on a hostfs mount then all
bytes in the output file produced by Gold are zero. However, the size of
the output file is correct and the debugging output from running gold with
--debug suggests that everything is working, so it seems like the content
is being produced by Gold correctly but the file ends up containing all
zeros instead. It has happened 100% of the time so far and it seems to be
independent of the linker command line or input files.
Are there any known issues where hostfs file content could end up as all
zeros?
Repros on both 2.6.34.13 and 3.7.1. I am using GNU binutils 2.21.1.
Much thanks for any help,
Tristan
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
</pre>Tristan Schmelcher2013-01-08T01:55:29UML Network Related Crashing
http://comments.gmane.org/gmane.linux.uml.devel/13756
<pre>I note that my message sent yesterday ended up heavily truncated, so I have
turned on the line-wrap for this one. Sorry about that.
What I was trying to say is that I can repeatedly crash UML by exercising the
networking heavily as a result of rsync'ing data to and from.
I also said that I have an older kernel (3.1.0) UML (which operates reasonably
successfully under most circumstances) that I access over the Internet. If I
try to rsync data from it, I can crash it reliably after 5 or 10 minutes.
This 3.1.0 UML was the first step in an upgrade to a much older UML based
virtual server that has been in operation for about a decade without any
trouble. The main objective of upgrading was to take advantage of BTRFS, but I
have noticed that the UML is less reliable and crashes occasionally. This UML
is not actually using BTRFS, it has exactly the same disk images as the
historic one, so the issue is not, I believe, related to BTRFS, but some other
aspect of the newer kernel. I now believe that the reliability issue is
probably related to the networking issue.
I have tried setting up a second, 3.8.0-rc2 based, UML on the same host and
rsync'd between them over mcast network interfaces. I get crashing on one or
the other UML.
I have found that I don't get much information about the failures. When things
go wrong, the UML is completely locked up and is not responsive either from
the session in which it was started, or via uml_mconsole. Things usually seem
to have locked-up before any message comes into view. Once or twice I have
seen the line that says '---[ cut here ]---', showing that something was
trying to come out, but whatever message there was does not become visible.
I have set up two 3.8.0-rc2 based UMLs on a local machine and rsync data over
mcast network interfaces. I'm hoping that I get something out that will help
someone to identify the problem.
The latest result that has some information is:
------------[ cut here ]------------0:00
WARNING: at net/core/skbuff.c:573 skb_release_head_state+0x60/0xba()
Modules linked in:
but that is as much as I get. This UML instance is now totally locked up. This
behaviour is consistent with the other failures I get on my older UML.
Previous conversations suggest that it is known that there is some network
related problem in UML, but it has not been tracked down. I feel that it
rather defeats the object if a UML instance cannot run reliably with
networking. I will carry on with my exercising of my UMLs and report anything
that I find.
Regards,
David Humphreys
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
</pre>Dave Humphreys (Bob2013-01-06T12:16:02Search EngineSearch the mailing list at Gmanequery
http://search.gmane.org/?group=$group=gmane.linux.uml.devel