[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwoWJMhdE7rG5LBy6vE=4BxYK1x=yoNeFB=5aKF8TZb7A@mail.gmail.com>
Date: Wed, 2 Nov 2011 11:10:27 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Simon Kirby <sim@...tway.ca>,
David Miller <davem@...emloft.net>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Dave Jones <davej@...hat.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Network Development <netdev@...r.kernel.org>
Subject: Re: Linux 3.1-rc9
On Wed, Nov 2, 2011 at 11:05 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> Yes, but only when tproxy is used, and in some obscure error
> conditions... Probably nobody ever hit them or complained.
Yes, I'm not disputing that. However, it does show how incredibly
fragile that code is.
May I suggest renaming those "clone_sk()" kinds of functions
"clone_sk_lock()" or something? So that you *see* that it's locked as
it is cloned. That might have made the bug not happen in the first
place..
Of course, maybe it's obvious to most net people - just not me looking
at the code - that the new socket ended up being locked at allocation.
But considering the bug happened twice, that "obvious" part is clearly
debatable..
Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists