From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752763AbcI0GHZ (ORCPT ); Tue, 27 Sep 2016 02:07:25 -0400 Received: from sender153-mail.zoho.com ([74.201.84.153]:25391 "EHLO sender153-mail.zoho.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751499AbcI0GHR (ORCPT ); Tue, 27 Sep 2016 02:07:17 -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=Cnp+j/gYtDaGE7hbA2fBX7EQnW4zSbFZF0JHknN/bYXgEySMthUL1FdLL5V8qRrCxS9ObkDiKEv5 ZapxZC3y4v8Nv1xamdlDHEbzENBIOrPXJPyC2tlTmcHe9gi5FgJR Subject: Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area() To: David Rientjes References: <57E20B54.5020408@zoho.com> <034db3ec-e2dc-a6da-6dab-f0803900e19d@zoho.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, zijun_hu@htc.com, Andrew Morton , tj@kernel.org, mingo@kernel.org, iamjoonsoo.kim@lge.com, mgorman@techsingularity.net From: zijun_hu Message-ID: <57EA0C86.3010303@zoho.com> Date: Tue, 27 Sep 2016 14:07:02 +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: 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 On 09/22/2016 07:15 AM, David Rientjes wrote: > On Thu, 22 Sep 2016, zijun_hu wrote: > >>> We don't support inserting when va->va_start == tmp_va->va_end, plain and >>> simple. There's no reason to do so. NACK to the patch. >>> >> i am sorry i disagree with you because >> 1) in almost all context of vmalloc, original logic treat the special case as normal >> for example, __find_vmap_area() or alloc_vmap_area() > > The ranges are [start, end) like everywhere else. __find_vmap_area() is > implemented as such for the passed address. The address is aligned in > alloc_vmap_area(), there's no surprise here. The logic is correct in > __insert_vmap_area(). > i am sorry to disagree with you i will resend this patch with more detailed illustration