From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752132AbbFZNnX (ORCPT ); Fri, 26 Jun 2015 09:43:23 -0400 Received: from mail-yk0-f174.google.com ([209.85.160.174]:35389 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751568AbbFZNnR (ORCPT ); Fri, 26 Jun 2015 09:43:17 -0400 Date: Fri, 26 Jun 2015 09:43:14 -0400 From: Tejun Heo To: Geert Uytterhoeven Cc: Jens Axboe , torvalds@linuxfoundation.org, "linux-kernel@vger.kernel.org" Subject: Re: [GIT PULL] Cgroup writeback support for 4.2 Message-ID: <20150626134314.GB15805@mtj.duckdns.org> References: <20150625144432.GD13739@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Geert. On Fri, Jun 26, 2015 at 11:49:58AM +0200, Geert Uytterhoeven wrote: > Spoiler for TLDR: These are all false positives. > > If CONFIG_CGROUP_WRITEBACK=n: > > mm/page-writeback.c: In function ‘balance_dirty_pages_ratelimited’: > mm/page-writeback.c:1574: warning: ‘writeback’ is used > uninitialized in this function > > In this case, mem_cgroup_wb_stats() is a dummy function that doesn't > write to its output parameters, hence writeback will contain arbitrary data. > > There's another call too mem_cgroup_wb_stats() in > wb_over_bg_thresh() where my gcc 4.1.2 didn't warn, where it probably > deduced that mdtc will always be NULL, and the branch thus never taken. Can you please tell me the version of gcc which triggered the above warnings? > Regardless of CONFIG_CGROUP_WRITEBACK: > > mm/page-writeback.c: In function ‘balance_dirty_pages_ratelimited’: > mm/page-writeback.c:1537: warning: ‘m_bg_thresh’ may be used > uninitialized in this function > mm/page-writeback.c:1537: warning: ‘m_thresh’ may be used > uninitialized in this function > mm/page-writeback.c:1537: warning: ‘m_dirty’ may be used > uninitialized in this function > > But these are false positives too, due to the many tests on mdtc or !mdtc, > and the creative use of dummy *_INIT() macros and mdtc_valid() static inline > functions. > I suggest refactoring this code to make it less fragile, though. It's written that way deliberately with the purpose of triggering compile warnings if later code breaks something and code paths which should be left out when !CGROUP_WRITEBACK aren't while not impeding readability with ifdefs and awakwardly split dummy functions. The hope was that most compilers in use today are smart enough to notice the code paths which are being disabled (it's pretty darn obvious) and it seemed that way given the dearth of build warning reports from -next. Thanks. -- tejun