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
