Date: Wed, 15 May 2019 10:02:51 +1200 From: Thomas Munro <tmunro@freebsd.org> To: Bob Bishop <rb@gid.co.uk> Cc: Andriy Gapon <avg@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org>, Alan Somers <asomers@freebsd.org> Subject: Re: leaked swap? Message-ID: <CA%2BhUKGKFrJvRgzy_rWfS%2BWpFZahV0RheSgakjYvvb-33aW%2BT=Q@mail.gmail.com> In-Reply-To: <C48F6C8D-28AB-4B46-A7A6-516321C2303B@gid.co.uk> References: <9c5eaa94-f55b-464a-ab0f-267e7fce4bd0@FreeBSD.org> <20190318153230.GS96870@kib.kiev.ua> <782c2d4b-6920-085b-5489-65fae462a194@FreeBSD.org> <C48F6C8D-28AB-4B46-A7A6-516321C2303B@gid.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 14, 2019 at 9:24 PM Bob Bishop <rb@gid.co.uk> wrote: > > On 14 May 2019, at 07:50, Andriy Gapon <avg@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhUKGKFrJvRgzy_rWfS%2BWpFZahV0RheSgakjYvvb-33aW%2BT=Q>