Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp4534296imd; Tue, 30 Oct 2018 03:39:54 -0700 (PDT) X-Google-Smtp-Source: AJdET5eXcgH7k5z25b4pVzClRbBxXHCRE1ma7IvEyZgUmtvHZaOj3iTtWPMivg/xeSsDPnoU39aX X-Received: by 2002:a62:8a91:: with SMTP id o17-v6mr2403417pfk.184.1540895994744; Tue, 30 Oct 2018 03:39:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540895994; cv=none; d=google.com; s=arc-20160816; b=Gyr8MCBwn1GhQ+DoX1A0J024gWvjSFUZtUqeCo/tiweKHs2OF3gxaWT9OIqZWf2Yw9 wlpXaROcetBcr8tmkWi9QDYUGhKz5t/Ygw0nUZ07+ov2lf9zjHV0tvuup0oFY1itP6A2 a1tOa3G9f97JQAkTQ3Go2CK7e39frYmcbRu9Q/9r9nyzE4PYRu0My1ksBXX4bG+I5Vcj jPr5s1HmYT1iiDpLL+0no8nyRujs1UteCmUJ83ps5MUHhG+M/QWP7ZhcrKAeE13SnK3i ARTYO2OOyMGZ0p03REhjfuL4f5MUX7wjzJEWhluVC7qfZQLbeYobYDmNZifd6zAIcRbq wEQQ== 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:date:from; bh=uMloEJ4IOd5zMN0uJTTwU/2/NtQw8oPjx/2S8AD6kPo=; b=WTdi3khxEJi4MIbNtdPTFNCICoTax+LCm7XphFTrzpYM6+Lkwz/EPVsHVXbSfnzgbX GQuea3eueJ5ws5nvVqgmpltC2FGmVRXmUAGk77bCYPJjtQvbjCNK6xYvmlkU1Y+PPgJy a6X2Iqz2M/6nrJpMT2RZF47uavQVyOpkl0g+CwcYnp0L67dK2yngmjQH0Au9f20FTqVL trjSMcebQRoxlwduIKirEN5IzKu+101LQEufuZfqty+5916B+8oLBAbUMlz/Q/BG/OEH WHTLuF4x4Qs1/G/BA3E/Hu8oDRDJtT8UUlOQLgsr8mTrSfok/mRnMB5ZgMmY9IUjuDTq L6Dg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v69si12821616pgb.3.2018.10.30.03.39.38; Tue, 30 Oct 2018 03:39:54 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727240AbeJ3TcM (ORCPT + 99 others); Tue, 30 Oct 2018 15:32:12 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:48009 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726720AbeJ3TcM (ORCPT ); Tue, 30 Oct 2018 15:32:12 -0400 Received: from mail-wm1-f72.google.com ([209.85.128.72]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1gHRQY-00029J-OC for linux-kernel@vger.kernel.org; Tue, 30 Oct 2018 10:39:14 +0000 Received: by mail-wm1-f72.google.com with SMTP id f3-v6so10307936wme.9 for ; Tue, 30 Oct 2018 03:39:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uMloEJ4IOd5zMN0uJTTwU/2/NtQw8oPjx/2S8AD6kPo=; b=YcKNm349uMKGMYf815caO6rrE7Xpt445TRg7q2LfmVcy5g9vm0C8bOT8XnY+1lxGSa nvWD29xwtxdEnSwn29Onktf8C53OxXhyOhnvfGw5H+nSNmY5kfuyGXSD4t/P1goguMjG hm4WpHiaZ4RtiV/ByKRv297jLKIk2cTqt8D9D1aHmaK1s8dcRipJqUbvPKUcQQh2X2Zc zs6V99JRHe40mgNNDRi1OQ41etb4y36+6eCK6U9wLr3l6xXZ2Fd0luXEEqtjTNZwkxCT vdMpuud+7/vor9tyNHINlaLDgD+WReJEkNqGtlgYfWtVjszm91QXGnkZ+4co95bYlXOX sZ1Q== X-Gm-Message-State: AGRZ1gK++OH75iE6NawiqI90bjfl/j7Fk1EgPkh48IAK4I8rWjJtxlIq +9HzF0gxmxDN20ZVBjJ9v+svaqRPaWLyqxTvRRZMhUR9mMYMxlH+ewzIUzHk9Dqeo9iPp82UEt2 vaUw5rxP6T2hsDQUjXEMeuz6CEmirEujrsYwYGHl3NQ== X-Received: by 2002:a5d:5685:: with SMTP id f5-v6mr5451122wrv.113.1540895954120; Tue, 30 Oct 2018 03:39:14 -0700 (PDT) X-Received: by 2002:a5d:5685:: with SMTP id f5-v6mr5451089wrv.113.1540895953394; Tue, 30 Oct 2018 03:39:13 -0700 (PDT) Received: from gmail.com ([2a02:8070:8895:9700:6d7a:7ba6:535c:106b]) by smtp.gmail.com with ESMTPSA id 4-v6sm4736154wmg.21.2018.10.30.03.39.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 30 Oct 2018 03:39:12 -0700 (PDT) From: Christian Brauner X-Google-Original-From: Christian Brauner Date: Tue, 30 Oct 2018 11:39:11 +0100 To: Daniel Colascione Cc: Joel Fernandes , LKML , Tim Murray , Suren Baghdasaryan Subject: Re: [RFC PATCH] Implement /proc/pid/kill Message-ID: <20181030103910.mnzot3zcoh6j7did@gmail.com> References: <20181029221037.87724-1-dancol@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 30, 2018 at 08:50:22AM +0000, Daniel Colascione wrote: > On Tue, Oct 30, 2018 at 3:21 AM, Joel Fernandes wrote: > > On Mon, Oct 29, 2018 at 3:11 PM Daniel Colascione wrote: > >> > >> Add a simple proc-based kill interface. To use /proc/pid/kill, just > >> write the signal number in base-10 ASCII to the kill file of the > >> process to be killed: for example, 'echo 9 > /proc/$$/kill'. > >> > >> Semantically, /proc/pid/kill works like kill(2), except that the > >> process ID comes from the proc filesystem context instead of from an > >> explicit system call parameter. This way, it's possible to avoid races > >> between inspecting some aspect of a process and that process's PID > >> being reused for some other process. > >> > >> With /proc/pid/kill, it's possible to write a proper race-free and > >> safe pkill(1). An approximation follows. A real program might use > >> openat(2), having opened a process's /proc/pid directory explicitly, > >> with the directory file descriptor serving as a sort of "process > >> handle". > > > > How long does the 'inspection' procedure take? If its a short > > duration, then is PID reuse really an issue, I mean the PIDs are not > > reused until wrap around and the only reason this can be a problem is > > if you have the wrap around while the 'inspecting some aspect' > > procedure takes really long. > > It's a race. Would you make similar statements about a similar fix for > a race condition involving a mutex and a double-free just because the > race didn't crash most of the time? The issue I'm trying to fix here > is the same problem, one level higher up in the abstraction hierarchy. > > > Also the proc fs is typically not the right place for this. Some > > entries in proc are writeable, but those are for changing values of > > kernel data structures. The title of man proc(5) is "proc - process > > information pseudo-filesystem". So its "information" right? > > Why should userspace care whether a particular operation is "changing > [a] value[] of [a] kernel data structure" or something else? That > something in /proc is a struct field is an implementation detail. It's > the interface semantics that matters, and whether a particular > operation is achieved by changing a struct field or by making a > function call is irrelevant to userspace. Proc is a filesystem about > processes. Why shouldn't you be able to send a signal to a process via > proc? It's an operation involving processes. > > It's already possible to do things *to* processes via proc, e.g., > adjust OOM killer scores. Proc filesystem file descriptors are > userspace references to kernel-side struct pid instances, and as such, > make good process handles. There are already "verb" files in procfs, > such as /proc/sys/vm/drop_caches and /proc/sysrq-trigger. Why not add > a kill "verb", especially if it closes a race that can't be closed > some other way? > > You could implement this interface as a system call that took a procfs > directory file descriptor, but relative to this proposal, it would be > all downside. Such a thing would act just the same way as > /pric/pid/kill, and wouldn't be usable from the shell or from programs > that didn't want to use syscall(2). (Since glibc isn't adding new > system call wrappers.) AFAIK, the only downside of having a "kill" > file is the need for a string-to-integer conversion, but compared to > process killing, integer parsing is insignificant. > > > IMO without a really good reason for this, it could really be a hard > > sell but the RFC was worth it anyway to discuss it ;-) > > The traditional unix process API is down there at level -10 of Rusty > Russel's old bad API scale: "It's impossible to get right". The races > in the current API are unavoidable. That most programs don't hit these > races most of the time doesn't mean that the race isn't present. > > We've moved to a model where we identify other system resources, like > DRM fences, locks, sockets, and everything else via file descriptors. > This change is a step toward using procfs file descriptors to work > with processes, which makes the system more regular and easier to > reason about. A clean API that's possible to use correctly is a > worthwhile project. So I have been disucssing a new process API With David Howells, Kees Cook and a few others and I am working on an RFC/proposal for this. It is partially inspired by the new mount API. So I would like to block this patch until then. I would like to get this right very much and I don't think this is the way to go. I hope to have a more detailed proposal out soon(ish). David and I were also thinking about an adhoc session at the kernel summit but we aren't clear whether there's still a slot.