Potential bug in ngx_event.c

[Maxim Dounin]

Hello!

On Sun, Sep 01, 2019 at 11:45:20AM -0700, Rian Hunter wrote:

> On 2019-08-31 11:28, Maxim Dounin wrote:
> > Hello!
> > 
> > On Fri, Aug 30, 2019 at 06:26:57PM -0700, Rian Hunter wrote:
> > 
> >> On 2019-08-30 07:19, Maxim Dounin wrote:
> >> > Yes, this is intentional.
> >> >
> >> > The first agument of the ngx_shmtx_create() function is a pointer
> >> > to the ngx_shmtx_t structure, which is not expected to be shared
> >> > between processes.  Copy of the structure as created by fork() is
> >> > enough.
> >> 
> >> The POSIX sem_t member (called "sem") needs to reside in shared memory
> >> if sem_wait()/sem_post() are to have an effect across processes. 
> >> Memory
> >> copied across fork is not sufficient.
> > 
> > No, fork() is explicitly documented to preserve semaphores
> > (http://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html):
> > 
> > : Any semaphores that are open in the parent process shall also be
> > : open in the child process.
> 
> That's only true for semaphores created with sem_open(). For semaphores 
> created with sem_init(pshared=1) the caller is responsible for using 
> supplying memory that resides in a shared memory segment (e.g. created 
> from mm ap(flags=MAP_SHARED|...)).
> 
> See: 
> https://blog.superpat.com/2010/07/14/semaphores-on-linux-sem_init-vs-sem_open/
> 
> Here is a program that illustrates my point (also here: 
> https://gist.github.com/rianhunter/a0bd4c9e8ab550ecadbe2464995726a8):

[...]

My bad, you are right here.

This isn't a problem though, as accept mutex does not use 
sem_wait(), but only uses ngx_shmtx_trylock() - that is, only 
atomic operations.

And for other mutexes we allocate ngx_shmtx_t structures from 
shared memory, so it works fine.

-- 
Maxim Dounin
http://mdounin.ru/