Subject: Re: [PATCH] mm, oom: initiallize all new zap_details fields before
 use
To: Andrew Morton <akpm@linux-foundation.org>
References: <1450487091-7822-1-git-send-email-sasha.levin@oracle.com>
 <20151219195237.GA31380@node.shutemov.name> <5675D423.6020806@oracle.com>
 <20151221142438.cbd34f0e663a795e649cdfbc@linux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>, mhocko@suse.com,
        mgorman@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org
From: Sasha Levin <sasha.levin@oracle.com>
Message-ID: <5678A001.4040700@oracle.com>
Date: Mon, 21 Dec 2015 19:57:37 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151221142438.cbd34f0e663a795e649cdfbc@linux-foundation.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1105
Lines: 28

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/