From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by kanga.kvack.org (Postfix) with ESMTP id 4D35F6B0031 for ; Fri, 24 Jan 2014 01:54:50 -0500 (EST) Received: by mail-bk0-f50.google.com with SMTP id w16so954182bkz.9 for ; Thu, 23 Jan 2014 22:54:49 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [2a00:1450:4010:c03::22b]) by mx.google.com with ESMTPS id j6si1705259bko.192.2014.01.23.22.54.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 22:54:49 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id pv20so2257464lab.16 for ; Thu, 23 Jan 2014 22:54:48 -0800 (PST) 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 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: malc , "linux-mm@kvack.org" , LKML , Jianyu Zhan 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, 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