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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFD3BC761AF for ; Thu, 30 Mar 2023 08:20:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230334AbjC3IUY (ORCPT ); Thu, 30 Mar 2023 04:20:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230362AbjC3IUM (ORCPT ); Thu, 30 Mar 2023 04:20:12 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BCDD6EB2 for ; Thu, 30 Mar 2023 01:20:07 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id w9so73344184edc.3 for ; Thu, 30 Mar 2023 01:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680164406; 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=rE+Nd7UYDrEpMLZdSjUiKej18eXol1/TN8rz8IxWo74=; b=GyiWHmVq+FRfL2cjm01ZTknwA6vfgE0p1ya77Ct3yJ2fB3E9yTJDYO2DG1GztDRNr1 mgqcDehwuGMzQozTkhWOck0f+hbdMLCW22Oz0H2Hw6ub0AxgTKvO7NZZd8kar0iXPa0I w1fR0oirsZVe2itG6Xr3UFIcRF4dGKzDyt2lNU2VwbqP6oVlYOxkUSoEnJivS8rNs64x VZVdjxryxpTbjqXXWbrRaMthVoEUjQbg6RENFAeilc95gCV/uc5zz8ndmctFE1QXVkv2 tyHZExil1HMZFY3eIbGsSr2E+zht6bWEo8TR5K8rxCHL18BXfX+/+YVs+jZNksasf9f2 oklg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680164406; 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=rE+Nd7UYDrEpMLZdSjUiKej18eXol1/TN8rz8IxWo74=; b=SXnayLzpFeHyU6AsbkZl67K+kxSldVRvcFAvOZVtKM4klEB0teLA3hJ68TcoS0n8hv yZ+XrTAkeC07c28s7oz/5kKdKpQ5NdqOFAAVHEV1tADwYrl6nfBEd/56tJPb2cNyX745 +hcBMzLTMPAkjhyXhoi3WptcnVSCXBG2yIXyIWWjzcu8Rz7u1E0jrm/rKgOXRTbna4DH y098Z7lt38WKzEOA941iqELXL8Yh7jaNUS6q1L0sida1E6qyuXUSpdX799qUM5RLlZvU LKrhZ7O+8tWPRpaGG9mkJEDz8C2e+pSqGa5QqdnpvpNgnBCbD911UopNfELzRERjLeze 6k3g== X-Gm-Message-State: AAQBX9f790ZzgEc+xC+jejMUSf91Y903LgBKCAqQjA639E1Sua9Gsuj0 hMzEQn9QGrraD34hRPBopAJQ7JldrOH3xHHXn/WXjQ== X-Google-Smtp-Source: AKy350bAhrh9NHy4UYkmG2jHp+l/1C2NvOUI9U59l2Zu/qbpFVbWrn1FsDF2AI+0/W7DKu39i6IFvDYFuiBiBzY6SzU= X-Received: by 2002:a50:8e0d:0:b0:4fc:473d:3308 with SMTP id 13-20020a508e0d000000b004fc473d3308mr11186298edw.8.1680164405731; Thu, 30 Mar 2023 01:20:05 -0700 (PDT) MIME-Version: 1.0 References: <20230328221644.803272-1-yosryahmed@google.com> <20230328221644.803272-5-yosryahmed@google.com> <20230329192059.2nlme5ubshzdbpg6@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 30 Mar 2023 01:19:29 -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 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Mar 30, 2023 at 1:15=E2=80=AFAM Michal Hocko wrot= e: > > 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 that. > 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. Any idea how to shout about "hey this may take too long, why are you doing it with irqs disabled?!"? > > -- > Michal Hocko > SUSE Labs