From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Date: Tue, 21 May 2019 12:09:29 +0000 Subject: Re: [PATCH 1/2] open: add close_range() Message-Id: <87tvdoau12.fsf@oldenburg2.str.redhat.com> List-Id: References: <20190521113448.20654-1-christian@brauner.io> In-Reply-To: <20190521113448.20654-1-christian@brauner.io> (Christian Brauner's message of "Tue, 21 May 2019 13:34:47 +0200") MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: Christian Brauner Cc: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, jannh@google.com, oleg@redhat.com, tglx@linutronix.de, torvalds@linux-foundation.org, arnd@arndb.de, shuah@kernel.org, dhowells@redhat.com, tkjos@android.com, ldv@altlinux.org, miklos@szeredi.hu, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org, x86@kernel.org * Christian Brauner: > +/** > + * __close_range() - Close all file descriptors in a given range. > + * > + * @fd: starting file descriptor to close > + * @max_fd: last file descriptor to close > + * > + * This closes a range of file descriptors. All file descriptors > + * from @fd up to and including @max_fd are closed. > + */ > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_= fd) > +{ > + unsigned int cur_max; > + > + if (fd > max_fd) > + return -EINVAL; > + > + rcu_read_lock(); > + cur_max =3D files_fdtable(files)->max_fds; > + rcu_read_unlock(); > + > + /* cap to last valid index into fdtable */ > + if (max_fd >=3D cur_max) > + max_fd =3D cur_max - 1; > + > + while (fd <=3D max_fd) > + __close_fd(files, fd++); > + > + return 0; > +} This seems rather drastic. How long does this block in kernel mode? Maybe it's okay as long as the maximum possible value for cur_max stays around 4 million or so. Solaris has an fdwalk function: So a different way to implement this would expose a nextfd system call to userspace, so that we can use that to implement both fdwalk and closefrom. But maybe fdwalk is just too obscure, given the existence of /proc. I'll happily implement closefrom on top of close_range in glibc (plus fallback for older kernels based on /proc=E2=80=94with an abort in case that doesn't work because the RLIMIT_NOFILE hack is unreliable unfortunately). Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F259C04AAF for ; Tue, 21 May 2019 12:09:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1F3A3217D4 for ; Tue, 21 May 2019 12:09:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727999AbfEUMJu convert rfc822-to-8bit (ORCPT ); Tue, 21 May 2019 08:09:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53008 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726344AbfEUMJt (ORCPT ); Tue, 21 May 2019 08:09:49 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CAE443179162; Tue, 21 May 2019 12:09:38 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-219.str.redhat.com [10.33.192.219]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8854750A63; Tue, 21 May 2019 12:09:30 +0000 (UTC) From: Florian Weimer To: Christian Brauner Cc: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, jannh@google.com, oleg@redhat.com, tglx@linutronix.de, torvalds@linux-foundation.org, arnd@arndb.de, shuah@kernel.org, dhowells@redhat.com, tkjos@android.com, ldv@altlinux.org, miklos@szeredi.hu, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 1/2] open: add close_range() References: <20190521113448.20654-1-christian@brauner.io> Date: Tue, 21 May 2019 14:09:29 +0200 In-Reply-To: <20190521113448.20654-1-christian@brauner.io> (Christian Brauner's message of "Tue, 21 May 2019 13:34:47 +0200") Message-ID: <87tvdoau12.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 21 May 2019 12:09:49 +0000 (UTC) Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org * Christian Brauner: > +/** > + * __close_range() - Close all file descriptors in a given range. > + * > + * @fd: starting file descriptor to close > + * @max_fd: last file descriptor to close > + * > + * This closes a range of file descriptors. All file descriptors > + * from @fd up to and including @max_fd are closed. > + */ > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_fd) > +{ > + unsigned int cur_max; > + > + if (fd > max_fd) > + return -EINVAL; > + > + rcu_read_lock(); > + cur_max = files_fdtable(files)->max_fds; > + rcu_read_unlock(); > + > + /* cap to last valid index into fdtable */ > + if (max_fd >= cur_max) > + max_fd = cur_max - 1; > + > + while (fd <= max_fd) > + __close_fd(files, fd++); > + > + return 0; > +} This seems rather drastic. How long does this block in kernel mode? Maybe it's okay as long as the maximum possible value for cur_max stays around 4 million or so. Solaris has an fdwalk function: So a different way to implement this would expose a nextfd system call to userspace, so that we can use that to implement both fdwalk and closefrom. But maybe fdwalk is just too obscure, given the existence of /proc. I'll happily implement closefrom on top of close_range in glibc (plus fallback for older kernels based on /proc—with an abort in case that doesn't work because the RLIMIT_NOFILE hack is unreliable unfortunately). Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 21 May 2019 14:09:29 +0200 Subject: [PATCH 1/2] open: add close_range() In-Reply-To: <20190521113448.20654-1-christian@brauner.io> (Christian Brauner's message of "Tue, 21 May 2019 13:34:47 +0200") References: <20190521113448.20654-1-christian@brauner.io> Message-ID: <87tvdoau12.fsf@oldenburg2.str.redhat.com> * Christian Brauner: > +/** > + * __close_range() - Close all file descriptors in a given range. > + * > + * @fd: starting file descriptor to close > + * @max_fd: last file descriptor to close > + * > + * This closes a range of file descriptors. All file descriptors > + * from @fd up to and including @max_fd are closed. > + */ > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_fd) > +{ > + unsigned int cur_max; > + > + if (fd > max_fd) > + return -EINVAL; > + > + rcu_read_lock(); > + cur_max = files_fdtable(files)->max_fds; > + rcu_read_unlock(); > + > + /* cap to last valid index into fdtable */ > + if (max_fd >= cur_max) > + max_fd = cur_max - 1; > + > + while (fd <= max_fd) > + __close_fd(files, fd++); > + > + return 0; > +} This seems rather drastic. How long does this block in kernel mode? Maybe it's okay as long as the maximum possible value for cur_max stays around 4 million or so. Solaris has an fdwalk function: So a different way to implement this would expose a nextfd system call to userspace, so that we can use that to implement both fdwalk and closefrom. But maybe fdwalk is just too obscure, given the existence of /proc. I'll happily implement closefrom on top of close_range in glibc (plus fallback for older kernels based on /proc—with an abort in case that doesn't work because the RLIMIT_NOFILE hack is unreliable unfortunately). Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 From: fweimer@redhat.com (Florian Weimer) Date: Tue, 21 May 2019 14:09:29 +0200 Subject: [PATCH 1/2] open: add close_range() In-Reply-To: <20190521113448.20654-1-christian@brauner.io> (Christian Brauner's message of "Tue, 21 May 2019 13:34:47 +0200") References: <20190521113448.20654-1-christian@brauner.io> Message-ID: <87tvdoau12.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190521120929.Bj2L8Wyk2Y0NOLqaywPo0PIXuiohyDjPrxA-BSCq2Io@z> * Christian Brauner: > +/** > + * __close_range() - Close all file descriptors in a given range. > + * > + * @fd: starting file descriptor to close > + * @max_fd: last file descriptor to close > + * > + * This closes a range of file descriptors. All file descriptors > + * from @fd up to and including @max_fd are closed. > + */ > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_fd) > +{ > + unsigned int cur_max; > + > + if (fd > max_fd) > + return -EINVAL; > + > + rcu_read_lock(); > + cur_max = files_fdtable(files)->max_fds; > + rcu_read_unlock(); > + > + /* cap to last valid index into fdtable */ > + if (max_fd >= cur_max) > + max_fd = cur_max - 1; > + > + while (fd <= max_fd) > + __close_fd(files, fd++); > + > + return 0; > +} This seems rather drastic. How long does this block in kernel mode? Maybe it's okay as long as the maximum possible value for cur_max stays around 4 million or so. Solaris has an fdwalk function: So a different way to implement this would expose a nextfd system call to userspace, so that we can use that to implement both fdwalk and closefrom. But maybe fdwalk is just too obscure, given the existence of /proc. I'll happily implement closefrom on top of close_range in glibc (plus fallback for older kernels based on /proc—with an abort in case that doesn't work because the RLIMIT_NOFILE hack is unreliable unfortunately). Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5AB4DC04AAF for ; Tue, 21 May 2019 12:18:52 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A9F3A21773 for ; Tue, 21 May 2019 12:18:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9F3A21773 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 457ZYj1hpczDqKJ for ; Tue, 21 May 2019 22:18:49 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=redhat.com (client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=fweimer@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 457ZWB2D2DzDqKJ for ; Tue, 21 May 2019 22:16:38 +1000 (AEST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CAE443179162; Tue, 21 May 2019 12:09:38 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-219.str.redhat.com [10.33.192.219]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8854750A63; Tue, 21 May 2019 12:09:30 +0000 (UTC) From: Florian Weimer To: Christian Brauner Subject: Re: [PATCH 1/2] open: add close_range() References: <20190521113448.20654-1-christian@brauner.io> Date: Tue, 21 May 2019 14:09:29 +0200 In-Reply-To: <20190521113448.20654-1-christian@brauner.io> (Christian Brauner's message of "Tue, 21 May 2019 13:34:47 +0200") Message-ID: <87tvdoau12.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 21 May 2019 12:09:49 +0000 (UTC) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, dhowells@redhat.com, linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org, shuah@kernel.org, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, miklos@szeredi.hu, x86@kernel.org, torvalds@linux-foundation.org, linux-mips@vger.kernel.org, linux-xtensa@linux-xtensa.org, tkjos@android.com, arnd@arndb.de, jannh@google.com, linux-m68k@lists.linux-m68k.org, viro@zeniv.linux.org.uk, tglx@linutronix.de, ldv@altlinux.org, linux-arm-kernel@lists.infradead.org, linux-parisc@vger.kernel.org, linux-api@vger.kernel.org, oleg@redhat.com, linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" * Christian Brauner: > +/** > + * __close_range() - Close all file descriptors in a given range. > + * > + * @fd: starting file descriptor to close > + * @max_fd: last file descriptor to close > + * > + * This closes a range of file descriptors. All file descriptors > + * from @fd up to and including @max_fd are closed. > + */ > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_= fd) > +{ > + unsigned int cur_max; > + > + if (fd > max_fd) > + return -EINVAL; > + > + rcu_read_lock(); > + cur_max =3D files_fdtable(files)->max_fds; > + rcu_read_unlock(); > + > + /* cap to last valid index into fdtable */ > + if (max_fd >=3D cur_max) > + max_fd =3D cur_max - 1; > + > + while (fd <=3D max_fd) > + __close_fd(files, fd++); > + > + return 0; > +} This seems rather drastic. How long does this block in kernel mode? Maybe it's okay as long as the maximum possible value for cur_max stays around 4 million or so. Solaris has an fdwalk function: So a different way to implement this would expose a nextfd system call to userspace, so that we can use that to implement both fdwalk and closefrom. But maybe fdwalk is just too obscure, given the existence of /proc. I'll happily implement closefrom on top of close_range in glibc (plus fallback for older kernels based on /proc=E2=80=94with an abort in case that doesn't work because the RLIMIT_NOFILE hack is unreliable unfortunately). Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2F02C04AAF for ; Tue, 21 May 2019 12:10:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 99AF4217D9 for ; Tue, 21 May 2019 12:10:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pe5S9WrG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99AF4217D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:In-Reply-To: Date:References:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=X032sUyl/QbBzE521kyjgNj876013ESbPaWEKhewLQw=; b=pe5S9WrGN0qR3q +OxLygon9emYj0W//gwL+g7ce1QYtCLgeKconpVFpm44etUTOxPWD7NTrPQ4pgIa59loiNu+1ie6C OpdMzRyqtb7Ctq+Sk55pBk1YUA3JN16k9FGDnE9BvqeknYL5ANouodurVnIqoKD6r4kBJfDIlNbO4 KTi6O0NDeodRszqhwNTWJJVFs188i83vl9hEBmHFcZW+qaZkV+t2Rp7AnuH+6+8YWU6OWovklniJQ c67CP+rl58Fo3edAS8EoGt6FHfjoxsXeTt7j12naAbHSNAbwtoxoOB8hK3nKyqjVrCi+31JpvJ3p0 y8zvzk+lLI5CWzbpxF/w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hT3ak-00073Z-0U; Tue, 21 May 2019 12:10:02 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hT3ag-00072S-Tx for linux-arm-kernel@lists.infradead.org; Tue, 21 May 2019 12:10:00 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CAE443179162; Tue, 21 May 2019 12:09:38 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-219.str.redhat.com [10.33.192.219]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8854750A63; Tue, 21 May 2019 12:09:30 +0000 (UTC) From: Florian Weimer To: Christian Brauner Subject: Re: [PATCH 1/2] open: add close_range() References: <20190521113448.20654-1-christian@brauner.io> Date: Tue, 21 May 2019 14:09:29 +0200 In-Reply-To: <20190521113448.20654-1-christian@brauner.io> (Christian Brauner's message of "Tue, 21 May 2019 13:34:47 +0200") Message-ID: <87tvdoau12.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 21 May 2019 12:09:49 +0000 (UTC) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190521_050958_985678_FD195D19 X-CRM114-Status: GOOD ( 15.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, dhowells@redhat.com, linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org, shuah@kernel.org, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, miklos@szeredi.hu, x86@kernel.org, torvalds@linux-foundation.org, linux-mips@vger.kernel.org, linux-xtensa@linux-xtensa.org, tkjos@android.com, arnd@arndb.de, jannh@google.com, linux-m68k@lists.linux-m68k.org, viro@zeniv.linux.org.uk, tglx@linutronix.de, ldv@altlinux.org, linux-arm-kernel@lists.infradead.org, linux-parisc@vger.kernel.org, linux-api@vger.kernel.org, oleg@redhat.com, linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org KiBDaHJpc3RpYW4gQnJhdW5lcjoKCj4gKy8qKgo+ICsgKiBfX2Nsb3NlX3JhbmdlKCkgLSBDbG9z ZSBhbGwgZmlsZSBkZXNjcmlwdG9ycyBpbiBhIGdpdmVuIHJhbmdlLgo+ICsgKgo+ICsgKiBAZmQ6 ICAgICBzdGFydGluZyBmaWxlIGRlc2NyaXB0b3IgdG8gY2xvc2UKPiArICogQG1heF9mZDogbGFz dCBmaWxlIGRlc2NyaXB0b3IgdG8gY2xvc2UKPiArICoKPiArICogVGhpcyBjbG9zZXMgYSByYW5n ZSBvZiBmaWxlIGRlc2NyaXB0b3JzLiBBbGwgZmlsZSBkZXNjcmlwdG9ycwo+ICsgKiBmcm9tIEBm ZCB1cCB0byBhbmQgaW5jbHVkaW5nIEBtYXhfZmQgYXJlIGNsb3NlZC4KPiArICovCj4gK2ludCBf X2Nsb3NlX3JhbmdlKHN0cnVjdCBmaWxlc19zdHJ1Y3QgKmZpbGVzLCB1bnNpZ25lZCBmZCwgdW5z aWduZWQgbWF4X2ZkKQo+ICt7Cj4gKwl1bnNpZ25lZCBpbnQgY3VyX21heDsKPiArCj4gKwlpZiAo ZmQgPiBtYXhfZmQpCj4gKwkJcmV0dXJuIC1FSU5WQUw7Cj4gKwo+ICsJcmN1X3JlYWRfbG9jaygp Owo+ICsJY3VyX21heCA9IGZpbGVzX2ZkdGFibGUoZmlsZXMpLT5tYXhfZmRzOwo+ICsJcmN1X3Jl YWRfdW5sb2NrKCk7Cj4gKwo+ICsJLyogY2FwIHRvIGxhc3QgdmFsaWQgaW5kZXggaW50byBmZHRh YmxlICovCj4gKwlpZiAobWF4X2ZkID49IGN1cl9tYXgpCj4gKwkJbWF4X2ZkID0gY3VyX21heCAt IDE7Cj4gKwo+ICsJd2hpbGUgKGZkIDw9IG1heF9mZCkKPiArCQlfX2Nsb3NlX2ZkKGZpbGVzLCBm ZCsrKTsKPiArCj4gKwlyZXR1cm4gMDsKPiArfQoKVGhpcyBzZWVtcyByYXRoZXIgZHJhc3RpYy4g IEhvdyBsb25nIGRvZXMgdGhpcyBibG9jayBpbiBrZXJuZWwgbW9kZT8KTWF5YmUgaXQncyBva2F5 IGFzIGxvbmcgYXMgdGhlIG1heGltdW0gcG9zc2libGUgdmFsdWUgZm9yIGN1cl9tYXggc3RheXMK YXJvdW5kIDQgbWlsbGlvbiBvciBzby4KClNvbGFyaXMgaGFzIGFuIGZkd2FsayBmdW5jdGlvbjoK CiAgPGh0dHBzOi8vZG9jcy5vcmFjbGUuY29tL2NkL0U4ODM1M18wMS9odG1sL0UzNzg0My9jbG9z ZWZyb20tM2MuaHRtbD4KClNvIGEgZGlmZmVyZW50IHdheSB0byBpbXBsZW1lbnQgdGhpcyB3b3Vs ZCBleHBvc2UgYSBuZXh0ZmQgc3lzdGVtIGNhbGwKdG8gdXNlcnNwYWNlLCBzbyB0aGF0IHdlIGNh biB1c2UgdGhhdCB0byBpbXBsZW1lbnQgYm90aCBmZHdhbGsgYW5kCmNsb3NlZnJvbS4gIEJ1dCBt YXliZSBmZHdhbGsgaXMganVzdCB0b28gb2JzY3VyZSwgZ2l2ZW4gdGhlIGV4aXN0ZW5jZSBvZgov cHJvYy4KCkknbGwgaGFwcGlseSBpbXBsZW1lbnQgY2xvc2Vmcm9tIG9uIHRvcCBvZiBjbG9zZV9y YW5nZSBpbiBnbGliYyAocGx1cwpmYWxsYmFjayBmb3Igb2xkZXIga2VybmVscyBiYXNlZCBvbiAv cHJvY+KAlHdpdGggYW4gYWJvcnQgaW4gY2FzZSB0aGF0CmRvZXNuJ3Qgd29yayBiZWNhdXNlIHRo ZSBSTElNSVRfTk9GSUxFIGhhY2sgaXMgdW5yZWxpYWJsZQp1bmZvcnR1bmF0ZWx5KS4KClRoYW5r cywKRmxvcmlhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5p bmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8v bGludXgtYXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: [PATCH 1/2] open: add close_range() Date: Tue, 21 May 2019 14:09:29 +0200 Message-ID: <87tvdoau12.fsf@oldenburg2.str.redhat.com> References: <20190521113448.20654-1-christian@brauner.io> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20190521113448.20654-1-christian@brauner.io> (Christian Brauner's message of "Tue, 21 May 2019 13:34:47 +0200") Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="windows-1252" To: Christian Brauner Cc: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, jannh@google.com, oleg@redhat.com, tglx@linutronix.de, torvalds@linux-foundation.org, arnd@arndb.de, shuah@kernel.org, dhowells@redhat.com, tkjos@android.com, ldv@altlinux.org, miklos@szeredi.hu, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org, x86@kernel.org * Christian Brauner: > +/** > + * __close_range() - Close all file descriptors in a given range. > + * > + * @fd: starting file descriptor to close > + * @max_fd: last file descriptor to close > + * > + * This closes a range of file descriptors. All file descriptors > + * from @fd up to and including @max_fd are closed. > + */ > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_= fd) > +{ > + unsigned int cur_max; > + > + if (fd > max_fd) > + return -EINVAL; > + > + rcu_read_lock(); > + cur_max =3D files_fdtable(files)->max_fds; > + rcu_read_unlock(); > + > + /* cap to last valid index into fdtable */ > + if (max_fd >=3D cur_max) > + max_fd =3D cur_max - 1; > + > + while (fd <=3D max_fd) > + __close_fd(files, fd++); > + > + return 0; > +} This seems rather drastic. How long does this block in kernel mode? Maybe it's okay as long as the maximum possible value for cur_max stays around 4 million or so. Solaris has an fdwalk function: So a different way to implement this would expose a nextfd system call to userspace, so that we can use that to implement both fdwalk and closefrom. But maybe fdwalk is just too obscure, given the existence of /proc. I'll happily implement closefrom on top of close_range in glibc (plus fallback for older kernels based on /proc=E2=80=94with an abort in case that doesn't work because the RLIMIT_NOFILE hack is unreliable unfortunately). Thanks, Florian