Document /proc/pid PID reuse behavior
PATCH 1/1 Document /proc/pid PID reuse behavior
State explicitly that holding a /proc/pid file descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.
--- Documentation/filesystems/proc.txt | 8 ++++++++ 1 file changed, 8 insertions(+)
Documentation/filesystems/proc.txt +8 -0
@@ -214,6 +214,14 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc/<pid>/smaps file and scan page table. It's slow but very precise. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on +open /proc/<pid> file descriptors corresponding to dead processes +never act on any new process that the kernel may, through chance, have +also assigned the process ID <pid>. Instead, operations on these FDs +usually fail with ESRCH. + Table 1-2: Contents of the status files (as of 4.8) .............................................................................. Field Content
Signature · 1 line
2.19.1.568.g152ad8e336-goog
Quoted 4 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.
Signed-off is missing.
Quoted 10 lines
--- Documentation/filesystems/proc.txt | 8 ++++++++ 1 file changed, 8 insertions(+)Documentation/filesystems/proc.txt +0
-0@@ -214,6 +214,14 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc/<pid>/smaps file and scan page table.
Documentation/filesystems/proc.txt asynchronous manner and the value may not be very precise. To see a precise · line 224
Quoted 10 lines
Documentation/filesystems/proc.txt +8
-0It's slow but very precise. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on +open /proc/<pid> file descriptors corresponding to dead processes +never act on any new process that the kernel may, through chance, have +also assigned the process ID <pid>. Instead, operations on these FDs +usually fail with ESRCH. +
I'd put this text in the beginning of the section, just before table 1-1. Otherwise looks good.
It maybe also useful to update 'man 5 proc' (1) as well
[1] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man5/proc.5
Quoted 6 lines
Documentation/filesystems/proc.txt +0
-0Table 1-2: Contents of the status files (as of 4.8) Field ContentSignature · 1 line
2.19.1.568.g152ad8e336-goog
Signature · 2 lines
Sincerely yours, Mike.
PATCH v2 1/1 Document /proc/pid PID reuse behavior
In reply to Daniel ColascioneState explicitly that holding a /proc/pid file descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.
--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)
Moved paragraphed to start of /proc/pid section; added signed-off-by.
Documentation/filesystems/proc.txt +7 -0
@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on +open /proc/<pid> file descriptors corresponding to dead processes +never act on any new process that the kernel may, through chance, have +also assigned the process ID <pid>. Instead, operations on these FDs +usually fail with ESRCH. Table 1-1: Process specific entries in /proc ..............................................................................
Signature · 1 line
2.19.1.930.g4563a0d9d0-goog
Quoted 6 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.Signed-off-by Daniel Colascione <[email protected]>
Quoted 27 lines
--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)Moved paragraphed to start of
/proc/pidsection; added signed-off-by.Documentation/filesystems/proc.txt +7
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on +open /proc/<pid> file descriptors corresponding to dead processes +never act on any new process that the kernel may, through chance, have +also assigned the process ID <pid>. Instead, operations on these FDs +usually fail with ESRCH. Table 1-1: Process specific entries in /procSignature · 1 line
2.19.1.930.g4563a0d9d0-goog
Signature · 2 lines
Sincerely yours, Mike.
Quoted 9 lines · Mike Rapoport
Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 128
Quoted 9 lines
Documentation/filesystems/proc.txt +1
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +Note that an open a file descriptor to /proc/<pid> or to any of its
"open file descriptor" (the "a" is unnecessary)
Quoted 6 lines
Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 134
Quoted 6 lines
Documentation/filesystems/proc.txt +6
-0+contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on +open /proc/<pid> file descriptors corresponding to dead processes +never act on any new process that the kernel may, through chance, have +also assigned the process ID <pid>. Instead, operations on these FDs +usually fail with ESRCH.
The paragraph is a bit wordy. More pithy:
An open file descriptor for /proc/<pid> (or any of the files or subdirectories in it) does not prevent <pid> from being reused after the process exits. Operations on a file descriptor referring to a dead process usually return ESRCH. They do not act on any new process which has been assigned the same <pid>.
Quoted 9 lines · Matthew Wilcox
Quoted 8 lines · Mike Rapoport
Quoted 8 lines
Documentation/filesystems/proc.txt +0
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1.
Quoted 3 lines
Quoted 1 line
Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 128
Quoted 1 line
Documentation/filesystems/proc.txt +1
-0+Note that an open a file descriptor to /proc/<pid> or to any of its"open file descriptor" (the "a" is unnecessary)
Thanks for spotting that. I had to re-read that sentence three times or so before even seeing that extra "a".
Quoted 9 lines
Quoted 6 lines
Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 134
Quoted 6 lines
Documentation/filesystems/proc.txt +6
-0+contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on +open /proc/<pid> file descriptors corresponding to dead processes +never act on any new process that the kernel may, through chance, have +also assigned the process ID <pid>. Instead, operations on these FDs +usually fail with ESRCH.The paragraph is a bit wordy. More pithy:
Quoted 5 lines
An open file descriptor for /proc/<pid> (or any of the files or subdirectories in it) does not prevent <pid> from being reused after the process exits. Operations on a file descriptor referring to a dead process usually return ESRCH. They do not act on any new process which has been assigned the same <pid>.
I'll send a new patch version --- unless we can just tweak the patch when we merge it into the tree?
Quoted 4 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.
This sounds quite obvious otherwise anybody could simply DoS the system by consuming all available pids. But I do not see any strong reason against having that stated explicitly.
Quoted 1 line
Signed-off-by Daniel Colascione <[email protected]>
Quoted 26 lines
--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)Moved paragraphed to start of
/proc/pidsection; added signed-off-by.Documentation/filesystems/proc.txt +7
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on +open /proc/<pid> file descriptors corresponding to dead processes +never act on any new process that the kernel may, through chance, have +also assigned the process ID <pid>. Instead, operations on these FDs +usually fail with ESRCH. Table 1-1: Process specific entries in /procSignature · 1 line
2.19.1.930.g4563a0d9d0-goog
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 7 lines · Michal Hocko
Quoted 4 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.This sounds quite obvious
Many people *on* *LKML* were wrong about this behavior. If it's not obvious to experienced kernel developers, it's certainly not obvious to the public.
Quoted 2 lines
otherwise anybody could simply DoS the system
by consuming all available pids.
People can do that today using the instrument of terror widely known as fork(2). The only thing standing between fork(2) and a full process table is RLIMIT_NPROC. In a world where we really did reserve a numeric PID through the lifetime of any struct pid to which it refers (i.e., where "cd /proc/$PID" held $PID), we could charge these struct pid reservations against RLIMIT_NPROC and achieve behavior as safe as what we have today. The details would be subtle (you'd have to take pains to avoid double-counting, for example), but it could be made to work. Other people, on the various lkml threads about my process API improvement proposals, have proposed fixing the longstanding PID race problem by making struct pid behave the way people mistakenly believe it behaves today. It's a serious idea worth actual consideration.
Quoted 7 lines · Daniel Colascione
Quoted 6 lines · Michal Hocko
Quoted 4 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.
Quoted 5 lines
Quoted 1 line
This sounds quite obvious
Many people *on* *LKML* were wrong about this behavior. If it's not obvious to experienced kernel developers, it's certainly not obvious to the public.
Fair enough
Quoted 6 lines
Quoted 2 lines
otherwise anybody could simply DoS the system
by consuming all available pids.People can do that today using the instrument of terror widely known as fork(2). The only thing standing between fork(2) and a full process table is
RLIMIT_NPROC.
not really. If you really do care about pid space depletion then you should use pid cgroup controller.
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 10 lines · Michal Hocko
Quoted 7 lines · Daniel Colascione
Quoted 2 lines · Michal Hocko
otherwise anybody could simply DoS the system
by consuming all available pids.People can do that today using the instrument of terror widely known as fork(2). The only thing standing between fork(2) and a full process table is
RLIMIT_NPROC.not really.
What else, besides memory consumption and (as you mention below) cgroups? In practice, nobody uses RLIMIT_NPROC, so outside of various container-y namespaced setups, avoidance of system-DoS-through-PID-exhaustion isn't a pressing problem.
If you really do care about pid space depletion then you
Quoted 1 line
should use pid cgroup controller.
Or that, sure. But since cgroups are optional, the problem with the core model remains. In general, if there's a problem X with the core system API, and you can mitigate X by using a cgroup, X is still a problem.
Quoted 1 line · Daniel Colascione
On Wed, Nov 7, 2018 at 4:00 PM, Michal Hocko <[email protected]> wrote:
[...]
Quoted 7 lines
Quoted 2 lines
If you really do care about pid space depletion then you should use pid cgroup controller.
Or that, sure. But since cgroups are optional, the problem with the core model remains. In general, if there's a problem X with the core system API, and you can mitigate X by using a cgroup, X is still a problem.
I am not questioning that. All that I am saying is that there is a way to mitigate the issue. This is not the only resource where the standard rlimit is not sufficient and there is no other way than cgroups. Actually cgroups were introduced to address rlimit limits IIRC.
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 10 lines · Daniel Colascione
Quoted 9 lines · Michal Hocko
Quoted 7 lines · Daniel Colascione
Quoted 2 lines · Michal Hocko
otherwise anybody could simply DoS the system
by consuming all available pids.People can do that today using the instrument of terror widely known as fork(2). The only thing standing between fork(2) and a full process table is
RLIMIT_NPROC.
Quoted 6 lines
Quoted 1 line
not really.
What else, besides memory consumption and (as you mention below) cgroups? In practice, nobody uses
RLIMIT_NPROC, so outside of various container-y namespaced setups, avoidance of system-DoS-through-PID-exhaustion isn't a pressing problem.
systemd has had a default pid cgroup controller policy (for both user and system slices) for a quite long time. I believe that the most recent version of most enterprise and community distributions support it by default (and probably even some older versions -- commit 49b786ea146f was merged in 2015 and I think systemd grew support for it in 2016).
I agree with your overall point, but it should be noted that the vast majority of Linux systems these days have protections against this (by default) that use the pids cgroup controller.
Signature · 4 lines
Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Michal Hocko - 07.11.18, 17:00:
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
otherwise anybody could simply DoS the system
by consuming all available pids.People can do that today using the instrument of terror widely known as fork(2). The only thing standing between fork(2) and a full process table is
RLIMIT_NPROC.not really. If you really do care about pid space depletion then you should use pid cgroup controller.
Its not quite on-topic, but I am curious now: AFAIK PID limit is 16 bits. Right? Could it be raised to 32 bits? I bet it would be a major change throughout different parts of the kernel.
16 bits sound a bit low these days, not only for PIDs, but also for connections / ports.
Signature · 1 line
Martin
From: Martin Steigerwald
Quoted 1 line
Sent: 07 November 2018 17:05
...
Quoted 3 lines
Its not quite on-topic, but I am curious now: AFAIK PID limit is 16 bits. Right? Could it be raised to 32 bits? I bet it would be a major change throughout different parts of the kernel.
It is probably 15 bits (since -ve pid numbers are used for process groups).
My guess is that userspace and the system call interface will handle 32bit (signed) pid numbers.
(I don't remember 'linux emulation' being one of the emulations that would truncate 32bit pids when one of the BDSs went to 32bit pids.) The main problem will be that big numbers will mess up the alignment of printouts from ps and top (etc).
This can be mitigated by only allocating 'big' numbers on systems that have a lot of pids.
You also really want an O(1) allocator.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Quoted 9 lines · David Laight
From: Martin Steigerwald
Quoted 1 line
Sent: 07 November 2018 17:05
...
Quoted 3 lines
Its not quite on-topic, but I am curious now: AFAIK PID limit is 16 bits. Right? Could it be raised to 32 bits? I bet it would be a major change throughout different parts of the kernel.
It is probably 15 bits (since -ve pid numbers are used for process groups).
Quoted 9 lines
My guess is that userspace and the system call interface will handle 32bit (signed) pid numbers.
(I don't remember 'linux emulation' being one of the emulations that would truncate 32bit pids when one of the BDSs went to 32bit pids.) The main problem will be that big numbers will mess up the alignment of printouts from ps and top (etc).
This can be mitigated by only allocating 'big' numbers on systems that have a lot of pids.
You also really want an O(1) allocator.
The allocator is O(log n) -- it's the IDR allocator, used in cyclic mode. n in this case is the highest ID which is still in use. The tree is log_64(n) levels high. It walks to the bottom of the tree and puts a pointer into the tree. If the cursor has wrapped to the beginning of the tree, it may encounter a PID which is still in use; if it does, it does a bitmap scan of that node, and will then walk up the tree, doing a bitmap scan forward at each level until it finds a free PID.
So it's not exactly O(log(n)), but it's close enough for all practical purposes. And more importantly, it doesn't touch a lot of cachelines. Two or three at each level of the tree that it accesses. If we went all the way to a 32-bit PID, the tree would grow to 6 levels deep, and worst-case would touch 6 + 5 + 4 levels of the tree (starting with trying to allocate PID 0xffffffff, failing, trying to allocate PID 300, then having to walk all the way forward to find PID 0xe0000000), so that's only 45 cachelines.
People care a little too much about O(1)/O(n) behaviour. Cacheline behaviour, and good average-case performance without falling off a cliff in the worst case is much more important.
From: Matthew Wilcox
Quoted 22 lines
Sent: 08 November 2018 12:28
Quoted 9 lines · David Laight
From: Martin Steigerwald
Quoted 1 line
Sent: 07 November 2018 17:05
...
Quoted 3 lines
Its not quite on-topic, but I am curious now: AFAIK PID limit is 16 bits. Right? Could it be raised to 32 bits? I bet it would be a major change throughout different parts of the kernel.
It is probably 15 bits (since -ve pid numbers are used for process groups).
Quoted 9 lines
My guess is that userspace and the system call interface will handle 32bit (signed) pid numbers.
(I don't remember 'linux emulation' being one of the emulations that would truncate 32bit pids when one of the BDSs went to 32bit pids.) The main problem will be that big numbers will mess up the alignment of printouts from ps and top (etc).
This can be mitigated by only allocating 'big' numbers on systems that have a lot of pids.
You also really want an O(1) allocator.
Quoted 7 lines
The allocator is O(log n) -- it's the IDR allocator, used in cyclic mode. n in this case is the highest ID which is still in use. The tree is
log_64(n)levels high. It walks to the bottom of the tree and puts a pointer into the tree. If the cursor has wrapped to the beginning of the tree, it may encounter a PID which is still in use; if it does, it does a bitmap scan of that node, and will then walk up the tree, doing a bitmap scan forward at each level until it finds a free PID.
Right, but you can choose the pid so that you get a perfect hash. You can then put a FIFO free list through the unused entries of the hash table (just an array).
Then pid allocate just picks the oldest free entry and ups the high bits (that the hash masks out) to make the old value stale. Almost no cache lines are involved in the whole operation.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Quoted 14 lines · David Laight
From: Matthew Wilcox
Quoted 5 lines · David Laight
Quoted 3 lines
This can be mitigated by only allocating 'big' numbers on systems that have a lot of pids.
You also really want an O(1) allocator.Quoted 7 lines
The allocator is O(log n) -- it's the IDR allocator, used in cyclic mode. n in this case is the highest ID which is still in use. The tree is
log_64(n)levels high. It walks to the bottom of the tree and puts a pointer into the tree. If the cursor has wrapped to the beginning of the tree, it may encounter a PID which is still in use; if it does, it does a bitmap scan of that node, and will then walk up the tree, doing a bitmap scan forward at each level until it finds a free PID.
Quoted 6 lines
Right, but you can choose the pid so that you get a perfect hash. You can then put a FIFO free list through the unused entries of the hash table (just an array).
Then pid allocate just picks the oldest free entry and ups the high bits (that the hash masks out) to make the old value stale. Almost no cache lines are involved in the whole operation.
You'd be looking for something like dynamic perfect hashing then? I think that'd make a great project for someone to try out. I don't have the time to look into it myself, and I'm not convinced there's a real workload that would benefit. But it'd be a great project for a university student.
From: Matthew Wilcox
Quoted 1 line
Sent: 08 November 2018 14:07
...
Quoted 6 lines
You'd be looking for something like dynamic perfect hashing then? I think that'd make a great project for someone to try out. I don't have the time to look into it myself, and I'm not convinced there's a real workload that would benefit. But it'd be a great project for a university student.
Been there, done that several times.
Half an afternoon's work.
I'm surprised there isn't a C++ container class that will give you a 'id' for a pointer (or other large value).
But they all do it the other way around.
It is also trivial to double the size of the array and 'unzip' the allocated items into their correct halves while adding the other entry to the free list.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Quoted 11 lines · Martin Steigerwald
Michal Hocko - 07.11.18, 17:00:
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
otherwise anybody could simply DoS the system
by consuming all available pids.People can do that today using the instrument of terror widely known as fork(2). The only thing standing between fork(2) and a full process table is
RLIMIT_NPROC.not really. If you really do care about pid space depletion then you should use pid cgroup controller.
Quoted 6 lines
Its not quite on-topic, but I am curious now: AFAIK PID limit is 16 bits. Right? Could it be raised to 32 bits? I bet it would be a major change throughout different parts of the kernel.
16 bits sound a bit low these days, not only for PIDs, but also for connections / ports.
Do you have any specific example of the pid space exhaustion? Well except for a fork bomb attacks that could be mitigated by the pid cgroup controller.
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 17 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.Signed-off-by Daniel Colascione <[email protected]>--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)Moved paragraphed to start of
/proc/pidsection; added signed-off-by.Documentation/filesystems/proc.txt +0
-0
Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 130
Quoted 6 lines
Documentation/filesystems/proc.txt +3
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on
"does not" -> "may not"?
We want to leave this unspecified, so that we can change it in future.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 21 lines · Pavel Machek
Quoted 20 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.Signed-off-by Daniel Colascione <[email protected]>--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)Moved paragraphed to start of
/proc/pidsection; added signed-off-by.Documentation/filesystems/proc.txt +0
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1.
Quoted 7 lines
Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 130
Quoted 3 lines
Documentation/filesystems/proc.txt +3
-0+Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on"does not" -> "may not"?
We want to leave this unspecified, so that we can change it in future.
No. "Does not". I'm sick and tired of procfs behavior being vague and unspecified to the point where even kernel developers have an incorrect mental model of how it all works. With Christian Brauner's good work in place and hopefully my own work to follow, we're moving firmly in the direction of procfs handles being struct pid references. Instead of waffling further, let's just buy into this model and do the best job we can of making it work well.
Pavel Machek
NAKQuoted 28 lines · Daniel Colascione
Quoted 27 lines · Pavel Machek
Quoted 17 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.Signed-off-by Daniel Colascione <[email protected]>--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)Moved paragraphed to start of
/proc/pidsection; added signed-off-by.Documentation/filesystems/proc.txt +0
-0Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 130
Quoted 6 lines
Documentation/filesystems/proc.txt +3
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on"does not" -> "may not"?
Quoted 4 lines
Quoted 1 line
We want to leave this unspecified, so that we can change it in future.
No. "Does not". I'm sick and tired of procfs behavior being vague and unspecified to the point where even kernel developers have an
You being sick and tired does not mean this is good idea.
Quoted 5 lines
incorrect mental model of how it all works. With Christian Brauner's good work in place and hopefully my own work to follow, we're moving firmly in the direction of procfs handles being struct pid references. Instead of waffling further, let's just buy into this model and do the best job we can of making it work well.
So basically decision is being made now, without seeing Christian's and your good work. That's not same thing as documentation...
Please don't do this.
NAK.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 21 lines · Pavel Machek
Quoted 20 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.Signed-off-by Daniel Colascione <[email protected]>--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)Moved paragraphed to start of
/proc/pidsection; added signed-off-by.Documentation/filesystems/proc.txt +0
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1.
Quoted 7 lines
Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 130
Quoted 3 lines
Documentation/filesystems/proc.txt +3
-0+Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on"does not" -> "may not"?
We want to leave this unspecified, so that we can change it in future.
Why can't the documentation describe the current implementation, and change in the future if the implementation changes? I doubt somebody would ever rely on the pid being reused while having the descriptor open. How would that make sense?
Pavel
Quoted 2 lines
Quoted 28 lines · Vlastimil Babka
Quoted 27 lines · Pavel Machek
Quoted 17 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.Signed-off-by Daniel Colascione <[email protected]>--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)Moved paragraphed to start of
/proc/pidsection; added signed-off-by.Documentation/filesystems/proc.txt +0
-0Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 130
Quoted 6 lines
Documentation/filesystems/proc.txt +3
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on"does not" -> "may not"?
Quoted 4 lines
Quoted 1 line
We want to leave this unspecified, so that we can change it in future.
Why can't the documentation describe the current implementation, and change in the future if the implementation changes? I doubt somebody
Documentation should describe "contract" between kernel and userspace.
Quoted 2 lines
would ever rely on the pid being reused while having the descriptor open. How would that make sense?
I agree this is corner space, but users might be surprised that keeping FDs of /proc/pid/X would lead to PID space exhaustion, for example.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 6 lines · Pavel Machek
Quoted 2 lines
would ever rely on the pid being reused while having the descriptor open. How would that make sense?
I agree this is corner space, but users might be surprised that keeping FDs of
/proc/pid/Xwould lead to PID space exhaustion, for example.
We have a limit on the number of FDs a process can have open for a reason. Well, for many reasons.
Quoted 11 lines · Matthew Wilcox
Quoted 6 lines · Pavel Machek
Quoted 2 lines
would ever rely on the pid being reused while having the descriptor open. How would that make sense?
I agree this is corner space, but users might be surprised that keeping FDs of
/proc/pid/Xwould lead to PID space exhaustion, for example.We have a limit on the number of FDs a process can have open for a reason. Well, for many reasons.
And the typical limit is too low. (I've seen people clamp it to 1024 for some reason.) A file descriptor is just a handle to a kernel resource. All kernel resources held on behalf of applications need *some* kind of management interface. File descriptors provide a consistent and uniform instance of such a management interface. Unless there's a very good reason, nobody should be using non-FD handles for kernel resource management. A low default FD table size limit is not an example of one of these good reasons, not when we can raise FD table size limit. In general, the software projects should not have to put up with ugly workarounds for limitations they impose on themselves.
Quoted 6 lines · Daniel Colascione
Quoted 2 lines · Matthew Wilcox
We have a limit on the number of FDs a process can have open for a reason. Well, for many reasons.
And the typical limit is too low. (I've seen people clamp it to 1024 for some reason.)
1024 is the soft limit. 4096 is the default hard limit. You can always ask root to set your hard limit higher if that's what you need.
Quoted 10 lines
A file descriptor is just a handle to a kernel
resource. All kernel resources held on behalf of applications need *some* kind of management interface. File descriptors provide a consistent and uniform instance of such a management interface. Unless there's a very good reason, nobody should be using non-FD handles for kernel resource management. A low default FD table size limit is not an example of one of these good reasons, not when we can raise FD table size limit. In general, the software projects should not have to put up with ugly workarounds for limitations they impose on themselves.
I'm not really sure why you decided to go off on this rant. My point to Pavel was that there's no way a single process can tie up all of the PIDs. Unless root decided to let them shoot everybody else in the system in the foot.
Quoted 29 lines · Vlastimil Babka
Quoted 27 lines · Pavel Machek
Quoted 17 lines · Daniel Colascione
State explicitly that holding a
/proc/pidfile descriptor open does not reserve the PID. Also note that in the event of PID reuse, these open file descriptors refer to the old, now-dead process, and not the new one that happens to be named the same numeric PID.Signed-off-by Daniel Colascione <[email protected]>--- Documentation/filesystems/proc.txt | 7 +++++++ 1 file changed, 7 insertions(+)Moved paragraphed to start of
/proc/pidsection; added signed-off-by.Documentation/filesystems/proc.txt +0
-0Documentation/filesystems/proc.txt process running on the system, which is named after the process ID (PID). · line 130
Quoted 6 lines
Documentation/filesystems/proc.txt +3
-0@@ -125,6 +125,13 @@ process running on the system, which is named after the process ID (PID). The link self points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +Note that an open a file descriptor to /proc/<pid> or to any of its +contained files or subdirectories does not prevent <pid> being reused +for some other process in the event that <pid> exits. Operations on"does not" -> "may not"?
Quoted 7 lines
Quoted 1 line
We want to leave this unspecified, so that we can change it in future.
Why can't the documentation describe the current implementation, and change in the future if the implementation changes? I doubt somebody would ever rely on the pid being reused while having the descriptor open. How would that make sense?
Agreed. I am also of the opinion that this should be documented.
- Joel
Jonathan Corbet
maintainerQuoted 4 lines · On Tue, 20 Nov 2018 10:05:21 +0100 Vlastimil Babka <[email protected]> wrote:
Why can't the documentation describe the current implementation, and change in the future if the implementation changes? I doubt somebody would ever rely on the pid being reused while having the descriptor open. How would that make sense?
In the hopes of ending this discussion, I'm going to go ahead and apply this. Documenting current behavior is good, especially in situations where that behavior can surprise people; if the implementation changes, the docs can change with it.
Thanks,
jon
Quoted 8 lines · Jonathan Corbet
Quoted 4 lines · On Tue, 20 Nov 2018 10:05:21 +0100 Vlastimil Babka <[email protected]> wrote:
Why can't the documentation describe the current implementation, and change in the future if the implementation changes? I doubt somebody would ever rely on the pid being reused while having the descriptor open. How would that make sense?
Quoted 4 lines
In the hopes of ending this discussion, I'm going to go ahead and apply this. Documenting current behavior is good, especially in situations where that behavior can surprise people; if the implementation changes, the docs can change with it.
I'd still prefer changing from "does not" to "may not".
It is really simple change, and once we documented a behaviour, we really should not be changing it.
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html