From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH] proc: allow killing processes via file descriptors (Larger pids) Date: Mon, 19 Nov 2018 10:26:00 -0600 Message-ID: <875zwt2fvr.fsf_-_@xmission.com> References: <20181118111751.6142-1-christian@brauner.io> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Dmitry Safonov's message of "Mon, 19 Nov 2018 16:13:30 +0000") Sender: linux-kernel-owner@vger.kernel.org To: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Andy Lutomirski , dancol@google.com, rdunlap@infradead.org, christian@brauner.io, open list , Serge Hallyn , jannh@google.com, Andrew Morton , Oleg Nesterov , cyphar@cyphar.com, Al Viro , linux-fsdevel@vger.kernel.org, Linux API , timmurray@google.com, Kees Cook , jengelh@inai.de, Andrei Vagin List-Id: linux-api@vger.kernel.org Dmitry Safonov <0x7f454c46@gmail.com> writes: > > So, I just wanted to gently remind about procfs with netlink socket[1]. > It seems to me that whenever you receive() pid information, you > can request some uniq 64(?) bit number and kill the process using it. > Whenever uniqueness of 64-bit number to handle pids will be a question > the netlink message might be painlessly extended to 128 or whatever. No. I have seen this requested twice in this thread now, and despite understanding where everyone is coming from I do not believe it will be wise to implement larger pids. The problem is that we then have to make these larger pids live in the pid namespace, make struct pid larger to hold them and update CRIU to save and restore them. All for a very small handful of processes that use this extended API. Eric