Re: [PATCH] writeback: initialize m_dirty to avoid compile warning

From: Shi, Yang
Date: Wed Nov 18 2015 - 13:57:10 EST


On 11/18/2015 10:55 AM, Andrew Morton wrote:
On Wed, 18 Nov 2015 10:39:23 -0800 "Shi, Yang" <yang.shi@xxxxxxxxxx> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/