Zypper triggers kernel NULL pointer dereference
OS: Tumbleweed 20250227 kernel: 6.13.4-1-default Zypp-main hangs, because of "kernel NULL pointer dereference": Case 1: https://paste.opensuse.org/pastes/af84e835da06 Case 2: https://paste.opensuse.org/pastes/9c986532f7bf I'll try to reboot and see if it's reproducible after that.
W dniu 2.03.2025 o 11:29, Adam Mizerski via openSUSE Factory pisze:
No problems after reboot. I have noticed, that recently the kernel became quite unstable after resuming from sleep. Often USB devices become unresponsive. Now this. It's hard to pinpoint the issue and create a reasonable bug report, and yet the experience is bad. And it's always after resuming from sleep.
Am 02.03.25 um 11:46 schrieb Adam Mizerski via openSUSE Factory:
Doesn't look zypper related but filesystem related to my untrained eye...
Well, memory corruption after suspend is nothing unheard of, maybe something is not properly saved / restored. But it might be totally unrelated. I'd suggest opening a bug and attaching your oops backtraces, also mention that it happens after suspend , maybe this will look familiar to a kernel developer, even if they are not reading factory@ Actually, Joe Salmeri's thread "TW 20250216 Kernel 6.13.2 USB issues" looks similar -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 3/2/25 7:39 AM, Stefan Seyfried via openSUSE Factory wrote:
Quick Summary: Kernel 6.12.8 had major USB issues which corrupted USB devices which do not occur with Kernel 6.11.8. Looks of complaints about kernel 6.12.8 problems. I did not have the USB corruption issues when I tried Kernel 6.13.2 but it has encountered the page-not-present issues 3 times for me when running a python program which reads lots of files from USB devices. I have tried all sorts of things to push the system and consume all the memory, like 12 kvms all running doing system updates, consuming almost all the memory ( 62 of 64 GB ) with files in /tmp and then running the python program reading all those files and NOTHING else causes the page not present issue except the combination of kernel 6.13.2 + python program reading lots of the same files from the USB device. Booting back to kernel 6.11.8 all issues go away every time. I modified zypper multiversion to also keep kernel 6.11.8 along with 4 other kernels until this is sorted out. -- Regards, Joe
On Sunday 2025-03-02 11:46, Adam Mizerski via openSUSE Factory wrote:
If I have to pitch in a theory: After wakeup, the disk does not come back (or so), the backing inode in memory "erroneously" disappears as a result, even though it probably should not have, and then in the innards of a stat(2) system call, it trips over NULL. int security_inode_getattr(const struct path *path) { if (unlikely(IS_PRIVATE(d_backing_inode(path->dentry)))) return 0; return call_int_hook(inode_getattr, path); } Now a wild theory: is selinux active, and if so, does the problem go away when it's turned off?
I have been having problems getting late 6.12 and each of the 6.13 kernels to revive the display after suspending . . . . There do seem to be issues with suspending in these recent kernels. Bug report filed some weeks back on the kernel. F
W dniu 2.03.2025 o 11:29, Adam Mizerski via openSUSE Factory pisze:
No problems after reboot. I have noticed, that recently the kernel became quite unstable after resuming from sleep. Often USB devices become unresponsive. Now this. It's hard to pinpoint the issue and create a reasonable bug report, and yet the experience is bad. And it's always after resuming from sleep.
Am 02.03.25 um 11:46 schrieb Adam Mizerski via openSUSE Factory:
Doesn't look zypper related but filesystem related to my untrained eye...
Well, memory corruption after suspend is nothing unheard of, maybe something is not properly saved / restored. But it might be totally unrelated. I'd suggest opening a bug and attaching your oops backtraces, also mention that it happens after suspend , maybe this will look familiar to a kernel developer, even if they are not reading factory@ Actually, Joe Salmeri's thread "TW 20250216 Kernel 6.13.2 USB issues" looks similar -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 3/2/25 7:39 AM, Stefan Seyfried via openSUSE Factory wrote:
Quick Summary: Kernel 6.12.8 had major USB issues which corrupted USB devices which do not occur with Kernel 6.11.8. Looks of complaints about kernel 6.12.8 problems. I did not have the USB corruption issues when I tried Kernel 6.13.2 but it has encountered the page-not-present issues 3 times for me when running a python program which reads lots of files from USB devices. I have tried all sorts of things to push the system and consume all the memory, like 12 kvms all running doing system updates, consuming almost all the memory ( 62 of 64 GB ) with files in /tmp and then running the python program reading all those files and NOTHING else causes the page not present issue except the combination of kernel 6.13.2 + python program reading lots of the same files from the USB device. Booting back to kernel 6.11.8 all issues go away every time. I modified zypper multiversion to also keep kernel 6.11.8 along with 4 other kernels until this is sorted out. -- Regards, Joe
On Sunday 2025-03-02 11:46, Adam Mizerski via openSUSE Factory wrote:
If I have to pitch in a theory: After wakeup, the disk does not come back (or so), the backing inode in memory "erroneously" disappears as a result, even though it probably should not have, and then in the innards of a stat(2) system call, it trips over NULL. int security_inode_getattr(const struct path *path) { if (unlikely(IS_PRIVATE(d_backing_inode(path->dentry)))) return 0; return call_int_hook(inode_getattr, path); } Now a wild theory: is selinux active, and if so, does the problem go away when it's turned off?
I have been having problems getting late 6.12 and each of the 6.13 kernels to revive the display after suspending . . . . There do seem to be issues with suspending in these recent kernels. Bug report filed some weeks back on the kernel. F
participants (5)
-
Adam Mizerski -
Fritz Hudnut -
Jan Engelhardt -
Joe Salmeri -
Stefan Seyfried