Re: unused shared objects in /dev/shm/ngpt

Hello!

On Tue, Aug 27, 2002 at 06:01:18PM +0200, [email protected] wrote:
> Am Dienstag den, 27. August 2002, um 07:52, schrieb Dr. Uwe Girlich:
> > I'm playing a bit with shared objects and find the whole concept a bit 
> > fragile:
> > I create a lot of shared mutexes and shared conditional variables in 
> > some
> > shared memory. Then all programs, using these shared objects (and the 
> > shared
> > memory holding them) will be killed and the shared memory will disappear
> > (either via ipcrm or because the shared memory id was removed already 
> > and so
> > the last detach (in the exit() system call) will destroy the shared 
> > memory
> > segment).
> ipcrm is only usable with SysV ipc -
Thats right but where else should I store my shared objects in? I could also
mmap a file (or /dev/zero) but the main point is, that in addition to this
already shared place, NGPT uses another (/dev/shm/ngpt) also shared place to
store the "second half" of the process shared conditional variables and
mutexes. The problems occur, when both places go out of sync, which happens
after kill -9 of all conditional varibles using programs and when the
shared memory, where the "first half" of the shared objects are stored
disappears. Then nobody knows any longer about the "second half" still in
/dev/shm/ngpt.

> And since shm/ngpt is world writable, 
> every user
> can bring "the system" (of cooperating procs/threads) down, or doing 
> other havoc.
I did not think about this "application", but it sounds interesting (from a
hackers point of view).

> Normally I would instantiate some mutexes/cond in shmem and use that 
> within
> my processes/threads. My system has to give proper filesystem protection 
> for the
> shmem arena. Because I have to "pin/lock" the pages for the futexes to 
> work - the
> kernel could use some resource limits (max locked pages) to prevent 
> exhaustive
> use by one user.
> Furthermore the kernel could release all locks in that page when the 
> reference count
> drops to zero.
Yes, you need kernel assistance for this. But how do you tell the kernel, that
a particular memory page contains a shared lock, which must be removed prior
to removing the shared memory itself?

> > Do I need a monitor process to constantly read /dev/shm/ngpt and 
> > looking for
> > mx_owner_pid values, which no longer exist (and a similar concept for 
> > cond.
> > variables)?
> Unfortunately the kernel does not know anything about the lock unless 
> there is
> contention. And without looking at the "owner" field, which is not 
> easily maintained
> without races, the kernel does not know who owns or uses the lock.
My question was a purely rhetoric one. I've seen the race problem.

> If you use a lock manager where the locks has to be registered, you can 
> put the
> lock entirely into the kernel - perhaps that's best with PROCESS_SHARED 
> locks?
Yes, every PROCESS_SHARED thing must be registered before using it to keep
an eye on it.

Bye, Uwe