[CRIU] CRIU: Is trying to dump and restore Chromium browser state hopeless? ("Unsupported mapping found")

[Dmitry Safonov]

2017-05-11 22:48 GMT+03:00 Dmitry Safonov <0x7f454c46 at gmail.com>:
> 2017-05-11 12:36 GMT+03:00 Brinkmann, Harald
> <Harald.Brinkmann at bst-international.com>:
>>
>> We want to save and restore a Chromium web browser process with a
>> complicated web page loaded. The hope is that restoring the browser
>> state is faster than reloading and reprocessing the web page.
>>
>> I can dump and restore a simple test process, so criu itself (commit
>> ed87c0f821a2) works.
>>
>> With Chromium everything looks fine until until I see that "Unsupported
>> mapping found" message in the criu dump log. I have modified criu to
>> print the vmflags and not to stop at the first "Unsupported mapping
>> found":
>>
>>
>> (00.892318) Dumping path for -3 fd via self 7 [/tmp/.org.chromium.Chromium.yo2UhN (deleted)]
>> (00.892343) Strip ' (deleted)' tag from './tmp/.org.chromium.Chromium.yo2UhN (deleted)'
>> (00.892359) Dumping ghost file for fd 7 id 0x20
>> (00.892376) mnt: Path `/tmp/.org.chromium.Chromium.yo2UhN' resolved to `./tmp' mountpoint
>> (00.892394) Dumping ghost file contents (id 0x5)
>> (00.913748) Warn  (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms '
>> (00.913913) Warn  (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
>> (00.913942) Warn  (criu/proc_parse.c:638): Unsupported mapping found 000000005f4bd000-000000005f4dd000
>> (00.914113) Warn  (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
>> (00.914141) Warn  (criu/proc_parse.c:638): Unsupported mapping found 000000005f4dd000-000000005f4fd000
>>
>>
>> Eventually criu gives up with this message:
>>
>> (01.873078) Warn  (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
>> (01.873127) Warn  (criu/proc_parse.c:638): Unsupported mapping found 00000000632f0000-0000000063310000
>> (01.873371) Warn  (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
>> (01.873421) Warn  (criu/proc_parse.c:638): Unsupported mapping found 0000000063310000-0000000063330000
>> (01.873668) Warn  (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
>> (01.874293) Warn  (criu/proc_parse.c:638): Unsupported mapping found 0000000063330000-0000000063350000
>> (01.874504) Error (criu/proc_parse.c:568): Can't handle non-regular mapping on 3844's map 63350000
>> (01.874652) Error (criu/cr-dump.c:1223): Collect mappings (pid: 3844) failed with -1
>>
>>
>> Here are my questions:
>>
>> In addition to the pf and io flags that criu doesn't like, the dc, dd
>> and de flags are also set. While pf and io mean that a page cannot be
>> restored by criu, the others seem to indicate that it *should* not be
>> dumped in the first place. Could this be resolved by criu not dumping
>> and restoring these pages or would that just not work?
>
> No, that doesn't seem to be sane and shouldn't work.
> dc means that vma will not be copied on fork();
> dd - that pages will not be included in coredump;
> de just means that vma's size can't be changed.
> Regardless of those flags, application might need them and very likely
> will miss them after restoring.
>
> What I suspect - is that those mappings are related to gpu/drm/ion.
> And at this moment criu can't restore graphics context.
> Likely you can simply check if it's so by `cat /proc/<chromium_pid>/maps
> for those vmas.
>
>> We are building Chromium from source, so provided we know what we are
>> doing, modifying it is a theoretical possibility. E.g. Modifying the
>> memory mapping?
>
> If the conjecture about graphic mappings is right then you can hack around
> that by running chromium in vnc: https://criu.org/VNC
> But that will add performance degradation (how much? depends!), which
> you try to minimize, AFAICS.

Quite likely, vnc is not a choice for you as I expect that running chromium
without graphics acceleration will be sloooow (esp. for embedded).

>
> Another way would be to add C/R of gpu context..
> At this moment there was no progress made in that direction, AFAIK,
> by the following reasons:
> 1) It is a HUGE task.
> 2) We don't know any customer ready to pay for it.
> 3) No one in criu community does patches for that (likely by the same reasons).
>
> So, I might be wrong and these aren't gpu mappings - please, check it.

-- 
             Dmitry