All of lore.kernel.org
 help / color / mirror / Atom feed
* netns refcounting
@ 2007-11-16 14:04 Denis V. Lunev
       [not found] ` <473DA358.9040705-3ImXcnM4P+0@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Denis V. Lunev @ 2007-11-16 14:04 UTC (permalink / raw)
  To: Eric W. Biederman, Daniel Lezcano, Pavel Emelianov,
	Linux Containers, devel-GEFAQzZX7r8dnm+yROfE0A

Hello, All!

During port of Eric's patches I have noticed an interesting thing.
The patch "net: Teach the ipv4 route cache to handle multiple network
namespaces" call hold_net for each IPv4 DST cache entry.

Though it is not possible to stop a namespace without stopping all the
devices inside. Additionally, the device can't be unregistered if there
are dst entries to it. These entries are moved to a namespace loopback
and the namespace will block until these entries will gone from a loopback.

So, I do not see a necessity to have an extra atomic on this hot path,
i.e. hold_net can re moved away for this. Are there any holes?

Regards,
	Den

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: netns refcounting
       [not found] ` <473DA358.9040705-3ImXcnM4P+0@public.gmane.org>
@ 2007-11-16 15:50   ` Daniel Lezcano
  2007-11-16 17:14   ` Eric W. Biederman
  1 sibling, 0 replies; 3+ messages in thread
From: Daniel Lezcano @ 2007-11-16 15:50 UTC (permalink / raw)
  To: Denis V. Lunev; +Cc: Linux Containers, Eric W. Biederman, Pavel Emelianov

Denis V. Lunev wrote:
> Hello, All!
> 
> During port of Eric's patches I have noticed an interesting thing.
> The patch "net: Teach the ipv4 route cache to handle multiple network
> namespaces" call hold_net for each IPv4 DST cache entry.
> 
> Though it is not possible to stop a namespace without stopping all the
> devices inside. Additionally, the device can't be unregistered if there
> are dst entries to it. These entries are moved to a namespace loopback
> and the namespace will block until these entries will gone from a loopback.
> 
> So, I do not see a necessity to have an extra atomic on this hot path,
> i.e. hold_net can re moved away for this. Are there any holes?

That seems reasonable to remove, good catch.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: netns refcounting
       [not found] ` <473DA358.9040705-3ImXcnM4P+0@public.gmane.org>
  2007-11-16 15:50   ` Daniel Lezcano
@ 2007-11-16 17:14   ` Eric W. Biederman
  1 sibling, 0 replies; 3+ messages in thread
From: Eric W. Biederman @ 2007-11-16 17:14 UTC (permalink / raw)
  To: Denis V. Lunev; +Cc: Linux Containers, Pavel Emelianov

"Denis V. Lunev" <den-3ImXcnM4P+0@public.gmane.org> writes:

> Hello, All!
>
> During port of Eric's patches I have noticed an interesting thing.
> The patch "net: Teach the ipv4 route cache to handle multiple network
> namespaces" call hold_net for each IPv4 DST cache entry.
>
> Though it is not possible to stop a namespace without stopping all the
> devices inside. Additionally, the device can't be unregistered if there
> are dst entries to it. These entries are moved to a namespace loopback
> and the namespace will block until these entries will gone from a loopback.
>
> So, I do not see a necessity to have an extra atomic on this hot path,
> i.e. hold_net can re moved away for this. Are there any holes?

So all hold_net is good for is to catch logic errors where people are
still using a network namespace but have freed it.  It is a bit like
the device reference count in that regard.

The usage of the dst cache from ipv4 looked complicated enough that making
some small mistake easy to have so I included the reference count for good
measure.

If the movement to loopback device is sufficient to prevent us from goofing
up in this area I am happy to avoid the reference count.

Eric

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-11-16 17:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-16 14:04 netns refcounting Denis V. Lunev
     [not found] ` <473DA358.9040705-3ImXcnM4P+0@public.gmane.org>
2007-11-16 15:50   ` Daniel Lezcano
2007-11-16 17:14   ` Eric W. Biederman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.