Re: POSIX shared memory and dying jails

On 2021-06-25 07:41, Michael Gmelin wrote:
> It seems like non-anonymous POSIX shared memory is not freed
> automatically when a jail is removed and keeps it in a dying state,
> until the shared memory segment is deleted manually.
> 
> See below for the most basic example:
> 
>     [root@jailhost ~]# jail -c path=/ command=/bin/sh
>     # posixshmcontrol create /removeme
>     # exit
>     [root@jailhost ~]# jls -dv -j shmtest dying
>     true
> 
> So at this point, the jail is stuck in a dying state.
> 
> Checking POSIX shared memory segments shows the shared memory segment
> which is stopping the jail from crossing the Styx:
> 
>     [root@jailhost ~]# posixshmcontrol list
>     MODE            OWNER   GROUP   SIZE    PATH
>     rw-------       root    wheel   0       /removeme
> 
> After removing the shared memory segment manually...
> 
>     [root@jailhost ~]# posixshmcontrol rm /removeme
> 
> the jail passes away peacefully:
> 
>     [root@jailhost ~]#  jls -dv -j shmtest dying
>     jls: jail "shmtest" not found
> 
> I wonder if it wouldn't make sense to always remove POSIX shared memory
> created by a jail automatically when it's removed.

That does seem reasonable, though it would take some bookkeeping to do
right.  There is currently no concrete idea of a jail's ownership of a
POSIX shm object, as it uses only uid and gid for access permissions,
same as files.  The tie to the jail is in the underlying vm_object,
which holds a cred that references the jail - that seems to be what's
keeping the jail from going away.

Like files, POSIX shared memory is one way a jail may communicate with
the rest of the system.  So it's theoretically conceivable that shared
memory created by a defunct jail my still be in use by a parent jail,
in the same way that shared memory created by a defunct process is
still visible to other processes, but that may be a rare enough case
to disregard.

- Jamie