linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Colascione <dancol@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Pavel Machek <pavel@ucw.cz>, Vlastimil Babka <vbabka@suse.cz>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Tim Murray <timmurray@google.com>,
	Joel Fernandes <joelaf@google.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roman Gushchin <guro@fb.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Dennis Zhou (Facebook)" <dennisszhou@gmail.com>,
	Prashant Dhamdhere <pdhamdhe@redhat.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v2] Document /proc/pid PID reuse behavior
Date: Tue, 20 Nov 2018 09:48:27 -0800	[thread overview]
Message-ID: <CAKOZuevidVnZ+9vB1CxsetPVH=2P7eoORA1F445HOp-jS5rwOA@mail.gmail.com> (raw)
In-Reply-To: <20181120173912.GD3065@bombadil.infradead.org>

On Tue, Nov 20, 2018 at 9:39 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Nov 20, 2018 at 10:18:29AM +0100, Pavel Machek wrote:
> > > 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.
>
> 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.

  reply	other threads:[~2018-11-20 17:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31 15:06 [PATCH] Document /proc/pid PID reuse behavior Daniel Colascione
2018-11-01  7:08 ` Mike Rapoport
2018-11-05 13:22 ` [PATCH v2] " Daniel Colascione
2018-11-06  6:01   ` Mike Rapoport
2018-11-07 17:16     ` Matthew Wilcox
2018-11-07 18:21       ` Daniel Colascione
2018-11-06 13:05   ` Michal Hocko
2018-11-07 15:48     ` Daniel Colascione
2018-11-07 16:00       ` Michal Hocko
2018-11-07 16:10         ` Daniel Colascione
2018-11-07 16:19           ` Michal Hocko
2018-11-19 11:16           ` Aleksa Sarai
2018-11-07 17:04         ` Martin Steigerwald
2018-11-08 12:02           ` David Laight
2018-11-08 12:27             ` Matthew Wilcox
2018-11-08 13:42               ` David Laight
2018-11-08 14:07                 ` Matthew Wilcox
2018-11-08 14:14                   ` David Laight
2018-11-08 13:25           ` Michal Hocko
2018-11-19 10:54   ` Pavel Machek
2018-11-19 16:24     ` Daniel Colascione
2018-11-20  8:50       ` Pavel Machek
2018-11-20  9:05     ` Vlastimil Babka
2018-11-20  9:18       ` Pavel Machek
2018-11-20 17:39         ` Matthew Wilcox
2018-11-20 17:48           ` Daniel Colascione [this message]
2018-11-20 17:59             ` Matthew Wilcox
2018-11-20 16:37       ` Joel Fernandes
2018-11-20 16:49       ` Jonathan Corbet
2018-11-20 16:57         ` Pavel Machek

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='CAKOZuevidVnZ+9vB1CxsetPVH=2P7eoORA1F445HOp-jS5rwOA@mail.gmail.com' \
    --to=dancol@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=dennisszhou@gmail.com \
    --cc=guro@fb.com \
    --cc=joelaf@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=pdhamdhe@redhat.com \
    --cc=rppt@linux.ibm.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=surenb@google.com \
    --cc=timmurray@google.com \
    --cc=vbabka@suse.cz \
    --cc=willy@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;
as well as URLs for NNTP newsgroup(s).