Re: kern/41225: sys_mqueue.c mq->mq_notify_proc can disappear

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

The following reply was made to PR kern/41225; it has been noted by GNATS.

From: Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>
To: ad%netbsd.org@localhost
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/41225: sys_mqueue.c mq->mq_notify_proc can disappear
Date: Sat, 25 Apr 2009 17:59:20 +0100

 > >Number:         41225
 > >Category:       kern
 > >Synopsis:       sys_mqueue.c mq->mq_notify_proc can disappear
 >
 > ...
 >
 > >Description:
 > Message queues are tied to file descriptors and so can live across
 > fork().
 > 
 > mq_notify() does: mq->mq_notify_proc = l->l_proc;
 > 
 > It looks like this process can exit while the mqueue still persists.
 
 When process is closing the descriptor (by exit or directly), the
 mq_notify_proc is checked by mq_close_fop():
 
 http://nxr.netbsd.org/source/xref/sys/kern/sys_mqueue.c#304
 
 Therefore it seems to be a small race condition, with window here:
 
 http://nxr.netbsd.org/source/xref/sys/kern/sys_mqueue.c#739
 
 Holding proc_lock before release of mq->mq_mtx should fix the problem:
 
 http://www.netbsd.org/~rmind/mq_kpsignal.diff
 
 Looks good?
 
 > Maybe a better solution:
 > 
 > In addition to a pid, store a generation number per struct proc.
 > Every time a pid is allocated, increment the generation number.
 > Add a p_find_gen() or similar that looks for a pid and also
 > compares the generation numbers.
 > This number could be a 64-bit system global (under proc_lock) or
 > we could have one for each pid table slot. I don't personally see
 > a big disadvantage to having a global. ??
 
 That would be a general way to ensure uniqueness. Are there any other
 users (or other usefulness) of such interface?
 
 -- 
 Best regards,
 Mindaugas