Date: Sat, 15 Jan 2005 22:24:34 +0000
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: slab.c use of __get_user and sparse
Message-ID: <20050115222434.GO26051@parcelfarce.linux.theplanet.co.uk>
References: <20050115213906.GA22486@mars.ravnborg.org> <20050115220151.GA16442@wotan.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050115220151.GA16442@wotan.suse.de>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1140
Lines: 26

On Sat, Jan 15, 2005 at 11:01:51PM +0100, Andi Kleen wrote:
> > Based on the comment it is understood that suddenly this pointer points
> > to userspace, because the module got unloaded.
> > I wonder why we can rely on the same address now the module got unloaded -
> > we may risk this virtual address is taken over by someone else?
> 
> The address is not user space; you would be lying.
> 
> Perhaps it's best to get rid of the hack completely. Turn kmem_cache_t->name
> into an array and copy the name instead of storing the pointer, then
> it wouldn't be needed at all.

Alternatively, we could provide a new primitive -

size_t safe_memcpy(void *to, void *from, size_t size);

Semantics: copy byte-by-byte until we either get 'size' bytes or trigger an
exception.  Return the number of bytes copied.

Obvious implementation via __get_user() would be default, overridable by
architecture...
-
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/