On Mon, May 05, 2025 at 12:01:09PM -0300, Jason Gunthorpe wrote:
On Mon, Apr 28, 2025 at 10:41:45AM -0700, Nicolin Chen wrote:
I'm uncertain, but perhaps pr_warn_ratelimited() would be a better alternative to WARN_ON() here? WARN_ON_ONCE() generates warning messages with kernel call traces in the kernel messages, which might lead users to believe that something serious has happened in the kernel.
We already have similar practice, e.g. iommufd_hwpt_nested_alloc.
In my review, a WARN_ON/WARN_ON_ONCE means there is a kernel bug, which shouldn't occur in the first place and isn't something that
Right, so it should never happen from any ioctl path and syzkaller should never trigger it based on system call randomization
Is that what this achieves?
The functions would be still used in the kernel path. So, I think we need to retain these warnings for that. But given that an ioctl could trigger a series of WARN_ONs, WARN_ON_ONCE is something that wouldn't bother user space a lot while it provides the kernel path enough info to debug.
Thanks Nicolin