[lkml]   [2008]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/2] Fix /proc/net in presence of net namespaces
    Eric W. Biederman wrote:
    > Pavel Emelyanov <> writes:
    >> I could use the struct net pointer values (obtained with sprintf(id, "%p", net))
    >> instead, but exporting internal kernel addresses seemed even uglier.
    > Agreed.
    >>> Can you try this approach by capturing a struct pid instead of an id
    >>> in a new global namespace?
    >> This is a bad approach. When task, that created the namespace dies, his
    >> pid is removed from the pidmap and can be reused, so we can get another
    >> net with the same id.
    > It takes a little updating of how we use pids. The easiest method
    > is to add an extra counter. So we know when someone besides the hash
    > chains is using the pid as an id. However it might make sense to actually
    > have a net namespace pointer in the pid.

    No, please, no. I'm strongly opposed to making pids provide identification
    for anything we need in the kernel.

    >> This net's id is not supposed to be used to address any net in the kernel.
    >> And I see no problems with migration - you can change the net's id safely
    >> during checkpoint/restart - tasks will always see this one via the /proc/net
    >> symlink, which is dynamic.
    > So you are really talking about a hidden id. There are just enough
    > ways for something like that to slip out I'm not especially
    > comfortable with the idea.
    > I really think we need something clean that we can live with, and be
    > proud of. However we implement the enhancement to /proc/net this has
    > to be maintained for decades.
    > Eric

     \ /
      Last update: 2008-03-03 09:57    [W:0.021 / U:0.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site