[CRIU] CRIU: Is trying to dump and restore Chromium browser state hopeless? ("Unsupported mapping found")
Dmitry Safonov
0x7f454c46 at gmail.com
Fri May 12 08:30:21 PDT 2017
2017-05-12 12:39 GMT+03:00 Brinkmann, Harald
<Harald.Brinkmann at bst-international.com>:
>
> Hi Dmitry,
>
> On Thu, 2017-05-11 at 22:48 +0300, Dmitry Safonov wrote:
>> 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.
>
> Hmmm. This is criu's first error:
>
> (00.935834) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms '
> (00.936093) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
> (00.936123) Error (criu/proc_parse.c:637): Unsupported mapping found 000000005f65e000-000000005f67e000
>
> But cat /proc/484/smaps says:
> an
> 5f65e000-5f67e000 rw-s 00000000 00:05 11582 /dev/zero (deleted)
> Size: 128 kB
> Rss: 0 kB
> Pss: 0 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 0 kB
> Anonymous: 0 kB
> AnonHugePages: 0 kB
> Shared_Hugetlb: 0 kB
> Private_Hugetlb: 0 kB
> Swap: 0 kB
> SwapPss: 0 kB
> KernelPageSize: 4 kB
> MMUPageSize: 4 kB
> Locked: 0 kB
> VmFlags: rd wr sh mr mw me ms pf io dc de dd
>
> There are many more of those, but in the end this happens:
>
> (01.946575) Error (criu/proc_parse.c:637): Unsupported mapping found 0000000062b33000-0000000062b53000
> (01.946708) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
> (01.946733) Error (criu/proc_parse.c:637): Unsupported mapping found 0000000062b53000-0000000062b73000
> (01.946806) Warn (criu/proc_parse.c:108): parse_vmflags: 'mr mw me ac '
> (01.946862) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr mr mw me ac '
> (01.946964) Error (criu/proc_parse.c:567): Can't handle non-regular mapping on 484's map 63373000
> (01.947018) Error (criu/cr-dump.c:1223): Collect mappings (pid: 484) failed with -1
>
> and that is:
>
> 63373000-6b373000 rw-s 00000000 00:06 1213 /dev/galcore
> Size: 131072 kB
> Rss: 0 kB
> Pss: 0 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 0 kB
> Anonymous: 0 kB
> AnonHugePages: 0 kB
> Shared_Hugetlb: 0 kB
> Private_Hugetlb: 0 kB
> Swap: 0 kB
> SwapPss: 0 kB
> KernelPageSize: 4 kB
> MMUPageSize: 4 kB
> Locked: 0 kB
> VmFlags: rd wr sh mr mw me ms pf io dc de dd
>
> FWIW we also have this:
>
> 72d37000-744f2000 rw-s 00000000 00:06 1511 /dev/fb0
> Size: 24300 kB
> Rss: 0 kB
> Pss: 0 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 0 kB
> Anonymous: 0 kB
> AnonHugePages: 0 kB
> Shared_Hugetlb: 0 kB
> Private_Hugetlb: 0 kB
> Swap: 0 kB
> SwapPss: 0 kB
> KernelPageSize: 4 kB
> MMUPageSize: 4 kB
> Locked: 0 kB
> VmFlags: rd wr sh mr mw me ms pf io de dd
>
>
>> > 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.
>
> Performance is already quite poor, so that isn't an option as you
> already suspected.
>
>> 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.
>
> At least that is a clear and definite statement. At one time I was
> hoping that we could get a restored Chromium to just redraw everything,
Well, I'm not an expert in graphics, but that could actually work with
fb device.
Or with dri with some additional ioctls.
But when you have accelerated graphics, you need to restore the context
on gpu: mapped for dma pages, tasks in a jobs scheduler and so on.
> but from the sounds of it
>
>> 1) It is a HUGE task.
>
> and may not even work, either.
>
>
> Thanks for your info.
>
> Even though it will not solve my problem, is the "/dev/zero
> (deleted)"-issue something you might be interested in or is that
> behaviour as expected?
It might be created by driver as anon mapping.
You may find where it came from by stracing chromium task.
>
>
> --
>
> Kind regards
>
> i.A. Harald Brinkmann
>
> BST eltromat International GmbH
> Werk Leopoldshöhe
> Herforder Straße 249-251
> D-33818 Leopoldshöhe
>
> T: +49 (5208) 987-513
>
> E: harald.brinkmann at bst-international.com
> W: http://www.bst-eltromat.com
>
>
>
>
> _______________________________________________________
> Amtsgericht Bielefeld, HRB Nr. 30830
> Geschäftsführer Kristian Jünke, Dr. Johann-Carsten Kipp, Dr. Gunter
> Tautorus
> Sitz der Gesellschaft: Bielefeld
> Vertrauliche E-Mail von BST eltromat International GmbH
>
--
Dmitry
More information about the CRIU
mailing list