Re: [PATCH 1/2] pidmap(2)

On 9/7/17, Djalal Harouni [off-list ref] wrote:

Hi Alexey,

On Thu, Sep 7, 2017 at 4:04 AM, Andy Lutomirski [off-list ref]
wrote:

quoted

On Wed, Sep 6, 2017 at 2:04 AM, Alexey Dobriyan [off-list ref]
wrote:

quoted

On 9/6/17, Randy Dunlap [off-list ref] wrote:

quoted

On 09/05/17 15:53, Andrew Morton wrote:

[...]

quoted

quoted

quoted

also, I expect that the tiny kernel people will want kconfig options
for
these syscalls.

We'll add it but the question if it is a good idea. Ideally these system
calls
should be mandatory and /proc optional.

$ size kernel/pidmap.o fs/fdmap.o
   text    data     bss     dec     hex filename
    560       0       0     560     230 kernel/pidmap.o
    617       0       0     617     269 fs/fdmap.o

After much discussion at LPC/KS last year, I thought the idea was to
try to speed up /proc rather than replacing it outright.  The two
specific ideas I recall were:

1. Add a syscall like readfileat() that you can use to, in a single
operation, open, read, and close a /proc file (or other file).  This
should vastly reduce locking and RCU overhead.

2. Add a /proc file that has a nice binary format for task info.
(nl_attr?)

I don't see why pidmap() deserves to be significantly faster than
getdents().

Also, a pidmap() syscall like this inherently bypasses any security
restrictions implied by the way that /proc is mounted.  It can respect
hidepid, but hidepid (as a per-namespace concept) is an enormous turd
that badly needs to be deprecated, and Djalal is working on exactly
that.

Yes as noted by Andy, me and Alexey Gladkov are working on modernizing
procfs [1] and to reduce/remove ties within pid namespaces which has lot
of problems now.
...

Kudos for digging into this mess.
But the question will remain: how get pids of existing processes quickly.