Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp4195069imd; Mon, 29 Oct 2018 20:22:41 -0700 (PDT) X-Google-Smtp-Source: AJdET5dLwnWbg32wvQqK0gTLoLkmpwh7JGE5zysUOA+WWq+2hlqFG40el6waZPHOkWQdRsZVheWu X-Received: by 2002:a62:6c49:: with SMTP id h70-v6mr1200733pfc.134.1540869761224; Mon, 29 Oct 2018 20:22:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540869761; cv=none; d=google.com; s=arc-20160816; b=CH3TnRPL/2egUHoLcYplg+NEBCMW3DGzsAFovN4xOmZqsQZX66F/AriYhUxOnEstXN LvVpJvqWyzP7LodVv/etba6plCY7OkxLMJ8+bjJoVxF/iuYHys84Bfh9TIB+RBL/om9x N+9q+ImmQceXP7xJxcLHADE6VHQlu166LCaiK+oOPCc/S1LGMseLi+umxYcNSBEfU+s9 SezzAcmfqes5BiQEe3//lwCh6Jcto2APSEWnJ2QqBa7nrTnJR7ESFw3glbUUa7MpFZd4 GJ00+2j8Geu+C2zjAOhY78aXNyXoursVxhGxMHuZywGvrSBI06XcXTT5IVhbsvCK+T1h YMUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=R0EIfBijL/UxPZzgpFvC5osTlwjsHUFUOn8FK6CMeE0=; b=wV+qPju0YVDrrjJg6Kmfs76tYysTo5s/qbl/yC1rYHPufnv09GSfU5thKLeberZw0G bpY24SwntcbyFM2N3JIZjpX8pNZAK60MAPeIWUVymZFTN/1sTPv+kNAyYr3RaGCYxmNv 4oCRYLY/Sfj59xrdeXrLpeKTVTXrdeAjbz4+ltJIv+NeGNvR9Pap/PVKxhu9MR0+rm1C 7OL12o8neXG/X5lAsgB9v1mAK2mvOSeLdJuKWLZAUIwrmiH1wY1xSAfBZ974TCPl9LNi rK9VToufxITBEWJ55LzruBQGBr8KQUKJpniOPT/qg4yvSDOuJDVInICGx7VO7cv/wlLv bJLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=g7Sx35Zd; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a8-v6si21657753plz.94.2018.10.29.20.22.25; Mon, 29 Oct 2018 20:22:41 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=g7Sx35Zd; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726692AbeJ3MNn (ORCPT + 99 others); Tue, 30 Oct 2018 08:13:43 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:36760 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726016AbeJ3MNn (ORCPT ); Tue, 30 Oct 2018 08:13:43 -0400 Received: by mail-qt1-f194.google.com with SMTP id u34-v6so11917961qth.3 for ; Mon, 29 Oct 2018 20:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R0EIfBijL/UxPZzgpFvC5osTlwjsHUFUOn8FK6CMeE0=; b=g7Sx35ZdD2zh3XwwtEKoP5iZ32Lvbwhco11LrGDEGm0J9Qd5lxaa0TH1mK2ViLzzjE gTHlru2iDdufhuax2QBjEaSTcVnloI/C5+cnIi/3zS4zKPB2XBsTA5T5WG0LFMu4Tt4u 9NwXPFrJP9H7XtbaTVDDeWxy8nE3yLwg58W7YwRTnfutxwlfWYeez4Djd1fyvTZk2ufZ KdtP9IwvpUe4Y5tqwMA/z5IfTR6uz5IfiNMM7FKhnVtgFxn09SEMNxI25WtUmvFLZMJx 2cd23e3OegjAjsnDLtgqOpX/yr83uK97UHhORLW5Bs+Pe0Oq2GXqqEWpFh9JrWCLfSQz IrGw== 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=R0EIfBijL/UxPZzgpFvC5osTlwjsHUFUOn8FK6CMeE0=; b=YTdwC7bcG+4qMIr0U3MAT0Jl+TE2k6zE09NJYYXYL+/LM6sM+ABpHdgOICdcUan8cf zkpO0mIhZr38dhJiB4IIdTCJfDzbGtYXpUeQ6B5uBEdL4X/1o6isTQh6+4uBdbUTUoQ7 J5YPfAWRdrShXbfVLyLJIEk5UKz4wX4p6KxzgYsRlra07d3Enwipv1oVlUx2ZsovGqut v5cCDYnh0Z7MtiM5CyweAy2DTFWdA11kzBD6BzsX7qg/LWKjzUGj7Bfmwqek5UsSK+NF 2LPLJGbgmsqgwCS46kQAOK0L+ockUgc+KSybhgtkTk3ClcwfRt67/+RtCGWo22/cSZKp LZXQ== X-Gm-Message-State: AGRZ1gKB4wEUfT7S7WD49o55v9A5IXb9OHVDlpxReITu9AtY6Zt1EjkP +cUyYBHmOYHe/BbgL8H8IpJJ2hcDjjPJO3qjFpXOiulhpaGaaA== X-Received: by 2002:aed:2ec1:: with SMTP id k59-v6mr849818qtd.304.1540869722757; Mon, 29 Oct 2018 20:22:02 -0700 (PDT) MIME-Version: 1.0 References: <20181029221037.87724-1-dancol@google.com> In-Reply-To: <20181029221037.87724-1-dancol@google.com> From: Joel Fernandes Date: Mon, 29 Oct 2018 20:21:51 -0700 Message-ID: Subject: Re: [RFC PATCH] Implement /proc/pid/kill To: Daniel Colascione Cc: LKML , Tim Murray , Suren Baghdasaryan 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, 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. 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? 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 ;-) thanks, - Joel