linux-kernel - Re: [PATCH] cgroup: Fix uninitialized variable warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20151223214134.GN5003@mtj.duckdns.org>
Date:	Wed, 23 Dec 2015 16:41:34 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Ross Zwisler <ross.zwisler@...ux.intel.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Li Zefan <lizefan@...wei.com>,
	Daniel Wagner <daniel.wagner@...-carit.de>,
	Johannes Weiner <hannes@...xchg.org>, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, Dave Jones <davej@...emonkey.org.uk>,
	kernel-team@...com, Aleksa Sarai <cyphar@...har.com>,
	Michal Hocko <mhocko@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Neil Horman <nhorman@...driver.com>
Subject: Re: [PATCH] cgroup: Fix uninitialized variable warning

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/