leaked swap?
Thomas Munro
tmunro at freebsd.org
Tue May 14 22:03:30 UTC 2019
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.
More information about the freebsd-current
mailing list