public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Emmanuel Deloget <emmanuel.deloget@efixo.com>
To: "[ML] linux-kernel" <linux-kernel@vger.kernel.org>
Cc: Emmanuel Deloget <emmanuel.deloget@efixo.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: /proc/$PID/sched does not take PID namespace into account
Date: Tue, 03 Sep 2013 16:22:33 +0200	[thread overview]
Message-ID: <5225F0A9.5040100@efixo.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2580 bytes --]

Hello,

(please CC me when answering this mail ; and sorry for my borken
English).

I noticed that when a process is executed in a PID namespace it can
still find his real PID by parsing /proc/$PID_IN_NS/sched.

(in this example I created a new PID namespace and ran /bin/bash at
PID 1)

  # uname -a
  Linux my-thinkpad 3.9-1-amd64 #1 SMP Debian 3.9.6-1 x86_64 GNU/Linux
  #
  # pidof bash
  1
  # head -n 1 /proc/1/sched
  bash (14957, #threads: 1)
  # cat /proc/1/stat
  1 (bash) S 0 1 0 34823 220 4202752 11359 (...)

In the root PID namespace

  # pidof bash
  (...) 14957 (...)
  # head -n 1 /proc/14957/sched
  bash (14957, #threads: 1)
  # cat /proc/14957/stat
  14957 (bash) S 14956 14957 23465 34823 14957 4202752 11386 (...)

The principle of least surprise tells me that if my PID is n in a
particular PID namespace then every stat or debug info should tell
me that my PID is n (i.e. I should not be able to get the real PID
of my program). This is a consistency issue: if I get different
information from different sources I may not be able to tell which
one is the right one.

The issue (if this is really an issue) lies in kernel/sched/debug.c,
function proc_sched_show_task(). The code says [1]:

    SEQ_printf(m, "%s (%d, #threads: %d)\n", p->comm, p->pid,
                        get_nr_threads(p));

I understand that you're not supposed to use the content of a /proc
file that has been generated by a kernel source file named "debug.c"
in a production environment yet several distributions out there seems
to enable this by default (at least the Debian distribution I'm using
does it).

I see a few options:

* either it's a bug and it should be corrected (I'm not sure how to
  do it; the printed PID should reflect the current PID namespace
  and I don't how how to get this information).

* or it has been decided on purpose (i.e. it's not a bug);
  /proc/$PID/sched then offers a reliable way to get the real PID
  of any process, including processes that run in a child PID
  namespace.

* or it's a bug but it cannot be corrected (kernel ABI ; it has been
  here for a looooong time - possibly since the PID namespace
  integration).

(There might be other options here).

In the two last cases there is no need for a patch but I'd be happy
if someone explains the reasoning.

Best regards,

-- Emmanuel Deloget

[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/debug.c?id=refs/tags/v3.11#n495
[2]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/debug.c?id=refs/tags/v3.11#n118



[-- Attachment #2: emmanuel_deloget.vcf --]
[-- Type: text/x-vcard, Size: 280 bytes --]

begin:vcard
fn:Emmanuel Deloget
n:Deloget;Emmanuel
org:efixo / SFR;DATA
adr;quoted-printable:;;67 mont=C3=A9e de St Menet;MARSEILLE;;13011;FRANCE
email;internet:emmanuel.deloget@efixo.com
title:Team Leader
tel;work:04 88 15 50 77
url:www.sfr.fr
version:2.1
end:vcard


             reply	other threads:[~2013-09-03 14:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03 14:22 Emmanuel Deloget [this message]
2013-09-09 11:01 ` /proc/$PID/sched does not take PID namespace into account Peter Zijlstra
2013-09-09 13:58   ` Emmanuel Deloget
2013-09-10  9:18   ` Peter Zijlstra
2013-09-12 18:05   ` [tip:sched/core] sched/debug: Take " tip-bot for Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5225F0A9.5040100@efixo.com \
    --to=emmanuel.deloget@efixo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox