On Fri, Oct 20, 2023 at 05:11:24PM +0300, Dan Carpenter wrote: > On Fri, Oct 20, 2023 at 02:55:37PM +0300, Ville Syrjälä wrote: > > On Fri, Oct 20, 2023 at 02:39:04PM +0300, Dan Carpenter wrote: > > > On Wed, Oct 18, 2023 at 05:17:42PM +0300, Dan Carpenter wrote: > > > > drivers/gpu/drm/drm_rect.c > > > > 134 static int drm_calc_scale(int src, int dst) > > > > 135 { > > > > 136 int scale = 0; > > > > 137 > > > > 138 if (WARN_ON(src < 0 || dst < 0)) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > These days, with automated fuzz testing, this WARN_ON() is problematic. > > > > WARN() is considered a kernel bug, and pr_warn() is the hip new way to > > > > alert the user about issues. > > > > > > Btw, a lot of people (Greg claims it's the majority of Linux users) > > > these days have run kernels with panic on warn enabled so that's another > > > reason to avoid using WARN_ON() for stuff that it known to be possible. > > > > This is not possible, unless there is a serious bug somewhere else. > > Ah. That's fine then. This is kunit which is deliberately triggering > the WARN_ON(). The KASAN testing also deliberately triggers WARN_ON()s > so it's a necessary thing. > > I just wonder if there is some way to mark these kinds of warnings as > expected. Perhaps we could add a comment in the kunit test?
Is there some kind of tool which looks at a dmesg and can separate out the intentional stack traces from the others? regards, dan carpenter