From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2489523A567 for ; Mon, 13 Jan 2025 13:17:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736774224; cv=none; b=D+0xBeENboihL3DfMugELO8alyKA8zksIeCVErVS40XEh2PYwwx43aqn/ZgPFR7eGhuyRi232Z65XIn4jpjBzq5DpkS/8CZwcHjWPebC7zV9oeEMBEaIbLtmD1A9lRCaYNDkQ5SB3pUiUm1y1OyUH5QxAq9rKYkDnLXGi3g0U6Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736774224; c=relaxed/simple; bh=W1uAMq9pTLFOZ0ZGCCyOdifmR/FrTFq1q0OsOSlcoCY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CSDMUIqP+ZZiCbzQrW2pYKLGRKdWQzAz7bMjNKC58VrjLJpvzmqaPPYEkr1djSu58l4yoa5q2igjwopGPqdSiHUIBRzw/8URtZxLxWU2DjbXKSvQ9GVGU+iDmXLTGaaM4/aRMCPR8hm+Ux3SAUgVR17sifbQgz6Q7iJMlyDfDzM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=UBw2sTUI; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="UBw2sTUI" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=d8SvSs2+6iMAfuKIe6UMMu8i0SSROBEBIQO7O8S0ehk=; b=UBw2sTUIVQB3mXD9gzGCWOagwv GxtLlsyxiQ7g88xszRDjPwxX15Lek3EYiY6DP2+eE/oyXmRzj4ctpkBMPnIWMCSnm/iXQVwS/wkFI hY5p62waE9ACHiYiL8KguTcZYY0xIqp5JA401ti1MINfWq6WXekt7y5lJc3CHtr4UdQtkRC8EE8Aa +TR8WB6PpVS/+BXAjEVUIyJRwJBiD03hXJB6LzaPAMZg+lJj9krIOd7J4csz904SW4b2Syige17Gm m4NvbuVZc5chP4xL5jrmPYxctFRjUbHBGYoLgHv8lvvyU4cIRp2kPsxgKSqhO98Ye4ZsWEe45QMIa sCNino6Q==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tXKJL-0000000AID7-3rXZ; Mon, 13 Jan 2025 13:16:56 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id C44E530057A; Mon, 13 Jan 2025 14:16:54 +0100 (CET) Date: Mon, 13 Jan 2025 14:16:54 +0100 From: Peter Zijlstra To: Maria Yu Cc: Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Ingo Molnar , linux-kernel@vger.kernel.org, kernel@quicinc.com Subject: Re: [PATCH] sched: Use printk_deferred_once() instead of WARN_ONCE() Message-ID: <20250113131654.GB8385@noisy.programming.kicks-ass.net> References: <20241227-sched-use-printk_deferred_once-v1-1-5da85cb38da2@quicinc.com> <20250113131243.GA8362@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250113131243.GA8362@noisy.programming.kicks-ass.net> On Mon, Jan 13, 2025 at 02:12:43PM +0100, Peter Zijlstra wrote: > On Fri, Dec 27, 2024 at 05:27:10PM +0800, Maria Yu wrote: > > A deadlock is observed when WARN_ONCE() uses printk() inside the scheduler > > logic. printk_deferred_once() is a WARN_ONCE() similar special printk > > facility for the scheduler to avoid unnecessary deadlocks. > > No, problem is with printk. Using delayed will make it so that you'll > never see the output if it dies. > > Only use delayed for printk()s that are expected and non fatal. Also, if you trip WARN in scheduler, correct thing to do is fix WARN, not make WARN run 'better'. No WARN, no problem.