[CRIU] Can't handle non-regular mapping

Zmudzinski, Krystof C krystof.c.zmudzinski at intel.com
Fri Sep 26 17:35:36 PDT 2014


Pavel,

This is a special device driver that allocates memory on behalf of a process that wants to use its services.  When suspending the container, I have to save that memory and it turns that is an easy part.  What I'm wondering about now is how to restore the connection between resumed process and the driver.  I was able to save and restore fd associated with the process but, of course, this is not enough.

My guess is that I'd have to add a couple of calls to the driver to let it know that a process is about to leave and to get all the information that the driver maintains about this process.  On the resume side, I would have to let the driver know that a new process wants to open a connection and that it has to be initialized with the saved state.

What I don't know and what I've started looking for, is what the driver would have to do to let the kernel know it wants to connect the fd that the resumed process has back to the driver.

Any hints, pointers are appreciated.

Krystof

-----Original Message-----
From: Pavel Emelyanov [mailto:xemul at parallels.com] 
Sent: Thursday, September 25, 2014 10:29 PM
To: Zmudzinski, Krystof C; CRIU
Subject: Re: [CRIU] Can't handle non-regular mapping

On 09/26/2014 03:41 AM, Zmudzinski, Krystof C wrote:
> I'm running a sample app that talks to a driver I loaded on the host.  
> I added lxc.cgroup.devices.allow line to the config file and executed 
> mknod in the container.  The app works just fine.  But if I try to 
> suspend my container while the app is running, I get this error from proc_parse.c: Can't handle non-regular mapping on PID's map BIG_NUMBER.
> 
> Once the application stop, I can suspend and then resume just fine.
> 
> I'd like to know what this error means and what should I do - even if 
> that includes writing some code - to be able to suspend the container while the app is running.

CRIU find that your application mmap()-s a driver into its virtual address space.
Such things cannot be "just dumped", because CRIU doesn't know what to do with this driver -- has it any state, that we should preserve or not?

What it this driver?

Thanks,
Pavel




More information about the CRIU mailing list