From: Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
To: "Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
"Denis V. Lunev" <den-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
Benjamin Thery <benjamin.thery-6ktuUTfB/bM@public.gmane.org>
Cc: "container >> Linux Containers"
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: [RFD] net list protected by rcu
Date: Wed, 31 Oct 2007 15:42:13 +0100 [thread overview]
Message-ID: <47289445.1060108@fr.ibm.com> (raw)
Hi,
Benjamin and I, we are currently looking for using IPV6 for the network
namespaces.
There is a special case where we must browse the network namespace list
to check the routes ages at a given time for garbage collecting.
fib6_run_gc
=> fib6_clean_all
In this function we browse the network namespace list with the usual
macro: for_each_net, which should be protected by rtnl_lock.
The function fib6_run_gc is a timer callback, that means we are called
from interrupt handler. But in this case, we can not use rtnl_lock
because it locks a mutex and this is forbidden to do that from an
interrupt handler.
If we put apart the fact there is perhaps a better solution than
browsing the netns list (eg. make a gc timer per namespace), can we
consider to simply use the RCU to lock the network namespace list ?
So we can remove the rtnl_lock calls in the network namespaces and just
use rcu_read_lock for browsing the netns list in the network code. That
will be more flexible, we can use it in interrupt handler, we can nest
with another rcu_read_lock and we don't add more locking contention for
the network.
reply other threads:[~2007-10-31 14:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47289445.1060108@fr.ibm.com \
--to=dlezcano-nmtc/0zbporqt0dzr+alfa@public.gmane.org \
--cc=benjamin.thery-6ktuUTfB/bM@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=den-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.