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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 855F8C54EBC for ; Thu, 12 Jan 2023 11:33:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lM6peiypH+UyzzpjCT55Arlwh+wZXoVleBTT7yNod10=; b=hVxZXoeLe9DxXs KcNzfcffUs3udaa2AhCf2JbJ72fQzaEnUokKD9ESfmxMzmFo62unc137ZVfoaorEKP/7Gwe+4AOdt OSSASYabodUeU+/SKX8Pj0eeiiKHb5lQg1p8q4u/AxX+lAfZAmpOTHjDwo9mYteEGc51ruike82HG nyB3Lg3sAGHeuZinSe+bIB+HRCDuDApbk51lsFmG4zWHxY6Yf5zjpcZCsa0rdUy+pN6sWkks/dr2P q17FBki8rHwH/3WBbxYH9X65S61+MGX2uHkwLa6KgStA/dE19aVi2iwZ60phN0HlSrLQML5r4+jdX pJcOUN/gLUR1fWHSbC6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFvor-00EqW3-Qr; Thu, 12 Jan 2023 11:32:29 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFvoo-00EqUG-3O for linux-arm-kernel@lists.infradead.org; Thu, 12 Jan 2023 11:32:27 +0000 Received: by mail-ej1-x62b.google.com with SMTP id az20so24935024ejc.1 for ; Thu, 12 Jan 2023 03:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=x0gSaQMG1ZEFcejTq7nLHyz4oYLVH4s87HrXZ9feFZw=; b=MxATrjpAReX++o2TYHHWOfICbw35vKWQ+92xVH35B4uAi4k3xpysWiDmXJEqF8hNYP K98P+1UPTVgUwELW/eHrcWQvuK5PopluglhhrXaGpKhlfOg5BTT7FMX9kkfzrSzMnPiV qJcHkM/NU+syr++OnBpDhLWYIcAP3+OBFa6DaAcmmuBDAOGLzdpIpi3BivMqtxc6yyac tzpUKrOAgff7npw/YqJ5823aPvKMC8ZPZfYmTzjBd/jI9V1zSn9QVGP524sNDJMH1gC9 PLJqLz2SyVGQo0CUnke6+hAFlz6fVai2u5qVdiC/njfVCBmc01WrKvZLZvvpG0kjeE4Y AK8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x0gSaQMG1ZEFcejTq7nLHyz4oYLVH4s87HrXZ9feFZw=; b=ovJyHRWzbvbkauV2bi59XBTJ7MnN4I/qaJjQjq/sfEGqgVugxzB05YgZJtFcefQD5A /5dDtO+obz3qnNOZQIuoXCBsvPZ3aewkrZEusuDAuYcti94j9x2RRF39ZT0hfYUXUCXc 3+65XG1aovD1+szVTGaVzJRtH8xwThj6kl22K2zLHxo7DIXox0Oq7JUdPg67GJCH57Vo IYUYq/lIMTqCWgEeYqOa894K66+pqm8TaPMBpPJrGNv9HSc2FBWuIuSwq/45qvRfRjqh Oqsh5gZCe0zYoEZFOMPHxAe9WJivmapbTfGYvtOD28BNYArbP6kJbvLxO8awVv7k4FfD HaNA== X-Gm-Message-State: AFqh2kpgoCTer2GsG8I7Dvlw+E9VodQsCYLyVa5ghTtauKUNcpKBsjPI nL7/AdPk8hBKfwBwJIkuK12DXQ== X-Google-Smtp-Source: AMrXdXt4Icsn6J2EIf5YR6zEEyxeLvlN8muBgDY7KHjKOXpXigEIGra9aZ16EDLnGrrB0D7ip4IWfg== X-Received: by 2002:a17:907:7f04:b0:7c0:a4e9:615b with SMTP id qf4-20020a1709077f0400b007c0a4e9615bmr81407577ejc.61.1673523142029; Thu, 12 Jan 2023 03:32:22 -0800 (PST) Received: from [192.168.1.109] ([178.197.216.144]) by smtp.gmail.com with ESMTPSA id ku12-20020a170907788c00b0084d4564c65fsm5153826ejc.42.2023.01.12.03.32.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Jan 2023 03:32:21 -0800 (PST) Message-ID: <428c9a9e-f5f3-661f-d3d1-19ca38a75336@linaro.org> Date: Thu, 12 Jan 2023 12:32:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v2 2/5] cpuidle: psci: Mark as PREEMPT_RT safe Content-Language: en-US To: Sebastian Andrzej Siewior Cc: "Rafael J. Wysocki" , Len Brown , Pavel Machek , Greg Kroah-Hartman , Kevin Hilman , Ulf Hansson , Daniel Lezcano , Lorenzo Pieralisi , Sudeep Holla , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Adrien Thierry , Brian Masney , linux-rt-users@vger.kernel.org References: <20221219151503.385816-1-krzysztof.kozlowski@linaro.org> <20221219151503.385816-3-krzysztof.kozlowski@linaro.org> From: Krzysztof Kozlowski In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230112_033226_185839_51FE71FA X-CRM114-Status: GOOD ( 17.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 12/01/2023 12:00, Sebastian Andrzej Siewior wrote: > On 2022-12-19 16:15:00 [+0100], Krzysztof Kozlowski wrote: >> The PSCI cpuidle power domain in power_off callback uses >> __this_cpu_write() so it is PREEMPT_RT safe. This allows to use it in > > Why does __this_cpu_write() matter here? I'll reword to "not using sleeping primitives nor spinlock_t" > >> Realtime kernels and solves errors like: >> >> BUG: scheduling while atomic: swapper/2/0/0x00000002 >> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) >> Call trace: >> dump_backtrace.part.0+0xe0/0xf0 >> show_stack+0x18/0x40 >> dump_stack_lvl+0x68/0x84 >> dump_stack+0x18/0x34 >> __schedule_bug+0x60/0x80 >> __schedule+0x628/0x800 >> schedule_rtlock+0x28/0x5c >> rtlock_slowlock_locked+0x360/0xd30 >> rt_spin_lock+0x88/0xb0 >> genpd_lock_nested_spin+0x1c/0x30 >> genpd_power_off.part.0.isra.0+0x20c/0x2a0 >> genpd_runtime_suspend+0x150/0x2bc >> __rpm_callback+0x48/0x170 >> rpm_callback+0x6c/0x7c >> rpm_suspend+0x108/0x660 >> __pm_runtime_suspend+0x4c/0x8c >> __psci_enter_domain_idle_state.constprop.0+0x54/0xe0 >> psci_enter_domain_idle_state+0x18/0x2c >> cpuidle_enter_state+0x8c/0x4e0 >> cpuidle_enter+0x38/0x50 >> do_idle+0x248/0x2f0 >> cpu_startup_entry+0x24/0x30 >> secondary_start_kernel+0x130/0x154 >> __secondary_switched+0xb0/0xb4 > > This is to a sleeping lock (spinlock_t) in an IRQ-off region which > starts in do_idle(). You could describe the problem and to solution you > aim for instead pasting a backtrace into the commit description and > adding a flow in the code. I'll extend the description. > > I don't see how your commit description matches your change in code. One > might think "Oh. If I see this pattern, I need an irqsafe lock to fix > it". Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 C7257C54EBC for ; Thu, 12 Jan 2023 11:42:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236146AbjALLms (ORCPT ); Thu, 12 Jan 2023 06:42:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235059AbjALLlf (ORCPT ); Thu, 12 Jan 2023 06:41:35 -0500 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8801432255 for ; Thu, 12 Jan 2023 03:32:23 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id u19so43953994ejm.8 for ; Thu, 12 Jan 2023 03:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=x0gSaQMG1ZEFcejTq7nLHyz4oYLVH4s87HrXZ9feFZw=; b=MxATrjpAReX++o2TYHHWOfICbw35vKWQ+92xVH35B4uAi4k3xpysWiDmXJEqF8hNYP K98P+1UPTVgUwELW/eHrcWQvuK5PopluglhhrXaGpKhlfOg5BTT7FMX9kkfzrSzMnPiV qJcHkM/NU+syr++OnBpDhLWYIcAP3+OBFa6DaAcmmuBDAOGLzdpIpi3BivMqtxc6yyac tzpUKrOAgff7npw/YqJ5823aPvKMC8ZPZfYmTzjBd/jI9V1zSn9QVGP524sNDJMH1gC9 PLJqLz2SyVGQo0CUnke6+hAFlz6fVai2u5qVdiC/njfVCBmc01WrKvZLZvvpG0kjeE4Y AK8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x0gSaQMG1ZEFcejTq7nLHyz4oYLVH4s87HrXZ9feFZw=; b=pHgEAgzPVJJ7AVS5XdLLDslLnQXQFBEsZby5wTN+f1AhUVqAo3/7PJDQYhA318sEaR H1HL5m3l2csZ/tZuWurT0ElCteojWBwWL2/E1hKlK8l0Qir1dIpdQ6+EwdHqpvtjog3c y/Hq+p7WPnAeOvXfVUfyukjuoZS8sqleSsBvZ26hMpYvMmCreMACwmUpNxPrBm2T+3wB rePAjmSVRDHLv69QNh3kPkCxsBLs37NVap305pH8bmAHIJi98wcihme9FwPKp20TCRrz uhAc8UZsSKPACXI0xTDtYBNpWjo5ZcXKbnDMFFqXBiAEW4yQUpy3UI6x5lKkIhdKDspk OWzA== X-Gm-Message-State: AFqh2kpP0dS2T4ViJl7hNL8zTTconv22puU5Xtui6i3Ozkp9HskGNmpY 5Q8IZZwhWDk5jZAUkQPb8qb4BmIbGMUNmWYp X-Google-Smtp-Source: AMrXdXt4Icsn6J2EIf5YR6zEEyxeLvlN8muBgDY7KHjKOXpXigEIGra9aZ16EDLnGrrB0D7ip4IWfg== X-Received: by 2002:a17:907:7f04:b0:7c0:a4e9:615b with SMTP id qf4-20020a1709077f0400b007c0a4e9615bmr81407577ejc.61.1673523142029; Thu, 12 Jan 2023 03:32:22 -0800 (PST) Received: from [192.168.1.109] ([178.197.216.144]) by smtp.gmail.com with ESMTPSA id ku12-20020a170907788c00b0084d4564c65fsm5153826ejc.42.2023.01.12.03.32.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Jan 2023 03:32:21 -0800 (PST) Message-ID: <428c9a9e-f5f3-661f-d3d1-19ca38a75336@linaro.org> Date: Thu, 12 Jan 2023 12:32:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v2 2/5] cpuidle: psci: Mark as PREEMPT_RT safe Content-Language: en-US To: Sebastian Andrzej Siewior Cc: "Rafael J. Wysocki" , Len Brown , Pavel Machek , Greg Kroah-Hartman , Kevin Hilman , Ulf Hansson , Daniel Lezcano , Lorenzo Pieralisi , Sudeep Holla , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Adrien Thierry , Brian Masney , linux-rt-users@vger.kernel.org References: <20221219151503.385816-1-krzysztof.kozlowski@linaro.org> <20221219151503.385816-3-krzysztof.kozlowski@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/01/2023 12:00, Sebastian Andrzej Siewior wrote: > On 2022-12-19 16:15:00 [+0100], Krzysztof Kozlowski wrote: >> The PSCI cpuidle power domain in power_off callback uses >> __this_cpu_write() so it is PREEMPT_RT safe. This allows to use it in > > Why does __this_cpu_write() matter here? I'll reword to "not using sleeping primitives nor spinlock_t" > >> Realtime kernels and solves errors like: >> >> BUG: scheduling while atomic: swapper/2/0/0x00000002 >> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) >> Call trace: >> dump_backtrace.part.0+0xe0/0xf0 >> show_stack+0x18/0x40 >> dump_stack_lvl+0x68/0x84 >> dump_stack+0x18/0x34 >> __schedule_bug+0x60/0x80 >> __schedule+0x628/0x800 >> schedule_rtlock+0x28/0x5c >> rtlock_slowlock_locked+0x360/0xd30 >> rt_spin_lock+0x88/0xb0 >> genpd_lock_nested_spin+0x1c/0x30 >> genpd_power_off.part.0.isra.0+0x20c/0x2a0 >> genpd_runtime_suspend+0x150/0x2bc >> __rpm_callback+0x48/0x170 >> rpm_callback+0x6c/0x7c >> rpm_suspend+0x108/0x660 >> __pm_runtime_suspend+0x4c/0x8c >> __psci_enter_domain_idle_state.constprop.0+0x54/0xe0 >> psci_enter_domain_idle_state+0x18/0x2c >> cpuidle_enter_state+0x8c/0x4e0 >> cpuidle_enter+0x38/0x50 >> do_idle+0x248/0x2f0 >> cpu_startup_entry+0x24/0x30 >> secondary_start_kernel+0x130/0x154 >> __secondary_switched+0xb0/0xb4 > > This is to a sleeping lock (spinlock_t) in an IRQ-off region which > starts in do_idle(). You could describe the problem and to solution you > aim for instead pasting a backtrace into the commit description and > adding a flow in the code. I'll extend the description. > > I don't see how your commit description matches your change in code. One > might think "Oh. If I see this pattern, I need an irqsafe lock to fix > it". Best regards, Krzysztof