Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector

[Evgeniy Polyakov]

On Wed, 23 Feb 2005 02:58:06 -0800
Andrew Morton <akpm@xxxxxxxx> wrote:

> Evgeniy Polyakov <johnpol@xxxxxxxxxxx> wrote:
> >
> > On Wed, 23 Feb 2005 01:07:47 -0800
> > Andrew Morton <akpm@xxxxxxxx> wrote:
> > 
> > > Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxx> wrote:
> > > >
> > > > Hello,
> > > > 
> > > >   This patch replaces the relay_fork module and it implements a fork
> > > > connector in the kernel/fork.c:do_fork() routine. The connector sends
> > > > information about parent PID and child PID over a netlink interface. It
> > > > allows to several user space applications to be informed when a fork
> > > > occurs in the kernel. The main drawback is that even if nobody listens,
> > > > message is send. I don't know how to avoid that.
> > > 
> > > We really should find a way to fix that.  Especially if we want all the
> > > distributors to enable the connector in their builds (we do).
> > 
> > Mesage is never reached anyone if there are no listeners, skb will be just freed,
> > even without any linking.
> > do_one_broadcast() in net/netlink/af_netlink.c takes care of it.
> > Unicast message also will be discarded in cn_rx_skb().
> 
> We should assume that there will always be listeners.  (why was the
> connector thing added anyway?  Its changelog is pathetic).
>
> > These operations are quite cheap - just link/unlink skb to/from appropriate
> > queues.
> 
> Please assume that <whatever secret application the connector stuff was
> originally written for> will always be listening.
>
> > > What happened to the idea of sending an on/off message down the netlink
> > > socket?
> > 
> > ?
> 
> All those emails I sent last week.
> 
> Arrange for the userspace daemon to send a message to the fork_connector
> subsystem turning it on or off.  So we can bypass all this code in the
> common case where <secret application> is listening, but your daemon is
> not.

Ok, now I see(I'm not a fork connector author, so I did not receive them).
That will require to add real fork connector with callback routing.
Guillaume?

> > > > +		if (msg) {
> > > > +			memset(msg, '\0', size);
> > > 
> > > Do we really need to memset the whole thing?
> > 
> > Yes, to not leak kernel memory context.
> 
> How would we do that?  There are no gaps in the payload and we tell netlink
> the exact length.

Without memset kernel memory from slab cache will be sent to the userspace.
Neither kmalloc() itself nor cache does not prefill the allocated area.

> > > > +			memcpy(&msg->id, &fork_id, sizeof(msg->id));
> > > > +			msg->seq = seq++;
> > > 
> > > `seq' needs a lock to protect it.  Or use atomic_add_return(), maybe.
> > 
> > Not necessary, I doubt fork userspace listener uses protocol described in
> > connector.c and relies on seq field since it is not needed to have acks/replays.
> > Although it can be used as a flag that it is new fork, but message itself
> > is already such an event.
> 
> Without a lock you can have two messages with the same sequence number. 
> Even if the daemon which you're planning on implementing can handle that,
> we shouldn't allow it.

Yes, they can have the same number, but does it cost atomic/lock overhead?
Anyway, simple spin_lock() should be enough in do_fork() context.
Guillaume?

	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/