[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgTpLOeMjpLOc8hY7KC6Qv+jR-hBacyBSajJ6iUKasmKA@mail.gmail.com>
Date: Wed, 3 Jun 2020 17:13:36 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <christian.brauner@...ntu.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kyle Evans <self@...e-evans.net>,
Victor Stinner <victor.stinner@...il.com>,
Al Viro <viro@...iv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
Florian Weimer <fweimer@...hat.com>,
Jann Horn <jannh@...gle.com>, Oleg Nesterov <oleg@...hat.com>,
Arnd Bergmann <arnd@...db.de>, Shuah Khan <shuah@...nel.org>,
David Howells <dhowells@...hat.com>,
"Dmitry V. Levin" <ldv@...linux.org>
Subject: Re: [PATCH v5 0/3] close_range()
On Wed, Jun 3, 2020 at 4:24 PM Christian Brauner
<christian.brauner@...ntu.com> wrote:
>
> Ok, here's what I have. Does the below look somewhat sane?
Probably. Needs lots of testing. But this one looks wrong:
> +int __close_range(unsigned fd, unsigned max_fd, unsigned int flags)
> {
> + if ((max_fd + 1) >= cur_max)
> + max_unshare_fds = fd;
A normal value for "close everything starting at X" would have a
max_fd value of ~0.
So "max_fd+1" would overflow to 0, and then this would never trigger.
Other than that it looks what what I imagine my feverdreams were about.
Linus
Powered by blists - more mailing lists