NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: Mindaugas Rasiukevicius <>
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():
 Therefore it seems to be a small race condition, with window here:
 Holding proc_lock before release of mq->mq_mtx should fix the problem:
 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,

Home | Main Index | Thread Index | Old Index