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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 A9161C16A69 for ; Wed, 22 May 2019 08:12:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7C6DC217D4 for ; Wed, 22 May 2019 08:12:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=brauner.io header.i=@brauner.io header.b="FQpPrYca" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728542AbfEVIM2 (ORCPT ); Wed, 22 May 2019 04:12:28 -0400 Received: from mail-lf1-f68.google.com ([209.85.167.68]:36885 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728608AbfEVIMY (ORCPT ); Wed, 22 May 2019 04:12:24 -0400 Received: by mail-lf1-f68.google.com with SMTP id m15so360421lfh.4 for ; Wed, 22 May 2019 01:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NinRxNHyDYbCj8IbjH00ChDPuWJUmzxEB5UBBCZfvuk=; b=FQpPrYcaQxCAFGTYiUsPu0qLO+TyOcW7gshxdKkzEdBEoeF7zfGLnQVrcgcr4gKCeX LJ4YXrL36Z8UOIkkUcBOLv8jo3+1wy2Zrr1Gv+mEl7u90rBwnDVcVlXzHgwabis+F7I/ dlJlteIhWCGDFh11b+aiyTTGML6DsZQmYr7FjOpjo+237NiSY/93FSEYu5SmcuC+kMHi w+QbDlfq/QnsLdgPfA6Jf+xdMdism6B4eELfwRuNPZvO4gmtKOqxk/k31Xt7g6ek0i6A 6O4E/le0sudnktBxl+9AFEIeQt8N5n9ZAVs90K2h9eXQLV3Rz/8qfSLtahw9cvbBcJ3h 1JTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NinRxNHyDYbCj8IbjH00ChDPuWJUmzxEB5UBBCZfvuk=; b=oLyJ5LojtS25W591aR+yWuec184dHfXQHuKlZo7aU9VDDzUYghnfpuGG4m4UDCWTPq f48KJPy7V2EBZZLZmFJS/RlUNj0sEvkoUQUvPyybc52E5RhuyCxBmeTQPOswUeezk3de PtlwWcS2kr6Lz91aoTUKf0TLzcGgcS01UB9dK8FRordcYhPnqyRnuAvgieFFd5Thmvcx 6R8mHsPtLHzbePSecgJhGJ1eg46Xwluaepa/3jQcLPROtxhD2RUmTBN4LfiljmsnNSyE IyfRzB8OnsKW4kscTNY2FKyV/lJaTJUZ+AH8DI2GJ5KIYer6aIPpxLAP+A3+4KHob2Fz Driw== X-Gm-Message-State: APjAAAWrdhJr8d8j+oJ1GQ+ttu9vQ2B7hZWIaobtRO3t4Acy5A6XZOc1 NV+sUOKYofkO+kLLZ+3qIe7ZTLQh3TTYcpqE1Oqf9Q== X-Google-Smtp-Source: APXvYqx7pLLI28SrC6KCXMaRxdNQfwff8OtpKLPW6FHDJY0UodmrushWU4y7kAd+10dOgbbxHnK3LHfXY1UCm8GAhHE= X-Received: by 2002:a05:6512:1c1:: with SMTP id f1mr4469627lfp.125.1558512742198; Wed, 22 May 2019 01:12:22 -0700 (PDT) MIME-Version: 1.0 References: <20190521150006.GJ17978@ZenIV.linux.org.uk> <20190521113448.20654-1-christian@brauner.io> <28114.1558456227@warthog.procyon.org.uk> <20190521164141.rbehqnghiej3gfua@brauner.io> In-Reply-To: From: Christian Brauner Date: Wed, 22 May 2019 10:12:11 +0200 Message-ID: Subject: Re: [PATCH 1/2] open: add close_range() To: Linus Torvalds Cc: David Howells , Al Viro , Linux List Kernel Mailing , linux-fsdevel , Linux API , Jann Horn , Florian Weimer , Oleg Nesterov , Thomas Gleixner , Arnd Bergmann , Shuah Khan , Todd Kjos , "Dmitry V. Levin" , Miklos Szeredi , alpha , Linux ARM , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, Parisc List , linuxppc-dev , linux-s390 , Linux-sh list , sparclinux , linux-xtensa@linux-xtensa.org, linux-arch , "open list:KERNEL SELFTEST FRAMEWORK" , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Tue, May 21, 2019 at 10:23 PM Linus Torvalds wrote: > > On Tue, May 21, 2019 at 9:41 AM Christian Brauner wrote: > > > > Yeah, you mentioned this before. I do like being able to specify an > > upper bound to have the ability to place fds strategically after said > > upper bound. > > I suspect that's the case. > > And if somebody really wants to just close everything and uses a large > upper bound, we can - if we really want to - just compare the upper > bound to the file table size, and do an optimized case for that. We do > that upper bound comparison anyway to limit the size of the walk, so > *if* it's a big deal, that case could then do the whole "shrink > fdtable" case too. Makes sense. > > But I don't believe it's worth optimizing for unless somebody really > has a load where that is shown to be a big deal. Just do the silly > and simple loop, and add a cond_resched() in the loop, like > close_files() does for the "we have a _lot_ of files open" case. Ok. I will resend a v1 later with the cond_resched() logic you and Al suggested added. Thanks! Christian