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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBBC2C433EF for ; Mon, 18 Oct 2021 06:26:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 573FA60F9D for ; Mon, 18 Oct 2021 06:26:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 573FA60F9D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E51316B006C; Mon, 18 Oct 2021 02:26:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD9CE6B0071; Mon, 18 Oct 2021 02:26:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7A1F900002; Mon, 18 Oct 2021 02:26:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id B43456B006C for ; Mon, 18 Oct 2021 02:26:06 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 56D5B2A48E for ; Mon, 18 Oct 2021 06:26:06 +0000 (UTC) X-FDA: 78708573132.40.59C8FC9 Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) by imf14.hostedemail.com (Postfix) with ESMTP id 0540B6001986 for ; Mon, 18 Oct 2021 06:26:06 +0000 (UTC) Received: by mail-ua1-f42.google.com with SMTP id r17so5673087uaf.8 for ; Sun, 17 Oct 2021 23:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5hyNbtoXj6gpz4GVzyiBy/BcrMKlU7PR5ScmW7Ah/0c=; b=fUoWDbarHptRaSJPZZmT2Ezo0RZISM9rh5s8evrCkVqnsmUDqct9pNJCt6UgP34gsu //k3IqFxT6I1pFaSnTEdzarl4ScQw4UqJSZb7AZp2uB4i9PWTHRi7dddDE8Bm5U2/y6X TrWAoVlheTVniBRFlgV5OPQuyXUzo03PX27Frzoqm9RPPlLSaKwAt3AUi8mYHf0cbpac ItwK1PtmtJpg/6gkYvNKt6Zpg8sU+1xsFRQWxdH8M/7MJBnqVA/+Hh6pXv9O2tJoUnXO HyTJ0FdgHfp2aGnq+CsMhhFoHWlBVuEGH77ze9DERaTmv/Gfj4QN8CK3FDDCwClcnuY2 D4mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5hyNbtoXj6gpz4GVzyiBy/BcrMKlU7PR5ScmW7Ah/0c=; b=ZTKMWKBHSMpNjX/Z4qFxt6Iw9sqy7BR6tTZevnrXp/fY9ymX0bQGgRroPRWb+lCSBZ Xo3YETPyuSfVceBRy4Rg8jNOG+xYCV67xQB0Vgz61Yr94Q7WoxUUZY2VJl7yFpmQxEvd Po+n7Wp9u+XAgG8+TBrEbkCwIFDf8gXUlz7i8wf/pFlHVsfR9rv0msqLSGe6QhJFxpEA KmcQpzDECYyk0UF6kiKnq2NiT1TBOLlWwEqWLmcPWAb1ylWFe9qFgX9PTI5W8u29eu+a qcjmKUnPLggb1Wr5b3SmBaFScx9akyO2jgv9AVkk2az5MyzQ9EPbVtzonHr9x89Q2GtZ woHg== X-Gm-Message-State: AOAM5337r0PcX80LjBkzgh6n8XLoWT6LwzB/LaoGcfqGoaI5LQO+meIu fRw8/q+vqldo7noZ1oaji60YIirxtlefRZYiZbk3gQ== X-Google-Smtp-Source: ABdhPJwLVSsvksTT5AZxm0evVbJT73BF/2Vlm124e/F9zu//3HXW69tjV+llW2vhLcKMEXT5XQWM34JmpeIdNDgHo80= X-Received: by 2002:ab0:49ca:: with SMTP id f10mr23313822uad.61.1634538365121; Sun, 17 Oct 2021 23:26:05 -0700 (PDT) MIME-Version: 1.0 References: <1M9_d6wrcu6rdPe1ON0_k0lOxJMyyot3KAb1gdyuwzDPC777XVUWPHoTCEVmcK3fYfgu7sIo3PSaLe9KulUdm4TWVuqlbKyYGxRAjsf_Cpk=@protonmail.ch> <87ee9pa6xw.fsf@disp2133> <878rzw77i3.fsf@disp2133> <20210929173611.fo5traia77o63gpw@example.org> <20210930130640.wudkpmn3cmah2cjz@example.org> <878rz8wwb6.fsf@disp2133> <87v92cvhbf.fsf@disp2133> <87mtnavszx.fsf_-_@disp2133> <24192747-7f69-ef22-7bf1-96b2e7c2bca1@infomedia.dk> In-Reply-To: <24192747-7f69-ef22-7bf1-96b2e7c2bca1@infomedia.dk> From: Yu Zhao Date: Mon, 18 Oct 2021 00:25:54 -0600 Message-ID: Subject: Re: [CFT][PATCH] ucounts: Fix signal ucount refcounting To: Rune Kleveland , "Eric W. Biederman" Cc: Alexey Gladkov , Jordan Glover , LKML , Linux-MM , "containers\\@lists.linux-foundation.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0540B6001986 X-Stat-Signature: bysnc6g9zmf8qbdi7fk8cf3b1d6hfuek Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=fUoWDbar; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.42 as permitted sender) smtp.mailfrom=yuzhao@google.com X-HE-Tag: 1634538366-841328 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000479, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Oct 17, 2021 at 10:47 AM Rune Kleveland wrote: > > Hi! > > After applying the below patch, the 5 most problematic servers have run > without any issues for 23 hours. That never happened before the patch on > 5.14, so the patch seems to have fixed the issue for me. Confirm. I couldn't reproduce the problem on 5.14 either. > On Monday there will be more load on the servers, which caused them to > crash faster without the patch. I will let you know if it happens again. > > Best regards, > Rune > > On 16/10/2021 00:10, Eric W. Biederman wrote: > > > > In commit fda31c50292a ("signal: avoid double atomic counter > > increments for user accounting") Linus made a clever optimization to > > how rlimits and the struct user_struct. Unfortunately that > > optimization does not work in the obvious way when moved to nested > > rlimits. The problem is that the last decrement of the per user > > namespace per user sigpending counter might also be the last decrement > > of the sigpending counter in the parent user namespace as well. Which > > means that simply freeing the leaf ucount in __free_sigqueue is not > > enough. > > > > Maintain the optimization and handle the tricky cases by introducing > > inc_rlimit_get_ucounts and dec_rlimit_put_ucounts. > > > > By moving the entire optimization into functions that perform all of > > the work it becomes possible to ensure that every level is handled > > properly. > > > > I wish we had a single user across all of the threads whose rlimit > > could be charged so we did not need this complexity.