Bug 216493
Summary: | [REGRESSION] Panic on __kernfs_remove (probably after 5.19.8) | ||
---|---|---|---|
Product: | Memory Management | Reporter: | Igor Raits (igor.raits) |
Component: | Other | Assignee: | Andrew Morton (akpm) |
Status: | NEEDINFO --- | ||
Severity: | normal | CC: | kernel, regressions |
Priority: | P1 | ||
Hardware: | Intel | ||
OS: | Linux | ||
Kernel Version: | 5.19.8 | Tree: | Mainline |
Subsystem: | Regression: | Yes |
Description
Igor Raits
2022-09-15 15:53:22 UTC
Would be great if you ran regression testing using git bisect. I think I am running into the same problem. I already reported it on arch https://bugs.archlinux.org/task/75925 The problem occurs when running docker (run, pull, prune) rather fast. Maybe it is triggered by concurrent calls like discussed in the linked discussion? It occurs on 5.19.8 and 5.19.9. The systems works fine when rolling back to 5.19.7. Do you still encounter the problem in the latest 5.19.y kernels? FWIW, there is a patch in Linux-next fixing concurrent calls to kernfs_remove_by_name_ns() for the same file: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4abc99652812a2ddf932f137515d5c5a04723538 I wonder if it might help, but it's just a wild guess, this is not my area of expertise. Igor, Patrick, any news? I cannot reproduce the error anymore. However, in my specific case with docker, ditching the devicemapper storage driver in favor of overlay2 helped to circumvent the problem. I tried to setup a VM that is similar to my setup, but I could not reproduce the problem. |