Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753016AbbLFR3n (ORCPT ); Sun, 6 Dec 2015 12:29:43 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:38450 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752137AbbLFR3l (ORCPT ); Sun, 6 Dec 2015 12:29:41 -0500 Date: Sun, 6 Dec 2015 18:29:36 +0100 From: Ingo Molnar To: Rusty Russell Cc: Steven Rostedt , LKML , Peter Zijlstra , Andrew Morton , Sergey Senozhatsky , Xunlei Pang Subject: Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero Message-ID: <20151206172936.GA29582@gmail.com> References: <20151203172428.600f380a@gandalf.local.home> <87lh9b573j.fsf@rustcorp.com.au> <20151203213745.52f21886@gandalf.local.home> <20151204073437.GA24827@gmail.com> <877fku553z.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877fku553z.fsf@rustcorp.com.au> 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 Content-Length: 2360 Lines: 59 * Rusty Russell wrote: > Ingo Molnar writes: > > * Steven Rostedt wrote: > > > >> On Fri, 04 Dec 2015 12:05:12 +1030 > >> Rusty Russell wrote: > >> > >> > This is clever, but I would advise against such subtle code. We will never be > >> > able to remove this code once it is in. > >> > > >> > Would suggest making the non-CPUMASK_OFFSTACK stubs write garbage into the > >> > cpumasks instead, iff !(flags & __GFP_ZERO). > >> > >> I actually thought of the same thing, but thought it was a bit harsh. If others > >> think that's a better solution, then I'll submit a patch to do that. > > > > That just makes things more fragile - 'garbage' will spread the breakage, and if > > the breakage is subtle, it will spread subtle breakage. > > > > So why not use a kzmalloc_node() [equivalent] call instead of kmalloc_node(), to > > make sure it's all zeroed instead of uninitialized? > > OTOH, why not make *every* kmalloc a kzmalloc? The big difference to alloc_cpumask_var_node() is that kmalloc() is well-defined in the sense that it will return uninitialized buffers (sometimes even poisoned ones), all the time. But alloc_cpumask_var_node() will return a zeroed cpumask 99.9% of the time when the kernel being run is using on-stack cpumasks. So it's very easy to not initialize and not discover it for extended periods of time. As it happened here, and as was fixed with the patch. Hence my suggestion. > The issue here is not that the issue is subtle (not using a zeroing allocator is > a pretty clear bug), it's that it's papered over by the normal config. Exactly. > If we had a config option already to garbage-fill allocations, it'd be a simple > solution. > > I don't think there are great answers here. But adding more subtle zeroing > semantics feels wrong, even if it will mostly Just Work. It's not subtle if the naming clearly reflects it (hence my suggestion to rename the API) - and the status quo for on-stack allocations is zeroing anyway, so it's not a big jump... Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/