From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE4BBC2D0BF for ; Tue, 17 Dec 2019 14:46:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 854802072D for ; Tue, 17 Dec 2019 14:46:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576594017; bh=fhMesn83IKAxNRDhgVHJgyYWKzv/CXg+cCNOfDYvvFo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=cinN5mrACP/sjvcZPRnse3kwKJtWCcLsXAvHMcpj9JbJ0jZ3Hwg9RKS2Q2nUIVlWL d1b/Yt+VuJfhTZ29IEde1TDlY6Wc/PyvSRsz5SqaJOG7KzAGouIFMt2t2cdSca7TW5 kOgyY8kiGOsgE0vCe8XBr0m59ivRqcZzos5dW8sI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729194AbfLQOq4 (ORCPT ); Tue, 17 Dec 2019 09:46:56 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:53665 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728573AbfLQOq4 (ORCPT ); Tue, 17 Dec 2019 09:46:56 -0500 Received: by mail-wm1-f66.google.com with SMTP id m24so3194020wmc.3; Tue, 17 Dec 2019 06:46:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tO9xCSowUipoQ7W1AR4AKa8ZqnZXGPs6Es0GLJPzMG4=; b=IRoB1LuyN3xZcturJXHUAGMtzDjEYCBSOQXVLpusA69ZYTAo474BvPCFfkYpiNy0mA 7zPlCzIG/XPnVLDmPurFkNqA9kPMAZaPH+V06WBgPJx+HUmImA5Fp9XamHOzPnRlxHg1 iXbFmSjK41q+RRu9Z+qYdZD8/Akl075zqZ3LGSD6+VhNadwf09eMdMhaZniATepOHyM2 HnndZlwDZojZLaL4SXtWYQ4vA7soFp5Pv1YgOMGSks6UXh8yaG8jtd9Gyd1dIUjk6J3C 4d8pYN+/mPuVGKyFF5D1HIvEbgn91JStU2WfMppRYEY9zIt4dcdxWFo65aTxs/PPITaT 6LbQ== X-Gm-Message-State: APjAAAXtLuWTlJY2RMsV2cXVnl7EZTXDS+rx/RhZWzOztS2AyMCU0v/M ptlmnc6Xi2Y0/dbzOX/SgVk= X-Google-Smtp-Source: APXvYqyQRDROOdlH8DpI5kAyQN88ZStAn4sknFkwi74VDSblzzh4EemeMlpYs4PM61Jl1NA5Lndw7g== X-Received: by 2002:a1c:c919:: with SMTP id f25mr5812629wmb.49.1576594013826; Tue, 17 Dec 2019 06:46:53 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id 5sm26063280wrh.5.2019.12.17.06.46.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2019 06:46:52 -0800 (PST) Date: Tue, 17 Dec 2019 15:46:52 +0100 From: Michal Hocko To: Qian Cai Cc: Chris Down , Kuninori Morimoto , Johannes Weiner , Vladimir Davydov , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: memcontrol.c: move mem_cgroup_id_get_many under CONFIG_MMU Message-ID: <20191217144652.GA7272@dhcp22.suse.cz> References: <20191217135440.GB58496@chrisdown.name> <392D7C59-5538-4A9B-8974-DB0B64880C2C@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <392D7C59-5538-4A9B-8974-DB0B64880C2C@lca.pw> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 17-12-19 09:16:36, Qian Cai wrote: > > > > On Dec 17, 2019, at 8:54 AM, Chris Down wrote: > > > > Let's just add __maybe_unused, since it seems like what we want in this scenario -- it avoids new users having to enter preprocessor madness, while also not polluting the build output. > > __maybe_unused should only be used in the last resort as it mark the compiler to catch the real issues in the future. In this case, it might be better just ignore it as only non-realistic compiling test would use !CONFIG_MMU in this case. yes, I would just ignore this warning. Btw. it seems that this is enabled by default for -Wall. Is this useful for kernel builds at all? Does it realistically help discovering real issues? If not then can we simply blacklist it? -- Michal Hocko SUSE Labs