All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shi, Yang" <yang.shi@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>, linaro-kernel@lists.linaro.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	tj@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] writeback: initialize m_dirty to avoid compile warning
Date: Wed, 18 Nov 2015 09:32:27 -0800	[thread overview]
Message-ID: <564CB62B.4070501@linaro.org> (raw)
In-Reply-To: <9389290.7xT8jb43sX@wuerfel>

On 11/18/2015 1:53 AM, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 15:38:55 Andrew Morton wrote:
>> On Fri, 13 Nov 2015 10:26:41 -0800 Yang Shi <yang.shi@linaro.org> wrote:
>>
>>> When building kernel with gcc 5.2, the below warning is raised:
>>>
>>> mm/page-writeback.c: In function 'balance_dirty_pages.isra.10':
>>> mm/page-writeback.c:1545:17: warning: 'm_dirty' may be used uninitialized in this function [-Wmaybe-uninitialized]
>>>     unsigned long m_dirty, m_thresh, m_bg_thresh;
>>>
>>> The m_dirty{thresh, bg_thresh} are initialized in the block of "if (mdtc)",
>>> so if mdts is null, they won't be initialized before being used.
>>> Initialize m_dirty to zero, also initialize m_thresh and m_bg_thresh to keep
>>> consistency.
>>>
>>> They are used later by if condition:
>>> !mdtc || m_dirty <= dirty_freerun_ceiling(m_thresh, m_bg_thresh)
>>>
>>> If mdtc is null, dirty_freerun_ceiling will not be called at all, so the
>>> initialization will not change any behavior other than just ceasing the compile
>>> warning.
>>
>> Geeze I hate that warning.  gcc really could be a bit smarter about it
>> and this is such a case.
>>
>>> --- a/mm/page-writeback.c
>>> +++ b/mm/page-writeback.c
>>> @@ -1542,7 +1542,7 @@ static void balance_dirty_pages(struct address_space *mapping,
>>>        for (;;) {
>>>                unsigned long now = jiffies;
>>>                unsigned long dirty, thresh, bg_thresh;
>>> -             unsigned long m_dirty, m_thresh, m_bg_thresh;
>>> +             unsigned long m_dirty = 0, m_thresh = 0, m_bg_thresh = 0;
>>>
>>>                /*
>>>                 * Unstable writes are a feature of certain networked
>>
>> Adding runtime overhead to suppress a compile-time warning is Just
>> Wrong.
>>
>> With gcc-4.4.4 the above patch actually reduces page-writeback.o's
>> .text by 36 bytes, lol.  With gcc-4.8.4 the patch saves 19 bytes.  No
>> idea what's going on there...
>
> I've done tons of build tests and never got the warning for the variables
> other than m_dirty, and that one also just with very few configurations
> (e.g. ARM omap2plus_defconfig).

Yes, I just got the warning for m_dirty too. Just initialize m_thresh 
and m_bg_thresh to keep consistency (not sure if it is necessary). And, 
I'm a little bit confused why gcc just reports m_dirty but ignore others.

>
> How about initializing only m_dirty but not the others?

Fine to me.

Thanks,
Yang

>
> 	Arnd
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: "Shi, Yang" <yang.shi@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>, linaro-kernel@lists.linaro.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	tj@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] writeback: initialize m_dirty to avoid compile warning
Date: Wed, 18 Nov 2015 09:32:27 -0800	[thread overview]
Message-ID: <564CB62B.4070501@linaro.org> (raw)
In-Reply-To: <9389290.7xT8jb43sX@wuerfel>

On 11/18/2015 1:53 AM, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 15:38:55 Andrew Morton wrote:
>> On Fri, 13 Nov 2015 10:26:41 -0800 Yang Shi <yang.shi@linaro.org> wrote:
>>
>>> When building kernel with gcc 5.2, the below warning is raised:
>>>
>>> mm/page-writeback.c: In function 'balance_dirty_pages.isra.10':
>>> mm/page-writeback.c:1545:17: warning: 'm_dirty' may be used uninitialized in this function [-Wmaybe-uninitialized]
>>>     unsigned long m_dirty, m_thresh, m_bg_thresh;
>>>
>>> The m_dirty{thresh, bg_thresh} are initialized in the block of "if (mdtc)",
>>> so if mdts is null, they won't be initialized before being used.
>>> Initialize m_dirty to zero, also initialize m_thresh and m_bg_thresh to keep
>>> consistency.
>>>
>>> They are used later by if condition:
>>> !mdtc || m_dirty <= dirty_freerun_ceiling(m_thresh, m_bg_thresh)
>>>
>>> If mdtc is null, dirty_freerun_ceiling will not be called at all, so the
>>> initialization will not change any behavior other than just ceasing the compile
>>> warning.
>>
>> Geeze I hate that warning.  gcc really could be a bit smarter about it
>> and this is such a case.
>>
>>> --- a/mm/page-writeback.c
>>> +++ b/mm/page-writeback.c
>>> @@ -1542,7 +1542,7 @@ static void balance_dirty_pages(struct address_space *mapping,
>>>        for (;;) {
>>>                unsigned long now = jiffies;
>>>                unsigned long dirty, thresh, bg_thresh;
>>> -             unsigned long m_dirty, m_thresh, m_bg_thresh;
>>> +             unsigned long m_dirty = 0, m_thresh = 0, m_bg_thresh = 0;
>>>
>>>                /*
>>>                 * Unstable writes are a feature of certain networked
>>
>> Adding runtime overhead to suppress a compile-time warning is Just
>> Wrong.
>>
>> With gcc-4.4.4 the above patch actually reduces page-writeback.o's
>> .text by 36 bytes, lol.  With gcc-4.8.4 the patch saves 19 bytes.  No
>> idea what's going on there...
>
> I've done tons of build tests and never got the warning for the variables
> other than m_dirty, and that one also just with very few configurations
> (e.g. ARM omap2plus_defconfig).

Yes, I just got the warning for m_dirty too. Just initialize m_thresh 
and m_bg_thresh to keep consistency (not sure if it is necessary). And, 
I'm a little bit confused why gcc just reports m_dirty but ignore others.

>
> How about initializing only m_dirty but not the others?

Fine to me.

Thanks,
Yang

>
> 	Arnd
>


  reply	other threads:[~2015-11-18 17:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 18:26 [PATCH] writeback: initialize m_dirty to avoid compile warning Yang Shi
2015-11-13 18:26 ` Yang Shi
2015-11-17 23:38 ` Andrew Morton
2015-11-17 23:38   ` Andrew Morton
2015-11-18  9:53   ` Arnd Bergmann
2015-11-18  9:53     ` Arnd Bergmann
2015-11-18 17:32     ` Shi, Yang [this message]
2015-11-18 17:32       ` Shi, Yang
2015-11-18 18:11   ` Tejun Heo
2015-11-18 18:11     ` Tejun Heo
2015-11-18 18:27     ` Shi, Yang
2015-11-18 18:27       ` Shi, Yang
2015-11-18 18:33       ` Tejun Heo
2015-11-18 18:33         ` Tejun Heo
2015-11-18 18:39         ` Shi, Yang
2015-11-18 18:39           ` Shi, Yang
2015-11-18 18:55           ` Andrew Morton
2015-11-18 18:55             ` Andrew Morton
2015-11-18 18:57             ` Shi, Yang
2015-11-18 18:57               ` Shi, Yang

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=564CB62B.4070501@linaro.org \
    --to=yang.shi@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tj@kernel.org \
    /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.