On Thu, Feb 11, 2010 at 01:29:52PM -0600, Serge E. Hallyn wrote: > Quoting Jean-Marc Pigeon (jmp@xxxxxxx): > > Hello, > > > > > > > > > > Thanks Jean-Marc. But this really isn't doing most of what I'd > > > recommended in my last emails (both public and private. In > > > particular: > > [....] > > > > > > syslog_ns should be moved into nsproxy and unshared with a > > > separate clone(CLONE_SYSLOG); > > This this not a problem. > > My understanding a new clone flag was not an option > > as we are short in CLONE flag. > > No design nor arch problem if we set CLONE_SYSLOG > > to be 0x100000000 ????? > > > > If moved in nsproxy what is the hook to > > get the "current context". (used current_user_ns() > > as it was in user_namespace). > > > > > > [...] > > > > > That was why I suggested: > > [...] > > > >! 4. take a printk call like the iptables ones you want and turn > > > >! int into nsprintk syscall. > > > >! > > > > If my understanding is right you propose to use a > > special nsprintk to be used by iptable such > > we can send "packet log" in "container context" > > Right? > > > > Logic is weak. > > No logic is irrefutable :) Because: > > > 1) > > The way I changed printk, so far, make of it a "de facto" > > nsprintk. So when called from netfilter, nsprintk > > is still stay in HOST: context. My understanding, > > No, it could be called from the context of a task in any > random container. Your comments seem good. However, I do have an issue with the idea of finding a single syslog corresponding to the netns for a hypothetical printk in iptables. What happens with: /* in init_syslog_ns */ clone(CLONE_SYSLOG) /* syslog_ns 1 */ clone(CLONE_SYSLOG) /* syslog_ns 2 */ <do something with iptables in the netns which triggers a printk> Even though that same printk is relevant to three "syslogs", it'll only go to one, correct? If so, my feeling is that nsprintk shouldn't take a syslog_ns directly. It should take some other form of namespace and then write to the syslog of all the nsproxies which share that namespace (a netns in this case). Cheers, -Matt Helsley _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
