Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > On Wed, 23 Feb 2005 01:07:47 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Guillaume Thouvenin <[EMAIL PROTECTED]> 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. > > > + 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. > > > + 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/