From: "Denis V. Lunev" <dlunev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
"Denis V. Lunev" <den-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] [NETNS45] network namespace locking rules
Date: Fri, 28 Sep 2007 21:02:53 +0400 [thread overview]
Message-ID: <46FD33BD.9070305@gmail.com> (raw)
In-Reply-To: <m1d4w2d92m.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
Eric W. Biederman wrote:
> "Denis V. Lunev" <den-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> writes:
>
>> Current locking for network namespace list/initialization is broken.
>> for_each_net is called under single rtnl_lock in
>> register_netdevice_notifier.
>
> As of 984e617a3e1974022b8f671427a76ffbe886f75b this issue has
> been addressed in net-2.6.24
>
> The only remaining part to address is rtnl_unlock().
>
> My current hypothesis is that rtnl_unlock() only needs to process
> the packets that are queued while we had the rtnl_lock held,
> to maintain the current semantics.
>
> So the retry may not be necessary as it may be possible to prove
> that the only extra packets that could come in come from another
> thread taking the rtnl_lock and they will those packets in their
> rtnl_unlock() if we don't.
>
> I will review this later today, and add the retry if necessary.
>
> One way or another I think we agree on how to get the locking correct.
> The other details are a bit tricky but look usable.
>
> Eric
>
Unfortunately, the answer is 'no'. data_ready callback takes rtnl
inside, so we can have new packets from other namespaces during the
processing.
No way, but restart :(
Regards,
Den
prev parent reply other threads:[~2007-09-28 17:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-28 14:36 [PATCH] [NETNS45] network namespace locking rules Denis V. Lunev
[not found] ` <20070928143654.GA14129-aPCOdVxUTlgvJsYlp49lxw@public.gmane.org>
2007-09-28 15:10 ` Daniel Lezcano
[not found] ` <46FD196C.6080309-GANU6spQydw@public.gmane.org>
2007-09-28 16:33 ` Denis V. Lunev
2007-09-28 16:54 ` Eric W. Biederman
[not found] ` <m1d4w2d92m.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-09-28 17:02 ` Denis V. Lunev [this message]
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=46FD33BD.9070305@gmail.com \
--to=dlunev-re5jqeeqqe8avxtiumwx3w@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.