Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754254AbcJLJzF (ORCPT ); Wed, 12 Oct 2016 05:55:05 -0400 Received: from mail-pa0-f67.google.com ([209.85.220.67]:34312 "EHLO mail-pa0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751107AbcJLJzE (ORCPT ); Wed, 12 Oct 2016 05:55:04 -0400 Date: Wed, 12 Oct 2016 11:54:39 +0200 From: Michal Hocko To: zijun_hu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, zijun_hu@htc.com, tj@kernel.org, akpm@linux-foundation.org, cl@linux.com Subject: Re: [RFC PATCH 1/1] mm/percpu.c: fix memory leakage issue when allocate a odd alignment area Message-ID: <20161012095439.GI17128@dhcp22.suse.cz> References: <20161011172228.GA30403@dhcp22.suse.cz> <7649b844-cfe6-abce-148e-1e2236e7d443@zoho.com> <20161012065332.GA9504@dhcp22.suse.cz> <57FDE531.7060003@zoho.com> <20161012082538.GC17128@dhcp22.suse.cz> <57FDF7EF.6070606@zoho.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57FDF7EF.6070606@zoho.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1034 Lines: 29 On Wed 12-10-16 16:44:31, zijun_hu wrote: > On 10/12/2016 04:25 PM, Michal Hocko wrote: > > On Wed 12-10-16 15:24:33, zijun_hu wrote: [...] > >> i found the following code segments in mm/vmalloc.c > >> static struct vmap_area *alloc_vmap_area(unsigned long size, > >> unsigned long align, > >> unsigned long vstart, unsigned long vend, > >> int node, gfp_t gfp_mask) > >> { > >> ... > >> > >> BUG_ON(!size); > >> BUG_ON(offset_in_page(size)); > >> BUG_ON(!is_power_of_2(align)); > > > > See a recent Linus rant about BUG_ONs. These BUG_ONs are quite old and > > from a quick look they are even unnecessary. So rather than adding more > > of those, I think removing those that are not needed is much more > > preferred. > > > i notice that, and the above code segments is used to illustrate that > input parameter checking is necessary sometimes Why do you think it is necessary here? -- Michal Hocko SUSE Labs