lkml.org 
[lkml]   [2022]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: BUG: BISECTED: in squashfs_xz_uncompress() (Was: RCU stalls in squashfs_readahead())
    From
    On 24/11/2022 18:04, Mirsad Goran Todorovac wrote:
    > On 24. 11. 2022. 18:19, Paul E. McKenney wrote:
    >> On Thu, Nov 24, 2022 at 06:06:13PM +0100, Mirsad Goran Todorovac wrote:
    >>> On 23. 11. 2022. 20:09, Paul E. McKenney wrote:
    >>>
    >>>>>> If you build with (say) CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=200, does
    >>>>>> this still happen?
    >>>>>
    >>>>> BTW, you don't need to rebuild the kernel to change those
    >>>>> parameters; they're
    >>>>> module parameters, so can be modified on the kernel command line
    >>>>> (if needed
    >>>>> during boot) and sysfs (if only needed after boot).
    >>>>>
    >>>>> For sysfs the syntax is:
    >>>>> #!/bin/bash
    >>>>> # set rcu timeouts to specified values
    >>>>> echo 60 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
    >>>>> echo 21000 > /sys/module/rcupdate/parameters/rcu_exp_cpu_stall_timeout
    >>>>> echo 600000 > /sys/module/rcupdate/parameters/rcu_task_stall_timeout
    >>>>> grep -Hs . /sys/module/rcupdate/parameters/rcu_*_timeout
    >>>>
    >>>> Excellent point, thank you!
    >>>>
    >>>> I hope that this makes Mirsad's life easier, perhaps featuring less
    >>>> time
    >>>> waiting for kernel builds and reboots.  ;-)
    >>>
    >>> Unfortunately, the first stall and NMI occurs before any system
    >>> script or setting a /sys/module/rcupdate/parameters/*
    >>> could be executed, as second 14 of the boot process:
    >>>
    >>> [   14.320045] rcu: INFO: rcu_preempt detected expedited stalls on
    >>> CPUs/tasks: { 7-.... } 6 jiffies s: 105 root: 0x80/.
    >>> [   14.320064] rcu: blocking rcu_node structures (internal RCU debug):
    >
    > ...
    >
    >>> Probably something sensible should be set in the case of KASAN build.
    >>> This example of stall
    >>> apparently has nothing to do with squashfs_readahead().
    >>
    >> Can't have everything, I guess!
    >>
    >> How about building your kernel with CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=200?
    >> Again, mainline defaults to 21000.
    >
    > Did just that, and so far there is no modprobe stall in second 14 of
    > boot at least. Looks good.
    > Probably it is too early to say anything in general before more uptime
    > and stress load.
    >
    > BTW, the 20 for CONFIG_RCU_EXP_STALL_TIMEOUT wasn't my invention, but it
    > comes from generic
    > Ubuntu stock kernel (but without KASAN or KMEMLEAK config options):
    >
    > # grep STALL /boot/config-5.19.5-051905-generic
    > CONFIG_RCU_STALL_COMMON=y
    > # CONFIG_HEADERS_INSTALL is not set
    > CONFIG_RCU_CPU_STALL_TIMEOUT=60
    > CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=20 > #

    That has been raised as a bug, and a fix has been committed.

    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991951


    >
    > Thanks,
    > Mirsad
    >
    > --
    > Mirsad Goran Todorovac
    > Sistem inženjer
    > Grafički fakultet | Akademija likovnih umjetnosti
    > Sveučilište u Zagrebu

    \
     
     \ /
      Last update: 2022-11-24 20:32    [W:7.317 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site