mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®