linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhangshaokun <zhangshaokun@hisilicon.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>,
	Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: build warning after merge of the akpm-current tree
Date: Fri, 17 Nov 2017 17:36:44 +0800	[thread overview]
Message-ID: <24a5b70c-aac4-29b5-6a4d-38ac3d10d475@hisilicon.com> (raw)
In-Reply-To: <20171117145320.714972ca@canb.auug.org.au>

Hi,

On 2017/11/17 11:53, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote:  
>>>> On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:    
>>>>>
>>>>> After merging the akpm-current tree, today's linux-next build (powerpc
>>>>> ppc64_defconfig) produced this warning:
>>>>>
>>>>> In file included from include/linux/mmzone.h:17:0,
>>>>>                  from include/linux/mempolicy.h:10,
>>>>>                  from mm/mempolicy.c:70:
>>>>> mm/mempolicy.c: In function 'mpol_to_str':
>>>>> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
>>>>>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
>>>>>                                          ^
>>>>> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>>>>>            nodemask_pr_args(&nodes));
>>>>>            ^    
>>>>
>>>> Hmm, this warning is quite surprising to me. Sure in this particular
>>>> case maskp will always be non-NULL so we always expand to
>>>>         MAX_NUMNODES, maskp->bits
>>>> which is what we want. But we have other users which may be NULL. Does
>>>> anybody understan why this warns at all?    
>>>
>>> As I understand it, the warning tries to address a common typo of accidentally
>>> testing the pointer to a stack object for being non-NULL, rather than the object
>>> pointed to for being non-zero.
>>>
>>> Adding an extra '!= NULL' comparison gets rid of the warning for me:
>>>
>>> #define nodemask_pr_args(maskp)  \
>>>    ((maskp) != NULL) ? MAX_NUMNODES : 0, \
>>>    ((maskp) != NULL) ?(maskp)->bits : NULL
>>>
>>>        Arnd  
>>
>> This warning now exists in Linus' tree :-(
> 
> Looking closer, it seems that the above workaround doesn't work for my
> compiler (gcc v5.2.0):
> 

I also came across this issue using Linus' tree and my gcc is gcc version 5.4.0 20160609
 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.5).

  CC      drivers/clk/renesas/rcar-gen3-cpg.o
In file included from ./include/linux/mmzone.h:17:0,
                 from ./include/linux/mempolicy.h:10,
                 from mm/mempolicy.c:70:
mm/mempolicy.c: In function ‘mpol_to_str’:
./include/linux/nodemask.h:108:11: warning: the comparison will always evaluate as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress]
  ((maskp) != NULL) ? MAX_NUMNODES : 0,  \
           ^
mm/mempolicy.c:2817:11: note: in expansion of macro ‘nodemask_pr_args’
           nodemask_pr_args(&nodes));
           ^
./include/linux/nodemask.h:109:11: warning: the comparison will always evaluate as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress]
  ((maskp) != NULL) ? (maskp)->bits : NULL
           ^
mm/mempolicy.c:2817:11: note: in expansion of macro ‘nodemask_pr_args’
           nodemask_pr_args(&nodes));
           ^
  CC      drivers/clk/renesas/renesas-cpg-mssr.o

Thanks,
Shaokun

> In file included from include/linux/mmzone.h:17:0,
>                  from include/linux/mempolicy.h:10,
>                  from mm/mempolicy.c:70:
> mm/mempolicy.c: In function 'mpol_to_str':
> include/linux/nodemask.h:108:11: warning: the comparison will always evaluate as 'true' for the address of 'nodes' will never be NULL [-Waddress]
>   ((maskp) != NULL) ? MAX_NUMNODES : 0,  \
>            ^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>            nodemask_pr_args(&nodes));
>            ^
> include/linux/nodemask.h:109:11: warning: the comparison will always evaluate as 'true' for the address of 'nodes' will never be NULL [-Waddress]
>   ((maskp) != NULL) ? (maskp)->bits : NULL
>            ^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>            nodemask_pr_args(&nodes));
>            ^
> 

  reply	other threads:[~2017-11-17  9:37 UTC|newest]

