From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965658AbbLWVlh (ORCPT ); Wed, 23 Dec 2015 16:41:37 -0500 Received: from mail-yk0-f182.google.com ([209.85.160.182]:33528 "EHLO mail-yk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934325AbbLWVlg (ORCPT ); Wed, 23 Dec 2015 16:41:36 -0500 Date: Wed, 23 Dec 2015 16:41:34 -0500 From: Tejun Heo To: Ross Zwisler Cc: Linus Torvalds , Li Zefan , Daniel Wagner , Johannes Weiner , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Dave Jones , kernel-team@fb.com, Aleksa Sarai , Michal Hocko , Ingo Molnar , Peter Zijlstra , Neil Horman Subject: Re: [PATCH] cgroup: Fix uninitialized variable warning Message-ID: <20151223214134.GN5003@mtj.duckdns.org> References: <1450906240-21821-1-git-send-email-ross.zwisler@linux.intel.com> <20151223213519.GM5003@mtj.duckdns.org> <20151223213813.GA21287@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151223213813.GA21287@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 23, 2015 at 02:38:13PM -0700, Ross Zwisler wrote: > On Wed, Dec 23, 2015 at 04:35:19PM -0500, Tejun Heo wrote: > > Hello, Ross. > > > > On Wed, Dec 23, 2015 at 02:30:40PM -0700, Ross Zwisler wrote: > > > static int mem_cgroup_can_attach(struct cgroup_taskset *tset) > > > { > > > struct cgroup_subsys_state *css; > > > - struct mem_cgroup *memcg; > > > + struct mem_cgroup *memcg = NULL; > > > > It's one thing to add spurious init to shut up gcc > > > > > @@ -4805,7 +4805,7 @@ static int mem_cgroup_can_attach(struct cgroup_taskset *tset) > > > p = leader; > > > memcg = mem_cgroup_from_css(css); > > > } > > > - if (!p) > > > + if (!p || !memcg) > > > > and to another to add an additional processing on it. > > Do you believe that the additional processing is incorrect? If somehow we > *do* get through the above loop without setting memcg, the next deref will > OOPs the kernel... That'd be a a plain kernel bug and oopsing is fine. If such conditions are particular (more likely, more difficult to debut, whatever), we sometimes add WARNs for them but we don't generally go around and add spurious checks. It actually is deterimental to readibility as people reading the code constantly have to go "when can p && !memcg can happen? why is this explicitly checked?". Thanks. -- tejun