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 383BFC6FD1D for ; Thu, 30 Mar 2023 08:54:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAB9C6B0072; Thu, 30 Mar 2023 04:54:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5B196B0074; Thu, 30 Mar 2023 04:54:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 922F66B0075; Thu, 30 Mar 2023 04:54:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7F8F76B0072 for ; Thu, 30 Mar 2023 04:54:18 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1BF911A0919 for ; Thu, 30 Mar 2023 08:54:18 +0000 (UTC) X-FDA: 80624952996.16.DCF0619 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf24.hostedemail.com (Postfix) with ESMTP id 45947180004 for ; Thu, 30 Mar 2023 08:54:16 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="WXf5DP/S"; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680166456; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oX0gvaOyZOPHIQS/lmv/Ti0/aOErAsGb3zG7Z5OZO2o=; b=OkNDmSJoZVesCfcXhPjI+AlTJXMhph8Pc65eOFwJ6z5xb+Pcgeq65oIxdk9YVsgcEQJ0EC Wv8rEYJY7BtbupaW2J1EAzWiEleggSz5fCEZ6p6luX7759hTvuGuyXD0Gk7iayD4fRzmHF eKUTonnGtwWkS/kuKP+zJkTO79pfNso= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="WXf5DP/S"; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680166456; a=rsa-sha256; cv=none; b=xBU7aLM0qpW5fTB/mJkD9eTCcxq1E4KzOksFM8yGGiHrHgWUns9kqKGZ/4uStbPCTza3Ht VKhQ4AvlWsJjuFdFICCB3UJhy5Mldl4KIAYTWW9eo+6KCzL5lIvXq5ipIj/NV52CzYqGmc lJt/pP2o/X8eDUUDeTb71RiuvjxPf24= Received: by mail-ed1-f52.google.com with SMTP id i5so73819150eda.0 for ; Thu, 30 Mar 2023 01:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680166455; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oX0gvaOyZOPHIQS/lmv/Ti0/aOErAsGb3zG7Z5OZO2o=; b=WXf5DP/SnSUFzsV29yQgNbT+UqQSF6+RPsReWZbLSzwsLGnGrCZ7mGJ+Kg/l3LT/Sa YlwaRxHHQ4V8lQ2ngT1wVPQMpGUNmakTZ5x8ceTg9l7uyxQYfBn3BhwcdUe8BUgFVqDb bVOJOTc+pwvM4OZmgIb2vZRKpL47bO6euuKgv9L3ClENMySR3LjJxL78id+QyVP+9Fvz FdJKYDAKkbtWpALArnt1W7TxIvNZmYl4ltnlCbMCIDvEu2F6DuajYEYUnNpe7RwlEMuh u94GrNUK8lYFRnnkcYCsxCIMmfShfaZNaHwS6ESlMLL2PYDi7KIj59BTIU269tYBDwan IPnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680166455; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oX0gvaOyZOPHIQS/lmv/Ti0/aOErAsGb3zG7Z5OZO2o=; b=FEcl+SJe2JLwnLekZ4pK/FF9CQMjkbC8gcKTcDKQ7u9FUAVMR4j5hSBueCpSJGV3To b9PLu+ClL8+C3nuRo+SlkTw7rG0cu9JkvqSIHKm13B5SjPVXUKWv5f81BniGrMe/93Sc iIfwaHi3Ha7tW8t5APrAPpGsDD7GP7WuN2ZEtxjbdRHAI9YZ940MfK8KvSNlSt05i+IX Nzmr3JU1Bf2cyGwkPMREtvErVXhpGQphIGxAmmGeLoZXfFwEYUzcT+6VL8v1DbuoFwkN SHtwk9ctlqHTvNEB7UF7SuHhyfFKmqKuNZTGG0jgUWU1PAXZcwwZUKRNsbpoHfrP7zZf Avig== X-Gm-Message-State: AAQBX9dCb8+5xF2UVtuxdSnLcvqTyzg5tCSsrLjt148AAHw8XubCKW8J u1GrO6m9r6qBLos708CbON9LauvmGmFwIRprRlQ0ew== X-Google-Smtp-Source: AKy350btdGZhlD0t6aAdY2/xVPLOK3+T5zqWbUhN/U7pPLdepDUEnYUTLCVTQkMwL0EVkjpbPAKrleuZnpRzmCBaJRE= X-Received: by 2002:a50:d756:0:b0:4fc:e5c:902 with SMTP id i22-20020a50d756000000b004fc0e5c0902mr11090294edj.8.1680166454625; Thu, 30 Mar 2023 01:54:14 -0700 (PDT) MIME-Version: 1.0 References: <20230328221644.803272-5-yosryahmed@google.com> <20230329192059.2nlme5ubshzdbpg6@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 30 Mar 2023 01:53:38 -0700 Message-ID: Subject: Re: [PATCH v2 4/9] cgroup: rstat: add WARN_ON_ONCE() if flushing outside task context To: Michal Hocko Cc: Johannes Weiner , Shakeel Butt , Tejun Heo , Josef Bacik , Jens Axboe , Zefan Li , Roman Gushchin , Muchun Song , Andrew Morton , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Vasily Averin , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 45947180004 X-Stat-Signature: 4htnj19bi5zj4krktrcoduzzaqn31p3r X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1680166456-132533 X-HE-Meta: U2FsdGVkX18UHD2IrDLLy0j7Efe+gfJHwGhe2X+IvUN5neGyxKmApdCZmb0zJjsliJzxR3NUA/MxhXyjHo3/RZd4ROIwitYR09zmZodPSiyUdDTaSDU7BZsDs1+70kQRGqeijfjlPHTihaXsJ3iRQza1pfjhVquJLw8AsSQH3XazhMkdUH7e6T9pL9YmwdOA65uOgSxDBXGheFUstoPa1+OhFXzkSGW9YS1RjcnZjORUiVmGwxRFzw/W0pwS8bGrm+1RVZ+kZXDCtNLaq8AT7yuAPRj2Wb5BuhOQRV4mgM7WpowxNUgNUbNMI2IzveVzVfWT1tjtTiGmPuUnqCXjtZTh987tOpXxaUKYODxi1vjCbt55jm71Fn1o0C6AyDhowVreHKozCU7vW5OaNYW2lR2szf0eqXMzG9vK/FWSW7qbmj4e0XHrcglJno77BanCTISk+cBcxktbz+vl53pK31Nvb/Yz+ewrt0kK/I7fPeRGHFNguOP0Iy5fVPtMsx4TW6SJnsijykAQ/iAAbTzacLCL6ga3yzZR0nHCPW4d36GySj+XwTk9PHF0AT81oIYuMhuE/t8EKuyGqf49yoFOKsBdsSxiUAXWA0vnwFO0pRWdoQ5XYmTrlZRk0wL1wqkctCusgWCkwSSOvXdiHA+aPAb0UYrdK28cW38cBorD+DSsKcIwlWgafgr5Zdu1khHD3++MY+kzsSf6m/1ma7FHqhFlQcD25vCVsVMvnZRsNS11e7ubSd33QyPmugIXkFaQB5tJvpwx1kUzVy2GxTobzxBjVtFIrPTSBIGGMXUVThBmxZbMzzFA389FTR1iwiHUinwSEzCWxsOGqe/9GSkSrro69S5EyMQTFx1GK8Gu760Zta7wr+bD9/3MjvKldBRf2fq3Cwr5alc89wTHDHipc4ecdQONH0yDCD4qneKY4/bFsqNl799gWvEUmEFXBFJ0m54+2T1X/PEZJEfLzSe cVQXwsOL 9o3V27DSDZZU4L+CdfhP6EG9GhJopx5MZtIk6f58wAd7RnC98W8GkMxFNEYc0t7tZSv+m4jOicmHP3XPiwa665RXIxEz+ZiCVRUpY0iIA2pDDwCv+7y13t8i9FUTvzzEBtpzVcG1FdYStEzLchcKpIDgF8xlHehHsOSppTzO3CsmRENbun/vlgVVyl2WsNjR+wtqSCj/aJspLZm3MD6Pwax5mHATxxyGSCz2DkHfaF+HAp6KAbp+u9cGtSvA1WdrWVHIeys7kHa7cF+sigG/jLHwe3ojCUydjrmH2AjC5B5L95xna1UbQJLmPZEMWuNCgLpbrfS9cdAEimjT76y2gAlSlymwCKtfk2Ht8 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 Thu, Mar 30, 2023 at 1:39=E2=80=AFAM Michal Hocko wrot= e: > > On Thu 30-03-23 01:19:29, Yosry Ahmed wrote: > > On Thu, Mar 30, 2023 at 1:15=E2=80=AFAM Michal Hocko = wrote: > > > > > > On Thu 30-03-23 01:06:26, Yosry Ahmed wrote: > > > [...] > > > > If we achieve that, do you think it makes sense to add > > > > WARN_ON_ONCE(irqs_disabled()) instead to prevent future users from > > > > flushing while disabling irqs or in irq context? > > > > > > WARN_ON (similar to BUG_ON) will not prevent anybody from doing bad > > > things. We already have means to shout about sleepable code being > > > invoked from an atomic context and there is no reason to duplicate th= at. > > > As I've said earlier WARN_ON might panic the system in some > > > configurations (and yes they are used also in production systems - do > > > not ask me why...). So please be careful about that and use that only > > > when something really bad (yet recoverable) is going on. > > > > Thanks for the information (I was about to ask why about production > > systems, but okay..). I will avoid WARN_ON completely. For the > > purposes of this series I will drop this patch anyway. > > Thanks! People do strange things sometimes... > > > Any idea how to shout about "hey this may take too long, why are you > > doing it with irqs disabled?!"? > > Well we have a hard lockup detector. It hits at a much higher stall by > default but if you care about IRQ latencies in general then you likely > want to lower. Another thing would be IRQ tracing. In any case this code > path shouldn't be any special. Sure it can take long on large systems > but I bet there are more of those. We did see hard lockups in extreme cases, and we do have setups with "nmi_watchdog=3Dpanic" that will panic when this happens, so we would rather catch the code paths that can lead to that before it actually happens. Maybe we can add a primitive like might_sleep() for this, just food for tho= ught. > -- > Michal Hocko > SUSE Labs