[CRIU] [PATCH 4/5] timerfd: Implement c/r procedure
Christopher Covington
cov at codeaurora.org
Wed Jul 2 09:15:01 PDT 2014
On 07/02/2014 12:03 PM, Cyrill Gorcunov wrote:
> On Wed, Jul 02, 2014 at 11:50:46AM -0400, Christopher Covington wrote:
>> I was seeing the following error.
>>
>> (00.055653) 446 fdinfo 0: pos: 0x 0 flags: 2/0
>> (00.056385) Dumping path for 0 fd via self 44 [/dev/null]
>> (00.056865) fdinfo: type: 0x 1 flags: 02/0 pos: 0x 0 fd: 0
>> (00.057723) 446 fdinfo 1: pos: 0x 63 flags: 2001/0
>> (00.058129) Dumping path for 1 fd via self 45 [/tmp/timerfd.out.inprogress]
>> (00.058482) fdinfo: type: 0x 1 flags: 02001/0 pos: 0x 63 fd: 1
>> (00.059299) 446 fdinfo 2: pos: 0x 63 flags: 2001/0
>> (00.059707) fdinfo: type: 0x 1 flags: 02001/0 pos: 0x 63 fd: 2
>> (00.060470) 446 fdinfo 3: pos: 0x 0 flags: 2/0
>> (00.061132) Error (proc_parse.c:1326): No records of type 17 found in fdinfo file
>> (00.061384) Error (proc_parse.c:1329): parse_fdinfo_pid_s: error parsing
>> [mnt_id: 9] for 17: Success
>>
>> Adding FD_TYPES__TIMERFD to the cases that skip that check made it go away,
>> but I'm not sure if that's correct. If I make that change, I get the following
>> error when restoring.
>>
>> (00.054811) 446: Error (files.c:538): No file for fd 3 id 0x3
>> (00.057321) Error (cr-restore.c:1052): 446 exited, status=1
>> (00.058133) Error (cr-restore.c:1615): Restoring FAILED.
>>
>> I'm not currently able to run zdtm.sh on my root filesystem, so I'm invoking
>> the timerfd test manually and may be doing it wrong.
>
> Timerfd requires kernel patching. I've sent out the patches but they
> are not yet merged. Probably the best solution for now -- simply
> don't run this test until we end up with kernel patches.
I'd be interested in testing on ARM and AArch64 with the kernel patches. Where
can I find them?
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
More information about the CRIU
mailing list