On 11/5/18, Jan Kara <jack@xxxxxxx> wrote:
> On Fri 02-11-18 16:31:06, Arnd Bergmann wrote:
>> In a rare randconfig build, I got a warning about possibly uninitialized
>> variables:
>>
>> mm/page-writeback.c: In function 'balance_dirty_pages':
>> mm/page-writeback.c:1623:16: error: 'writeback' may be used uninitialized
>> in this function [-Werror=maybe-uninitialized]
>> mdtc->dirty += writeback;
>> ^~
>> mm/page-writeback.c:1624:4: error: 'filepages' may be used uninitialized
>> in this function [-Werror=maybe-uninitialized]
>> mdtc_calc_avail(mdtc, filepages, headroom);
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> mm/page-writeback.c:1624:4: error: 'headroom' may be used uninitialized in
>> this function [-Werror=maybe-uninitialized]
>>
>> The compiler evidently fails to notice that the usage is in dead code
>> after 'mdtc' is set to NULL when CONFIG_CGROUP_WRITEBACK is disabled.
>> Adding an IS_ENABLED() check makes this clear to the compiler.
>>
>> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
>
> I'm surprised the compiler was not able to infer this since:
>
> struct dirty_throttle_control * const mdtc = mdtc_valid(&mdtc_stor) ?
> &mdtc_stor : NULL;
>
> and if CONFIG_CGROUP_WRITEBACK is disabled, mdtc_valid() is defined to
> 'false'. But possibly the function is just too big and the problematic
> condition is in the loop so maybe it all confuses the compiler too much.
On second thought, I suspect this started with the introduction of
CONFIG_NO_AUTO_INLINE in linux-next. That also caused a similar
issue in 28 other files that I patched later. I wrote this patch before I
saw the others, and then didn't make the connection.
Let's drop the patch for now, and decide what we want to do for the
others. I fixed those by adding 'inline' markers for whatever
function needed it.
Arnd
