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

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

> >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