From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932582AbbFJBtD (ORCPT ); Tue, 9 Jun 2015 21:49:03 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:39041 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752658AbbFJBs5 (ORCPT ); Tue, 9 Jun 2015 21:48:57 -0400 Date: Tue, 9 Jun 2015 18:51:50 -0700 From: Andrew Morton To: Christoph Lameter Cc: Sergey Senozhatsky , Minchan Kim , Pekka Enberg , Joonsoo Kim , Michal Hocko , David Rientjes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, sergey.senozhatsky.work@gmail.com, Joe Perches Subject: Re: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions Message-Id: <20150609185150.8c9fed8d.akpm@linux-foundation.org> In-Reply-To: References: <1433851493-23685-1-git-send-email-sergey.senozhatsky@gmail.com> <20150609142523.b717dba6033ee08de997c8be@linux-foundation.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 9 Jun 2015 20:11:25 -0500 (CDT) Christoph Lameter wrote: > On Tue, 9 Jun 2015, Andrew Morton wrote: > > > Well I like it, even though it's going to cause a zillion little cleanup > > patches. > > > > checkpatch already has a "kfree(NULL) is safe and this check is > > probably not required" test so I guess Joe will need to get busy ;) > > > > I'll park these patches until after 4.1 is released - it's getting to > > that time... > > Why do this at all? For the third time: because there are approx 200 callsites which are already doing it. > I understand that kfree/kmem_cache_free can take a > null pointer but this is the destruction of a cache and it usually > requires multiple actions to clean things up and these actions have to be > properly sequenced. All other processors have to stop referencing this > cache before it can be destroyed. I think failing if someone does > something strange like doing cache destruction with a NULL pointer is > valuable. More than half of the kmem_cache_destroy() callsites are declining that value by open-coding the NULL test. That's reality and we should recognize it.