[CRIU] CRIU saving/restoring fd for the device file
Zmudzinski, Krystof C
krystof.c.zmudzinski at intel.com
Fri Oct 3 09:34:09 PDT 2014
The file was blocked because of *.sh files. How about just the files that changed and new?
Krystof
-----Original Message-----
From: criu-bounces at openvz.org [mailto:criu-bounces at openvz.org] On Behalf Of Zmudzinski, Krystof C
Sent: Friday, October 3, 2014 9:14 AM
To: CRIU
Subject: Re: [CRIU] CRIU saving/restoring fd for the device file
I've received requests to post my code. This is probably not the best way but here it is a snapshot of criu-1.3.1 with my test code, and without test and Documentation folders. Search for testfd to see the code I added to dump and restore processes, even containers with processes connected to my test driver. I based the code loosely on timerfd.
What is missing still is the code to retrieve the context from the driver and then restore it. So any VMAs mapped by the driver into processes' address space required special code to be dumped/restored. But that is very driver specific.
Krystof
-----Original Message-----
From: criu-bounces at openvz.org [mailto:criu-bounces at openvz.org] On Behalf Of Zmudzinski, Krystof C
Sent: Thursday, October 2, 2014 8:47 AM
To: CRIU
Subject: Re: [CRIU] CRIU saving/restoring fd for the device file
One more detail that may help. I have sleep(20) in my app so I can criu suspend at predetermined places. So the app is always interrupted at sleep(20). When the app is restored, the sleep doesn't finish. In other words, if I suspend the app after 5 seconds, there is no remaining 15-second sleep on after restore.
Krystof
-----Original Message-----
From: Pavel Emelyanov [mailto:xemul at parallels.com]
Sent: Thursday, October 2, 2014 8:42 AM
To: Zmudzinski, Krystof C; CRIU
Subject: Re: [CRIU] CRIU saving/restoring fd for the device file
On 10/02/2014 07:37 PM, Zmudzinski, Krystof C wrote:
> If the app runs uninterrupted by criu suspend/restore, each sys call
> to the driver works just fine: open returns valid fd and icotls return
> 0. Also, errno is always 0. After criu restore, open and ioctls still work and return valid fd and 0 respectively but errno is set to EINTR.
Hm... Interesting. OK, I'll try to investigate what's going on.
Thanks for the report :)
> Krystof
>
> -----Original Message-----
> From: Pavel Emelyanov [mailto:xemul at parallels.com]
> Sent: Thursday, October 2, 2014 8:17 AM
> To: Zmudzinski, Krystof C; CRIU
> Subject: Re: [CRIU] CRIU saving/restoring fd for the device file
>
> On 10/02/2014 07:08 PM, Zmudzinski, Krystof C wrote:
>> I have finally figured out that I can indeed talk to the driver just
>> fine. The problem is that my code checks for errno even when ioctls
>> don't return -1. For some reason, after resume, errno is set to
>> EINTR. Is it possible that criu causes this by sending a signal to the my app during suspend?
>
> I doubt this. errno is just a variable in memory, criu doesn't touch the app's memory.
>
>> Shouldn't errno be cleared by criu on resume?
>
> AFAIK no, app's memory should be left intact on restore.
>
> Can you describe problem in more details, please?
>
> Thanks,
> Pavel
>
>
>
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
>
_______________________________________________
CRIU mailing list
CRIU at openvz.org
https://lists.openvz.org/mailman/listinfo/criu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-fd.tar.gz
Type: application/x-gzip
Size: 50821 bytes
Desc: test-fd.tar.gz
URL: <http://lists.openvz.org/pipermail/criu/attachments/20141003/c5afe826/attachment-0001.gz>
More information about the CRIU
mailing list