Linux-Next Archive on lore.kernel.org
 help / color / 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
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 index

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13  5:42 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 --
2019-11-06  7:05 linux-next: build warning after merge of the akpm-current tree 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 publically 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

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git