[CRIU] [PATCH v3 12/16] files: new "used" files introduced

Pavel Emelyanov xemul at parallels.com
Mon Dec 14 04:08:27 PST 2015


On 12/14/2015 03:00 PM, Stanislav Kinsburskiy wrote:
> 
> 
> 14.12.2015 12:49, Pavel Emelyanov пишет:
>> On 12/14/2015 02:24 PM, Stanislav Kinsburskiy wrote:
>>>
>>> 14.12.2015 12:21, Pavel Emelyanov пишет:
>>>> On 12/10/2015 06:17 PM, Stanislav Kinsburskiy wrote:
>>>>> This list contains all per-process used file fdinfo's, sorted by fd number.
>>>>> Will be used to safely create new artificial file descriptors and also allow
>>>>> to recreate temporary descriptors with original number, if possible, like
>>>>> AutoFS tries to preserve original pipe write end descriptor, when it was
>>>>> closed.
>>>> AFAIU you only need this to find the first unused descriptor number. Why
>>>> not just have max_fd number in the rst_info and update one in every place
>>>> a new fd is added?
>>> This can be done like this, yes.
>>> One of the intentions was to try to keep autofs restored options as
>>> close to original as possible.
>>> The actual idea was to try to reopen write end of the pipe with the same
>>> fd, as it was originally.
>>> To be able to do so, loop over all the descriptor is required to make
>>> sure, that fd is not busy.
>> But where is this code? The only usage for used list is to find the first
>> unused one (patch #13) and, btw, the only benefit of the list as compared to
>> the plan max_used_fd value -- the ability to get a 'hole' between used fds --
>> is not taken in this patch.
>>
> 
> It's patch #13 with find_unused_fd() helper and patch #15, which uses 
> this helper.

Patch #13 (and its user patch #15) do only one thing -- find any number that
is unused in the fd table. And it does this quite straightforward -- just find
the maximum value of the fd list. This can be done by jst tracking this value
while fds get collected, there's no need in keeping the list of fds for that.

So why do you think the list of used fds better than just max_fd value?

-- Pavel


More information about the CRIU mailing list