|To:||Ralf Baechle <firstname.lastname@example.org>|
|Subject:||Re: [MIPS] TLB handler fix for vmalloc'ed addresses|
|From:||Maxim Uvarov <email@example.com>|
|Date:||Thu, 10 Sep 2009 20:00:07 +0400|
|References:||<4AA656D8.firstname.lastname@example.org> <20090910141518.GA10547@linux-mips.org> <4AA90F3B.email@example.com> <20090910153744.GA10998@linux-mips.org> <4AA91FB9.firstname.lastname@example.org>|
|User-agent:||Thunderbird 18.104.22.168 (X11/20090817)|
Maxim Uvarov wrote:
Yes, it is so. Bug occurs on rmmod this module. (Module does not free memory}So your test case allocates vmalloc memory but never touches it.allocated with vmalloc().Nor does it stop the thread on exit or avoid unloading. So panicing is expected.Ralf, I'm sorry for misunderstanding. Original kernel does panic in this situation. In my patch it went to panic with
Original kernel does _NOT_ panic.
+ else if (pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_k)) + goto no_context; Actually it was the reason of this patch.But looks like we need go immediately to no_context for 64 bit and do not do this checks.Maxim.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [MIPS] TLB handler fix for vmalloc'ed addresses, Maxim Uvarov|
|Next by Date:||[PATCH 00/10] Add support for GCC's __builtin_unreachable() and use it in BUG., David Daney|
|Previous by Thread:||Re: [MIPS] TLB handler fix for vmalloc'ed addresses, Maxim Uvarov|
|Next by Thread:||Re: [PATCH] cleanup vmalloc_fault for 64bit kernel, David Daney|
|Indexes:||[Date] [Thread] [Top] [All Lists]|