[PATCH AUTOSEL 6.16-5.4] ipmi: Use dev_warn_ratelimited() for incorrect message warnings

[Sasha Levin <sashal@kernel.org>]

From: Breno Leitao <leitao@debian.org>

[ Upstream commit ec50ec378e3fd83bde9b3d622ceac3509a60b6b5 ]

During BMC firmware upgrades on live systems, the ipmi_msghandler
generates excessive "BMC returned incorrect response" warnings
while the BMC is temporarily offline. This can flood system logs
in large deployments.

Replace dev_warn() with dev_warn_ratelimited() to throttle these
warnings and prevent log spam during BMC maintenance operations.

Signed-off-by: Breno Leitao <leitao@debian.org>
Message-ID: <20250710-ipmi_ratelimit-v1-1-6d417015ebe9@debian.org>
Signed-off-by: Corey Minyard <corey@minyard.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit is an excellent candidate for backporting to stable kernel
trees for the following reasons:

1. **Fixes a Real User-Impacting Bug**: The commit addresses log
   flooding during BMC firmware upgrades or when BMC is temporarily
   offline. This is a practical operational issue that affects
   production systems, especially in large deployments where BMC
   maintenance is routine.

2. **Minimal and Safe Change**: The change is trivial - simply replacing
   `dev_warn()` with `dev_warn_ratelimited()`. This is:
   - A single-line change
   - Uses well-established kernel infrastructure (ratelimited logging)
   - Has no functional impact on the IPMI driver's operation
   - Cannot introduce regressions in driver functionality

3. **Clear Problem Statement**: The commit message clearly describes a
   specific scenario (BMC firmware upgrades) where excessive "BMC
   returned incorrect response" warnings flood system logs. This is a
   documented, reproducible issue.

4. **Follows Established Pattern**: The kernel already has precedent for
   this type of fix. Commit ca8c1c53b03b ("ipmi: rate limit ipmi
   smi_event failure message") from kernel v5.15 made similar changes to
   address log flooding in the same subsystem, and that was successfully
   integrated into stable trees.

5. **Low Risk**: The change only affects logging behavior, not the
   actual handling of IPMI messages. The error path (goto
   return_unspecified) remains unchanged, maintaining the same error
   handling logic.

6. **Addresses Operational Concerns**: In production environments with
   many servers, BMC maintenance is common. Without rate limiting, logs
   can grow excessively, potentially:
   - Filling up disk space
   - Making real issues harder to spot
   - Degrading system performance due to excessive logging I/O

7. **Code Context Shows Repeated Condition**: Looking at the code path
   (lines 4604-4615), this warning triggers when the BMC response
   doesn't match the expected NetFN and Command. During BMC firmware
   updates or reboots, this mismatch can occur repeatedly until the BMC
   comes back online, making rate limiting essential.

The change meets all criteria for stable backporting: it fixes a bug
affecting users, is small and contained, has minimal risk of regression,
and addresses a clear operational problem without introducing new
features or architectural changes.

 drivers/char/ipmi/ipmi_msghandler.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c
index 064944ae9fdc..8e9050f99e9e 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -4607,10 +4607,10 @@ static int handle_one_recv_msg(struct ipmi_smi *intf,
 		 * The NetFN and Command in the response is not even
 		 * marginally correct.
 		 */
-		dev_warn(intf->si_dev,
-			 "BMC returned incorrect response, expected netfn %x cmd %x, got netfn %x cmd %x\n",
-			 (msg->data[0] >> 2) | 1, msg->data[1],
-			 msg->rsp[0] >> 2, msg->rsp[1]);
+		dev_warn_ratelimited(intf->si_dev,
+				     "BMC returned incorrect response, expected netfn %x cmd %x, got netfn %x cmd %x\n",
+				     (msg->data[0] >> 2) | 1, msg->data[1],
+				     msg->rsp[0] >> 2, msg->rsp[1]);
 
 		goto return_unspecified;
 	}
-- 
2.39.5