Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6621040yba; Tue, 14 May 2019 10:32:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqy94AMG3krcwdOX0Ps6qqz8cG0CrRfBRb0a6sQnQWZC89YUCipZPat/glmrQRxIwLLZ2aax X-Received: by 2002:a17:902:e7:: with SMTP id a94mr14147190pla.182.1557855170288; Tue, 14 May 2019 10:32:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557855170; cv=none; d=google.com; s=arc-20160816; b=Q2xn7t+19hbNwBK1Ms3ajkxNDu4zIenlBqIto7X4ynD+Bs2qBOxVFcM82KLh4jNvvJ e1ukMefODp1sCoWURdhbUXk/YELgXAESLYLHArYk1a31Jm4YNI0eZp88rnoSOZUyOGIO UzjJU+4ehe5nnz8Dwcf0Ogrve6s1ApHGx6YM+ObWPWunAVBSNCSrJwJiaFFKsIguuM5k EgzVbr9qR16MRnuiTp3LiRegzGYF10VZeuHpAcus1eVoH7AE1cAqavWVvi5Wk42ph27i 2y8q/s0GBqHKtKV4USPcYkpeYLBBSuTI7AqPM87/Cihc7Uq6IDWYKBXjx1PB4Xs4rTP0 GazA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ErzBDF5ta8fy4S6axV5usgeVf1icUMn3T8UVynCsAWs=; b=b/K8SBkiOT3Ss44BhN7NfBEFWBjGQICBNj3CGL042M4m+an58WGeOKbVyh+EGT+VYe V3b+ZmMaOZliNU1oFFq3PV6zPj4xHQBqVkBU1LJWezP8UGjzCZeknu/b4KozqKnBEzJu eKTEsjs08//wImxf12E+a+ks2nOXAmZYFdePcZ4Gt7Bw5wdpMszr/g7tZBaaJdBr88jN 87J5DuBqCISQ5HA6tNvK5KEyrOfTZAoVS2SzBX4PrRXjjE9ddZKb2HBK/nqtEk52fwph eI7oTktQU5pf2q3rdci5DO3hAhtAyPZoC44vYpQ9kJNMyFZux2bxeW8o4jmmgGwqBphp bozQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3si21476253pgt.305.2019.05.14.10.32.35; Tue, 14 May 2019 10:32:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727009AbfENRb0 (ORCPT + 99 others); Tue, 14 May 2019 13:31:26 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:41967 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726013AbfENRbZ (ORCPT ); Tue, 14 May 2019 13:31:25 -0400 Received: by mail-ot1-f67.google.com with SMTP id g8so16001290otl.8 for ; Tue, 14 May 2019 10:31:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ErzBDF5ta8fy4S6axV5usgeVf1icUMn3T8UVynCsAWs=; b=UohxSKf/RDYZxIdFU4oSsi9uZkXLk53EsAVAFJYTnGOrBEMTtlMnJzoUo/DyMZD4+L /zNyEySGkxJXRnJcK8rSRE9wi+OX8CMCb/gRxErcajWgjpuHvR7Zqvm+tR59xqJUP5N/ 93TLYJv7aldBBh6ObLjLENRmvUlyrBGdgjEI88+imPpi8uZ1uPdGHT0ILIjXdvz7uqIt zKEsfHh9yN/JRayRlb/Bu7maCaaWMwxRtVRzDSNs6zuabDb10+uE7aiun9PpOLmWT2gp ck/5lXJhw5hSDr8CpmVUBSvga4xku6mpZh9EUs40rSJa3iJpm/cXPHwmKJhKfUaF4Hi5 Do1g== X-Gm-Message-State: APjAAAUcXOw98cG/LzhqQgcqmYQFFjpoesGAKuMuNtrhLZRTDx9mVNBJ RqFEDdm/w+3X6TTNhRzLsUA= X-Received: by 2002:a9d:362:: with SMTP id 89mr4306623otv.17.1557855084265; Tue, 14 May 2019 10:31:24 -0700 (PDT) Received: from sultan-box.localdomain ([107.193.118.89]) by smtp.gmail.com with ESMTPSA id m25sm6357027otp.81.2019.05.14.10.31.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 May 2019 10:31:23 -0700 (PDT) Date: Tue, 14 May 2019 10:31:19 -0700 From: Sultan Alsawaf To: Steven Rostedt Cc: Oleg Nesterov , Christian Brauner , Daniel Colascione , Suren Baghdasaryan , Tim Murray , Michal Hocko , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Ingo Molnar , Peter Zijlstra , LKML , "open list:ANDROID DRIVERS" , linux-mm , kernel-team , Andy Lutomirski , "Serge E. Hallyn" , Kees Cook , Joel Fernandes Subject: Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android Message-ID: <20190514173119.GA19142@sultan-box.localdomain> References: <20190319231020.tdcttojlbmx57gke@brauner.io> <20190320015249.GC129907@google.com> <20190507021622.GA27300@sultan-box.localdomain> <20190507153154.GA5750@redhat.com> <20190507163520.GA1131@sultan-box.localdomain> <20190509155646.GB24526@redhat.com> <20190509183353.GA13018@sultan-box.localdomain> <20190510151024.GA21421@redhat.com> <20190513164555.GA30128@sultan-box.localdomain> <20190514124453.6fb1095d@oasis.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190514124453.6fb1095d@oasis.local.home> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 14, 2019 at 12:44:53PM -0400, Steven Rostedt wrote: > OK, this has gotten my attention. > > This thread is quite long, do you have a git repo I can look at, and > also where is the first task_lock() taken before the > find_lock_task_mm()? > > -- Steve Hi Steve, This is the git repo I work on: https://github.com/kerneltoast/android_kernel_google_wahoo With the newest simple_lmk iteration being this commit: https://github.com/kerneltoast/android_kernel_google_wahoo/commit/6b145b8c28b39f7047393169117f72ea7387d91c This repo is based off the 4.4 kernel that Google ships on the Pixel 2/2XL. simple_lmk iterates through the entire task list more than once and locks potential victims using find_lock_task_mm(). It keeps these potential victims locked across the multiple times that the task list is iterated. The locking pattern that Oleg said should cause lockdep to complain is that iterating through the entire task list more than once can lead to locking the same task that was locked earlier with find_lock_task_mm(), and thus deadlock. But there is a check in simple_lmk that avoids locking potential victims that were already found, which avoids the deadlock, but lockdep doesn't know about the check (which is done with vtsk_is_duplicate()) and should therefore complain. Lockdep does not complain though. Sultan