From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754103AbdLNSQT (ORCPT <rfc822;w@1wt.eu>);
        Thu, 14 Dec 2017 13:16:19 -0500
Received: from gum.cmpxchg.org ([85.214.110.215]:54794 "EHLO gum.cmpxchg.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753698AbdLNSQS (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 14 Dec 2017 13:16:18 -0500
Date: Thu, 14 Dec 2017 13:16:08 -0500
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Paul Menzel <pmenzel+linux-cgroups@molgen.mpg.de>,
        Vladimir Davydov <vdavydov.dev@gmail.com>, cgroups@vger.kernel.org,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        it+linux-cgroups@molgen.mpg.de
Subject: Re: mm/memcontrol.c:5364:1: warning: the frame size of 1032 bytes is
 larger than 1024 bytes [-Wframe-larger-than=]
Message-ID: <20171214181608.GA2476@cmpxchg.org>
References: <a16d8181-3bb4-90cc-3c4b-ac44529494ed@molgen.mpg.de>
 <20171214091917.GE16951@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20171214091917.GE16951@dhcp22.suse.cz>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Dec 14, 2017 at 10:19:17AM +0100, Michal Hocko wrote:
> On Thu 14-12-17 07:49:29, Paul Menzel wrote:
> > I enabled the undefined behavior sanitizer, and built Linus’ master branch
> > under Ubuntu 17.10 with gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0.
> > 
> > ```
> > $ grep UBSAN /boot/config-4.15.0-rc3+
> > CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
> > # CONFIG_ARCH_WANTS_UBSAN_NO_NULL is not set
> > CONFIG_UBSAN=y
> > CONFIG_UBSAN_SANITIZE_ALL=y
> > # CONFIG_UBSAN_ALIGNMENT is not set
> > CONFIG_UBSAN_NULL=y

> But this depends on the configuration because NR_VM_EVENT_ITEMS enables
> some counters depending on the config. The stack is really large but
> this is a function which is called from a shallow context wrt. stack so
> we should fit into a single page. One way we could do, though, is to
> make those large arrays static and use a internal lock around them.
> Something like the following. What do you think Johannes?

As you said, this is a very shallow stack. Why introduce a global lock
to save memory, when we have a statically allocated 16k kernel stack
which we know is plenty for that call chain? It introduces a potential
bottleneck for nothing in return.