Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2948210imu; Mon, 19 Nov 2018 08:29:01 -0800 (PST) X-Google-Smtp-Source: AFSGD/UDawkH0YQvAh4U7Qlp2l/UOjX2hj1gNkzGBdCdc8PymGECXlOyKt/q7at+qmXdf+7veVcf X-Received: by 2002:a17:902:9897:: with SMTP id s23mr10367757plp.69.1542644941547; Mon, 19 Nov 2018 08:29:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542644941; cv=none; d=google.com; s=arc-20160816; b=HRKXF0rPiZwGZ1SxKS5R3RHdlte4t8c09CtnfysLSogxkgItcBunTsdlrjriCvuTiX DqOADIvJM5p3rjTEh6H8VNGPbiU3GsmJdI8wvqz3C7fxL6ORcGtUIvRYF4X5SPvI0AX8 hrCvLbiyJj6wNTVYnE+r0TQEgapSj3Dpdifa5iisOLqc9wt5rOFsTdvVM/pydy/FcZ2h 5ngrc54RFB9sXOqLOwlaoCeKapMRl3mM2ViVid76iAd29JMN4mLjr2KuayW2Rk32gvBI fmsPtKsbTkbMm+xxXcJ2BQlM+2alzpL1bINcPZsg6Kfb4pMbBIkp2PfxcId6eABq9k77 pDiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from; bh=kDW4d7MT9R/NwiEzi3zZroYFdzf4ZHyK+ktAimOo8Qs=; b=juVPC/69G7Vg8Voamm2IL0RT0R+Eb1i2e8rQvEPfD2hDiWfFPW4vTq4Hs8lg1N3A/d A6F4PN0i8EghhFZ2lZ0e+QWT1ZDh8dxNLozim74beSs4hzdBpvh+Y0o89ZLi0CaGxqQY NdAYIVbx5y6whipG9THqN7KQv0b+pWil0FYZukbgCdOH9W9nW63aFWD+brXnJpqCCHIl xwYN0LEWYuEaxby+I/gQLPBDtv/7/hRR1NvQEfo2CkYXkhwDtbakKNnlC5yW0k+ke1fo jmleZBgBwktCEFnhOhhjKEn1QmCV/lYKbxjMAvFr+1IwxIDRxa0CbTM/2cVeH7yfhAMI +RoQ== 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=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t11si13136594plo.293.2018.11.19.08.28.45; Mon, 19 Nov 2018 08:29:01 -0800 (PST) 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=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730132AbeKTCuR (ORCPT + 99 others); Mon, 19 Nov 2018 21:50:17 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:54106 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729865AbeKTCuR (ORCPT ); Mon, 19 Nov 2018 21:50:17 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gOmNF-0003to-14; Mon, 19 Nov 2018 09:26:09 -0700 Received: from 67-3-154-154.omah.qwest.net ([67.3.154.154] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gOmNC-0001BG-SL; Mon, 19 Nov 2018 09:26:08 -0700 From: ebiederm@xmission.com (Eric W. Biederman) 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 References: <20181118111751.6142-1-christian@brauner.io> Date: Mon, 19 Nov 2018 10:26:00 -0600 In-Reply-To: (Dmitry Safonov's message of "Mon, 19 Nov 2018 16:13:30 +0000") Message-ID: <875zwt2fvr.fsf_-_@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1gOmNC-0001BG-SL;;;mid=<875zwt2fvr.fsf_-_@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.154.154;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/eyLRLeC/f35jz/EU5CEoWdYiiMT2Fhk8= X-SA-Exim-Connect-IP: 67.3.154.154 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa04.xmission.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TVD_RCVD_IP,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01, XMSubLong,XMSubMetaSx_00 autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4997] * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 XMSubMetaSx_00 1+ Sexy Words * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Dmitry Safonov <0x7f454c46@gmail.com> X-Spam-Relay-Country: X-Spam-Timing: total 1169 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 3.3 (0.3%), b_tie_ro: 2.2 (0.2%), parse: 1.41 (0.1%), extract_message_metadata: 4.1 (0.3%), get_uri_detail_list: 1.31 (0.1%), tests_pri_-1000: 7 (0.6%), tests_pri_-950: 1.95 (0.2%), tests_pri_-900: 1.50 (0.1%), tests_pri_-90: 25 (2.2%), check_bayes: 23 (2.0%), b_tokenize: 9 (0.8%), b_tok_get_all: 6 (0.5%), b_comp_prob: 2.6 (0.2%), b_tok_touch_all: 3.4 (0.3%), b_finish: 0.75 (0.1%), tests_pri_0: 1092 (93.4%), check_dkim_signature: 0.60 (0.1%), check_dkim_adsp: 2.3 (0.2%), poll_dns_idle: 0.39 (0.0%), tests_pri_10: 4.5 (0.4%), tests_pri_500: 16 (1.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] proc: allow killing processes via file descriptors (Larger pids) X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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