namespace acceptance process. bad news

[Daniel Lezcano]

Alexey Kuznetsov wrote:
> Hello!
> 
>> Alexey seems to disagree with this approach, is it possible to elaborate
>> a little bit ?
> 
> My first reaction was exactly the same as David's one. Exactly. :-)
> 
> flowi structure was invented to be both easily initialized/disposed
> as a local variable and copied/stored in various caches as a key.
> 
> If it has some reference inside, it becomes really ugly.
> 
> But it is the first reaction. I guess you do not have much of choice.
> The only alternative is to add an additional argument to functions
> taking flowi, which is even uglier.
> 
> So, it looks like netns still have to go to flowi, but functions copying
> flowi (in route.c/flow.c/whatever) should not use raw memcpy to store this
> and must remember that saving flowi is possible only when refcnt to netns
> is held somewhere.
> 
> Alexey

Thanks Alexey for your analysis.

There is no refcount for netns held because it is used as an identifier. 
  We can perhaps make it clear by changing the field fl_net by:

	struct net *fl_net => unsigned long fl_net_key;

In this case, we must track all places where we reused fl_net as a 
pointer to retrieve the netns like in route.c, fib_hash.c or fib_rules.c 
because in this case we must held a reference. So the functions will 
probably take a new netns parameter or pick the netns pointer from 
somewhere else.