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=DKIMWL_WL_HIGH,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 B290CC072B5 for ; Tue, 21 May 2019 20:31:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 841E32173E for ; Tue, 21 May 2019 20:31:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558470685; bh=+anNa+EcDyQqpCdZyW1zAWtrJQKMwJ04olCg4LcelJQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=tm3F8TBIBuuN6yAK0evGz8VDNIDT8OHr17pvL0T9i0E7t6wAD26F5UqL8dGLRL9w/ WB1PYXcWQXAkiEM32FZuWxRZCWqX0zpjsJipAWWTLLyQ/a2Q2XkzuackwPKxH/hyAk slpFn2XBw6/2e+HRS3s4OzfP6SwKyi48U2yRxU6k= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727174AbfEUUbZ (ORCPT ); Tue, 21 May 2019 16:31:25 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:41832 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726766AbfEUUbY (ORCPT ); Tue, 21 May 2019 16:31:24 -0400 Received: by mail-lj1-f196.google.com with SMTP id q16so6097328ljj.8 for ; Tue, 21 May 2019 13:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mwA8SKkNo0NB1BSSFbQlGkhBkIi6dkzdh19hX1ggqqc=; b=E9cuWHFCD4Bgx1lOv97Ctr9bLKO3EjHQDpiZyM5FZUFuOxpsSHENK8V3oPkAEWY2CT 4OwJ0l1afyS0KlYgZEStFftLyE7H7JbMd/BnYgfS8lVdq73pcYKuqkBJcrl7o7GLJZCx 7466NcnIhfaDTvK1H+iwihEveSzhyKGC/2Zgk= 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=mwA8SKkNo0NB1BSSFbQlGkhBkIi6dkzdh19hX1ggqqc=; b=N1W2s06tLlQ4ItZegOG4vMNmxvbNT+1apFlvtoErfs5s8td+Q5852+RgKNxXLVzzjA mkI4V3ijgwkSgqpEIb+k2WcSbAQ0aaum+A/nLuZLYKmdWKSHAjDyzGFUZkhCSZOorP55 Xcg6Z9fvDu3vI99a+/P/BLDoJrhOknsnUUgxkZqUU4hZNxujM0pDWhhSmnhfEXU2A2eY 5ZgZ/J/Sf+UvbK3L9FM0PxEbtU9bg26Ms62+x8EgRGZnogy/lfwhh48nzvYwHPVBm7iw OOVoXFYb2flyHkMD7YHjs8FoR8H08Yn5l2PT8P/0gHDZfjs5qPIyZUQygQKVdcpAYYfV 2KeA== X-Gm-Message-State: APjAAAWcNMjU2zgr4iIkHcby/JX8zgZVip/yGsZJl6X3ARIUKmP11sbd Kx7SX7sE1KHepn7sM9u1m8/bvnnCBgI= X-Google-Smtp-Source: APXvYqyIm6t0TSKSx5DiCqkgGM0IsqkNUd/tLm7akTMr7C2XZEQ4gJW00uDAhEpwLsjSP8q9yTu9tg== X-Received: by 2002:a2e:5dcb:: with SMTP id v72mr43443780lje.54.1558470682568; Tue, 21 May 2019 13:31:22 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id m25sm4733745ljj.92.2019.05.21.13.31.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 May 2019 13:31:22 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id m15so7785620ljg.13 for ; Tue, 21 May 2019 13:31:22 -0700 (PDT) X-Received: by 2002:a2e:2f03:: with SMTP id v3mr4725518ljv.6.1558470208997; Tue, 21 May 2019 13:23:28 -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: <20190521164141.rbehqnghiej3gfua@brauner.io> From: Linus Torvalds Date: Tue, 21 May 2019 13:23:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] open: add close_range() To: Christian Brauner 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 , tkjos@android.com, "Dmitry V. Levin" , Miklos Szeredi , alpha , Linux ARM , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390 , Linux-sh list , sparclinux@vger.kernel.org, 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-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org 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. 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. Linus