Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp65018ybg; Tue, 2 Jun 2020 16:35:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzIR7W9OPaqt06pYyax2bxnXrdlNsI+wvpM9bUVARq8bX3/lAYoipYd/jRTYWdKHQm/gHNK X-Received: by 2002:a17:906:f10a:: with SMTP id gv10mr11675226ejb.309.1591140925279; Tue, 02 Jun 2020 16:35:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591140925; cv=none; d=google.com; s=arc-20160816; b=HHTjJ4gCmo1PkivL++3PE2egJ31kY8AaQrXuLh+zTJ4rDKFlLRv4Y80Z7vIUbhTrgc hs/nm2XYT8yVyznm/lnVridwmBszXbGSW9uz+dn+znHkWLuLSTI8Q1CXFtLjB9U0PKcx jA2oVSPLl2gxaXzr7IsflIRJEoJVK0mYtjp71wESTxgs2aXr/oS4L/e42Imfz+5pYvUX eLn3mrlENO9aQFqIN1cWF6YnqhYBzZ6Ka/nEjLV+EQpsGXsR3NiMRy7Sc6hXx+X4qCYI LHfSCtSywi8zZQ0Crk1wORi9TkFHO897nH7lP2IMHcXgl6R5JKQ+MJnLxqdMdYrqFT0c x/Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to:date :references:subject:cc:to:from; bh=OGkonZMx0TIuoUkPrcLkAjZ4nsIQ1jqqTIHTh8hUEYU=; b=YFNKXZUj74oxz0U4zL+BQ66yOgA+XeMRW1bUNn2REhXx8WinMba8As9pcEW3E9JUjT x0smNuCH3m23ucdkmPpREFg8JeXEc1bh5uJcIRpfhmh/tui7MRdOAOYo5th6hdm3vIbz emnijKp+cOgZExKsAI63Z9km6pBJ7xYZuZq9sZop3ZYtBKU5qsOQ0/NLpmyheqSjF/tC zMWqkgk3UbDUeniMO9B3MDbtLCS35d/8cLljx8QIsuVk6hFSHEfHeOLH78yTISWOgePP m+po/eJ/V9039yZh/1AGu/7lSPZjcYZXq74WbBNG4s3uMMGj7dSzGmY813v1ATlm2Mbv z9gw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e1si198661ejd.353.2020.06.02.16.35.02; Tue, 02 Jun 2020 16:35:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728344AbgFBXbC (ORCPT + 99 others); Tue, 2 Jun 2020 19:31:02 -0400 Received: from albireo.enyo.de ([37.24.231.21]:55286 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726809AbgFBXbC (ORCPT ); Tue, 2 Jun 2020 19:31:02 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jgGN0-0005GC-1l; Tue, 02 Jun 2020 23:30:58 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jgGMz-0001Se-VB; Wed, 03 Jun 2020 01:30:57 +0200 From: Florian Weimer To: Christian Brauner Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, Kyle Evans , Victor Stinner , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, fweimer@redhat.com, jannh@google.com, oleg@redhat.com, arnd@arndb.de, shuah@kernel.org, dhowells@redhat.com, ldv@altlinux.org Subject: Re: [PATCH v5 1/3] open: add close_range() References: <20200602204219.186620-1-christian.brauner@ubuntu.com> <20200602204219.186620-2-christian.brauner@ubuntu.com> Date: Wed, 03 Jun 2020 01:30:57 +0200 In-Reply-To: <20200602204219.186620-2-christian.brauner@ubuntu.com> (Christian Brauner's message of "Tue, 2 Jun 2020 22:42:17 +0200") Message-ID: <87d06hdozy.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Christian Brauner: > The performance is striking. For good measure, comparing the following > simple close_all_fds() userspace implementation that is essentially just > glibc's version in [6]: > > static int close_all_fds(void) > { > int dir_fd; > DIR *dir; > struct dirent *direntp; > > dir = opendir("/proc/self/fd"); > if (!dir) > return -1; > dir_fd = dirfd(dir); > while ((direntp = readdir(dir))) { > int fd; > if (strcmp(direntp->d_name, ".") == 0) > continue; > if (strcmp(direntp->d_name, "..") == 0) > continue; > fd = atoi(direntp->d_name); > if (fd == dir_fd || fd == 0 || fd == 1 || fd == 2) > continue; > close(fd); > } > closedir(dir); > return 0; > } > > [6]: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/grantpt.c;h=2030e07fa6e652aac32c775b8c6e005844c3c4eb;hb=HEAD#l17 > Note that this is an internal implementation that is not exported. > Currently, libc seems to not provide an exported version of this > because of missing kernel support to do this. Just to be clear, this code is not compiled into glibc anymore in typical configurations. I have posted a patch to turn grantpt into a no-op: I'm not entirely convinced that it's safe to keep iterating over /proc/self/fd while also closing descriptors. Ideally, I think an application should call getdents64, process the file names for descriptors in the buffer, and if any have been closed, seek to zero before the next getdents64 call. Maybe procfs is different, but with other file systems, unlinking files can trigger directory reordering, and then you get strange effects. The d_ino behavior for /proc/self/fd is a bit strange as well (it's not consistently descriptor plus 3).