Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1026655ybp; Fri, 11 Oct 2019 07:59:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqxHsDpljOn6CHWd4RcJ+UbVf3exqPLa4G0qgktLV3dHjt7wzm8cJo8CPE7oFw0tWo2edSkJ X-Received: by 2002:a17:906:c443:: with SMTP id ck3mr14569915ejb.0.1570805959202; Fri, 11 Oct 2019 07:59:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570805959; cv=none; d=google.com; s=arc-20160816; b=c5Ri+W/3yDcFWy0eN4Zeah7yDa6aWPBAq8hJDUh/oGZFzRGjSTBx+hroEKNkeoN42Z CQyHgGF8x9RAh+pW1RVxFYhbmw6l/Vp630ZT9MvLfhHNJUbQwpnDm7btnacqIuqExosx 5ZGTjZKlUx+C8Z9/EXabJLgs0y0VyfaXgYfRK4AGGfHJDp8GpZGKGZ1wAmZzzyCDJ6HP SmlWo62YVKFrJyrpzdulOMPegcxJ6NMROAq/aRjVL1P/FW4vw9CTVbtw37UfxI04GpCx IaC17MneA/G4r1W86xDhOYIYIi7J5VpGFtGlmPmEkuqvOoCQYkJPzadPWAonZyxx8aMp gd0w== 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=Cpz0OPVdz0lvY7YxjxR86HQw6Mhe0P0KSoHxNBSYZCk=; b=Gpbr02HHOXbMIrKPzljgkAAAGuZX38iuLhyYl2lWdz24oEZSwD2vqNyTTNes53RC7h ak2nfNjDPRHTvRrliQ5A1qxw5AmEh7LN7I04x7LCNsUF3S3980zJ8+7UA5HBwMk2j4DG MX3dYHBBNM9QVtij7fL8SebcJn4VfCfEc1aEubvEY2B9JFQ6jRacTaPmzaJXHszRVITP f1tHr7jVtET/XXz+qofHtf6GHuLzcl2ZkDIozrdS7IUWnKpoAUx2mG+U2fILsOZ1/M68 Xcqo+sDMNCRk6jto6uR1m6NucxFweBqKKWbS2dLtnTjViZuH1KxCawBEpg6ItUvmnO8k WCIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ijTDwhFl; 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 k23si5819386ede.274.2019.10.11.07.58.55; Fri, 11 Oct 2019 07:59:19 -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=ijTDwhFl; 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 S1727364AbfJKO43 (ORCPT + 99 others); Fri, 11 Oct 2019 10:56:29 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:46019 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727188AbfJKO42 (ORCPT ); Fri, 11 Oct 2019 10:56:28 -0400 Received: by mail-ot1-f68.google.com with SMTP id 41so8180652oti.12 for ; Fri, 11 Oct 2019 07:56:28 -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=Cpz0OPVdz0lvY7YxjxR86HQw6Mhe0P0KSoHxNBSYZCk=; b=ijTDwhFlFn4QfgOlhEtom29w42EeeTy7Ujy2bs4ItZsaR8Uf8Uno5gRFSvhqw8UfLh JyrIBHwR68u6KRVzMacEGroyDb1oe2yfyTTgXNBG5wy0IfsCQDTf3GxLZdzOmQKsT3p/ sn4OIbiIKgDNQS2WgatN3wXKK9MP997vKqjwv4CsSQ1ab0hnXuaLYjMjxTDYHPVopj7W 9WH7yFFRzB2eidrgZaGHSST/gLbYkid2jVy7IVBpExnz0hzFdoMYnDhcnllKnil37Z5a 7Mj7hbQzCoOWDI4ymSTAEDc9/rbnGROoTCpVJx9oLV8wy+rLTuHd3k9y2cri1mZaoWMN Ap/Q== 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=Cpz0OPVdz0lvY7YxjxR86HQw6Mhe0P0KSoHxNBSYZCk=; b=dMqMNJvh8fIokUD8+KIvjG9k5W/S6bpVNM0es2rkjarnhWh8QSkqVaVg09XgjZ6HnO 8GqPK8awnCuAjHKu7AfwKyzVGjb6p6VZd/ASxdTG7lLLNaYDV3cPKExBnMBD2GN4Ntwo HYVf4SrsyxcFhgbWOyt4njJyjr94+kWayHflF0HfZyTZLvskSDekEahuXmBPuxqSAKAI MMIIR2JiTEqcgXAG41z/GQfC25hJkCo49rcg7VGWPwbwbP/785iV6qP5/KGmveW134pE IpkVTdE9nXKBMJcdFiVmFD1AGXn2d0e8aAkhmWx+o82N944oAXlxbuEvhdVrybnbNa5T dFWw== X-Gm-Message-State: APjAAAXbfvreH9uK3CYyhdCKf53vB4TjTsTCPNqWLftGnYGXOcmjqeAr 1Gk6cGgcKCiJ49MH/Icp5xwRV2yYjgEIcDJJehGqZw== X-Received: by 2002:a05:6830:10cc:: with SMTP id z12mr5196034oto.110.1570805787289; Fri, 11 Oct 2019 07:56:27 -0700 (PDT) MIME-Version: 1.0 References: <20191009160532.20674-1-ckellner@redhat.com> <20191011122323.7770-1-ckellner@redhat.com> In-Reply-To: <20191011122323.7770-1-ckellner@redhat.com> From: Jann Horn Date: Fri, 11 Oct 2019 16:55:59 +0200 Message-ID: Subject: Re: [PATCH v3 1/2] pidfd: show pids for nested pid namespaces in fdinfo To: Christian Kellner , Christian Brauner Cc: 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 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.