Messages in this thread | | | Date | Thu, 9 May 2019 17:56:46 +0200 | From | Oleg Nesterov <> | Subject | Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android |
| |
On 05/07, Sultan Alsawaf wrote: > > On Tue, May 07, 2019 at 05:31:54PM +0200, Oleg Nesterov wrote: > > > Did you test this patch with lockdep enabled? > > > > If I read the patch correctly, lockdep should complain. vtsk_is_duplicate() > > ensures that we do not take the same ->alloc_lock twice or more, but lockdep > > can't know this. > > Yeah, lockdep is fine with this, at least on 4.4.
Impossible ;) I bet lockdep should report the deadlock as soon as find_victims() calls find_lock_task_mm() when you already have a locked victim.
Nevermind, I guess this code won't run with lockdep enabled...
As for https://github.com/kerneltoast/android_kernel_google_wahoo/commit/afc8c9bf2dbde95941253c168d1adb64cfa2e3ad Well,
mmdrop(mm); simple_lmk_mm_freed(mm);
looks racy because mmdrop(mm) can free this mm_struct. Yes, simple_lmk_mm_freed() does not dereference this pointer, but the same memory can be re-allocated as another ->mm for the new task which can be found by find_victims(), and _in theory_ this all can happen in between, so the "victims[i].mm == mm" can be false positive.
And this also means that simple_lmk_mm_freed() should clear victims[i].mm when it detects "victims[i].mm == mm", otherwise we have the same theoretical race, victims_to_kill is only cleared when the last victim goes away.
Another nit... you can drop tasklist_lock right after the 1st "find_victims" loop.
And it seems that you do not really need to walk the "victims" array twice after that, you can do everything in a single loop, but this is cosmetic.
Oleg.
| |