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 D1E65C4167B for ; Sun, 26 Nov 2023 16:17:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230186AbjKZQR2 (ORCPT ); Sun, 26 Nov 2023 11:17:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbjKZQRZ (ORCPT ); Sun, 26 Nov 2023 11:17:25 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 244A9D3; Sun, 26 Nov 2023 08:17:32 -0800 (PST) From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1701015450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KA0lDoV5G5Peuw5aoWsAKffieXWD7sSMsne9MKzdxaY=; b=zqKWyY/nAZnzrOIpYqQo3Mwy8WSs9c7+XOPgm2+o1WwBNEC67xa83d4yMbyVK6czzKZPQ2 Skaao1godL5ZD2rPS+mt8k+vEPW0BnSYU8btf+x8lEA1gX4DakjWm21JUHI15v0IZdAiTS zXMSBZKB15Fz06rwapGAutBGxIpiu5Keu6kdOBDP5jxILlStTTUk/wmy9EepSyGzpfjgnF SRIjUuWekFbmHiKMEzkTQpM07geuA+Wr29seaX4HkMRfKiwUPlQc61whaUdRobZifFW/Tc 1ef7o1Uvj46KeWbgVOJ9uWh+zGSL3fQoJ2HlYJB0mKryTdyyzP+ujlgH1vutpw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1701015450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KA0lDoV5G5Peuw5aoWsAKffieXWD7sSMsne9MKzdxaY=; b=BwrXFy+skkl94ocXW+NpEpjC6YMKz11ciAZNDycQ9gm9LG7BWdgEs+Jsa0S/DJdy9favH/ BGxy2msUs7eRYeAg== To: Xuewen Yan , gregkh@linuxfoundation.org, jirislaby@kernel.org, ilpo.jarvinen@linux.intel.com, tony@atomide.com Cc: tglx@linutronix.de, andriy.shevchenko@linux.intel.com, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, ke.wang@unisoc.com, xuewen.yan94@gmail.com, Petr Mladek , Sergey Senozhatsky , Steven Rostedt Subject: Re: [RFC PATCH] serial: core: Use pm_runtime_get_sync() in uart_start() In-Reply-To: <20231124122258.1050-1-xuewen.yan@unisoc.com> References: <20231124122258.1050-1-xuewen.yan@unisoc.com> Date: Sun, 26 Nov 2023 17:23:26 +0106 Message-ID: <87il5o32w9.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Added printk maintainers CC.] On 2023-11-24, Xuewen Yan wrote: > The commit 84a9582fd203("serial: core: Start managing serial > controllers to enable runtime PM") use the pm_runtime_get() after > uart_port_lock() which would close the irq and disable preement. At > this time, pm_runtime_get may cause the following two problems: > > (1) deadlock in try_to_wake_up: > > uart_write() > uart_port_lock() <<< get lock > __uart_start > __pm_runtime_resume > rpm_resume > queue_work_on > try_to_wake_up > _printk > uart_console_write > ... > uart_port_lock() <<< wait forever I suppose you got this because of the lockdep message generated by #2. It probably would make sense to call __printk_safe_enter() inside uart_port_lock(). This would allow printk() to automatically defer the printing for that CPU until the port lock is released. > (2) scheduling while atomic: > uart_write() > uart_port_lock() <<< get lock > __uart_start > __pm_runtime_resume > rpm_resume > schedule() << sleep rpm_resume() is a fascinating function. It requires the caller to hold a spin_lock (dev->power.lock) with interrupts disabled. But it seems to believe that this is the *only* spin_lock held so that it can temporarily spin_unlock and call might_sleep() functions. In the case of uart_write(), it certainly is not the only spin_lock held. I do not know enough about the internals of RPM to suggest a proper solution. But it looks like rpm_resume() cannot assume dev->power.lock is the only spin_lock held by the caller. John Ogness