Received: by 2002:ac0:a874:0:0:0:0:0 with SMTP id c49csp73260ima; Thu, 14 Mar 2019 20:17:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqxoOJNLk63OPBlMIOtqsSNHY4h6b65daZH2fB1EmuaUkSROqVlLgLLx6YepmerPlC9OdBOq X-Received: by 2002:a17:902:44a4:: with SMTP id l33mr1792455pld.292.1552619877473; Thu, 14 Mar 2019 20:17:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552619877; cv=none; d=google.com; s=arc-20160816; b=FawKwfzWVnzhJySiMODZisb5EMe6zBvR1kLT3F0iHGI5vNloqPXhxlJKhCzaWUT8yh nKKCFsKy1Rthg7mTsH0Qaq2/Yq5TxDiP2u1v/bRYAGyFg2Kxjd5nX/kDySi24OZ78EOr RIMWE1L8536XOq4fPTX7tYiAHeT6GfejrnvbDS0nBKpW2yjDjt7UYCUKaibZr6ayfqTL fNmosvzwxbu99o5c8ys50EOsRG+tnXy1u+gWkhH/uLSARUUL3/fcU55VdHa0onE9nsqG RF2v0QH2cJsvQB/5fhRz0mwN8f3TH5mCbF2P85Gk8x83hjaPdRESnddBMRtsw2KjycG7 s0wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=IUB+yUuwUkJce0Q3R1yjfPaL3wwssMR6Fd5G5nd/6jQ=; b=Gv0GVe5gYR6bPBFUTkmydVrn/XQjbotivk3ce+G4JOcILEgI3fhcCgo/HG22gONzhV FvnCEaYV0ymvYs9zZokvVR1HV5KDLRykc+peHLDuMjZvwGU5zj67LBAqfQTTe5NWQSe0 P5BgdZriwaodctLoDw1ny87WEywMupDqwNdyy7LFqVMQ7y4uk6NnJ0J4Yz8Rn8Hw1EnZ 3yQihqHuUjSLIDCiHNttwgdqq9MqYR0gJXVuNapfUnO1kDKDz/LNpjtJGhsOkDdFwKqC ggL75HJmH72dk12DYGGOosL0m6ERXu1uLri/QCuRVmNMdRS8fqMekjZahHV+VfqWp82Z oAmg== 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 l38si596558plb.160.2019.03.14.20.17.40; Thu, 14 Mar 2019 20:17:57 -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 S1726946AbfCODQs (ORCPT + 99 others); Thu, 14 Mar 2019 23:16:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:51580 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726487AbfCODQs (ORCPT ); Thu, 14 Mar 2019 23:16:48 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F404321873; Fri, 15 Mar 2019 03:16:45 +0000 (UTC) Date: Thu, 14 Mar 2019 23:16:41 -0400 From: Steven Rostedt To: Sultan Alsawaf Cc: Joel Fernandes , Tim Murray , Michal Hocko , Suren Baghdasaryan , Greg Kroah-Hartman , Arve =?UTF-8?B?SGrDuG5uZXbDpWc=?= , Todd Kjos , Martijn Coenen , Christian Brauner , Ingo Molnar , Peter Zijlstra , LKML , "open list:ANDROID DRIVERS" , linux-mm , kernel-team Subject: Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android Message-ID: <20190314231641.5a37932b@oasis.local.home> In-Reply-To: <20190314204911.GA875@sultan-box.localdomain> References: <20190310203403.27915-1-sultan@kerneltoast.com> <20190311174320.GC5721@dhcp22.suse.cz> <20190311175800.GA5522@sultan-box.localdomain> <20190311204626.GA3119@sultan-box.localdomain> <20190312080532.GE5721@dhcp22.suse.cz> <20190312163741.GA2762@sultan-box.localdomain> <20190314204911.GA875@sultan-box.localdomain> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Mar 2019 13:49:11 -0700 Sultan Alsawaf wrote: > Perhaps I'm missing something, but if you want to know when a process has died > after sending a SIGKILL to it, then why not just make the SIGKILL optionally > block until the process has died completely? It'd be rather trivial to just > store a pointer to an onstack completion inside the victim process' task_struct, > and then complete it in free_task(). How would you implement such a method in userspace? kill() doesn't take any parameters but the pid of the process you want to send a signal to, and the signal to send. This would require a new system call, and be quite a bit of work. If you can solve this with an ebpf program, I strongly suggest you do that instead. -- Steve