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,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS autolearn=ham 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 F0892C43381 for ; Mon, 1 Apr 2019 16:08:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BE5962133D for ; Mon, 1 Apr 2019 16:08:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554134899; bh=4mUBPSvFW43cZvn4hu1jhHu1mmod6UfLuzf+HJTOWoA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=MA11Hp65yMkDmZNOFV10jOZ8cZJq+pnQAxIo3RxsLemEZ1Uf3UvEJQqvtAsJinIep ihw0zTTaYuCBqpX/I5GVQG3G2FMPNlR8afd7Rr3/pHoNglZ8bjv5r2pe/dmSlKEuF7 PXptHBcBHT6yRqVDx65H1xWzqsYG5MUl25q+ZW+A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728671AbfDAQIS (ORCPT ); Mon, 1 Apr 2019 12:08:18 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:38061 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726854AbfDAQIR (ORCPT ); Mon, 1 Apr 2019 12:08:17 -0400 Received: by mail-lj1-f193.google.com with SMTP id p14so8707866ljg.5 for ; Mon, 01 Apr 2019 09:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9zX6pW+dmmCXMEz4jCv0a4w3jGqqO84SK/D3MDTDCm0=; b=MY6OYHwH/K9pFTSK+Hc6dMo3sYWaw5y4092j+7NxrZKSktB0Oq4qHjylDxqIpcNsZE vkrHIMPlIhCVYnn6kn7Ba5j7ru7eDu2I5IeR71OkYEZ4hWg7DtspqAGlIsm9nF99BPph Uh/OZMGeyTZkmrke+z/G/mSg01N+vKgcqyjCU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9zX6pW+dmmCXMEz4jCv0a4w3jGqqO84SK/D3MDTDCm0=; b=jspQt8W2HqHZjH3pOnXrgaySa4T0q9Hyxf1vkBKXxnnDBpfUFjuzJPfdUA1bk8HVHa SKChPch03zS50oP/EyYHg792usu9puhISprZxtrCYYtPzKL6YQzXaQGHeE6Qtw1FlS1E s7aLMjk0bouUi8cf2rvD9ML0utR4i7cBN9NCCY3TWS1fAAbBeAd4IbzPJeDCuV6t1gI3 ajbz2bU/mFIHRsdqKEOF1blzlT8p6CzRwr77j26k2VzQf0rgSGD+oq2le3SOJyYj/pqe L/q8pZeJMn3FYtaJYfKUUFVRav0PWbT97i0NTJqVezrGb3YaM4nqC3Z1oM34eXCGTaw6 3w/A== X-Gm-Message-State: APjAAAXqFNQmtl1XhH8HUFKxi2WRQ1JYWpUlVLdteCGCE3NA9o++ICyX sZAklZ5YwhSkQTmb5HR1GvcqLooK1Oo= X-Google-Smtp-Source: APXvYqw2H/oCN/oDyD8b/ZP7EX5KL95T9sVr+O+2TMZqnsAQAgMCF2DnbGezy6HoNpSX6GnqOvkczg== X-Received: by 2002:a2e:9b48:: with SMTP id o8mr561819ljj.51.1554134895557; Mon, 01 Apr 2019 09:08:15 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id f25sm1461606lfk.69.2019.04.01.09.08.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Apr 2019 09:08:15 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id l7so8695400ljg.6 for ; Mon, 01 Apr 2019 09:08:15 -0700 (PDT) X-Received: by 2002:a2e:9a91:: with SMTP id p17mr33165967lji.127.1554134506239; Mon, 01 Apr 2019 09:01:46 -0700 (PDT) MIME-Version: 1.0 References: <20190330171215.3yrfxwodstmgzmxy@brauner.io> <132107F4-F56B-4D6E-9E00-A6F7C092E6BD@amacapital.net> <20190331211041.vht7dnqg4e4bilr2@brauner.io> <18C7FCB9-2CBA-4237-94BB-9C4395A2106B@amacapital.net> <20190401114059.7gdsvcqyoz2o5bbz@yavin> In-Reply-To: From: Linus Torvalds Date: Mon, 1 Apr 2019 09:01:29 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() To: Daniel Colascione Cc: Aleksa Sarai , Andy Lutomirski , Christian Brauner , Jann Horn , Andrew Lutomirski , David Howells , "Serge E. Hallyn" , Linux API , Linux List Kernel Mailing , Arnd Bergmann , "Eric W. Biederman" , Konstantin Khlebnikov , Kees Cook , Alexey Dobriyan , Thomas Gleixner , Michael Kerrisk-manpages , Jonathan Kowalski , "Dmitry V. Levin" , Andrew Morton , Oleg Nesterov , Nagarathnam Muthusamy , Al Viro , Joel Fernandes Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 1, 2019 at 8:55 AM Daniel Colascione wrote: > > > > I wonder if we really want a fill procfs2, or maybe we could just make > > the pidfd readable (yes, it's a directory file descriptor, but we > > could allow reading). > > What would read(2) read? We could make it read anything, but it would have to be something people agree is sufficient (and not so expensive to create that rare users of that data would find the overhead excessive). Eg we could make it return the same thing that /proc//status reads right now. But it sounds like you need pretty much all of /proc//xyz: > We do a lot of process state inspection and manipulation, including > reading and writing the oom killer adjustment score, reading smaps, > and the occasional cgroup manipulation. More generally, I'd also like > to be able to write a race-free pkill(1) I suspect most of what pkill wants is indeed in that 'status' file, but other things aren't. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() Date: Mon, 1 Apr 2019 09:01:29 -0700 Message-ID: References: <20190330171215.3yrfxwodstmgzmxy@brauner.io> <132107F4-F56B-4D6E-9E00-A6F7C092E6BD@amacapital.net> <20190331211041.vht7dnqg4e4bilr2@brauner.io> <18C7FCB9-2CBA-4237-94BB-9C4395A2106B@amacapital.net> <20190401114059.7gdsvcqyoz2o5bbz@yavin> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Daniel Colascione Cc: Aleksa Sarai , Andy Lutomirski , Christian Brauner , Jann Horn , Andrew Lutomirski , David Howells , "Serge E. Hallyn" , Linux API , Linux List Kernel Mailing , Arnd Bergmann , "Eric W. Biederman" , Konstantin Khlebnikov , Kees Cook , Alexey Dobriyan , Thomas Gleixner , Michael Kerrisk-manpages , Jonathan Kowalski , "Dmitry V. Levin" , Andrew Morton List-Id: linux-api@vger.kernel.org On Mon, Apr 1, 2019 at 8:55 AM Daniel Colascione wrote: > > > > I wonder if we really want a fill procfs2, or maybe we could just make > > the pidfd readable (yes, it's a directory file descriptor, but we > > could allow reading). > > What would read(2) read? We could make it read anything, but it would have to be something people agree is sufficient (and not so expensive to create that rare users of that data would find the overhead excessive). Eg we could make it return the same thing that /proc//status reads right now. But it sounds like you need pretty much all of /proc//xyz: > We do a lot of process state inspection and manipulation, including > reading and writing the oom killer adjustment score, reading smaps, > and the occasional cgroup manipulation. More generally, I'd also like > to be able to write a race-free pkill(1) I suspect most of what pkill wants is indeed in that 'status' file, but other things aren't. Linus