[GSOC] System V IPC in userspace week7 report

[Grigore Larisa <larisagrigore@xxxxxxxxx>]

--90e6ba6e850086339a04e32799ef
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

This week I fixed some locking bugs on the client side. In functions like
shmget and shmat that are not often called and there are not so many
operations to be done I have decreased the number of locks acquired. I
focused on multithreading case and sysv semaphores, added locking where was
the case and handled some error conditions (a semaphore was removed by
another process, a semaphore was removed by another thread from the same
space address, etc).

During the test period, I realized that I need to handle the case when a
process that uses userland sysv ipc calls fork() or exec().
The fork() case is treated using pthread_atfork function. The parent
acquires all locks before forking itself and both child and parent release
them after fork. The child must than connect to the daemon and inform it
about the shared memory segments to which it is attached (those segments
can be used for shm, sem, msg).

For exec() case, all file descriptors used to communicate with the daemon
have FD_CLOEXEC set. The daemon handles this case as if the client was
disconnected. There is a problem with the segment used for undo operations.
All operations that have SEM_UNDO flag set (flag used by semop()) are
written in this segment in order to be undone by the server when the
process dies. The daemon can not make difference between exec() and the end
of execution so it will undo all operations in exec() case too (the
operations should be undone after the process dies).