linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: jobol@nonadev.net
Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Re: [RFC DRAFT] Adds PUI: process unic identifier
Date: Thu, 12 Jan 2017 19:33:22 +0900	[thread overview]
Message-ID: <201701121933.CBH73963.JQHFLOFMFtOSVO@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20170110215924.4623-1-jobol@nonadev.net>

Jose Bollo wrote:
> Hi all,
> 
> I'd like to get your feeling about the idea
> exposed in that draft. Should continue or stop
> immediately? Is there already some existing work?
> How is the taken approach?
> 
> BR - Jose Bollo
> 
> [RFC DRAFT] Adds PUI: process unic identifier
> 
> The name 'pui' is choosen -instead of puid-
> to avoid confusion with either pid and uid.
> It is intended to identify uniquely each
> activated task item, accordling to namespaces.
> 
> 64 bits seems to be a good deal for beginning.
> The count of second in a year is less than 2^25.
> So if a huge machine is able to create 2^31 processes
> per second (ex: 2^7 cores, each creating 2^24 processes
> -a nighmare-), then the unic id is over in 2^8 years.
> Far more than what a regular system upgrade needs.
> 
> The pui is represented as a hexadecimal value because
> it is much more efficient.

Firstly, please explain the motivation why you need process unique
identifier that is really unique. This patch involves userspace visible
changes but not everybody is aware of what your PTAGS wants to do.

Secondly, please describe how userspace processes use process unique
identifier. This patch adds "Pui:" line and "NSpui:" line to
/proc/$pid/status and SO_PEERPUI option to getsockopt(), but nothing else.
Why these lines and option are needed and why they are sufficient?

There is start_time field ("struct task_struct"->real_start_time)
in /proc/$pid/stat which is already almost unique. Even if userspace
processes use both $pid and start_time for identifying a process, is it
unreliable? If userspace processes use both "struct task_struct"->pid
and "struct task_struct"->real_start_time for identifying a process,
is it still unreliable? I wonder why find_pui_ns() needs to be aware of
CONFIG_PID_NS. How userspace processes use process unique identifier for
identifying a "struct task_struct"?

There are %Lu %Ld %Lx %LX kstrtoull() kstrtoll() for converting
string to 64bit integer, and %llu %lld %llx %llX for converting
64bit integer to string. You don't need to redefine 64bit types
using typedef keyword.

  reply	other threads:[~2017-01-12 10:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10 21:59 [RFC DRAFT] Adds PUI: process unic identifier jobol
2017-01-12 10:33 ` Tetsuo Handa [this message]
2017-01-13  8:45   ` José Bollo

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=201701121933.CBH73963.JQHFLOFMFtOSVO@I-love.SAKURA.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=jobol@nonadev.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).