linux-kernel - Re: [PATCH] slab: fix slab flags for archs use alignment larger 64-bit

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:	Fri, 13 Feb 2009 11:46:50 +0100
From:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Paul Mundt <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org,
	linux-sh@...r.kernel.org, linux-mm@...r.kernel.org,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [PATCH] slab: fix slab flags for archs use alignment larger 
 64-bit

Hi Pekka,
thanks for your prompt feedback.
Feel free to ask again if you need some other information.

Peppe

Kernel 2.6.23.17
=============================================
1) LOG with my patch:
root@...ux:~# cat /proc/meminfo | grep Slab
Slab:             2612 kB

root@...ux:~# cat /proc/slab_allocators
rpc_buffers: 8 mempool_alloc_slab+0x10/0x1c
rpc_tasks: 11 mempool_alloc_slab+0x10/0x1c
rpc_inode_cache: 10 rpc_alloc_inode+0x10/0x2c
...
anon_vma: 62 anon_vma_prepare+0x38/0xd4
pid: 20 alloc_pid+0x1e/0x2cc
size-2048: 1 tty_write+0xac/0x1d8
size-2048: 1 alloc_netdev_mq+0x40/0xbc
...

=============================================
2) LOG without my patch:
root@...ux:~# cat /proc/meminfo | grep Slab
Slab:             2504 kB

root@...ux:~# cat /proc/slab_allocators
rpc_buffers: 8 mempool_alloc_slab+0x10/0x1c
rpc_tasks: 11 mempool_alloc_slab+0x10/0x1c
rpc_inode_cache: 10 rpc_alloc_inode+0x10/0x2c
...
pid: 20 alloc_pid+0x1e/0x2cc

Pekka Enberg wrote:
> Hi Giuseppe,
>
> On Fri, Feb 13, 2009 at 12:00 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@...com> wrote:
>   
>> IIUC, and as you explained above, ralign is already set to the cache
>> line size by the following code:
>> ...
>> /* 3) caller mandated alignment */
>> if (ralign < align)
>> ralign = align;
>>
>> Then, there is following check:
>> ...
>> /* disable debug if necessary */
>> if (ralign > _alignof__(unsigned long long))
>> flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
>>
>> In my point of view, just this check appears "incoherent" (please, note
>> I'm not familiar with the slab internals).
>> It always makes sense in case of x86 where ARCH_KMALLOC_MINALIGN is
>> defined as: __alignof__(unsigned long long) as well.
>>     
>
> The code is indeed quite cryptic but I don't think the above statement
> is correct. Both SLAB_RED_ZONE and SLAB_STORE_USER add padding in
> front of an object and the maximum size of that padding is 2 *
> sizeof(unsigned long long). That's why we check for
> __alignof__(unsigned long) there to make sure the object can begin
> immediately after the padding added for red-zone and user pointer.
>
> On Fri, Feb 13, 2009 at 12:00 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@...com> wrote:
>   
>> In case of sh, we always disable debug for 32 aligned objects. As side
>> effect, within the leaks_show function we immediately exit for them.
>> Indeed, after applying the patch, I attached, I was able to find size-X
>> fields within the slab_allocators proc entry.
>>     
>
> That sounds unfortunate. Can you post
>
>   cat /proc/meminfo | grep Slab
>
> results on sh without and with your patch? Bumping the limit up to
> ARCH_KMALLOC_MINALIGN does make sense but we'd need to know what kind
> of problems it might cause.
>
>                                 Pekka
>
>   

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