[CRIU] custom initialization during restore

Cyrill Gorcunov gorcunov at gmail.com
Wed Aug 12 14:13:55 PDT 2015


On Wed, Aug 12, 2015 at 05:37:37PM +0300, Pavel Emelyanov wrote:
> > 
> > This, actually brings a number of problems: the CRIU's pie code
> > (if I understand correctly we need to call some pre-sigreturn helper
> >  functions, which are "external" in terms of CRIU symbols) is very
> >  special one -- the main requirement is that all symbols must be
> >  resolved, so in general we carry all the data needed for restorer
> >  inside the memory blob which we're generating dynamically.
> 
> Sure, but symbols resolution can be done before calling pie code. I
> would even add -- we can do it dump-time and save hooks' addresses
> into images :D

I see but for me this should be done like this

 - criu reads plugin(s) and move them into restorer blob
 - restore maps and etc
 - before sigreturn criu pass execution into the plugin
   - plugin does something (mmap/syscalls/openfiles or whatever)
   - calls return
 - criu calls sigreturn dropping all memory (including restorer
   blob itself together with plugin) and all this  goes transparently
   to the dumped application

I must admit this actually not much different from what you
propose except I think this would limit the naming scheme. Currently
CRIU plugins doesn't care how functions are named.

So I won't argue if someone implement your idea ;)

> > we're applying strict rules on plugins structure and we assume
> > that such plugin does _not_ carry any unresolved symbols. Hm?
> 
> The plugins we're talking about should better be per-application.
> Thus linking them into a process sounds more promising.

I'm not that sure because native criu plugins would look more
natural for me, but it's just an opinion, I don't have strong
preference yet.


More information about the CRIU mailing list