[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 <rmind%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
> Message queues are tied to file descriptors and so can live across
> 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:
> 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?
Main Index |
Thread Index |