shm: have os remove shared memory if fio dies unexpectedly
authorSitsofe Wheeler <sitsofe@yahoo.com>
Tue, 24 Jan 2017 06:31:58 +0000 (06:31 +0000)
committerSitsofe Wheeler <sitsofe@yahoo.com>
Thu, 26 Jan 2017 11:06:30 +0000 (11:06 +0000)
commit97900ebfb0192130823dce8aa8f36916313a1c18
treea80bb3f39acd3db9ab1f1d21c08d013ffd335237
parentbd4d9bdc5097c3b35b5172508e1a2828296e01c2
shm: have os remove shared memory if fio dies unexpectedly

When fio doesn't exit cleanly shared memory segments are left behind on
those platforms where shared memory is supported.

Due to how fio manages shared memory lifetime we can combat the above by
marking the shared memory segment as removed shortly after we attach to
it for the first time if the OS offers both the following (non-standard)
behaviours:

1. A shared memory segment marked for removal with IPC_RMID isn't
   destroyed until all processes have detached from it.
2. After 1. has occurred it is still possible to (re)attach to the
   marked-for-removal shared memory segment.

Linux has always done the above so enable the workaround there. OpenBSD
switched to having the above behaviours in 5.1 (see shmctl in
https://www.openbsd.org/plus51.html ) so add a comment about it in
os/os-openbsd.h . FreeBSD only has the above behaviours if
kern.ipc.shm_allow_removed (introduced in 5.2) is 1 and this only became
the default in FreeBSD 11
(https://svnweb.freebsd.org/base?view=revision&revision=289112 ) so add
a comment in os/os-freebsd.h . DragonFly also has the FreeBSD flag but
at the time of writing it defaults to 0 so add a comment to
os/os-dragonfly.h .

There's a nice (if dated) post discussing how IPC_RMID behaves on
various OSes in https://www.cygwin.com/ml/cygwin/2007-11/msg00078.html
("Re: cygwin stable and cvs snapshot - fork() bug").  While fio doesn't
support the Cygwin "OS", Cygwin itself has the
kern.ipc.shm_allow_removed option in a config file and defaults it to
no.
init.c
os/os-dragonfly.h
os/os-freebsd.h
os/os-linux.h
os/os-openbsd.h