All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Kitt <steve@sk2.org>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: linux-man@vger.kernel.org,
	Alejandro Colomar <alx.manpages@gmail.com>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	Giuseppe Scrivano <gscrivan@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6] close_range.2: new page documenting close_range(2)
Date: Thu, 28 Jan 2021 23:10:40 +0100	[thread overview]
Message-ID: <20210128231040.6c85915f@heffalump.sk2.org> (raw)
In-Reply-To: <e761f00d-751f-f782-9af1-c5f868d52df0@gmail.com>

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

Hello Michael,

On Thu, 28 Jan 2021 21:50:23 +0100, "Michael Kerrisk (man-pages)"
<mtk.manpages@gmail.com> wrote:
> Thanks for your patch revision. I've merged it, and have
> done some light editing, but I still have a question:
> 
> On 1/23/21 5:11 PM, Stephen Kitt wrote:
> 
> [...]
> 
> > +.SH ERRORS  
> 
> > +.TP
> > +.B EMFILE
> > +The per-process limit on the number of open file descriptors has been
> > reached +(see the description of
> > +.B RLIMIT_NOFILE
> > +in
> > +.BR getrlimit (2)).  
> 
> I think there was already a question about this error, but
> I still have a doubt.
> 
> A glance at the code tells me that indeed EMFILE can occur.
> But how can the reason be because the limit on the number
> of open file descriptors has been reached? I mean: no new
> FDs are being opened, so how can we go over the limit. I think
> the cause of this error is something else, but what is it?

Here’s how I understand the code that can lead to EMFILE:

* in __close_range(), if CLOSE_RANGE_UNSHARE is set, call unshare_fd() with
  CLONE_FILES to clone the fd table
* unshare_fd() calls dup_fd()
* dup_fd() allocates a new fdtable, and if the resulting fdtable ends up
  being too small to hold the number of fds calculated by
  sane_fdtable_size(), fails with EMFILE

I suspect that, given that we’re starting with a valid fdtable, the only way
this can happen is if there’s a race with sysctl_nr_open being reduced.

Incidentally, isn’t this comment in file.c somewhat misleading?

		/*
		 * If the requested range is greater than the current maximum,
		 * we're closing everything so only copy all file descriptors
		 * beneath the lowest file descriptor.
		 */

As I understand it, dup_fd() will always copy any open file descriptor
anyway, it won’t stop at max_unshare_fds if that’s lower than the number of
open fds (thanks to save_fdtable_size())...

Regards,

Stephen

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-01-28 23:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-23 16:11 [PATCH v6] close_range.2: new page documenting close_range(2) Stephen Kitt
2021-01-28 20:50 ` Michael Kerrisk (man-pages)
2021-01-28 22:10   ` Stephen Kitt [this message]
     [not found]     ` <20210129100024.m4bil5mz5prry4iq@wittgenstein>
2021-03-21 15:31       ` Michael Kerrisk (man-pages)
2021-01-29 10:01   ` Christian Brauner
2021-03-09 19:53   ` Stephen Kitt
2021-03-21 15:38     ` Michael Kerrisk (man-pages)
2021-03-22 21:31       ` Stephen Kitt

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=20210128231040.6c85915f@heffalump.sk2.org \
    --to=steve@sk2.org \
    --cc=alx.manpages@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=gscrivan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.