Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932688AbcJLJ7j (ORCPT ); Wed, 12 Oct 2016 05:59:39 -0400 Received: from sender153-mail.zoho.com ([74.201.84.153]:25469 "EHLO sender153-mail.zoho.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932395AbcJLJ7b (ORCPT ); Wed, 12 Oct 2016 05:59:31 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:cc:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=hGMTz0hxtvRUND18N68G+PDHJORxbusRHp7aOIcc89EDhwL2mGUTYVvaID0ZjQuRWtFGUgNrVJBd uhe2Rg5nyBQuRju5rYLEwYwwXDCJNxg8S4viljl1Wuw6SI4n7fb9 Subject: Re: [RFC PATCH 1/1] mm/percpu.c: fix memory leakage issue when allocate a odd alignment area To: Michal Hocko 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> <20161012095439.GI17128@dhcp22.suse.cz> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, zijun_hu@htc.com, tj@kernel.org, akpm@linux-foundation.org, cl@linux.com From: zijun_hu Message-ID: <57FE0969.8080002@zoho.com> Date: Wed, 12 Oct 2016 17:59:05 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20161012095439.GI17128@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1202 Lines: 30 On 10/12/2016 05:54 PM, Michal Hocko wrote: > 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? > i am sorry for reply late i don't know whether it is necessary i just find there are so many sanity checkup in current internal interfaces