Re: Possible broken MM code in dell-laptop.c?
From: Pali Rohár <hidden>
Date: 2015-06-16 07:15:36
Also in:
lkml, platform-driver-x86
On Tuesday 16 June 2015 08:33:46 Michal Hocko wrote:
On Mon 15-06-15 23:27:59, Pali RohA!r wrote:quoted
On Monday 15 June 2015 23:18:16 Michal Hocko wrote:quoted
On Sun 14-06-15 11:05:07, Pali RohA!r wrote:quoted
Hello, in drivers/platform/x86/dell-laptop.c is this part of code: static int __init dell_init(void) { ... /* * Allocate buffer below 4GB for SMI data--only 32-bit physical addr * is passed to SMI handler. */ bufferpage = alloc_page(GFP_KERNEL | GFP_DMA32);[...]quoted
buffer = page_address(bufferpage);[...]quoted
fail_rfkill: free_page((unsigned long)bufferpage);This one should be __free_page because it consumes struct page* and it is the proper counter part for alloc_page. free_page, just to make it confusing, consumes an address which has to be translated to a struct page. I have no idea why the API has been done this way and yeah, it is really confusing. [...]quoted
static void __exit dell_exit(void) { ... free_page((unsigned long)buffer);So both, either: free_page((unsigned long)buffer); or __free_page(bufferpage); is correct?Yes. Although I would use __free_page variant as both seem to be globally visible.
Michal, thank you for explaining this situation! Darren, I will prepare patch which will fix code and use __free_page(). (Btw, execution on fail_rfkill label caused kernel panic) -- Pali RohA!r pali.rohar@gmail.com -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>