On Sun, Jan 11, 2026 at 07:38:50PM -0000, Stuart Henderson wrote: > On 2026-01-10, Crystal Kolipe <[email protected]> wrote: > > Besides, the proposed 'change' on the linux kernel side seems to be just to > > rate-limit the reporting of the errors. That might be the only realistic > > option open to the developers there, since they are only concerned with the > > kernel itself. > > It's already rate-limited on Linux, that proposal is to change to warning > once only.
Yes, I worded that badly, I was thinking more of 'rate limiting' in the general sense, I.E. to just once, but you are right it's already using dev_warn_ratelimited(). > Our implementation of the *_ratelimited logging functions in DRM is > currently just "printf" so using ratecheck(9) would be an improvement. Maybe, but it seems like a cludge more appropriate for the linux kernel than OpenBSD: If it's just one buggy userland program that triggers this in 99% of cases, and that can be identified and fixed, the log flooding problem goes away for most cases anyway. I remain curious about the way the code we're discussing simply truncates the buffer if it is too large, (so presumably it's considered that 'nothing bad can happen' in this case). Is that really the case? Do hardware implementations of the same check not discard the whole overflowing buffer?
