From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 D91E0371040 for ; Wed, 3 Jun 2026 01:37:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780450642; cv=none; b=fvpIF73AkdLSCA0WTe/yUqbnkALCHzbdFyqWlY1jXKSZWIkRZHzZBPtBZmZlySsBPMZc613I0bEZ4ghyxeL241Cxq8uUT4kseS28FJVwqVii+JqhuVxADV0/WO0yV1PZbR7AILw2tRcU01r1b05UYWB8GGYSyaDrZG8J6N0IEP8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780450642; c=relaxed/simple; bh=Lacip953XP38N5MCELHjfXIvYfPyP7yT4lfXMiE5OM8=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=NVNyb+P4CLGp9VU87f1aAlbbHFFBwW+AZAWpXl3VrQHxRvTgHiRQWDn+8lA3UiKkzn3tbk3ZeEdUpb9w2nrBegzg3TbIjM+5pPPI8qWKKrHeI6i7gyVu5rGmQqTbaFCLCEEIxa+xIfZ+ny2HLxr+xHaK1PHvx7GqRzSI15CQjIQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=cuK/BFQX; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="cuK/BFQX" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Lacip953XP38N5MCELHjfXIvYfPyP7yT4lfXMiE5OM8=; b=cuK/BFQXO76YbSLRdTPN1GL4aO bg/EXyiqpmw9ClbifPfiDaRZk84cdaPjk/XRTxvKegatIQJugFlnSB8SlrYHIeULDfZweNmBaHbSU i9GWuZT5NQgMN6HnAm/C33h0aBDCMr4D9wZcPTiw/QW0sDiXglY/z/SHJn5QziOPhxy9WTCm+Rh37 VzhbNDLVIpluO6oVltagX1v2REwBYWiKEHG5rlz4bkgJu9XxfVfa0KkIasONMV9Qcskg0XES0a88x ISwaBjTIqwRlDmKoSxPWWW3DgZfgkX7uZCZddJ44yvYLku2zDb3pxnYsvBMKwlFheyaSyC9X4Cqk7 TU1hFTzA==; Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1wUaXX-000000001Fo-1MhZ; Tue, 02 Jun 2026 21:37:03 -0400 Message-ID: <5d88d3b1bd02b6583d8b66eedd9bf1fd96e6e788.camel@surriel.com> Subject: Re: [PATCH] smp: prevent soft lockup in smp_call_function_many_cond From: Rik van Riel To: Mark Tomlinson , Madhavan Srinivasan , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Date: Tue, 02 Jun 2026 21:37:03 -0400 In-Reply-To: <20260527031618.2940365-1-mark.tomlinson@alliedtelesis.co.nz> References: <20260527031618.2940365-1-mark.tomlinson@alliedtelesis.co.nz> Autocrypt: addr=riel@surriel.com; prefer-encrypt=mutual; keydata=mQENBFIt3aUBCADCK0LicyCYyMa0E1lodCDUBf6G+6C5UXKG1jEYwQu49cc/gUBTTk33A eo2hjn4JinVaPF3zfZprnKMEGGv4dHvEOCPWiNhlz5RtqH3SKJllq2dpeMS9RqbMvDA36rlJIIo47 Z/nl6IA8MDhSqyqdnTY8z7LnQHqq16jAqwo7Ll9qALXz4yG1ZdSCmo80VPetBZZPw7WMjo+1hByv/ lvdFnLfiQ52tayuuC1r9x2qZ/SYWd2M4p/f5CLmvG9UcnkbYFsKWz8bwOBWKg1PQcaYHLx06sHGdY dIDaeVvkIfMFwAprSo5EFU+aes2VB2ZjugOTbkkW2aPSWTRsBhPHhV6dABEBAAG0HlJpayB2YW4gU mllbCA8cmllbEByZWRoYXQuY29tPokBHwQwAQIACQUCW5LcVgIdIAAKCRDOed6ShMTeg05SB/986o gEgdq4byrtaBQKFg5LWfd8e+h+QzLOg/T8mSS3dJzFXe5JBOfvYg7Bj47xXi9I5sM+I9Lu9+1XVb/ r2rGJrU1DwA09TnmyFtK76bgMF0sBEh1ECILYNQTEIemzNFwOWLZZlEhZFRJsZyX+mtEp/WQIygHV WjwuP69VJw+fPQvLOGn4j8W9QXuvhha7u1QJ7mYx4dLGHrZlHdwDsqpvWsW+3rsIqs1BBe5/Itz9o 6y9gLNtQzwmSDioV8KhF85VmYInslhv5tUtMEppfdTLyX4SUKh8ftNIVmH9mXyRCZclSoa6IMd635 Jq1Pj2/Lp64tOzSvN5Y9zaiCc5FucXtB9SaWsgdmFuIFJpZWwgPHJpZWxAc3VycmllbC5jb20+iQE +BBMBAgAoBQJSLd2lAhsjBQkSzAMABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDOed6ShMTe g4PpB/0ZivKYFt0LaB22ssWUrBoeNWCP1NY/lkq2QbPhR3agLB7ZXI97PF2z/5QD9Fuy/FD/jddPx KRTvFCtHcEzTOcFjBmf52uqgt3U40H9GM++0IM0yHusd9EzlaWsbp09vsAV2DwdqS69x9RPbvE/Ne fO5subhocH76okcF/aQiQ+oj2j6LJZGBJBVigOHg+4zyzdDgKM+jp0bvDI51KQ4XfxV593OhvkS3z 3FPx0CE7l62WhWrieHyBblqvkTYgJ6dq4bsYpqxxGJOkQ47WpEUx6onH+rImWmPJbSYGhwBzTo0Mm G1Nb1qGPG+mTrSmJjDRxrwf1zjmYqQreWVSFEt26tBpSaWsgdmFuIFJpZWwgPHJpZWxAZmIuY29tP okBPgQTAQIAKAUCW5LbiAIbIwUJEswDAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQznneko TE3oOUEQgAsrGxjTC1bGtZyuvyQPcXclap11Ogib6rQywGYu6/Mnkbd6hbyY3wpdyQii/cas2S44N cQj8HkGv91JLVE24/Wt0gITPCH3rLVJJDGQxprHTVDs1t1RAbsbp0XTksZPCNWDGYIBo2aHDwErhI omYQ0Xluo1WBtH/UmHgirHvclsou1Ks9jyTxiPyUKRfae7GNOFiX99+ZlB27P3t8CjtSO831Ij0Ip QrfooZ21YVlUKw0Wy6Ll8EyefyrEYSh8KTm8dQj4O7xxvdg865TLeLpho5PwDRF+/mR3qi8CdGbkE c4pYZQO8UDXUN4S+pe0aTeTqlYw8rRHWF9TnvtpcNzZw== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-05-27 at 15:16 +1200, Mark Tomlinson wrote: > Using the PowerPC P2040 (e500mc) CPU, soft lockups can occasionally > be > seen in smp_call_function_many_cond(). The conclusion is that this > CPU > does not process the doorbell interrupt while in a data-storage (MMU) > exception. If more than one CPU in a multi core environment is > calling > this function at the same time, it is possible for a deadlock to > occur. Does that mean if the CPU in question does not call smp_call_function_many_cond() while in a data-storage exception, the system might still hang? Not that there's anything wrong with reducing the frequency of what is (presumably) an already pretty rare hang. >=20 > The fix for this is to call flush_smp_call_function_queue() before > waiting for responses from other CPUs. If there is something in the > queue, this is a good time to process it before busy-waiting on other > CPUs. On other architectures this call will quickly do nothing, as > the > queue will be empty. Agreed, this does look completely harmless at worst, and does look like it would at the very least improve that e500mc issue. >=20 > Signed-off-by: Mark Tomlinson >=20 Reviewed-by: Rik van Riel --=20 All Rights Reversed.