Subject: Re: [RFC][PATCH] Prevent overriding of Symbols in the Kernel,
	avoiding Undefined behaviour
From: Rusty Russell <rusty@rustcorp.com.au>
To: Ashutosh Naik <ashutosh.naik@gmail.com>
Cc: Jesper Juhl <jesper.juhl@gmail.com>, anandhkrishnan@yahoo.co.in,
       linux-kernel@vger.kernel.org, rth@redhat.com, akpm@osdl.org,
       Greg KH <greg@kroah.com>, alan@lxorguk.ukuu.org.uk
In-Reply-To: <81083a450512132146g1177b457q5fd6cc5685a3d3b3@mail.gmail.com>
References: <81083a450512120439h69ccf938m12301985458ea69f@mail.gmail.com>
	 <1134424878.22036.13.camel@localhost.localdomain>
	 <81083a450512130626x417d86c9w31f300555c99fdb2@mail.gmail.com>
	 <9a8748490512130849o73c14313l166e6dd360f32d70@mail.gmail.com>
	 <1134525816.30383.13.camel@localhost.localdomain>
	 <81083a450512132146g1177b457q5fd6cc5685a3d3b3@mail.gmail.com>
Content-Type: text/plain
Date: Thu, 15 Dec 2005 10:02:07 +1100
Message-Id: <1134601327.7773.12.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1004
Lines: 25

On Wed, 2005-12-14 at 11:16 +0530, Ashutosh Naik wrote:
> On 12/14/05, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > We already do this to resolve (more) symbols, so I don't see it as a
> > problem.  However, I believe that lock is redundant here: we need both
> > locks to write the list, but either is sufficient for reading, and we
> > already hold the sem.
> 
> Was just wondering, in that case, if we really need the spinlock in
> resolve_symbol() function, where there exists a spinlock around the
> __find_symbol() function

Yes, I think that's redundant as well.  We're not altering the module
list itself, so either of the two locks is sufficient, and we have the
semaphore.

Patch welcome!
Rusty.
-- 
 ccontrol: http://ozlabs.org/~rusty/ccontrol

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/