Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1310771ybz; Wed, 22 Apr 2020 18:15:01 -0700 (PDT) X-Google-Smtp-Source: APiQypJe4mGnru0+4s2B4O6CatYD6/bOQsNgafWVE4GV5niYc6Mh8zXoHo2cs2nol/H8wu3TmbYw X-Received: by 2002:aa7:d518:: with SMTP id y24mr943969edq.222.1587604501107; Wed, 22 Apr 2020 18:15:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587604501; cv=none; d=google.com; s=arc-20160816; b=MCD+oH93c5BboLgmtCrGYpCSVl9c/deoJ8SrOm+RNwNMru7p2/No1lQ0RuigVd6bsF C+hdsMkyLNvamdmwxErnIcrs6gL8+u4sERX8n1xW95drQhHYSylJ/Emajuas2EwZUmuX W1DG+xkGQSmhzpDMxfFVe/y5IKEBzyTP1qkKiufYThcFG8XQiLQMJcICG3+YM04D2j3J /REgL2L2KX4ysSeiwn5n/oRrsTO02/+Kd+SJvmvhlKF6cxWqIIAQPmRSA+1qFwPMPFHY LjhKIJpoyNdeTwC9Z10rHj5mdNjIzkHoSKqaqR+T6V7Zc0oe7WHfV82Ehg8/2ZAg8Mxf 9w8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=YEDtIeP2tn6AZ1PSy5jjvGp7v2slQz247ZK+7RrLF9w=; b=Aj+cJ7STOlr5pjsA2enpQJSbMQIAj2YxVp0mEkd5lxju/T/kyuHMGX0ZtDvV9baPa4 +RMamSi9iE/AiZbiUGnv4yAozOl41490XkMblkMjNE0PMLGJReLGJv7ZmnTYyfBKNmj4 NyVSBolBT6Gl1+eL2mwCtjx6ReSLyk/ydxHZ8Brk2cqfZv8X3/oAM/6uS8WiWwNt23o+ SE3uaq/HgsLSdxKIdWTDhS5kxzt2SC4BjtVCkBGhI4W0rbIUbP3PkYe0enYpqk42gNSD TwojoxdiDWK6VX5pyGWYDxM3Bp9ECjMn3o9+VGpTiVLLnREJH3RZZwtYQx6PcQCPLPE8 tRTw== 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 q25si481761eja.500.2020.04.22.18.14.38; Wed, 22 Apr 2020 18:15:01 -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 S1726381AbgDWBM4 (ORCPT + 99 others); Wed, 22 Apr 2020 21:12:56 -0400 Received: from vmicros1.altlinux.org ([194.107.17.57]:59578 "EHLO vmicros1.altlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725846AbgDWBM4 (ORCPT ); Wed, 22 Apr 2020 21:12:56 -0400 Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 8FE1972CCEF; Thu, 23 Apr 2020 04:12:53 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 803DA7CF575; Thu, 23 Apr 2020 04:12:53 +0300 (MSK) Date: Thu, 23 Apr 2020 04:12:53 +0300 From: "Dmitry V. Levin" To: Josh Triplett Cc: io-uring@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, mtk.manpages@gmail.com, Alexander Viro , Arnd Bergmann , Jens Axboe , Aleksa Sarai , linux-man@vger.kernel.org, Linux API Subject: Re: [PATCH v5 1/3] fs: Support setting a minimum fd for "lowest available fd" allocation Message-ID: <20200423011253.GA18957@altlinux.org> References: <05c9a6725490c5a5c4ee71be73326c2fedf35ba5.1587531463.git.josh@joshtriplett.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05c9a6725490c5a5c4ee71be73326c2fedf35ba5.1587531463.git.josh@joshtriplett.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 21, 2020 at 10:19:49PM -0700, Josh Triplett wrote: > Some applications want to prevent the usual "lowest available fd" > allocation from allocating certain file descriptors. For instance, they > may want to prevent allocation of a closed fd 0, 1, or 2 other than via > dup2/dup3, or reserve some low file descriptors for other purposes. > > Add a prctl to increase the minimum fd and return the previous minimum. > > System calls that allocate a specific file descriptor, such as > dup2/dup3, ignore this minimum. > > exec resets the minimum fd, to prevent one program from interfering with > another program's expectations about fd allocation. Please make this aspect properly documented in "Effect on process attributes" section of execve(2) manual page. [...] > +unsigned int increase_min_fd(unsigned int num) > +{ > + struct files_struct *files = current->files; > + unsigned int old_min_fd; > + > + spin_lock(&files->file_lock); > + old_min_fd = files->min_fd; > + files->min_fd += num; > + spin_unlock(&files->file_lock); > + return old_min_fd; > +} If it's "increase", there should be an overflow check. Otherwise it's "assign" rather than "increase". -- ldv