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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 16 Jul 2012 15:14:15 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	David Rientjes <rientjes@...gle.com>
cc:	Shuah Khan <shuah.khan@...com>, Pekka Enberg <penberg@...nel.org>,
	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 Mon, 16 Jul 2012, David Rientjes wrote:

> > These checks are useless for regular kernel operations. They are
> > only useful when developing code and should only be enabled during
> > development. There is no point in testing the size and the name which are
> > typically constant when a slab is created with a stable kernel.
> >
>
> Sounds like a response from someone who is very familiar with slab
> allocators.  The reality, though, is that very few people are going to be
> doing development with CONFIG_DEBUG_VM enabled unless they notice problems
> beforehand.

Kernels are certainly run with CONFIG_DEBUG_VM before merges to mainstream
occur. If the developer does not do it then someone else will.

> Are you seriously trying to optimize kmem_cache_create()?  These checks
> certainly aren't going to hurt your perfromance and it seems appropriate
> to do some sanity checking before blowing up in unexpected ways.  It's
> also the way it's been done for years before extracting common allocator
> functions to their own file.

The kernel cannot check everything and will blow up in unexpected ways if
someone codes something stupid. There are numerous debugging options that
need to be switched on to get better debugging information to investigate
deper. Adding special code to replicate these checks is bad.

Frankly, these checks are there only for legacy reasons in the common code
due to SLAB having them. Checking for NULL pointers is pretty useless
since any dereference will cause a oops that will show where this
occurred.

The other checks are of the same order of uselessness. The interrupt check
f.e. is nonsense since the first attempt to acquire the slab
futex will trigger another exception.

I would suggest to rather drop these checks entirely. SLUB never had these
braindead things in them and has been in use for quite a long time.

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