Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965055AbbLSWDc (ORCPT ); Sat, 19 Dec 2015 17:03:32 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:49856 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932130AbbLSWDb (ORCPT ); Sat, 19 Dec 2015 17:03:31 -0500 Subject: Re: [PATCH] mm, oom: initiallize all new zap_details fields before use To: "Kirill A. Shutemov" References: <1450487091-7822-1-git-send-email-sasha.levin@oracle.com> <20151219195237.GA31380@node.shutemov.name> Cc: akpm@linux-foundation.org, mhocko@suse.com, mgorman@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Sasha Levin Message-ID: <5675D423.6020806@oracle.com> Date: Sat, 19 Dec 2015 17:03:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151219195237.GA31380@node.shutemov.name> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1403 Lines: 34 On 12/19/2015 02:52 PM, Kirill A. Shutemov wrote: > On Fri, Dec 18, 2015 at 08:04:51PM -0500, Sasha Levin wrote: >> > Commit "mm, oom: introduce oom reaper" forgot to initialize the two new fields >> > of struct zap_details in unmap_mapping_range(). This caused using stack garbage >> > on the call to unmap_mapping_range_tree(). >> > >> > Signed-off-by: Sasha Levin >> > --- >> > mm/memory.c | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/mm/memory.c b/mm/memory.c >> > index 206c8cd..0e32993 100644 >> > --- a/mm/memory.c >> > +++ b/mm/memory.c >> > @@ -2431,6 +2431,7 @@ void unmap_mapping_range(struct address_space *mapping, >> > details.last_index = hba + hlen - 1; >> > if (details.last_index < details.first_index) >> > details.last_index = ULONG_MAX; >> > + details.check_swap_entries = details.ignore_dirty = false; > 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. 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/