[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5678A001.4040700@oracle.com>
Date: Mon, 21 Dec 2015 19:57:37 -0500
From: Sasha Levin <sasha.levin@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>, mhocko@...e.com,
mgorman@...e.de, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm, oom: initiallize all new zap_details fields before
use
On 12/21/2015 05:24 PM, Andrew Morton wrote:
>>> Should we use c99 initializer instead to make it future-proof?
>> >
>> > I didn't do that to make these sort of failures obvious. In this case, if we would have
>> > used an initializer and it would default to the "wrong" values it would be much harder
>> > to find this bug.
>> >
> If we're to make that approach useful and debuggable we should poison
> the structure at the outset with some well-known and crazy pattern. Or
> use kasan.
We sort of do. Consider stack garbage as "poison"...
This bug was found using UBSan which complained that a bool suddenly had the
value of '64'.
If we go back to the scenario I've described, and the struct would have been
initialized on declaration, you'd have a much harder time finding it rather
than letting our existing and future tools find it.
Thanks,
Sasha
--
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/
Powered by blists - more mailing lists