On Wednesday, 14 January 2026 09:19:36 CET Kamil Konieczny wrote:
> Hi Janusz,
> On 2026-01-13 at 16:59:36 +0100, Janusz Krzysztofik wrote:
> > The smem-oom subtest can expectedly result in oom-killer being triggered,
> > which then dumps a call trace from a process that triggered it.  If that
> > happens to be a process that executes drm or i915 functions then the call
> > trace dump contains lines recognized by igt_runner running in piglit mode
> > as potential warnings.  If severity of the call trace dump messages is
> > NOTICE or higher, which isn't unlikely, then a dmesg-warn result is
> > reported despite successful completion of the subtest.
> > 
> > Fortunately, severity of those call trace dump messages depends on kernel
> > default log level which can be controlled from user space over sysctl.
> > 
> > To avoid false failure reports, relax kernel default log level to INFO so
> > those log lines are ignored by igt_runner in piglit mode at an expense of
> > call traces from real issues potentially detected by the subtest not
> > contributing to the igt_runner reported result.  Since those call traces
> > are still available to developers, only submitted with reduced severity,
> > that shouldn't hurt as long as the igt_runner still abandons further
> > execution and reports an abort result on a kernel taint.
> > 
> > v3: Move cleanup to an exit handler in case we are killed (Kamil).
> > v2: Move default log level setup inside subtest smem-oom (Kamil),
> >   - move cleanup there as well.
> > 
> > Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5493
> > Cc: Kamil Konieczny <[email protected]>
> > Signed-off-by: Janusz Krzysztofik <[email protected]>
> > ---
> >  tests/intel/gem_lmem_swapping.c | 61 +++++++++++++++++++++++++++++++--
> >  1 file changed, 59 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tests/intel/gem_lmem_swapping.c 
> > b/tests/intel/gem_lmem_swapping.c
> > index adae26716c..e68d318fd0 100644
> > --- a/tests/intel/gem_lmem_swapping.c
> > +++ b/tests/intel/gem_lmem_swapping.c
> > @@ -661,6 +661,21 @@ static void gem_leak(int fd, uint64_t alloc)
> >     gem_madvise(fd, handle, I915_MADV_DONTNEED);
> >  }
> >  
> > +static FILE *printk;
> > +static int console_log_level, default_log_level;
> > +
> > +static void printk_exit_handler(int sig)
> > +{
> > +   if (printk) {
> > +           rewind(printk);
> > +           igt_debug_on(fprintf(printk, "%d %d",
> > +                                console_log_level,
> > +                                default_log_level) != 3);
> > +           fclose(printk);
> > +           printk = NULL;
> > +   }
> > +}
> > +
> 
> I would prefer just using write() with already prepared buf,
> not fprintf, as this is for at_exit path and should be fast,

I see your point.
To keep it simple, how about switching to open() + dprintf()?

Thanks,
Janusz


> but this is maybe a matter of style.
> 
> Reviewed-by: Kamil Konieczny <[email protected]>
> 
> Regards,
> Kamil
> 
> >  static int *lmem_done;
> >  
> >  static void smem_oom_exit_handler(int sig)
> > @@ -861,8 +876,50 @@ int igt_main_args("", long_options, help_str, 
> > opt_handler, NULL)
> >     }
> >  
> >     igt_describe("Exercise local memory swapping during exhausting system 
> > memory");
> > -   dynamic_lmem_subtest(region, regions, "smem-oom")
> > -           test_smem_oom(i915, ctx, region);
> > +   igt_subtest_with_dynamic("smem-oom") {
> > +           unsigned int i;
> > +
> > +           /*
> > +            * This subtest can result in oom-killer being triggered, which
> > +            * then dumps a call trace from a process that triggered it.
> > +            * If that happens to be a process that executes drm or i915
> > +            * functions then the call trace dump contains lines recognized
> > +            * by igt_runner as warnings and a dmesg-warn result is
> > +            * reported.  To avoid false failure reports, relax kernel
> > +            * default log level to INFO for those lines to be ignored by
> > +            * igt_runner in piglit mode, at an expense of call traces from
> > +            * potential real issues not contributing to the igt_runner
> > +            * reported result.  Since those call traces are still available
> > +            * to developers, only displayed with relaxed severity, that
> > +            * shouldn't hurt as long as igt_runner still abandons further
> > +            * execution and reports an abort result on a kernel taint.
> > +            */
> > +           printk = fopen("/proc/sys/kernel/printk", "r+");
> > +           if (!igt_debug_on(!printk)) {
> > +                   if (!igt_debug_on(fscanf(printk, "%d %d",
> > +                                            &console_log_level,
> > +                                            &default_log_level) != 2) &&
> > +                       default_log_level < 6) {
> > +                           igt_install_exit_handler(printk_exit_handler);
> > +
> > +                           rewind(printk);
> > +                           igt_debug_on(fprintf(printk, "%d 6",
> > +                                                console_log_level) != 3);
> > +                   } else {
> > +                           fclose(printk);
> > +                           printk = NULL;
> > +                   }
> > +           }
> > +
> > +           for (i = 0; i < regions->num_regions; i++) {
> > +                   region = &regions->regions[i];
> > +                   if (region->region.memory_class == 
> > I915_MEMORY_CLASS_DEVICE)
> > +                           igt_dynamic_f("lmem%u", 
> > region->region.memory_instance)
> > +                                   test_smem_oom(i915, ctx, region);
> > +           }
> > +
> > +           printk_exit_handler(0);
> > +   }
> >  
> >     igt_fixture() {
> >             intel_allocator_multiprocess_stop();
> 




Reply via email to