linux-kernel - Re: [patch] mm, compaction: properly initialize alloc_flags in compact

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] [day] [month] [year] [list]

Message-ID: <cf51bc1a-8e12-8c91-3012-238a65ce1c55@suse.cz>
Date:   Tue, 17 Oct 2017 08:51:07 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        David Rientjes <rientjes@...gle.com>
Cc:     Joonsoo Kim <iamjoonsoo.kim@....com>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [patch] mm, compaction: properly initialize alloc_flags in
 compact_control

On 10/17/2017 12:12 AM, Andrew Morton wrote:
> On Mon, 16 Oct 2017 15:03:37 -0700 (PDT) David Rientjes <rientjes@...gle.com> wrote:
> 
>>
>> compaction_suitable() requires a useful cc->alloc_flags, otherwise the
>> results of compact_zone() can be indeterminate.  Kcompactd currently
>> checks compaction_suitable() itself with alloc_flags == 0, but passes an
>> uninitialized value from the stack to compact_zone(), which does its own
>> check.
>>
>> The same is true for compact_node() when explicitly triggering full node
>> compaction.
>>
>> Properly initialize cc.alloc_flags on the stack.
>>
> 
> The compiler will zero any not-explicitly-initialized fields in these
> initializers.

Right.

>> @@ -1945,8 +1947,8 @@ static void kcompactd_do_work(pg_data_t *pgdat)
>>  		if (compaction_deferred(zone, cc.order))
>>  			continue;
>>  
>> -		if (compaction_suitable(zone, cc.order, 0, zoneid) !=
>> -							COMPACT_CONTINUE)
>> +		if (compaction_suitable(zone, cc.order, cc.alloc_flags,
>> +					zoneid) != COMPACT_CONTINUE)
>>  			continue;
> 
> So afaict the above hunk is the only functional change here.  It will
> propagate any of compact_zone()'s modifications to cc->alloc_flags into
> succeeding calls to compaction_suitable().  I suspect this is a
> no-op (didn't look), and it wasn't changelogged.

compact_zone() shouldn't modify cc->alloc_flags. Actually, it's even
declared as "const" in struct compact_control.