All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shi, Yang" <yang.shi@linaro.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linaro-kernel@lists.linaro.org
Subject: Re: [PATCH] writeback: initialize m_dirty to avoid compile warning
Date: Wed, 18 Nov 2015 10:57:01 -0800	[thread overview]
Message-ID: <564CC9FD.3080307@linaro.org> (raw)
In-Reply-To: <20151118105517.2947aaa2.akpm@linux-foundation.org>

On 11/18/2015 10:55 AM, Andrew Morton wrote:
> On Wed, 18 Nov 2015 10:39:23 -0800 "Shi, Yang" <yang.shi@linaro.org> wrote:
>
>> On 11/18/2015 10:33 AM, Tejun Heo wrote:
>>> Hello,
>>>
>>> On Wed, Nov 18, 2015 at 10:27:32AM -0800, Shi, Yang wrote:
>>>>> This was the main reason the code was structured the way it is.  If
>>>>> cgroup writeback is not enabled, any derefs of mdtc variables should
>>>>> trigger warnings.  Ugh... I don't know.  Compiler really should be
>>>>> able to tell this much.
>>>>
>>>> Thanks for the explanation. It sounds like a compiler problem.
>>>>
>>>> If you think it is still good to cease the compile warning, maybe we could
>>>
>>> If this is gonna be a problem with new gcc versions, I don't think we
>>> have any other options. :(
>>>
>>>> just assign it to an insane value as what Andrew suggested, maybe
>>>> 0xdeadbeef.
>>>
>>> I'd just keep it at zero.  Whatever we do, the effect is gonna be
>>> difficult to track down - it's not gonna blow up in an obvious way.
>>> Can you please add a comment tho explaining that this is to work
>>> around compiler deficiency?
>>
>> Sure.
>>
>> Other than this, in v2, I will just initialize m_dirty since compiler
>> just reports it is uninitialized.
>
> gcc-4.4.4 and gcc-4.8.4 warn about all three variables.

It sounds 5.x is smarter :-)
>
>
> --- a/mm/page-writeback.c~writeback-initialize-m_dirty-to-avoid-compile-warning-fix
> +++ a/mm/page-writeback.c
> @@ -1542,7 +1542,9 @@ static void balance_dirty_pages(struct a
>   	for (;;) {
>   		unsigned long now = jiffies;
>   		unsigned long dirty, thresh, bg_thresh;
> -		unsigned long m_dirty = 0, m_thresh = 0, m_bg_thresh = 0;
> +		unsigned long m_dirty = 0;	/* stop bogus uninit warnings */
> +		unsigned long m_thresh = 0;
> +		unsigned long m_bg_thresh = 0;

Still need v2?

Thanks,
Yang

>
>   		/*
>   		 * Unstable writes are a feature of certain networked
> _
>

--
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: Andrew Morton <akpm@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linaro-kernel@lists.linaro.org
Subject: Re: [PATCH] writeback: initialize m_dirty to avoid compile warning
Date: Wed, 18 Nov 2015 10:57:01 -0800	[thread overview]
Message-ID: <564CC9FD.3080307@linaro.org> (raw)
In-Reply-To: <20151118105517.2947aaa2.akpm@linux-foundation.org>

On 11/18/2015 10:55 AM, Andrew Morton wrote:
> On Wed, 18 Nov 2015 10:39:23 -0800 "Shi, Yang" <yang.shi@linaro.org> wrote:
>
>> On 11/18/2015 10:33 AM, Tejun Heo wrote:
>>> Hello,
>>>
>>> On Wed, Nov 18, 2015 at 10:27:32AM -0800, Shi, Yang wrote:
>>>>> This was the main reason the code was structured the way it is.  If
>>>>> cgroup writeback is not enabled, any derefs of mdtc variables should
>>>>> trigger warnings.  Ugh... I don't know.  Compiler really should be
>>>>> able to tell this much.
>>>>
>>>> Thanks for the explanation. It sounds like a compiler problem.
>>>>
>>>> If you think it is still good to cease the compile warning, maybe we could
>>>
>>> If this is gonna be a problem with new gcc versions, I don't think we
>>> have any other options. :(
>>>
>>>> just assign it to an insane value as what Andrew suggested, maybe
>>>> 0xdeadbeef.
>>>
>>> I'd just keep it at zero.  Whatever we do, the effect is gonna be
>>> difficult to track down - it's not gonna blow up in an obvious way.
>>> Can you please add a comment tho explaining that this is to work
>>> around compiler deficiency?
>>
>> Sure.
>>
>> Other than this, in v2, I will just initialize m_dirty since compiler
>> just reports it is uninitialized.
>
> gcc-4.4.4 and gcc-4.8.4 warn about all three variables.

It sounds 5.x is smarter :-)
>
>
> --- a/mm/page-writeback.c~writeback-initialize-m_dirty-to-avoid-compile-warning-fix
> +++ a/mm/page-writeback.c
> @@ -1542,7 +1542,9 @@ static void balance_dirty_pages(struct a
>   	for (;;) {
>   		unsigned long now = jiffies;
>   		unsigned long dirty, thresh, bg_thresh;
> -		unsigned long m_dirty = 0, m_thresh = 0, m_bg_thresh = 0;
> +		unsigned long m_dirty = 0;	/* stop bogus uninit warnings */
> +		unsigned long m_thresh = 0;
> +		unsigned long m_bg_thresh = 0;

Still need v2?

Thanks,
Yang

>
>   		/*
>   		 * Unstable writes are a feature of certain networked
> _
>


  reply	other threads:[~2015-11-18 18:57 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
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 [this message]
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=564CC9FD.3080307@linaro.org \
    --to=yang.shi@linaro.org \
    --cc=akpm@linux-foundation.org \
    --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.