linux-kernel - Re: [PATCH v2] mm/sparse.c: Use kvmalloc_node/kvfree to alloc/free memmap for the classic sparse

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: <c5b8328f-a46f-6f5b-2ef0-e1d8a375fa8e@suse.cz>
Date:   Fri, 13 Mar 2020 15:46:28 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Matthew Wilcox <willy@...radead.org>,
        Wei Yang <richard.weiyang@...il.com>
Cc:     Baoquan He <bhe@...hat.com>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, mhocko@...e.com, akpm@...ux-foundation.org,
        david@...hat.com
Subject: Re: [PATCH v2] mm/sparse.c: Use kvmalloc_node/kvfree to alloc/free
 memmap for the classic sparse

On 3/13/20 1:00 AM, Matthew Wilcox wrote:
> On Thu, Mar 12, 2020 at 10:50:55PM +0000, Wei Yang wrote:
>> On Thu, Mar 12, 2020 at 07:25:35AM -0700, Matthew Wilcox wrote:
>> >Yes, I thought about that.  I decided it wasn't a problem, as long as
>> >the struct page remains aligned, and we now have a guarantee that allocations
>> >above 512 bytes in size are aligned.  With a 64 byte struct page, as long
>> 
>> Where is this 512 bytes condition comes from?
> 
> Filesystems need to do I/Os from kmalloc addresses and those I/Os need to
> be 512 byte aligned.

To clarify, the guarantee exist for every power of two size. The I/O usecase was
part of the motivation for the guarantee, but there is not 512 byte limit. But
that means there is also no guarantee for a non-power-of-two size above (or
below) 512 bytes. Currently this only matters for sizes that fall into the 96
byte or 192 byte caches. With SLOB it can be any size.

So what I'm saying the allocations should make sure they are power of two and
then they will be aligned. The page size of 64bytes depends on some debugging
options being disabled, right?

>> >as we're allocating at least 8 pages, we know it'll be naturally aligned.
>> >
>> >Your calculation doesn't take into account the size of struct page.
>> >128M / 64k is indeed 2k, but you forgot to multiply by 64, which takes
>> >us to 128kB.
>> 
>> You are right. While would there be other combination? Or in the future?
>> 
>> For example, there are definitions of
>> 
>> #define SECTION_SIZE_BITS       26
>> #define SECTION_SIZE_BITS       24
>> 
>> Are we sure it won't break some thing?
> 
> As I said, once it's at least 512 bytes, it'll be 512 byte aligned.  And I
> can't see us having sections smaller than 8 pages, can you?
>