Probably spitting WARNs on user supplied output looks more like a debug approach. So if this WARN_ONCE is breaking some tests we should just remove that instead of changing it into pr_warn_ratelimited.

On 7/6/26 14:11, Andrey Zhadchenko wrote:
I don't like that. Customers do not run with panic_on_warn. If this fails in our test environment, that's actually great (it means something went very wrong). pr_warn_ratelimited is worse than WARN_ONCE regarding intentional spamming.

On 7/6/26 12:59, Konstantin Khorenko wrote:
blk_cbt_ioctl() reads abi_version straight from the ioctl argument and
WARN_ONCE()s if it does not match CBT_ABI_VERSION. The value is fully
userspace-controlled, so any process issuing a BLKCBT* ioctl with a
stale/newer struct taints the kernel, dumps a backtrace, and can panic a
host that runs with panic_on_warn. Downgrade to pr_warn_ratelimited();
the -EOPNOTSUPP return is the actual contract.

Fixes: 6e42f62a2c88 ("block/blk-cbt: introduce ABI versioning")
Feature: cbt: changed block tracking (for backup)
https://virtuozzo.atlassian.net/browse/VSTOR-137234
Signed-off-by: Konstantin Khorenko <[email protected]>
---
  block/blk-cbt.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/blk-cbt.c b/block/blk-cbt.c
index 90219f58f1ae..91a888770411 100644
--- a/block/blk-cbt.c
+++ b/block/blk-cbt.c
@@ -1093,8 +1093,8 @@ int blk_cbt_ioctl(struct block_device *bdev, unsigned cmd, char __user *arg)
          return -EFAULT;
      if (abi_version != CBT_ABI_VERSION) {
-        WARN_ONCE(1, "blk-cbt ABI mimatch: kernel has %d, userspace uses %d",
-              CBT_ABI_VERSION, abi_version);
+        pr_warn_ratelimited("blk-cbt: ABI mismatch: kernel has %d, userspace uses %d\n",
+                    CBT_ABI_VERSION, abi_version);
          return -EOPNOTSUPP;
      }

_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel

_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel

Reply via email to