All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: Michal Hocko <mhocko@kernel.org>
Cc: Qian Cai <cai@lca.pw>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	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
Date: Tue, 17 Dec 2019 15:09:21 +0000	[thread overview]
Message-ID: <20191217150921.GA136178@chrisdown.name> (raw)
In-Reply-To: <20191217144652.GA7272@dhcp22.suse.cz>

Michal Hocko writes:
>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?

There's no way we're the first people to encounter these problems, so what did 
we do in the past when situations like this (adding a generic API which is not 
yet used by non-configurable code) came up, and in retrospect did they work 
well?

As far as I know -Wunused-function also guards against other errors, like when 
a function is prototyped but not actually defined, which might be more useful 
to know about.

(Side note: I'm moderately baffled that a tightly scoped __maybe_unused is 
considered sinister but somehow disabling -Wunused-function is on the table 
:-))

  parent reply	other threads:[~2019-12-17 15:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17  6:47 [PATCH] mm: memcontrol.c: move mem_cgroup_id_get_many under CONFIG_MMU Kuninori Morimoto
2019-12-17  9:53 ` Michal Hocko
2019-12-17 13:54   ` Chris Down
2019-12-17 14:16     ` Qian Cai
2019-12-17 14:37       ` Chris Down
2019-12-17 15:09         ` Qian Cai
2019-12-17 14:46       ` Michal Hocko
2019-12-17 15:04         ` Qian Cai
2019-12-17 15:13           ` Michal Hocko
2019-12-17 15:17             ` Qian Cai
2019-12-17 15:09         ` Chris Down [this message]
2019-12-17 15:19           ` Michal Hocko
2019-12-17 15:28             ` Chris Down
2019-12-17 15:32               ` Chris Down
2019-12-17 15:34               ` Qian Cai
2019-12-17 15:46               ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191217150921.GA136178@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=akpm@linux-foundation.org \
    --cc=cai@lca.pw \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=vdavydov.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.