y.mi. (she/they)
y.mi. (she/they)
will you merge rc5,rc6 to your testing tree @koverstreet ?
No, not fixed. You never ever pressed sysrq+m or sysrq+f to just test your own changes? Sad.
@koverstreet ``` [ 92.636534][ T179] sysrq: Show Memory [ 92.636546][ T179] Mem-Info: [ 92.636551][ T179] active_anon:0 inactive_anon:140 isolated_anon:0 [ 92.636551][ T179] active_file:1186 inactive_file:3939 isolated_file:0 [ 92.636551][ T179] unevictable:4 dirty:1 writeback:0...
It's not the same, but it's obvious that somewhere null pointer is passed to function(s) that in the end dereferences it
In the build where you tested, you had config memcg on?
oh ok, I changed ``` seq_buf_puts(out, shrinker->name); seq_buf_putc(out, '\n'); ``` to ``` if (unlikely(!shrinker->name)) seq_buf_puts(out, "(null)"); else seq_buf_puts(out, shrinker->name); seq_buf_putc(out, '\n'); ``` Will test when I can
@koverstreet works!
@koverstreet but we take shrinkers lock
Considering that it always happens (I did lots of attempts), I don't think that it can be a race with removal/add of shrinker
I'll try a torture test using `while true; do (echo m > /proc/sysrq-trigger); done` in conjunction with the null check, to be more confident that we can rely on it...