linux-kernel - Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache

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.00.1207171005550.15061@router.home>
Date:	Tue, 17 Jul 2012 10:11:56 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Pekka Enberg <penberg@...nel.org>
cc:	David Rientjes <rientjes@...gle.com>,
	Shuah Khan <shuah.khan@...com>, glommer@...allels.com,
	js1304@...il.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	shuahkhan@...il.com
Subject: Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache_create()

On Tue, 17 Jul 2012, Pekka Enberg wrote:

> Well, even SLUB checks for !name in mainline so that's definitely
> worth including unconditionally. Furthermore, the size related checks
> certainly make sense and I don't see any harm in having them as well.

There is a WARN_ON() there and then it returns NULL!!! Crazy. Causes a
NULL pointer dereference later in the caller?

> As for "in_interrupt()", I really don't see the point in keeping that
> around. We could push it down to mm/slab.c in "__kmem_cache_create()"
> if we wanted to.

Ok we could do that but I guess we are in the discussion of how much
checking should be done for a production kernel.

I think these checks are way out of hand. We cannot afford to
consistently check parameters to all kernel functions in production. We
will only do these checks in a select manner if these values could
result in serious difficult to debug problems. The checks in slab look
like debugging code that someone needed for a specific debugging scenario.

I can understand that we would keep that in for development but not for
production. Maybe I am a bit biased but my prod kernels need to have
minimal memory footprint due to excessive code size causing regressions.

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