gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] [PATCH 3/3] Fix access to shared memory on Linux


From: Fred Wright
Subject: Re: [gpsd-dev] [PATCH 3/3] Fix access to shared memory on Linux
Date: Fri, 24 Mar 2017 19:23:10 -0700 (PDT)

On Fri, 10 Mar 2017, Robert Norris wrote:

> I finally got around to setting up a FreeBSD (release 11.0) virtual machine.
>
> It too has the same behaviour as Linux, in that the shared memory key
> gets changed to 0 (i.e. IPC_PRIVATE) when shmctl with IP_RMID is
> applied. So I expect most other OS's follow this behaviour.

Yes, I expect that that's true, even though it doesn't explicitly state it
in the manpage.  It actually makes sense when you think about it, since
the purpose of IPC_RMID is to *remove* the segment.  The only reason it
can't remove it immediately is that it can't pull the rug out from under
existing mappings.  But in addition to flagging it for later removal, it
also wants to ensure that no further mappings to it are created, which is
done by clearing the key.

It was always a mistake to do IPC_RMID at the *beginning*, but reasonable
to do it at the end.  I fixed that, but in the process discovered some
other issues with regard to SHM collisions in regression testing, which I
also fixed.

There's still an issue with collisions of the 'NTPx' segments during
regression testing.  Although it would theoretically be useful to allow
those to be moved to unique keys during testing as well, there's not
currently anything to make use of such a scheme.  It might make sense for
now just to disable the 'NTPx' segments altogether whenever GPSD_SHM_KEY
is defined, mainly to avoid having regression tests step on a system
gpsd's feed to ntpd.  Another environment variable to provide an alternate
NTPD_BASE could be added later, if needed.

One slight problem with the new scheme is that if an old gpsd was
previously running and left the 'GPSD' segment around, the new gpsd won't
use it.  Since there's no reliable way to distinguish this from the real
collision case, it seems safer to live with that, and require the manual
ipcrm cleanup.

Also, even the new gpsd could leave the SHM segment lying around if it
crashes.  I'm not sure this is worth the hassle of setting up an atexit()
handler to fix.  Basically, the whole SYSV SHM API is pretty awful.

Given that the whole 'GPSD' SHM mechanism has been completely broken for
almost a year, I'm not *too* worried about those two corner cases. :-)

I also merged the test_gpsmm fix.

Fred Wright



reply via email to

[Prev in Thread] Current Thread [Next in Thread]