From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 3BE1A1ADC85 for ; Tue, 14 Jan 2025 10:02:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736848943; cv=none; b=HkLdlXlwH13/QSbA3QmxtwdqNuwM5D5rZzySV0MfNYOSsXpBSXtNe0v2bu71uW8CMOsYqtgifWLkmm9yzi1tEihhhTI0ZgU70la92jJj6MOVaQpAHrZRLsKP0F+DBIO+Te7kCX7DAh/1BV8wCWl73yw+iSg/v5x8FnUpSWeaQ9Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736848943; c=relaxed/simple; bh=GFzslzADu5QmOb5+3xqlLrh/jZTr7kAQP9hNfJQQEs4=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=uT0c0QxCe9BCmyi1PWV3lDGSB4nNUNnEhJykOi/IAVys5tu1Z3NEkQufdkmsMSy4PicZwE5QAbgMzqGJUXf9wrp4ryWOod3T8P3AprJU8BGa3XnrXveclNEkpMkGDvmeCbCglPsGRW08gxHMu8fGXkmZ6jldo68NROjnw4mf/Ko= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=Pikr96XS; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="Pikr96XS" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50E7cXR7019680; Tue, 14 Jan 2025 10:01:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= ib7esN5eBjrQgyCybLTcOByJ8Cge+VIDBfUWEzIzKF0=; b=Pikr96XS6QMvzYHr EYO+9yvrxVuKhl1zqHbZVRZFJXjITRDhFP1nUzqro/WYzuPu9V4P8BfL4mnT/2pg 7gg22oEy6emiYvrOFKXkHILsgWdHLdy3Iaozmyh0CRTCaa9NZCCYWIqZzvoJFvyr Ovqej2UShnKzTtvwy0SaPGYEHfi3QihPkZQgTutPtRR7vEtuuh6bZAdrEluQdqCG jPU/OehY/753aQa+3THwB13mRRfyELPJ8JnISSXxRCllEgSSX/FZ/Hiur9MzIah7 ML5AZm70rViPsDvyeNF+x/VymUtHI1uf+sNK0YsSb9d5HA5oFjix/1BbD1oTRdg2 4Ip++g== Received: from nasanppmta04.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 445kqc09wy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Jan 2025 10:01:37 +0000 (GMT) Received: from nasanex01a.na.qualcomm.com (nasanex01a.na.qualcomm.com [10.52.223.231]) by NASANPPMTA04.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTPS id 50EA1bva015117 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Jan 2025 10:01:37 GMT Received: from [10.239.132.150] (10.80.80.8) by nasanex01a.na.qualcomm.com (10.52.223.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.9; Tue, 14 Jan 2025 02:01:30 -0800 Message-ID: <503bc4c9-a022-4802-bad8-c8fb82f01dc3@quicinc.com> Date: Tue, 14 Jan 2025 18:01:27 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] sched: Use printk_deferred_once() instead of WARN_ONCE() To: Peter Zijlstra CC: Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Ingo Molnar , , References: <20241227-sched-use-printk_deferred_once-v1-1-5da85cb38da2@quicinc.com> <20250113131243.GA8362@noisy.programming.kicks-ass.net> <20250113131654.GB8385@noisy.programming.kicks-ass.net> From: "Aiqun(Maria) Yu" Content-Language: en-US In-Reply-To: <20250113131654.GB8385@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01a.na.qualcomm.com (10.52.223.231) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: QyqXlUfkRjjnSMbgfVSOSk5IvvP9tPxD X-Proofpoint-ORIG-GUID: QyqXlUfkRjjnSMbgfVSOSk5IvvP9tPxD X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 suspectscore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 priorityscore=1501 spamscore=0 clxscore=1015 bulkscore=0 adultscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501140083 On 1/13/2025 9:16 PM, Peter Zijlstra wrote: > 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. printk_deferred() only defers the console print, while it still ensures that the log buffer is logged immediately and correctly. There may be a side effect of showing fewer logs in a corner case if the kernel crashes before the first console_unlock is called. However, printk_deferred() will have the entire sched warn log in the printk log buffer, and the log buffer content is a common method to check the crash root cause. Therefore, in my opinion, in scenarios where the console-enabled printk is likely to crash, printk_deferred() will be more useful since the entire log information can be captured in the log buffer. >> >> 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. I agree that the real issue caused SCHED_WARN_ON() should be addressed. The actual sched logic problem is also being handled separately. However, it is still useful to use the correct method to print the information needed for debugging. Therefore, this patch aims to fix the debug method of SCHED_WARN_ON(). We've encountered various crash issues that exhibited the similar deadlock problem, but with different SCHED_WARN_ON() actually. Anyway, we don't want SCHED_WARN_ON() to sometimes be a warning in the log and other times cause a BUG_ON() behavior that crashes the device. -- Thx and BRs, Aiqun(Maria) Yu