From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751900AbcFWKl3 (ORCPT ); Thu, 23 Jun 2016 06:41:29 -0400 Received: from outbound-smtp04.blacknight.com ([81.17.249.35]:49806 "EHLO outbound-smtp04.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751638AbcFWKl2 (ORCPT ); Thu, 23 Jun 2016 06:41:28 -0400 Date: Thu, 23 Jun 2016 11:41:24 +0100 From: Mel Gorman To: Arnd Bergmann Cc: Vlastimil Babka , Johannes Weiner , Rik van Riel , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC, DEBUGGING 1/2] mm: pass NR_FILE_PAGES/NR_SHMEM into node_page_state Message-ID: <20160623104124.GR1868@techsingularity.net> References: <20160623100518.156662-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20160623100518.156662-1-arnd@arndb.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 23, 2016 at 12:05:17PM +0200, Arnd Bergmann wrote: > I see some new warnings from a recent mm change: > > mm/filemap.c: In function '__delete_from_page_cache': > include/linux/vmstat.h:116:2: error: array subscript is above array bounds [-Werror=array-bounds] > atomic_long_add(x, &zone->vm_stat[item]); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > include/linux/vmstat.h:116:35: error: array subscript is above array bounds [-Werror=array-bounds] > atomic_long_add(x, &zone->vm_stat[item]); > ~~~~~~~~~~~~~^~~~~~ > include/linux/vmstat.h:116:35: error: array subscript is above array bounds [-Werror=array-bounds] > include/linux/vmstat.h:117:2: error: array subscript is above array bounds [-Werror=array-bounds] > > Looking deeper into it, I find that we pass the wrong enum > into some functions after the type for the symbol has changed. > > This changes the code to use the other function for those that > are using the incorrect type. I've done this blindly just going > by warnings I got from a debug patch I did for this, so it's likely > that some cases are more subtle and need another change, so please > treat this as a bug-report rather than a patch for applying. > I have an alternative fix for this in a private tree. For now, I've asked Andrew to withdraw the series entirely as there are non-trivial collisions with OOM detection rework and huge page support for tmpfs. It'll be easier and safer to resolve this outside of mmotm as it'll require a full round of testing which takes 3-4 days. Thanks. -- Mel Gorman SUSE Labs