* 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[parent not found: <473DA358.9040705-3ImXcnM4P+0@public.gmane.org>]
* 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.