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 B4D58C761AF for ; Thu, 30 Mar 2023 08:39:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229448AbjC3IjL (ORCPT ); Thu, 30 Mar 2023 04:39:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229680AbjC3IjI (ORCPT ); Thu, 30 Mar 2023 04:39:08 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C1746582; Thu, 30 Mar 2023 01:39:07 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1AB851FE3F; Thu, 30 Mar 2023 08:39:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1680165546; h=from:from:reply-to: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; bh=l77j8HdtGUHY1DMGytaSmxCL2KwdNyQtcXi/v8k1LPw=; b=ZgNg5GontEAiDlgn92dJ6MtfZud/Zqf+VjcX9eEi4gTi2tHmEQ33ugODl7Ly+X0ZWtEsA+ p3AZ19J4aHB5KoT4BR/c1glf2Ls0e6ZF0/gGE1sQoKTvQeCB+cmYH2J59mXyjUNEtHGGaB aZDvQcyHUI3flpOOeXADbKoneVeUCeA= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id EC0D1138FF; Thu, 30 Mar 2023 08:39:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6e0lN6lKJWRCHQAAMHmgww (envelope-from ); Thu, 30 Mar 2023 08:39:05 +0000 Date: Thu, 30 Mar 2023 10:39:04 +0200 From: Michal Hocko To: Yosry Ahmed Cc: Johannes Weiner , Shakeel Butt , Tejun Heo , Josef Bacik , Jens Axboe , Zefan Li , Roman Gushchin , Muchun Song , Andrew Morton , Michal =?iso-8859-1?Q?Koutn=FD?= , Vasily Averin , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org Subject: Re: [PATCH v2 4/9] cgroup: rstat: add WARN_ON_ONCE() if flushing outside task context Message-ID: References: <20230328221644.803272-5-yosryahmed@google.com> <20230329192059.2nlme5ubshzdbpg6@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu 30-03-23 01:19:29, Yosry Ahmed wrote: > On Thu, Mar 30, 2023 at 1:15 AM 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 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. 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. -- Michal Hocko SUSE Labs