Thread overview: 160+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13  5:42 linux-next: build warning after merge of the akpm-current tree Stephen Rothwell
2017-11-13  8:09 ` Michal Hocko
2017-11-13  8:23   ` Michal Hocko
2017-11-13 11:43   ` Arnd Bergmann
2017-11-13 11:54     ` Michal Hocko
2017-11-13 12:24       ` Arnd Bergmann
2017-11-13 12:29       ` Michal Hocko
2017-11-16 22:44     ` Stephen Rothwell
2017-11-17  3:53       ` Stephen Rothwell
2017-11-17  9:36         ` Zhangshaokun [this message]
2017-11-17  9:56         ` Arnd Bergmann
2017-11-17 10:15           ` [PATCH] mm: fix nodemask printing Arnd Bergmann
2017-11-20  8:22             ` Michal Hocko
2017-11-20 11:33               ` Arnd Bergmann
  -- strict thread matches above, loose matches on Subject: below --
2022-04-27  6:41 linux-next: build warning after merge of the akpm-current tree Stephen Rothwell
2022-04-27 14:15 ` Liam Howlett
2022-04-13  5:15 Stephen Rothwell
2022-04-13  6:20 ` Yu Zhao
2022-02-09  5:58 Stephen Rothwell
2022-02-09  8:09 ` Huang, Ying
2022-02-07  4:06 Stephen Rothwell
2022-02-02  3:54 Stephen Rothwell
2022-02-03 23:06 ` Andrew Morton
2022-02-03 23:21   ` Randy Dunlap
2022-01-06 15:45 Stephen Rothwell
2021-12-23 23:12 Stephen Rothwell
2021-11-23  5:26 Stephen Rothwell
2021-11-23  8:38 ` Suren Baghdasaryan
2021-11-23 19:03   ` Suren Baghdasaryan
2021-11-23 22:26     ` Stephen Rothwell
2021-11-23 22:30       ` Suren Baghdasaryan
2021-07-19  7:52 Stephen Rothwell
2021-07-19  8:47 ` Feng Tang
2021-05-21  5:39 Stephen Rothwell
2021-05-21  6:53 ` Miaohe Lin
2021-03-30 20:04 Stephen Rothwell
2021-03-15  5:35 Stephen Rothwell
2021-03-16 18:18 ` Minchan Kim
2021-03-16 21:49   ` Stephen Rothwell
2021-03-16 23:09     ` Jonathan Corbet
2021-03-17 13:22       ` Mauro Carvalho Chehab
2020-12-10  9:38 Stephen Rothwell
2020-12-10 16:05 ` Georgi Djakov
2020-11-13  6:01 Stephen Rothwell
2020-11-16 10:03 ` Andy Shevchenko
2020-11-06  6:26 Stephen Rothwell
2020-11-05  6:45 Stephen Rothwell
2020-11-05  7:03 ` Mike Rapoport
2020-11-05  7:42   ` Anand K. Mistry
2020-11-05  7:45     ` Anand K. Mistry
2020-11-05  9:17       ` Mike Rapoport
2020-11-05  8:00     ` Stephen Rothwell
2020-11-05  8:03       ` Stephen Rothwell
2020-09-14  7:00 Stephen Rothwell
2020-09-15  4:03 ` David Gow
2020-09-15  4:16   ` Stephen Rothwell
2020-09-15  9:57   ` Marco Elver
2020-09-14  6:57 Stephen Rothwell
2020-07-17 10:31 Stephen Rothwell
2020-07-17 17:47 ` Roman Gushchin
2020-07-09  9:11 Stephen Rothwell
2020-06-21 14:40 Stephen Rothwell
2020-03-31  8:56 Stephen Rothwell
2020-04-01 22:58 ` Andrew Morton
2020-04-01 23:00   ` Jason Gunthorpe
2020-04-01 23:06     ` Mike Kravetz
2020-03-13 10:42 Stephen Rothwell
2020-03-13 10:55 ` Baoquan He
2020-03-13 12:56 ` Baoquan He
2020-03-14  0:09   ` Stephen Rothwell
2020-03-14  0:35     ` Baoquan He
2020-03-16  4:58 ` Baoquan He
2020-03-16  6:13   ` Stephen Rothwell
2020-03-16  6:51     ` Baoquan He
2020-03-16  6:54     ` Stephen Rothwell
2020-03-12  7:31 Stephen Rothwell
2020-03-12 16:48 ` Mike Kravetz
2020-03-12  7:27 Stephen Rothwell
2020-03-13  0:31 ` Andrew Morton
2020-03-05  5:37 Stephen Rothwell
2020-03-05  5:54 ` Dmitry Vyukov
2020-03-07  5:03   ` Walter Wu
2020-03-05  8:54 ` Walter Wu
2020-03-05  9:33   ` Stephen Rothwell
2020-03-06 18:59     ` Walter Wu
2020-03-06 20:45       ` Walter Wu
2020-02-17  2:00 Stephen Rothwell
2019-11-06  7:05 Stephen Rothwell
2019-11-06  7:52 ` Shaokun Zhang
2019-11-06  6:54 Stephen Rothwell
2019-08-07  8:00 Stephen Rothwell
2019-08-07 11:29 ` Rikard Falkeborn
2019-08-07 23:31   ` Stephen Rothwell
2019-07-31  6:16 Stephen Rothwell
2019-07-31 12:01 ` Jia-Ju Bai
2019-07-31  6:11 Stephen Rothwell
2019-07-31  6:28 ` Miles Chen
2019-08-01  5:51   ` Stephen Rothwell
2019-08-01  6:15     ` Michal Hocko
2019-08-01  6:30       ` Miles Chen
2019-08-01  6:38         ` Michal Hocko
2019-08-01  6:39         ` Stephen Rothwell
2019-08-01  6:42           ` Miles Chen
2019-07-29  3:48 Stephen Rothwell
2019-07-29  3:44 Stephen Rothwell
2019-05-30  4:55 Stephen Rothwell
2019-05-30  9:02 ` Matteo Croce
2019-03-29  2:39 Stephen Rothwell
2019-04-16  6:52 ` Stephen Rothwell
2019-04-16 22:45   ` Andrew Morton
2019-01-31  5:01 Stephen Rothwell
2018-06-08  4:45 Stephen Rothwell
2018-05-04  4:17 Stephen Rothwell
2018-05-04 15:39 ` Randy Dunlap
2018-05-07 14:10   ` Minchan Kim
2018-05-07 16:47     ` Randy Dunlap
2018-05-08 10:48       ` Minchan Kim
2018-04-06  4:53 Stephen Rothwell
2018-01-02  7:04 Stephen Rothwell
2017-12-15  2:48 Stephen Rothwell
2017-11-23  2:01 Stephen Rothwell
2017-11-13  5:54 Stephen Rothwell
2017-08-01  5:22 Stephen Rothwell
2017-05-26  2:43 Stephen Rothwell
2017-05-26 10:16 ` Jeff Layton
2017-05-26 11:28   ` Dave Kleikamp
2017-05-19  4:44 Stephen Rothwell
2017-05-15  1:56 Stephen Rothwell
2017-05-15  4:02 ` Xunlei Pang
2017-05-15  5:07   ` Stephen Rothwell
2017-02-02  6:49 Stephen Rothwell
2016-11-09  4:10 Stephen Rothwell
2016-11-09  7:18 ` Huang Shijie
2016-11-09 21:21   ` Andrew Morton
2016-11-10  2:56     ` Stephen Rothwell
2016-06-23  6:53 Stephen Rothwell
2016-06-23 14:00 ` Mel Gorman
2016-05-27  3:07 Stephen Rothwell
2016-05-27 19:53 ` Andrew Morton
2016-04-29  6:45 Stephen Rothwell
2016-04-29  6:55 ` Stephen Rothwell
2016-04-29 13:32 ` Josh Poimboeuf
2016-04-29 14:03   ` Josh Poimboeuf
2016-04-30  5:52     ` Stephen Rothwell
2015-07-16  5:26 Stephen Rothwell
2015-07-16 23:00 ` Andrew Morton
2015-06-04 12:29 Stephen Rothwell
2015-06-04 13:56 ` Andrea Arcangeli
2015-02-04  7:48 Stephen Rothwell
2015-02-04  7:53 ` Jan Kiszka
2015-01-19  7:45 Stephen Rothwell
2015-01-19 15:50 ` Chris Mason
2014-10-30  5:19 Stephen Rothwell
2014-10-30  9:00 ` Aneesh Kumar K.V
2014-09-26 10:42 Stephen Rothwell
2014-09-29 21:30 ` Andrew Morton
2014-09-08  8:57 Stephen Rothwell
2014-06-20  5:27 Stephen Rothwell
2014-06-20  5:29 ` Yinghai Lu
2014-06-16  1:57 Stephen Rothwell

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=24a5b70c-aac4-29b5-6a4d-38ac3d10d475@hisilicon.com \
    --to=zhangshaokun@hisilicon.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).