From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5B8DC10F14 for ; Fri, 12 Apr 2019 21:33:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 74B7E218CD for ; Fri, 12 Apr 2019 21:33:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555104792; bh=G0n+RD7WzgKE1Bp1mc3p0Joa9QfqNlG2x2vv8QQloFw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=QX8Mg9wQ3+xlb0vremzMRjhpXQLCthwVoJBu9vccuwEHhJiiTje18xzo5cIntcbcm FEvOjwSZCQ/2lkJDibvoDOd9Eg0OdKyLUjimnMpP35eHtWfw8hRQ2e/MGO2OIyzGuf WPuHU7g5R/4UhzZg74JYaEuaLvYYnknafNe50JvI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727040AbfDLVdL (ORCPT ); Fri, 12 Apr 2019 17:33:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:33712 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726886AbfDLVdH (ORCPT ); Fri, 12 Apr 2019 17:33:07 -0400 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3FBE6218CD for ; Fri, 12 Apr 2019 21:33:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555104786; bh=G0n+RD7WzgKE1Bp1mc3p0Joa9QfqNlG2x2vv8QQloFw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=l1mS0Z24mBEOBqu7t+gfQYA/4aNAmm/de1JMGdrebrcsJTEO0eQJAi8KLGHN2QxIv IJW4Rq68JGkEkOhGRtIfrgeB9FZnegy5KHhd8bL8CLnp72/krW2UC6pwsENTnp2BM4 gozCPH03EqkYozUSEhN4GfWFoBXwzIzR+HY9O1z8= Received: by mail-wm1-f45.google.com with SMTP id z24so12677365wmi.5 for ; Fri, 12 Apr 2019 14:33:06 -0700 (PDT) X-Gm-Message-State: APjAAAUCpaFtMNFAQuFUM+RkE2ufDavyAxCl+K0qHprz7tBStLncS+k3 le86ZeSRaXCKBqkNuzczthTHUH3/aBKCDnsIi8TLlg== X-Google-Smtp-Source: APXvYqyWkWQmR3dFfAyiKEnxHZBFm/hmsqTjQDWvcKZLincV//nNnrTxC3QydrvhPfst/4cCh1lb1GQGZR7GLK845pM= X-Received: by 2002:a1c:99d5:: with SMTP id b204mr12313630wme.95.1555104784796; Fri, 12 Apr 2019 14:33:04 -0700 (PDT) MIME-Version: 1.0 References: <20190411175043.31207-1-joel@joelfernandes.org> In-Reply-To: <20190411175043.31207-1-joel@joelfernandes.org> From: Andy Lutomirski Date: Fri, 12 Apr 2019 14:32:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 1/2] Add polling support to pidfd To: "Joel Fernandes (Google)" Cc: LKML , Steven Rostedt , Daniel Colascione , Christian Brauner , Jann Horn , Suren Baghdasaryan , Linus Torvalds , Alexey Dobriyan , Al Viro , Andrei Vagin , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , Linux FS Devel , "open list:KERNEL SELFTEST FRAMEWORK" , Michal Hocko , Nadav Amit , Oleg Nesterov , Serge Hallyn , Shuah Khan , Stephen Rothwell , Taehee Yoo , Tejun Heo , Thomas Gleixner , Tycho Andersen Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Apr 11, 2019 at 10:51 AM Joel Fernandes (Google) wrote: > > pidfd are /proc/pid directory file descriptors referring to a task group > leader. Android low memory killer (LMK) needs pidfd polling support to > replace code that currently checks for existence of /proc/pid for > knowing a process that is signalled to be killed has died, which is both > racy and slow. The pidfd poll approach is race-free, and also allows the > LMK to do other things (such as by polling on other fds) while awaiting > the process being killed to die. > > It prevents a situation where a PID is reused between when LMK sends a > kill signal and checks for existence of the PID, since the wrong PID is > now possibly checked for existence. > > In this patch, we follow the same mechanism used uhen the parent of the > task group is to be notified, that is when the tasks waiting on a poll > of pidfd are also awakened. > > We have decided to include the waitqueue in struct pid for the following > reasons: > 1. The wait queue has to survive for the lifetime of the poll. Including > it in task_struct would not be option in this case because the task can > be reaped and destroyed before the poll returns. Are you sure? I admit I'm not all that familiar with the innards of poll() on Linux, but I thought that the waitqueue only had to survive long enough to kick the polling thread and did *not* have to survive until poll() actually returned. > > 2. By including the struct pid for the waitqueue means that during > de_exec, the thread doing de_thread() automatically gets the new > waitqueue/pid even though its task_struct is different. I didn't follow this. Can you clarify? Also, please don't call your new helper wake_up_pidfd_pollers(). One of the goals of my patch was to make it generically possible for kernel code to wait for a task to exit. There are other cases besides pidfd for which this would be useful. Ahem, kthread. (The kthread implementation currently does some seriously awful things to detect when kthreads die.) Also, some hypothetical future vastly improved debugging API (to supercede ptrace for new applications) might want this. --Andy