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]

Date:	7 May 2014 21:46:36 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	linux@...izon.com, rientjes@...gle.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()

(Oops, previous e-mail was sent halfway through composition in error.)

> I'm not sure it's even correct since 
> you're now clearing after doing recheck_pfmemalloc_active().

I thought this through before rearranging the code.
recheck_pfmemalloc_active() checks global lists, but __ac_get_obj()
is doing clear_obj_pfmemalloc on a local variable.  So it
can't affect recheck_pfmemalloc_active().

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

Perhaps the name needs to be modified, but it's still pretty clear.
It just clears the bit in its argument and returns it, as opposed to
operating in-place.

In particular, when reading the code that calls it, there is obviously
a return value.  What could it possibly be?

> There's no complier generated code optimization with this patch

On that subject, you're absolutely correct:
   text    data     bss     dec     hex filename
  10635     939       4   11578    2d3a mm/slab.o.before
  10635     939       4   11578    2d3a mm/slab.o.after

If I don't have CONFIG_CC_OPTIMIZE_FOR_SIZE=y, the padding NOPs after
unconditional jumps get aligned a little differently and it actually
gets bigger.

   text    data     bss     dec     hex filename
  12958    1079       4   14041    36d9 mm/slab.o.before
  12990    1079       4   14073    36f9 mm/slab.o.after

__ac_get_obj actually spills one fewer register in this case, and
the code paths seem a little cleaner, but I haven't gone through
it completely.
--
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/