[CRIU] Can't handle non-regular mapping

[Pavel Emelyanov]

On 09/29/2014 09:45 PM, Zmudzinski, Krystof C wrote:
> Let's say that a process inside a container did the following:
> 
> int fd = open("/dev/special_driver", O_RDWR);
> 
> int ret = ioctl(fd, special_operation_1, &special_operation_1_params);
> 
> Then, the container is suspended.  
> 
> I can save fd.  I can restore it too. I can tell the driver that there is a new process that will use its services and I can pass the state that the driver kept about the process before it was suspended.
> 
> What I have to do however, is to tell the kernel that any ioclt calls from this process on fd should be directed to the driver.
> 
> When the resumed process does this:
> ret = ioctl(fd, special_operation_2, &special_operation_2_params);
> 
> I get errno = EINTR       

This can be device-specific behavior. For example we have this situation
with /dev/tun device, we do call ioctl-s on them for dump and restore,
but don't get into this trouble.

> I've been looking at fcntl and dup but can't come up with anything yet.  I know that this probably will require special code just for my case but I'm sure this could also help others in similar situation.
> 
> Krystof
> 
> -----Original Message-----
> From: Pavel Emelyanov [mailto:xemul at parallels.com] 
> Sent: Monday, September 29, 2014 2:14 AM
> To: Zmudzinski, Krystof C; CRIU
> Subject: Re: [CRIU] Can't handle non-regular mapping
> 
> On 09/27/2014 04:35 AM, Zmudzinski, Krystof C wrote:
>> 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.
> 
> Yup, what you say is 100% correct.
> 
>> Any hints, pointers are appreciated.
> 
> If you could tell what the driver is, I would suggest. But with such a generic description, I can only say -- yes, we should talk to driver to save and restore the needed state.
> 
> Thanks,
> Pavel
> 
> .
>