[CRIU] ARM: SIGSEGV in parasite code

[Chanho Park]

Hi Alexander,

I found data aborts are sometimes occurred in infected code.
We can't dump correctly due to this issue.
It couldn't be resolved even though applying your commit '9a37454'.

I attached a core dump file and a test program.
And I also added below kernel command line option to debug page fault.
	user_debug=8

It generated below backtrace log.

[  445.430000] test_test: unhandled page fault (11) at 0x00000002, code
0x817
[  445.430000] pgd = ee58c000
[  445.430000] [00000002] *pgd=6e6a6831, *pte=00000000, *ppte=00000000
[  445.440000] 
[  445.440000] CPU: 1 PID: 2970 Comm: test_test Not tainted
3.10.0-rc1-00289-gf5f8b48-dirty #158
[  445.450000] task: ee72e800 ti: eebb4000 task.ti: eebb4000
[  445.455000] PC is at 0xb6f27fe0
[  445.455000] LR is at 0xb6f27b84
[  445.460000] pc : [<b6f27fe0>]    lr : [<b6f27b84>]    psr: 80000010
[  445.460000] sp : b6f2b484  ip : 00000000  fp : b6f29594
[  445.470000] r10: b6f27f9c  r9 : b6f29594  r8 : b6f27f8c
[  445.475000] r7 : befd7cf0  r6 : 66667d10  r5 : 00000000  r4 : b6f2b488
[  445.485000] r3 : 0000003a  r2 : 00000002  r1 : b6f29548  r0 : 00000003
[  445.490000] Flags: Nzcv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment
user
[  445.495000] Control: 10c5387d  Table: 6e58c04a  DAC: 00000015
[  445.505000] CPU: 1 PID: 2970 Comm: test_test Not tainted
3.10.0-rc1-00289-gf5f8b48-dirty #158
[  445.510000] [<c00166ec>] (unwind_backtrace+0x0/0x13c) from [<c0013444>]
(show_stack+0x10/0x14)
[  445.520000] [<c0013444>] (show_stack+0x10/0x14) from [<c001dbe0>]
(__do_user_fault+0xc4/0xc8)
[  445.530000] [<c001dbe0>] (__do_user_fault+0xc4/0xc8) from [<c001de70>]
(do_page_fault+0x208/0x38c)
[  445.535000] [<c001de70>] (do_page_fault+0x208/0x38c) from [<c00084a4>]
(do_DataAbort+0x38/0x98)
[  445.545000] [<c00084a4>] (do_DataAbort+0x38/0x98) from [<c000ed34>]
(__dabt_usr+0x34/0x40)
[  445.555000] Exception stack(0xeebb5fb0 to 0xeebb5ff8)
[  445.560000] 5fa0:                                     00000003 b6f29548
00000002 0000003a
[  445.565000] 5fc0: b6f2b488 00000000 66667d10 befd7cf0 b6f27f8c b6f29594
b6f27f9c b6f29594
[  445.575000] 5fe0: 00000000 b6f2b484 b6f27b84 b6f27fe0 80000010 ffffffff

Upon run the test several times, I found abort points are differ all the
time.
I wonder you doesn't have the problem. Does it occur only our environment?
I used 3.10-rc1 kernel with CRIU patches not yet merged and
debian-7.0.0-minimal-armhf platform.
You can find the platform next link:
	
http://rcn-ee.net/deb/minfs/wheezy/debian-7.0.0-minimal-armhf-2013-05-05.tar
.xz
I also use exynos4210 based board.

IMO it is important problem because it can disturb dumping.

Best regards,
Chanho Park
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core
Type: application/octet-stream
Size: 704512 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130611/f532bdd1/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_test
Type: application/octet-stream
Size: 452832 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130611/f532bdd1/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump_test.sh
Type: application/octet-stream
Size: 334 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130611/f532bdd1/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: criu
Type: application/octet-stream
Size: 1100772 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130611/f532bdd1/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.log
Type: application/octet-stream
Size: 5219 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130611/f532bdd1/attachment-0009.obj>