[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4DA33E1E.701@parallels.com>
Date: Mon, 11 Apr 2011 12:45:02 -0500
From: Rob Landley <rlandley@...allels.com>
To: Alexey Dobriyan <adobriyan@...il.com>
CC: "Serge E. Hallyn" <serge@...lyn.com>,
<linux-kernel@...r.kernel.org>, <linux-nfs@...r.kernel.org>,
<containers@...ts.linux-foundation.org>,
Trond Myklebust <Trond.Myklebust@...app.com>,
Tim Spriggs <tims@...irise.org>,
Kir Kolyshkin <kir@...allels.com>,
Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [PATCH 3/3] Compare namespaces when comparing addresses in auth_unix
cache.
On 04/11/2011 08:57 AM, Alexey Dobriyan wrote:
> On Mon, Apr 11, 2011 at 4:36 PM, Serge E. Hallyn <serge@...lyn.com> wrote:
>
>> Besides use-after-free, the other concern is an invalid net_eq()
>> result due to the * being re-used for a new netns.
>
> Exactly.
>
> "struct net" dies last, no exceptions, anything different is a disaster.
Actually the patch turns out to be irrelevant because Pavel made the
whole thing into a pernet subsystem, so it was already fixed in a
different way. (Commit 2f72c9b7. My bad, I initially started working
against an NFS tree with an older kernel version, this fix was to a
different source file so my patch still applied, and I just regression
tested that it worked, not that it still failed without it. Just caught
it now.)
I actually did talk about addressing potential reuse of the net * in my
email with Stanislav (point of the patch was to allow one cache to
maintain two different contexts at the same time; a situation that
changed the meaning of an existing cache entry by requiring the old
context to go away didn't introduce any new problems that a single
context didn't already have due to DNAT, servers moving, administrators
changing credentials on the server). But sort of a moot point now.
I believe the third patch can be dropped entirely.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists