Received: by 10.223.164.221 with SMTP id h29csp2249857wrb; Tue, 17 Oct 2017 19:09:55 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RaKr1k49KjfvXszSHqm2JPpHT04gRU2chYDwXhE8BkF6co6PgUDfWACpB0nDUi+1Q6e7VF X-Received: by 10.84.129.36 with SMTP id 33mr5634249plb.303.1508292595054; Tue, 17 Oct 2017 19:09:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508292595; cv=none; d=google.com; s=arc-20160816; b=SOa74Vsjvw8qV8MidDP+AlZ/lvOHGy2vT7dPcv6O4nKrmiSUgl2S/lWf3+DtWCU6WD 7WqCBG2s7tAw5PKumei0Oh6kTpGJCX5pshjECq5ds/TJQS6yehFJLmM/GpNDbF2zs1d7 7V0MP8BG3/+LNaob5wuo3sJ20FgUzUtriy+mVIwKzFd0aMFML4sRTN6Jh5IpefFHvWIB U36fPIVvtr3+mVtmCQyPYtRT7BC2Xm3km5ZwElCI5jMT65Icei3KuGmkWDp6ZKWPHxot UOserhHIuXrvbnkBDMutEZS/DC0PIw9suEQomVFP78vIqr5FjYejmkmKBPKgtwz+CHFm Oh/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=L0QNHHCZ8Au/wd/b5WQ8OJRSWMOOf8un8rXzQmnGNYo=; b=dhdZMfQHfRaSsMA7wdyGRCQQ7PzvG4m3ST7LrWqh6c0jgyYYZL551/TMmRiZb0lHzK 5Ypua+oOom6kqfobFmU7CRK+CxXfirIQt78BnBiWG3fAsePUVM7WvlZJUBh2UwqNUjqn 6hISXQNxqfQvw9cdxUDBpqVsmuwlmSBiJeJ3vUWgYBfYuZ4ak1KD4ew6UmkECoFC4Pl4 NLNYTu+aOq7yfSnOras1Gc0uwguR+nJ9gj2XYFwzQ27XpDivSKi3bgfo+Gphf8vjQkUb NN/WxiaZz3Kn4oDB2Mkqy3StMGIejC4N//OsmiFbGksyt0RRAdN5cOwqloVDYwpPofb9 qwnw== 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=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u3si6964862plb.171.2017.10.17.19.09.40; Tue, 17 Oct 2017 19:09:55 -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=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936536AbdJQPi5 (ORCPT + 99 others); Tue, 17 Oct 2017 11:38:57 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:32212 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934122AbdJQPiz (ORCPT ); Tue, 17 Oct 2017 11:38:55 -0400 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9HFciiT024325 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Oct 2017 15:38:45 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v9HFciUd002084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Oct 2017 15:38:44 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v9HFchoV028476; Tue, 17 Oct 2017 15:38:44 GMT Received: from dhcp-whq-twvpn-1-vpnpool-10-159-152-30.vpn.oracle.com (/10.159.152.30) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Oct 2017 08:38:43 -0700 Subject: Re: [PATCH v4] pidns: introduce syscall translate_pid To: Andy Lutomirski References: <150788678482.924140.11785205105514746135.stgit@buzz> <20171013160514.GA27812@redhat.com> <3bdb5341-9ae6-265a-ce5b-45c2cfc76fad@yandex-team.ru> <20171016143628.b2ef80a9ef16d4345889b4d9@linux-foundation.org> Cc: Nagarathnam Muthusamy , Andrew Morton , Konstantin Khlebnikov , Oleg Nesterov , Linux API , "linux-kernel@vger.kernel.org" , Serge Hallyn , "Eric W. Biederman" , Eugene Syromiatnikov From: Prakash Sangappa Message-ID: Date: Tue, 17 Oct 2017 08:38:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/16/17 5:52 PM, Andy Lutomirski wrote: > On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa > wrote: >> >> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote: >>> >>> >>> On 10/16/2017 02:36 PM, Andrew Morton wrote: >>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov >>>> wrote: >>>> >>>>>>>> pid_t translate_pid(pid_t pid, int source, int target); >>>>>>>> >>>>>>>> This syscall converts pid from source pid-ns into pid in target >>>>>>>> pid-ns. >>>>>>>> If pid is unreachable from target pid-ns it returns zero. >>>>>>>> >>>>>>>> Pid-namespaces are referred file descriptors opened to proc files >>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative >>>>>>>> argument >>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid. >>>>>>>> >>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward >>>>>>>> translation requires scanning all tasks. Also pids could be >>>>>>>> translated >>>>>>>> by sending them through unix socket between namespaces, this method >>>>>>>> is >>>>>>>> slow and insecure because other side is exposed inside pid namespace. >>>>> Andrew asked why we might need this. >>>>> >>>>> Such conversion is required for interaction between processes across >>>>> pid-namespaces. >>>>> For example to identify process in container by pid file looking from >>>>> outside. >>>>> >>>>> Two years ago I've solved this in project of mine with monstrous code >>>>> which >>>>> forks couple times just to convert pid, lucky for me performance wasn't >>>>> important. >>>> That's a single user who needed this a single time, and found a >>>> userspace-based solution anyway. This is not exactly compelling! >>>> >>>> Is there a stronger case to be made? How does this change benefit our >>>> users? Sell it to us! >>> Oracle database is planning to use pid namespace for sandboxing database >>> instances and they need an API similar to translate_pid to effectively >>> translate process IDs from other pid namespaces. Prakash (cced in mail) can >>> provide more details on this usecase. >> >> As Nagarathnam indicated, Oracle Database will be using pid namespaces and >> needs a direct method of converting pids of processes in the pid namespace >> hierarchy. In this use case multiple >> nested PID namespaces will be used. The currently available mechanism are >> not very efficient for this use case. For ex. as Konstantin described, using >> /proc//status would require the application to scan all the pid's >> status files to determine the pid of given process in a child namespace. >> >> Use of SCM_CREDENTIALS's socket message is another way, which would require >> every process starting inside a pid namespace to send this message and the >> receiving process in the target namespace would have to save the converted >> pid and reference it. This mechanism becomes cumbersome especially if the >> application has to deal with multiple nested pid namespaces. Also, the >> Database needs to be able to convert a thread's global pid(gettid()). >> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires >> CAP_SYS_ADMIN, which is an issue. >> >> So having a direct method, like the API that Konstantin is proposing, will >> work best for the Database >> since pid of a process in any of the nested pid namespaces can be converted >> as and when required. I think with the proposed API, the application should >> be able to convert pid of a process or tid(gettid()) of a thread as well. >> > > Can you explain what Oracle's database is planning to do with this information? Database uses the PID to programmatically find out if the process/thread is alive(kill 0) also send signals to the processes requesting it to dump status/debug information and kill the processes in case of a shutdown abort of the instance. -Prakash. From 1581505856271166498@xxx Tue Oct 17 11:58:36 +0000 2017 X-GM-THRID: 1581133950441644275 X-Gmail-Labels: Inbox,Category Forums