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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 7CC13C433F5 for ; Sun, 19 Sep 2021 04:23:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 479F9611C8 for ; Sun, 19 Sep 2021 04:23:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229873AbhISEZU (ORCPT ); Sun, 19 Sep 2021 00:25:20 -0400 Received: from shells.gnugeneration.com ([66.240.222.126]:35712 "EHLO shells.gnugeneration.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229558AbhISEZT (ORCPT ); Sun, 19 Sep 2021 00:25:19 -0400 X-Greylist: delayed 488 seconds by postgrey-1.27 at vger.kernel.org; Sun, 19 Sep 2021 00:25:19 EDT Received: by shells.gnugeneration.com (Postfix, from userid 1000) id CE0BC1A545A2; Sat, 18 Sep 2021 21:15:46 -0700 (PDT) Date: Sat, 18 Sep 2021 21:15:46 -0700 From: Vito Caputo To: Jens Axboe Cc: io-uring Subject: Re: [BUG? liburing] io_uring_register_files_update with liburing 2.0 on 5.13.17 Message-ID: <20210919041546.bbs5u45pyythmwvj@shells.gnugeneration.com> References: <7bfd2fdd-15ba-98e3-7acc-cecf2a42e157@kernel.dk> <36866fef-a38f-9d7d-0c85-b4c37a8279ce@kernel.dk> <3df95a9f-7a5a-14bd-13e4-cef8a3f58dbd@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3df95a9f-7a5a-14bd-13e4-cef8a3f58dbd@kernel.dk> Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Sat, Sep 18, 2021 at 05:40:51PM -0600, Jens Axboe wrote: > On 9/18/21 5:37 PM, Jens Axboe wrote: > >> and it failed with the same as before... > >> > >> io_uring_register(13, IORING_REGISTER_FILES, [-1, -1, -1, 3, 4, 5, 6, 7, 8, > >> 9, 10, 11, 12, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, > >> -1, -1, -1, -1, > >> -1, ...], 32768) = -1 EMFILE (Too many open files) > >> > >> if you want i can debug it for you tomorrow? (in london) > > > > Nah that's fine, I think it's just because you have other files opened > > too. We bump the cur limit _to_ 'nr', but that leaves no room for anyone > > else. Would be my guess. It works fine for the test case I ran here, but > > your case may be different. Does it work if you just make it: > > > > rlim.rlim_cur += nr; > > > > instead? > > Specifically, just something like the below incremental. If rlim_cur > _seems_ big enough, leave it alone. If not, add the amount we need to > cur. And don't do any error checking here, let's leave failure to the > kernel. > > diff --git a/src/register.c b/src/register.c > index bab42d0..7597ec1 100644 > --- a/src/register.c > +++ b/src/register.c > @@ -126,9 +126,7 @@ static int bump_rlimit_nofile(unsigned nr) > if (getrlimit(RLIMIT_NOFILE, &rlim) < 0) > return -errno; > if (rlim.rlim_cur < nr) { > - if (nr > rlim.rlim_max) > - return -EMFILE; > - rlim.rlim_cur = nr; > + rlim.rlim_cur += nr; > setrlimit(RLIMIT_NOFILE, &rlim); > } > > Perhaps it makes more sense to only incur the getrlimit() cost on the errno=EMFILE path? As in bump the ulimit and retry the operation on failure, but when things are OK don't do any of this. Regards, Vito Caputo