Hello, Philip!
On 12:48 Fri 04 Dec, Philip Guenther wrote:
> > @@ -372,6 +374,7 @@ tunopen(dev_t dev, int flag, int mode, s
> > s = splnet();
> > ifp->if_flags |= IFF_RUNNING;
> > tun_link_state(tp);
> > + tp->tun_proc = p;
>
> Ick, holding a pointer to a struct proc from inside a driver?! What
> happens when the process forks and the parent exits?
Thanks for pointing that out. Haven't thought about it at all.
> The file will
> still be open in the child, so the device close routine won't have
> been called and you'll have a dangling pointer, no? (Doesn't ppp do
> exactly that open/fork/exit routine?)
>
> I suspect this should instead follow the lead of fcntl(F_[SG]ETOWN)
> and save the pid, though that still has fun if the process exits and
> the pid is reused. What do you think the correct semantics are if the
> original process exits?
After this I thought replacing a struct proc pointer to a pid_t,
with 'sanity' checks in it,
for example:
- do a proc lookup (pfind())
- found:
- check the process' filedesc table to
contain the tunnel
(How? struct file does not contain filedesc struct pointers and
doesn't keep record of processes, referencing it and none of the tun
cdevsw operations know, which struct file the processed tunnel is)
- if not:
- check all filedescs of all processes to contain the
tunnel, update pid_t record in tun_softc and return it
So, is there a way (an interface) to find out from the character
device driver which struct file is it in it's current instance?
Or am I digging into the wrong direction?
Or just keep a record of a PID without any check just to know who opened
it (but that's not that handy, right?)
> > + tunr->tun_pid = tp->tun_proc->p_pid;
>
> This is wrong if the process is using rthreads. It should be
> tp->tun_proc->p_p->ps_mainproc->p_pid
Got that, thank you.
