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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 DDA7CC4338F for ; Sun, 15 Aug 2021 03:42:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B1DFA60FC3 for ; Sun, 15 Aug 2021 03:42:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235079AbhHODmw (ORCPT ); Sat, 14 Aug 2021 23:42:52 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:49187 "EHLO wout5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233848AbhHODmv (ORCPT ); Sat, 14 Aug 2021 23:42:51 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8415C320046E; Sat, 14 Aug 2021 23:42:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 14 Aug 2021 23:42:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= joshtriplett.org; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=fm1; bh=fsc QQUiCrfJu2B/FroGWlGgv8rX7vCHNTDmiXT/+3qg=; b=HPv8LWAWIBoYE5/gick zpULfhUf6sx7a1h7vcfHUgp1AgSThKYiQzOu30lYEEcOzBfdHr0fnSSJO1eI+ShK IOY2S8GA5uWCjzzN6Fm3TXcIVOaY/XsKXk0MpxWbJQr+vKCgbnop28IU0dye3V1Q BdB+TfzzOCI8MgQv/P/zA5OLC/N0isk8eWObyLRW23Wzl1067q1efxRMLYQ3fsKi VLrzYLOyDvghyfn/ql0Q5IsUbsjdoUUzSLu1rOWeFCAcNQ/QAQEVa1gtrMvcouWK aOLCXSr/ktBmntQexAZ/ABZT839MvkaAL5aodmmVrXaKKhixhBC4PYBfc8b99ob1 eJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=fscQQU iCrfJu2B/FroGWlGgv8rX7vCHNTDmiXT/+3qg=; b=d+z6GWPiqYOBUwIpYT1EfA RH4GJXsLkVCjT5UzWtYBuB5mjFBddQG51Emp7tRed027+Co8+84j3eOfnByCrh4k opaagkyrbb99WWcfmRb9xHXIkp9mV08voXfJsXDF6uT3p5u6irKQ7QK8x1rXSxqP Eihu0qU5Ja/NG09ZeFMxGosz781ChYQwSQ+Mug9xajxbnRCb9v+ohjujj1prlVc2 pAotL1nY7A6DfI4p/oal8QBGV4XsSHxiZWFmUgZCkg62yxBcTQeZeUVZAeCBClQZ sFV/DBrpv31EptWIDhXr51Fb7HffAD1mxR2sEGFU33cJOIJMfwU8OevTE2fEYYig == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrkeekgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomheplfhoshhhucfv rhhiphhlvghtthcuoehjohhshhesjhhoshhhthhrihhplhgvthhtrdhorhhgqeenucggtf frrghtthgvrhhnpeegtdfgfeeghfevgeelgfefieegudeuheekkedtueeutefgheffveeg ueeiteehteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehjohhshhesjhhoshhhthhrihhplhgvthhtrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 14 Aug 2021 23:42:18 -0400 (EDT) Date: Sat, 14 Aug 2021 20:42:17 -0700 From: Josh Triplett To: Jens Axboe Cc: Pavel Begunkov , io-uring@vger.kernel.org, "David S . Miller" , Jakub Kicinski , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Stefan Metzmacher Subject: Re: [PATCH v2 0/4] open/accept directly into io_uring fixed file table Message-ID: References: <5cf40313-d151-9d10-3ebd-967eb2f53b1f@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5cf40313-d151-9d10-3ebd-967eb2f53b1f@kernel.dk> Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Sat, Aug 14, 2021 at 05:03:44PM -0600, Jens Axboe wrote: > What's the plan in terms of limiting the amount of direct descriptors > (for lack of a better word)? That seems like an important aspect that > should get sorted out upfront. [...] > Maybe we have a way to size the direct table, which will consume entries > from the same pool that the regular file table does? That would then > work both ways, and could potentially just be done dynamically similarly > to how we expand the regular file table when we exceed its current size. I think we'll want a way to size the direct table regardless, so that it's pre-allocated and doesn't need to be resized when an index is used. Then, we could do one of two equally easy things, depending on what policy we want to set: - Deduct the full size of the fixed-file table from the allowed number of files the process can have open. So, if RLIMIT_NOFILE is 1048576, and you pre-allocate 1000000 entries in the fixed-file table, you can have no more than 48576 file descriptors open. Stricter, but potentially problematic: a program *might* expect that it can dup2(some_fd, nofile - 1) successfully. - Use RLIMIT_NOFILE as the maximum size of the fixed-file table. There's precedent for this: we already use RLIMIT_NOFILE as the maximum number of file descriptors you can have in flight over UNIX sockets. I personally would favor the latter; it seems simple and straightforward.