[CRIU] [PATCH v7 1/9] restore: Use pstree_pid_cmp helper in pid_rst_prio

Cyrill Gorcunov gorcunov at gmail.com
Wed Jun 6 22:23:01 MSK 2018


On Mon, Jun 04, 2018 at 03:26:30PM -0700, Andrey Vagin wrote:
> On Mon, Jun 04, 2018 at 10:28:04PM +0300, Cyrill Gorcunov wrote:
> > On Mon, Jun 04, 2018 at 11:45:51AM -0700, Andrey Vagin wrote:
> > > On Wed, May 23, 2018 at 07:06:07PM +0300, Cyrill Gorcunov wrote:
> > > > The pid number is absolutely not a guarantee to
> > > > introduce order relationship into pid set because
> > > > they might be reused. Instead we should consider
> > > > parent->child relationship.
> > > 
> > > I don't understand this. Could you elaborate with more details?
> > > 
> > > > 
> > > > Otherwise we might get
> > > > 
> > > >  |  31964  31964  31964       epoll
> > > >  |    585  31964  31964           epoll
> > > >  |    586  31964  31964           epoll
> > > >  |...
> > > >  | (04.797121)    585: Error (criu/eventpoll.c:180): epoll: Unexpected state for tfd (id 0 fd 8)
> > 
> > An example tree is above: comparing only pid numbers we will
> > choose 586 as a master and 31964 as a slave, which is wrong
> > of course. Instead we should walk over the pid tree and
> > find which pid is a master (parent) and which is slave (children)
> 
> Why is it wrong? Why is the parent better than a child?

Please take a look on https://jira.sw.ru/browse/PSBM-63355, the
former fix I made for criu-2.10 series where we alread had new
files engine. The parent should have opened eventpoll descriptor
so we would add target descriptors then.

I think what I really should do instead is to create a test
case for it since we have an ability to generate pid tree
with pids needed. Thus for now please drop the patch.
Once I create a test and it get failed without a patch
then I'll come with some proves.


More information about the CRIU mailing list