Re: Process pointer PID panics

On Sun, Jun 11, 2006 at 02:46:39AM +0200, Tomas Olsson wrote:
> [email protected] writes:
> > If a client application (ie: not arlad) opens the /dev/nnpfs0 device
> > before daemon-ifying itself, the (chan->proc) pointer will point into
> > the process struct from the starting shell.
> > 
> Any particular reason why one would do such a thing?

Logging fatal startup errors to console, since daemon() closes stderr.
Nasty things like the device returning EBUSY, config file or
/var/spool/afs not existing, etc.

Privilege separation will also do it, when forking an unprivileged child
after opening the fd.

> > +    if (chan->proc == NULL || chan->proc != nnpfs_get_proc(uiop))
> >  	chan->proc = nnpfs_get_proc(uiop);
> >  
> Apple demands that procs are released too.  It's not hard at all, I just
> want to understand why we want this.

For arla as a whole, it is a corner case that will never happen in the
current arlad code.  A warning in doc/nnpfs.txt to never change process
ID after open()ing the nnpfs device would probably suffice.

If there is some kernel magic that can detect the process change on the
descriptor, it would be better than comparing process pointers with
every message.  I will have to defer to someone more familiar with what
is possible here.

cheers
--chris