Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp3354445ioa; Tue, 26 Apr 2022 01:49:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3KpviYYL9DsYM/D+pl7hlyfcIPtYZTBp19+BzP4udCnr45ymmHRb3sWjfEWo1Py3sJC0M X-Received: by 2002:aa7:d350:0:b0:425:e029:da56 with SMTP id m16-20020aa7d350000000b00425e029da56mr11950794edr.296.1650962996710; Tue, 26 Apr 2022 01:49:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650962996; cv=none; d=google.com; s=arc-20160816; b=IZD51UIbIpSp9lJDCMc9EyGtNJhnVyPRYVXfdQAb35A+RrOisDtzuwwJlgrWILIATW ef0o8L6QElVzCEYO0dojQwgV2iXw70d7TiPYJsFianigHGv5sNBm0Yg8LbxY1346ofDw jhegld/2isKUThuecRT+43vWtFFbhh0SLk9I64rTsVgYAchvRajaN6b0mkViejIyb+0+ aOgth5jnAzIa70RD0t5r98R73wMgYuuasKyibtlBdyNf5HVBOTu0Z8Xu6othZImmFhMa k3kJEd4v/NidPhKePllcCql9hOCchSN2c4qy1DMTNSs6V6mg8x7JxU5muzz1V60EvL1z DdLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id :in-reply-to:date:dkim-signature; bh=Pl23pgw2QRmZxu/rVHBG/vRwq0BrcXgENMaH2heZ7ug=; b=X2CsSHztkzzTC9d8qxxHh2vCl1bFNmjwMiHsYImfu0Bp+eF+6WDRA1cSp+xS9f1cF5 N+o7NXYArpCP/bha+kfi3/OB4DSkukuU/DcTci4n26bR8rK47FnJ0K5EHPiz4xVsPsLh xiImC8F6x6JdVOGypE1GBaOk5UJ7WDXkcfDcqh4gqHyq++ypysBNY/2Uha4ilwCyTqsh sc8zVLa2j0sRzJR+HMIHZHWv8NeLI4wyBYcJwVqvc6BCDas5TZOuRD5Qll1452NlToUM ve5wcMPFi5mbeDa+Ic7HqRqilZT9+80SRnz8Qt2Wco933MxPg6UT5SaCP1KiVJT+YYiY 4KSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=b86lc2my; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ay21-20020a056402203500b00425d5787628si6673200edb.407.2022.04.26.01.49.33; Tue, 26 Apr 2022 01:49:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=b86lc2my; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239051AbiDZHDG (ORCPT + 99 others); Tue, 26 Apr 2022 03:03:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237798AbiDZHDE (ORCPT ); Tue, 26 Apr 2022 03:03:04 -0400 Received: from mail-ej1-x64a.google.com (mail-ej1-x64a.google.com [IPv6:2a00:1450:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C71E5606DC for ; Mon, 25 Apr 2022 23:59:56 -0700 (PDT) Received: by mail-ej1-x64a.google.com with SMTP id ne12-20020a1709077b8c00b006f3aca1f2b2so926640ejc.17 for ; Mon, 25 Apr 2022 23:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:subject:from:to:cc; bh=Pl23pgw2QRmZxu/rVHBG/vRwq0BrcXgENMaH2heZ7ug=; b=b86lc2mydFvYH75fQREZ4C1BxVG0XfRGBq1e+5PLjfo9D0MM9Iu6ws1pvccyZZHjVR OuR7Hwv7NkvffG5FT4oV14TT5shJ6+B4z4VdaEJlbCih9kSFh6K9LQ41RSkUOy7FEnhJ iSkfBIdXImU9PY9ykGOEC1MJNywC/7knrmlXtRoYMIvzfJU6HFXUytjH1LMtaW6BDl1s xwhoFt5Fptv2hHCd+yNUXgxdX34pczjLnc1sh24p48fa+8zp8dpL7NMuefGPacSNYrrP U6ELCW/mMsd1oMlyqE5HaXtqwOup9HN+HGpYrcVRSNyLeebGvJS5UZy4WhVU4rkPNtRl BfVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version:subject :from:to:cc; bh=Pl23pgw2QRmZxu/rVHBG/vRwq0BrcXgENMaH2heZ7ug=; b=IjaYF0Y7zEkeKVD693Yet+3FCPIY4uGSFmDGXKKFOhpitBNgsw7/+MswmbSKdwFMrZ KlLF/qkTjI96/2gpxgepY91/ZlmYNNicePsfvSjHXaBf/2nBbFefAMnZxvHcBAzIJKXK YkXh7/MBsU0woBjRVdp2Nmq96aGGeQKQYucRVyNQ8SjX1Zv2BTB7nT1mU6KAL5QvOjCa bkLOOxsph2bGMVROZKJlj08v/tZQn0ShIj1lXX2WIDFFuDvOAg/ElAgKgFPdJYJPpMHU XVZBWdLgYJboLfTRFNc/oMJ5Y8PWdmNeO4CNgSWS+ShLwvT8pJYstTkO/W10jvV7gXu5 4mdQ== X-Gm-Message-State: AOAM530B6kWoUxUztLaWEFnB8J3J9ecsfvYpTJ6+VCOvgIUX1GzWVdJI Tw1Ks3Vn+KpMs2Wa2B49jPE/6kP/vfq/gpM= X-Received: from bartoschek.muc.corp.google.com ([2a00:79e0:15:10:5734:8ae8:25cb:cd3]) (user=bartoschek job=sendgmr) by 2002:a50:ed11:0:b0:425:c3d1:4547 with SMTP id j17-20020a50ed11000000b00425c3d14547mr19795956eds.410.1650956395087; Mon, 25 Apr 2022 23:59:55 -0700 (PDT) Date: Tue, 26 Apr 2022 08:59:17 +0200 In-Reply-To: <8E281DF1-248F-4861-A3C0-2573A5EFEE61@fb.com> Message-Id: <20220426065917.3123488-1-bartoschek@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.36.0.rc2.479.g8af0fa9b8e-goog Subject: Re: [PATCH RFC fs/namespace] Make kern_unmount() use synchronize_rcu_expedited() From: Christoph Bartoschek To: Chris Mason , "Paul E. McKenney" , Giuseppe Scrivano Cc: linux-kernel@vger.kernel.org, "riel@surriel.com" , "viro@zeniv.linux.org.uk" , Christoph Bartoschek Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The regression that has been introduced with commit e1eb26fa62d04ec0955432be1aa8722a97cb52e7 has hit us when building with Bazel using the linux-sandbox (https://github.com/bazelbuild/bazel/blob/master/src/main/tools/linux-sandbox.cc). The sandbox tries to isolate build steps from each other and to ensure that builds are hermetic and therefore sets up new namespaces for each step. For large software packages and even with the time spend building we run out of namespaces on larger machines that allow for enough parallelism. I have reduced the sandbox to a simple test case: #define _GNU_SOURCE #include #include #include #include #include #include int pid1main(void *) { return 0; } int main(void) { int clone_flags = CLONE_NEWUSER | CLONE_NEWIPC | SIGCHLD; void * stack = malloc(1024*1024); const pid_t child_pid = clone(pid1main, stack + 1024*1024, clone_flags, NULL); if (child_pid < 0) { perror("clone"); } int ret = waitpid(child_pid, NULL, 0); if (ret < 0) { perror("waitpid"); return ret; } return 0; } Run it with $ gcc clone-test.cc $ seq 1 10000000 | parallel --halt now,fail=1 -j32 $PWD/a.out clone: No space left on device waitpid: No child processes parallel: This job failed: /usr/local/google/home/bartoschek/linux-sandbox-test/a.out 53070 I run the test on kernel v5.18-rc4. Depending on your configured limits you will soon get an ENOSPC even though never more than 32 additional namespaces should be in use by parallel. During execution the whole system can become quite unresponsive. This does not happen without e1eb26fa62d04ec0955432be1aa8722a97cb52e7. I see that the issue was already reported in 2020: http://merlin.infradead.org/pipermail/linux-nvme/2020-September/019565.html Would it be possible to revert e1eb26fa62d04ec0955432be1aa8722a97cb52e7? It seems to make the kernel less deterministic and hard to reason about active namespaces. Christoph