linux-kernel - Re: [PATCH 5/8] mm/slub: Factor out some common code.

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.1103161352150.11002@chino.kir.corp.google.com>
Date:	Wed, 16 Mar 2011 14:51:16 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	George Spelvin <linux@...izon.com>
cc:	herbert@...dor.hengli.com.au, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, mpm@...enic.com,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [PATCH 5/8] mm/slub: Factor out some common code.

On Wed, 16 Mar 2011, George Spelvin wrote:

> > Where's your signed-off-by?
> 
> Somewhere under the pile of crap on my desk. :-)
> (More to the point, waiting for me to think it's good enough to submit
> For Real.)
> 

Patches that you would like to propose but don't think are ready for merge 
should have s/PATCH/RFC/ done on the subject line.

> > Nice cleanup.
> > 
> > "flag" should be unsigned long in all of these functions: the constants 
> > are declared with UL suffixes in slab.h.
> 
> Actually, I did that deliberately.  Because there's a problem I keep
> wondering about, which repeats many many times in the kernel:
> 

You deliberately created a helper function to take an unsigned int when 
the actuals being passed in are all unsigned long to trigger a discussion 
on why they are unsigned long?

> *Why* are they unsigned long?  That's an awkward type: 32 bits on many
> architectures, so we can't portably assign more than 32 bits, and on
> platforms where it's 64 bits, the upper 32 are just wasting space.
> (And REX prefixes on x86-64.)
> 

unsigned long uses the native word size of the architecture which can 
generate more efficient code; we typically imply that flags have a limited 
size by including leading zeros in their definition for 32-bit 
compatibility:

#define SLAB_DEBUG_FREE         0x00000100UL    /* DEBUG: Perform (expensive) checks on free */
#define SLAB_RED_ZONE           0x00000400UL    /* DEBUG: Red zone objs in a cache */
#define SLAB_POISON             0x00000800UL    /* DEBUG: Poison objects */
...
--
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/