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 B896FC433EF for ; Mon, 18 Oct 2021 10:31:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 49982610A3 for ; Mon, 18 Oct 2021 10:31:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 49982610A3 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=protonmail.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id D61556B006C; Mon, 18 Oct 2021 06:31:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D11086B0071; Mon, 18 Oct 2021 06:31:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFF496B0072; Mon, 18 Oct 2021 06:31:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id A90C66B006C for ; Mon, 18 Oct 2021 06:31:49 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6C64318036FD0 for ; Mon, 18 Oct 2021 10:31:49 +0000 (UTC) X-FDA: 78709192338.20.814F047 Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by imf16.hostedemail.com (Postfix) with ESMTP id CB052F000090 for ; Mon, 18 Oct 2021 10:31:46 +0000 (UTC) Date: Mon, 18 Oct 2021 10:31:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail; t=1634553106; bh=HYCqN5T+QYzLh/zNNwmm3Jblg3/9nkHgKNp4c3zRw0E=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=iz1aBOLhcLUFZzHy48w+1/uKpOt/mY4U/WDXHPNkkh+DjIl6qys/9icS6CYXhHcl1 Q85uMCjYqJqY18kz+SnEIq9l0yahlhsZkjATSG2L4iCtQyYmNA7cuXNOLczQklYKA9 I+HqGiM1jna5pcCZ0eGV8A8eGXH5ABCdZN75vlvc= To: Yu Zhao From: Jordan Glover Cc: Rune Kleveland , "Eric W. Biederman" , Alexey Gladkov , LKML , Linux-MM , "containers\\\\@lists.linux-foundation.org" Reply-To: Jordan Glover Subject: Re: [CFT][PATCH] ucounts: Fix signal ucount refcounting Message-ID: In-Reply-To: References: <1M9_d6wrcu6rdPe1ON0_k0lOxJMyyot3KAb1gdyuwzDPC777XVUWPHoTCEVmcK3fYfgu7sIo3PSaLe9KulUdm4TWVuqlbKyYGxRAjsf_Cpk=@protonmail.ch> <20210930130640.wudkpmn3cmah2cjz@example.org> <878rz8wwb6.fsf@disp2133> <87v92cvhbf.fsf@disp2133> <87mtnavszx.fsf_-_@disp2133> <24192747-7f69-ef22-7bf1-96b2e7c2bca1@infomedia.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CB052F000090 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=protonmail.ch header.s=protonmail header.b=iz1aBOLh; spf=pass (imf16.hostedemail.com: domain of Golden_Miller83@protonmail.ch designates 185.70.43.19 as permitted sender) smtp.mailfrom=Golden_Miller83@protonmail.ch; dmarc=pass (policy=quarantine) header.from=protonmail.ch X-Stat-Signature: m3p66ej19ryka8ndum36doo1gnt7wn8p X-Rspamd-Server: rspam05 X-HE-Tag: 1634553106-199941 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 Monday, October 18th, 2021 at 6:25 AM, Yu Zhao wrote= : > On Sun, Oct 17, 2021 at 10:47 AM Rune Kleveland > > rune.kleveland@infomedia.dk 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 o= n > > > > 5.14, so the patch seems to have fixed the issue for me. > > Confirm. I couldn't reproduce the problem on 5.14 either. > I'm also unable to reproduce the crash as for now. Thx for the patch. Jordan > > 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 decremen= t > > > > > > 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.