From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8ACC7ECE58C for ; Fri, 11 Oct 2019 15:30:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 617F5206A1 for ; Fri, 11 Oct 2019 15:30:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="axMZJb56" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728158AbfJKPab (ORCPT ); Fri, 11 Oct 2019 11:30:31 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:42043 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726827AbfJKPaa (ORCPT ); Fri, 11 Oct 2019 11:30:30 -0400 Received: by mail-oi1-f194.google.com with SMTP id i185so8305440oif.9 for ; Fri, 11 Oct 2019 08:30:30 -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=G65rnrPhLbwiKa12jxK6VsnV1tu58T/eP6dY6zrzvZM=; b=axMZJb56FTNco00uonEJke76cy2AQd2gHUV3BqSx2OB0U6z6GuUjQ/Xz6xiljm5g5Z lW6rWqLQwABKmQ3T7lwpMck0t6kyXZ5t7+incgZFUVfOJ76gcLCkthIk+XDFt9lHczAC nktxww/gmoLYI6OOJY4ZZRSwXdcoT/+Rp8la7qB1uV8Ir/rkNeVYs4rrDBatIyui1oQ0 EebxyMVyHzNptgHHQHUH9c8utm6XDIp/POf1aKlASei1mcB37YHRw6a48R6YDxMiFyMM gyT8fjsL/3HGGKf84fttmBK6bz4mOXpQDT+vUlJJfYdBoc9ont8aU7zgzfPQZ5v1aaj3 IL9A== 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=G65rnrPhLbwiKa12jxK6VsnV1tu58T/eP6dY6zrzvZM=; b=iPv26K9oco91ln6y7F9LpVCqclvW3NZIOvivHSulLItyas/IL1cJnLkLhymGyXrnPV C1d1A89OHI4ecPDw6rmEOW6oNBB8kkzLGMRzrdDcunHfzmjiashnBH983SRSMkRkARKl O7A5MS+BHVWp6CWsRbbbpY7L0doVsgKB6YT/bzajgESaJD5RytsIpe4fzISECCmBl0Kx j6hkoIsCfT27ELV9DIir5UhweyfNwOMso6qFBvqS3z7pVAH9pgrBURXgs68VMJS1U986 jIb87AL0K2vYP3K6rb9uP8tNp+CohUwbueImm4dx6WAdjEuUT8GhHuX8XllnsjdCnhPQ 73vQ== X-Gm-Message-State: APjAAAX4MLwLETXyU7qObs39gYqdMtWZwtRHLkeMAPULYHRadJN3O5bA 3/As0gHx2XvdCo6cawFbYx1+10nDk5fJUL0LJGlYqg== X-Google-Smtp-Source: APXvYqztJ6TtWV/CrITLOCN+D+HZbp0PNRoBL4ZgaP0aQOPkhKOlPy6vMt3rYNP9qXdAzUUGPhAq8/WORY/3Xm8vQzI= X-Received: by 2002:aca:da41:: with SMTP id r62mr12192042oig.47.1570807829434; Fri, 11 Oct 2019 08:30:29 -0700 (PDT) MIME-Version: 1.0 References: <20191009160532.20674-1-ckellner@redhat.com> <20191011122323.7770-1-ckellner@redhat.com> <20191011151700.hdvztoxonpvogadv@wittgenstein> In-Reply-To: <20191011151700.hdvztoxonpvogadv@wittgenstein> From: Jann Horn Date: Fri, 11 Oct 2019 17:30:03 +0200 Message-ID: Subject: Re: [PATCH v3 1/2] pidfd: show pids for nested pid namespaces in fdinfo To: Christian Brauner Cc: Christian Kellner , Christian Brauner , kernel list , Linux API , Christian Kellner , Andrew Morton , "Peter Zijlstra (Intel)" , Ingo Molnar , Michal Hocko , Thomas Gleixner , Elena Reshetova , Roman Gushchin , Andrea Arcangeli , Al Viro , Aleksa Sarai , "Dmitry V. Levin" 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 Fri, Oct 11, 2019 at 5:17 PM Christian Brauner wrote: > > On Fri, Oct 11, 2019 at 04:55:59PM +0200, Jann Horn wrote: > > On Fri, Oct 11, 2019 at 2:23 PM Christian Kellner wrote: > > > The fdinfo file for a process file descriptor already contains the > > > pid of the process in the callers namespaces. Additionally, if pid > > > namespaces are configured, show the process ids of the process in > > > all nested namespaces in the same format as in the procfs status > > > file, i.e. "NSPid:\t%d\%d...". This allows the easy identification > > > of the processes in nested namespaces. > > [...] > > > #ifdef CONFIG_PROC_FS > > > +static inline void print_pidfd_nspid(struct seq_file *m, struct pid *pid, > > > + struct pid_namespace *ns) > > > > `ns` is the namespace of the PID namespace of the procfs instance > > through which the file descriptor is being viewed. > > > > > +{ > > > +#ifdef CONFIG_PID_NS > > > + int i; > > > + > > > + seq_puts(m, "\nNSpid:"); > > > + for (i = ns->level; i <= pid->level; i++) { > > > > ns->level is the level of the PID namespace associated with the procfs > > instance through which the file descriptor is being viewed. pid->level > > is the level of the PID associated with the pidfd. > > > > > + ns = pid->numbers[i].ns; > > > + seq_put_decimal_ull(m, "\t", pid_nr_ns(pid, ns)); > > > + } > > > +#endif > > > +} > > > > I think you assumed that `ns` is always going to contain `pid`. > > However, that's not the case. Consider the following scenario: > > > > - the init_pid_ns has two child PID namespaces, A and B (each with > > its own mount namespace and procfs instance) > > - process P1 lives in A > > - process P2 lives in B > > - P1 opens a pidfd for itself > > - P1 passes the pidfd to P2 (e.g. via a unix domain socket) > > - P2 reads /proc/self/fdinfo/$pidfd > > > > Now the loop will print the ID of P1 in A. I don't think that's what > > you intended? You might want to bail out if "pid_nr_ns(pid, ns) == 0", > > or something like that. > > I assumed the same thing happens when you pass around an fd for > /proc/self/status and that's why I didn't object to this behavior. I don't see how /proc/$pid/status is relevant. In the /proc/$pid/status case, the output is the list of PIDs starting at the PID namespace the procfs is associated with; and the process is always contained in that namespace, which also means that the first PID listed is the one in the PID namespace of the procfs instance. In the pidfd case, the process is not necessarily contained in that namespace, and the output doesn't make sense.