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
