linux-kernel - Re: [PATCH v2 03/10] slab: move up code to get kmem_cache_node in free

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.02.1405071502040.25024@chino.kir.corp.google.com>
Date:	Wed, 7 May 2014 15:05:22 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	George Spelvin <linux@...izon.com>
cc:	cl@...ux.com, iamjoonsoo.kim@....com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH v2 03/10] slab: move up code to get kmem_cache_node in
 free_block()

On Wed, 7 May 2014, George Spelvin wrote:

> > I think this unnecessarily obfuscates the code.
> 
> Thanks for the feedback!  (Even if it's negative, I appreciate it.)
> 
> To me, the confusing thing is the whole passing-a-pointer-to-a-pointer
> business.  How about the following, which makes set_obj_pfmemalloc and
> clear_obj_pfmemalloc take void *, not void **?  Is this better, or worse?
> 

A function called clear_obj_pfmemalloc() doesn't indicate it's returning 
anything, I think the vast majority of people would believe that it 
returns void just as it does.  There's no complier generated code 
optimization with this patch and I'm not sure it's even correct since 
you're now clearing after doing recheck_pfmemalloc_active().

I think it does make sense to remove the pointless "return;" in 
set_obj_pfmemalloc(), however.  Not sure it's worth asking someone to 
merge it, though.
--
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/