On Tue, 2009-06-23 at 14:01 -0700, Matt Helsley wrote: > On Mon, Jun 22, 2009 at 04:19:09PM -0700, Andrew Morton wrote: > > > + get_seq(&msg->seq, &ev->cpu); > > > + ktime_get_ts(&ts); /* get high res monotonic timestamp */ > > > + put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns); > > > + ev->what = PROC_EVENT_SID; > > > + ev->event_data.sid.process_pid = task->pid; > > > > This is a bit of a worry. In a containerised environment, pids are not > > unique. Now what do we do? > > An excellent point. It's broadcast via a netlink multicast address. That > means we'd have pids and listeners from arbitrary combinations of pid > namespaces. > Yeah, right now that's a general problem with the netlink approach compared to the signal approach I was using before. Of course, it's also non-obvious how init in the initial pid namespace should deal with processes dying in a different pid namespace. > One obvious but poor solution is to only send the pid of the initial > pid namespace. Then it's not ambiguous what an event refers to. However > it also means that the events would only be useful to tasks running > in the initial pid namespace -- not a good solution given Scott's example > and our desire to run things like sshd in separate pid namespaces. > > Alternatively, we may be able to split up the connector such that the > listeners only see events from their own pid namespace. I'm not > sure that netlink and connectors can enable this change though. > Or the netlink socket could include both the pid, and a descriptor of the pid namespace that it is in (isn't it just a pid itself?) That way listeners could check the namespace is the same before carrying on. Though that obviously leaks information you may not actually want leaked? Scott -- Scott James Remnant scott@xxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
