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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F29D9C61DA4 for ; Sat, 4 Feb 2023 13:16:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 293326B0072; Sat, 4 Feb 2023 08:16:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 243BC6B0073; Sat, 4 Feb 2023 08:16:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10BA26B0074; Sat, 4 Feb 2023 08:16:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F0C466B0072 for ; Sat, 4 Feb 2023 08:16:05 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C51DD1203D1 for ; Sat, 4 Feb 2023 13:16:05 +0000 (UTC) X-FDA: 80429657490.17.CE73E28 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 8718DA0011 for ; Sat, 4 Feb 2023 13:16:03 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=MFmGT5x5; spf=pass (imf25.hostedemail.com: domain of bcodding@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bcodding@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675516564; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4UloaC8p+3e6sJ8izpr2qKf2jUP+gRvxvgLL5VJAzCM=; b=uTLpa8Y1yBZ2AUP1F7EVhsRY0TcrEtE3yMnnxQcJEZgBOSoBcGZVuTDkat/Fw6Vfv+fmOa 56SRM39jRD7bSPEeH98gsBO+ogmCjptLS+XR/c74jGLcF2HSR7TPYVsd6eH3CcqeNwbKsz KMXmPReP+Azes/XI1UxacWW1fsUoSXo= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=MFmGT5x5; spf=pass (imf25.hostedemail.com: domain of bcodding@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bcodding@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675516564; a=rsa-sha256; cv=none; b=dthb5/EtK0T8aDNs2I2JbZ3ZgBWtVH3H+hqHDxWxmNRyRW6zm5HoWBv5olnZNg97E6tAAC y1/G7nJ+QuyKMjOAOIsJ7DyvvxNGPdDF1Aih/IujrobT7LvkpevICLNV5zCA59camYeMEe 53een1oSDqmOF7EwNki2zessHR8wavU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675516562; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4UloaC8p+3e6sJ8izpr2qKf2jUP+gRvxvgLL5VJAzCM=; b=MFmGT5x5HoZTf9FVVyP2I0dn+g0nzb/JHa94+8IiqkpzMEFUAn8HlFwcnBSsBmvbkUGSQT VGprX+AOwdfC3w2r0xov2uLWZBV7IeE9S1TExbjgX5pmBKRO2rfIuEz9/Zh6TQLzBlKijf xijdVwHMAVeMWTZn7RzlcVZDQZlecJg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-495-_4FVVWJTMZqYICkYfs1-iw-1; Sat, 04 Feb 2023 08:15:57 -0500 X-MC-Unique: _4FVVWJTMZqYICkYfs1-iw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 513D1802314; Sat, 4 Feb 2023 13:15:56 +0000 (UTC) Received: from [172.16.176.1] (unknown [10.22.50.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2F8C6C15BA0; Sat, 4 Feb 2023 13:15:54 +0000 (UTC) From: Benjamin Coddington To: Thorsten Leemhuis Cc: Trond Myklebust , Hugh Dickins , Charles Edward Lever , Linux NFS Mailing List , Anna Schumaker , Alexander Viro , Amir Goldstein , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Linux kernel regressions list Subject: Re: git regression failures with v6.2-rc NFS client Date: Sat, 04 Feb 2023 08:15:52 -0500 Message-ID: <15679CC0-6B56-4F6D-9857-21DCF1EFFF79@redhat.com> In-Reply-To: References: <9A4A5673-691D-47EC-BC44-C43BE7E50A48@oracle.com> <5FF4061F-108C-4555-A32D-DDBFA80EE4E7@redhat.com> <44CB1E86-60E0-4CF0-9FD4-BB7E446542B7@redhat.com> <1AAC6854-2591-4B21-952A-BC58180B4091@oracle.com> <41813D21-95C8-44E3-BB97-1E9C03CE7FE5@redhat.com> <79261B77-35D0-4E36-AA29-C7BF9FB734CC@oracle.com> <104B6879-5223-485F-B099-767F741EB15B@redhat.com> <966AEC32-A7C9-4B97-A4F7-098AF6EF0067@oracle.com> <545B5AB7-93A6-496E-924E-AE882BF57B72@hammerspace.com> <4dd32d-9ea3-4330-454a-36f1189d599@google.com> <0D7A0393-EE80-4785-9A83-44CF8269758B@hammerspace.com> <8B4F6A20-D7A4-4A22-914C-59F5EA79D252@hammerspace.com> MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Stat-Signature: xkgj5swy9piw5r5ogccmkor81fns96rz X-Rspam-User: X-Rspamd-Queue-Id: 8718DA0011 X-Rspamd-Server: rspam06 X-HE-Tag: 1675516563-361512 X-HE-Meta: U2FsdGVkX1+hpCiuKuVJPOYh3ojrsFu/ejFfVgWYKT3Cn3HFhKxbnCI6BTH9RFpVkCiotLvkiXRp7JBSvO9XnqcaaAvqeFD3T09Z6EXsaLyUAZVx9EkmuE9NC2oJjw765gcEBcmp8Q3ht8JlJe5c99/ADnyuzlG2Olgofjpy7krgZrLbiEdx7R8cR6Nx4c5ieauHBxPzvwwDGKACNGc6pPiuDzcXHExqVZTECXMVEO+KMEtvnes7UeFd7CU0vuhmG10qQh5ANOQCoZpbgUdCRHdgduFOCTypsosgFwjg0dwU77gUWGUrLhTLPEy03pbLpzJg5o0DOURqUuNXzMzP/IXo14F298/2zesf3AxcSTwFzp+vlYtvOsNMMpD1kUcn5U47ZpGY6JsHWNTbQ5M2M9+zNxKTYiGqF0Se8EFzuRHIEwmmRKL0wOeSMuITElwQryeRsDjY0IvIoeedXPPyPgyzmD73qJAYw32Tiuw8zr48zTkXYEdFxTWuxBFbqb4aC8mraW0EPvg6rJ2XAEDww1+fQVQMj0lfr0zmj9HEGHY0RL0hNWExu3CHaglAp04wCxBzaYl1aD9mKui60EEhyuP9e0yPyAPdoVWlrRw2i7J251R85ciSpJ3otFZYYLjPjjFIx246fzGiDV8GxFPRpnW8xpDpZj0mDIJc0zUf6F8q+JIxOyLlQbHAi2JyDfGFrbnGuEA82jfkap79VJa3rt5v2PsDjfNSEzi4smiJb9Xsudspj8HwRa/VALsXxsg5NVhl14fdfOveaqf9jrkfWH4/i/0NpKnBZ06FxZAguyqm/MvecjTagaPecDGKF9e0HQFXi2sM0LuXNmSKcOstLtIIU8WMEuZ2ohnvYYMssZQHxEj+8kF6E36wxARAcBudnZ4sLi5js7XVStLbPQ9kR9AT6GD85Whf0DbvqANPhVK4WOIGSLuNb7qFOMI2qdCkrTVIDsaywdkz2puTAXZ e3L+YrVw EAQYTJlkAIdM7IFJs/tKNWwHQV6P6UexTjmk7Ds9zx393Ndtggmz9qRYip0zrfV9LBYre6aGDPViaZCAi5BzoP1wOqdyJcEmUl3H0F1TRqddcD2sl8ddGMnOoAHMu4HPP8vdicBBMYFub/imKv7z8YZjQ8pwdO9fc5Cb9dgq3gvmdt9tphw9Pu7w3lr4dJ0BsqAP/kq/20dSEzOCsGjwLC+pvGAqNDHiazTXjCgp6X6ED5Kc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 4 Feb 2023, at 6:07, Thorsten Leemhuis wrote: > But as you said: people are more likely to run into this problem now. > This in the end makes the kernel worse and thus afaics is a regression, > as Hugh mentioned. > > There sadly is no quote from Linus in > https://docs.kernel.org/process/handling-regressions.html > that exactly matches and helps in this scenario, but a few that come > close; one of them: > > ``` > Because the only thing that matters IS THE USER. > > How hard is that to understand? > > Anybody who uses "but it was buggy" as an argument is entirely missing > the point. As far as the USER was concerned, it wasn't buggy - it > worked for him/her. > ``` > > Anyway, I guess we get close to the point where I simply explicitly > mention the issue in my weekly regression report, then Linus can speak > up himself if he wants. No hard feeling here, I think that's just my duty. > > BTW, I CCed the regression list, as it should be in the loop for > regressions per > https://docs.kernel.org/admin-guide/reporting-regressions.html] > > BTW, Benjamin, you earlier in this thread mentioned: > > ``` > Thorsten's bot is just scraping your regression report email, I doubt > they've carefully read this thread. > ``` > > Well, kinda. It's just not the bot that adds the regression to the > tracking, that's me doing it. But yes, I only skim threads and sometimes > simply when adding lack knowledge or details to decide if something > really is a regression or not. But often that sooner or later becomes > clear -- and then I'll remove an issue from the tracking, if it turns > out it isn't a regression. > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) Ah, thanks for explaining that. I'd like to summarize and quantify this problem one last time for folks that don't want to read everything. If an application wants to remove all files and the parent directory, and uses this pattern to do it: opendir while (getdents) unlink dents closedir rmdir Before this commit, that would work with up to 126 dentries on NFS from tmpfs export. If the directory had 127 or more, the rmdir would fail with ENOTEMPTY. After this commit, it only works with up to 17 dentries. The argument that this is making things worse takes the position that there are more directories in the universe with >17 dentries that want to be cleaned up by this "saw off the branch you're sitting on" pattern than directories with >127. And I guess that's true if Chuck runs that testing setup enough. :) We can change the optimization in the commit from NFS_READDIR_CACHE_MISS_THRESHOLD + 1 to nfs_readdir_array_maxentries + 1 This would make the regression disappear, and would also keep most of the optimization. Ben