From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753314AbbDCTv2 (ORCPT ); Fri, 3 Apr 2015 15:51:28 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:44155 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752130AbbDCTvZ (ORCPT ); Fri, 3 Apr 2015 15:51:25 -0400 X-IronPort-AV: E=Sophos;i="5.11,519,1422918000"; d="scan'208";a="108294276" Date: Fri, 3 Apr 2015 21:51:21 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@localhost6.localdomain6 To: "Drokin, Oleg" cc: Julia Lawall , Greg Kroah-Hartman , "Dhere, Chaitanya (C.)" , "Dilger, Andreas" , Al Viro , "Xiong, Jinshan" , "aybuke.147@gmail.com" , "Hammond, John" , "HPDD-discuss@lists.01.org" , "" , " Mailing List" Subject: Re: [PATCH] staging: lustre: replace kzalloc with copy_from_user with memdup_user In-Reply-To: <9F3C271F-637B-4A70-B9EF-E806D5CC3B64@intel.com> Message-ID: References: <20150331150933.GA2833@chaitanya-Ideapad-Z560> <20150331155756.GA12842@kroah.com> <9F3C271F-637B-4A70-B9EF-E806D5CC3B64@intel.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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