Re: leaked swap?

On Tue, May 14, 2019 at 9:24 PM Bob Bishop <rb_at_gid.co.uk> wrote:
> > On 14 May 2019, at 07:50, Andriy Gapon <avg_at_freebsd.org> wrote:
> > In the end, it was POSIX shared memory.
> > I put the system into the single-user to clean up the memory as much as possible
> > and then I panic'ed it and went through dirty pages and their related objects in
> > kgdb.  As far as I can tell, the memory was leaked via POSIX shared memory
> > objects that were never shm_unlink-ed.  It seems that there was a misbehaving
> > program that had been creating such objects and then losing track of them.  (I
> > was able to identify it from names it used for the objects)
> >
> > It seems that, unfortunately, there is no way to list / discover POSIX shared
> > memory objects that are not opened by any process.
>
> Losing track of shared memory objects has been a problem since SysVr2 ...
>
> > I wrote a small gdb script to examine shm_dictionary in kgdb.  It would be nice
> > to have a utility (and a kernel interface) that could do the same from userland.
>
> ... it is indeed high time it was fixed.

Hello,

Newbie hacker here.  Here are some things I've noticed while working
(fairly heavily) with POSIX shm:

1.  As mentioned, you can't list 'em (unlike Linux, where you can just
ls /dev/shm).  There's a TODO note, but it's not clear whether it's
best to extend ipcs or create a new userspace tool, and it wasn't
immediately clear to me how to feed the arbitrary sized results back
to userspace.  I had a scheme worked out where you'd keep calling a
sysctl repeatedly to collect the data until it was done, and it'd
sometimes tell you you need a bigger buffer (because you probably have
to drain at least a whole hash table bucket at a time), but an
experienced FreeBSD hacker told me that was BS, and maybe what's
needed is a device you read.  As well as the list-all-the-segments
tool, you'd also want to be able to unlink to tidy up.

2.  procstat -v doesn't show the paths of POSIX shm objects that are
mapped in (unlike the Linux equivalent, where they're treated as
mapped files).  That's quite useful to me when developing.  I have a
draft patch somewhere that fixes that, though I hadn't got around to
dealing with jail prefixes sensibly.

3.  The hash table is of fixed size and has one simple lock.  Maybe
this is not really a problem for anyone yet, I don't know.  Perhaps
the locking should be made more granular to reduce contention from the
list-all-the-segments thing that needs to loop over it.

4.  I'm suspicious of the way jailing is implemented; I haven't tested
but I suspect that jails leak all their POSIX shm when they shut down,
but then if you start a new jail at the same path it can be accessed
again.