On 10/17/2017 12:12 AM, Andrew Morton wrote: > On Mon, 16 Oct 2017 15:03:37 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
