Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces

[Eric W. Biederman]

Pavel Emelyanov <xemul@xxxxxxxxxx> 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.

>
> 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
--
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/