[CRIU] [PATCH 4/5] timerfd: Implement c/r procedure

[Cyrill Gorcunov]

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.