Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751545AbaAXGyw (ORCPT ); Fri, 24 Jan 2014 01:54:52 -0500 Received: from mail-la0-f41.google.com ([209.85.215.41]:50248 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750753AbaAXGyv (ORCPT ); Fri, 24 Jan 2014 01:54:51 -0500 MIME-Version: 1.0 In-Reply-To: <20140123144954.644c14d60a4b55255d32960b@linux-foundation.org> References: <20140123144954.644c14d60a4b55255d32960b@linux-foundation.org> Date: Fri, 24 Jan 2014 10:54:48 +0400 Message-ID: Subject: Re: [PATCH] Revert "mm/vmalloc: interchage the implementation of vmalloc_to_{pfn,page}" From: Vladimir Murzin To: Andrew Morton Cc: malc , "linux-mm@kvack.org" , LKML , Jianyu Zhan Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew On Fri, Jan 24, 2014 at 2:49 AM, Andrew Morton wrote: > On Thu, 23 Jan 2014 20:27:29 +0400 (MSK) malc wrote: > >> Sep 17 00:00:00 2001 >> From: Vladimir Murzin >> Date: Thu, 23 Jan 2014 14:54:20 +0400 >> Subject: [PATCH] Revert "mm/vmalloc: interchage the implementation of >> vmalloc_to_{pfn,page}" >> >> This reverts commit ece86e222db48d04bda218a2be70e384518bb08c. >> >> Despite being claimed that patch doesn't introduce any functional >> changes in fact it does. >> >> The "no page" path behaves different now. Originally, vmalloc_to_page >> might return NULL under some conditions, with new implementation it returns >> pfn_to_page(0) which is not the same as NULL. >> >> Simple test shows the difference. >> >> test.c >> >> #include >> #include >> #include >> #include >> >> int __init myi(void) >> { >> struct page *p; >> void *v; >> >> v = vmalloc(PAGE_SIZE); >> /* trigger the "no page" path in vmalloc_to_page*/ >> vfree(v); >> >> p = vmalloc_to_page(v); >> >> pr_err("expected val = NULL, returned val = %p", p); >> >> return -EBUSY; >> } >> >> void __exit mye(void) >> { >> >> } >> module_init(myi) >> module_exit(mye) >> >> Before interchange: >> expected val = NULL, returned val = (null) >> >> After interchange: >> expected val = NULL, returned val = c7ebe000 >> > > hm, yes, I suppose that's bad. > > Rather than reverting the patch we could fix up vmalloc_to_pfn() and/or > vmalloc_to_page() to handle this situation. Did you try that? > Personally, I didn't try; I leaved this responsibility to the author of the patch as a review feedback. Unfortunately, there was no any response. Being said that original patch makes vmalloc_to_* "slightly more efficient", I'm in doubt that with additional handling it'd still improve something. I'd be very glad if someone point me at the benefit of the patch - just to have an idea why we need to put extra effort here. Thanks Vladimir > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- 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/