linux-kernel - Re: [PATCH] staging: lustre: replace kzalloc with copy_from_user with memdup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1504032151120.2078@localhost6.localdomain6>
Date:	Fri, 3 Apr 2015 21:51:21 +0200 (CEST)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	"Drokin, Oleg" <oleg.drokin@...el.com>
cc:	Julia Lawall <Julia.Lawall@...6.fr>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Dhere, Chaitanya (C.)" <cvijaydh@...teon.com>,
	"Dilger, Andreas" <andreas.dilger@...el.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	"Xiong, Jinshan" <jinshan.xiong@...el.com>,
	"aybuke.147@...il.com" <aybuke.147@...il.com>,
	"Hammond, John" <john.hammond@...el.com>,
	"HPDD-discuss@...ts.01.org" <HPDD-discuss@...1.01.org>,
	"<devel@...verdev.osuosl.org>" <devel@...verdev.osuosl.org>,
	"<linux-kernel@...r.kernel.org> Mailing List" 
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] staging: lustre: replace kzalloc with copy_from_user
 with memdup_user



On Fri, 3 Apr 2015, Drokin, Oleg wrote:

> Hello!
> 
> On Apr 2, 2015, at 6:18 AM, Julia Lawall wrote:
> 
> >> Julia, I wonder if you happen to have a bunch of other patches to get rid of the rest of OBD_ALLOC and OBD_FREE stuff by any chance?
> > I can generate them again, but I wasn't clear on what was wanted.  I would
> > really prefer something where it is explicit at the call site that an
> > assignment is taking place.  If we can have x = obd_alloc(...) and
> > obd_free(x,...) (I don't have time to look up the exact arguments at the
> > moment), then I can take care of that).  I still think it is too bad that
> > this code won't benefit from rules written for more generic memory
> > allocation functions, but if the extra debugging facility provided by
> > these functions is useful, then I guess it is reasonable to keep it.
> 
> Like I mentioned sometime last year - it's now pretty easy to replace the memleak
> detection with other in-kernel mechanisms some of which are in fact even better
> than what we have. And considering our mechanisms are totally broken now by the mixup of
> wrapped vs nonwrapped allocation/freeing - there's no point in holding to it remaining at all.
> The only last bit of useful functionality left, I imagine, is the ability to redirect allocation
> to regular kmalloc or to vmalloc based on the allocation size (there's kvfree already for the
> freeing part of it).
> Other than that the wrappers could go away at any time now, I think.

OK, thanks.

julia
--
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/