linux-kernel - Re: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.11.1506092056570.6964@east.gentwo.org>
Date:	Tue, 9 Jun 2015 21:00:58 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Minchan Kim <minchan@...nel.org>,
	Pekka Enberg <penberg@...nel.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Michal Hocko <mhocko@...e.cz>,
	David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, sergey.senozhatsky.work@...il.com,
	Joe Perches <joe@...ches.com>
Subject: Re: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy()
 functions

On Tue, 9 Jun 2015, Andrew Morton wrote:

> > Why do this at all?
>
> For the third time: because there are approx 200 callsites which are
> already doing it.

Did some grepping and I did see some call sites that do this but the
majority has to do other processing as well.

200 call sites? Do we have that many uses of caches? Typical prod system
have ~190 caches active and the merging brings that down to half of that.

> 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.

Well that may just indicate that we need to have a look at those
callsites and the reason there to use a special cache at all. If the cache
is just something that kmalloc can provide then why create a special
cache. On the other hand if something special needs to be accomplished
then it would make sense to have special processing on kmem_cache_destroy.
--
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/