Re: [BProc] F_ASYNC on slave node

[<er...@he...>]

On Sat, Mar 06, 2004 at 12:10:48AM +0000, Steven James wrote:
> Greetings,
> 
> I've been working on an app that uses the fcntls F_SETOWN, F_ASYNC,
> F_SETSIG, and friends on TCP sockets to handle async events.
> 
> The program works fine on the master or between unrelated machines, but on
> a bproc slave, the signals are not delivered.
> 
> Digging through the code, I believe I have the reason but want to sanity
> check my finding:
> 
> 1. ghost processes are only on the master.
> 2. getpid (from userspace) returns the PID as seen by the master (the pid
> of the ghost).
> 
> So when fcntl( sock, F_SETOWN, getpid()), I set the ghost processes pid
> into filep->f_owner.pid
> 
> When data arrives, send_sigio in fs/fcntl.c does (on the slave):
> 
> 435 void send_sigio(struct fown_struct *fown, int fd, int band)
> 436 {
> 437         struct task_struct * p;
> 438         int   pid       = fown->pid;
> 439
> 440         read_lock(&tasklist_lock);
> 441         if ( (pid > 0) && (p = find_task_by_pid(pid)) ) {
> 442                 send_sigio_to_task(p, fown, fd, band);
> 443                 goto out;
> 444         }
> 445         for_each_task(p) {
> 446                 int match = p->pid;
> 447                 if (pid < 0)
> 448                         match = -p->pgrp;
> 449                 if (pid != match)
> 450                         continue;
> 451                 send_sigio_to_task(p, fown, fd, band);
> 452         }
> 453 out:
> 454         read_unlock(&tasklist_lock);
> 455 }
> 
> And since pid isn't there, it does nothing at all.
> 
> The easy answer would be to hack do_fcntl to translate the pid passed in
> to the real pid on the slave. However, I'm not certain that that wouldn't
> be just a band-aid on a more general issue.
> 
> Thoughts?

That sounds like it would work out ok.  You might want to require the
pid argument to exist (i.e. the mapping is successful) before doing
the assignment of the mapped pid in the f_owner structure.  That might
be good enough to avoid some shenanigans that could result in sending
signals across a process spaces.  This would make it work on local
processes only and sending to a process group would probably still be
busted.  It sounds like it might work for a lot of things though.

The more general issue is signals being sent by things other than
processes.  The file descriptor really needs a process space context
along with it so that it can look up PIDs in the right process space.
Then the mapping could be done when the signal is actually sent and it
could be forwarded if necessary, etc.  I can't think of a reasonable
case where anybody would want a file descriptor on one machine to send
a signal to a process on another machine but I guess that's what you'd
have to support to be strictly correct.  TTY generated signals have
the same problem.  I don't much like the idea of adding extra goop to
the file structure but it's probably necessary to get this right.

- Erik