-
Notifications
You must be signed in to change notification settings - Fork 0
/
rss.xml
40 lines (40 loc) · 3.28 KB
/
rss.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Rustam Kovhaev's blog</title>
<link>https://rustylife.github.io/</link>
<description>Recent content on Rustam Kovhaev's blog</description>
<generator>Hugo</generator>
<language>en</language>
<lastBuildDate>Sun, 24 Nov 2024 00:00:00 +0000</lastBuildDate>
<atom:link href="https://rustylife.github.io/rss.xml" rel="self" type="application/rss+xml" />
<item>
<title>Debugging a superblock percpu_rw_semaphore deadlock</title>
<link>https://rustylife.github.io/2024/11/24/io_uring.html</link>
<pubDate>Sun, 24 Nov 2024 00:00:00 +0000</pubDate>
<guid>https://rustylife.github.io/2024/11/24/io_uring.html</guid>
<description>There are many ways you can go about analyzing a kernel deadlock.
While some prefer using lockdep, I find it easier to analyze a kernel dump file.
The issue that has recently come up is this:
[ 2335.487579] INFO: task mariadbd:1914 blocked for more than 122 seconds. ... [ 2335.489157] INFO: task peer local sock:2449 blocked for more than 122 seconds. The kernel watchdog has detected that the tasks with PID 2449 and 1914 stopped making forward progress.</description>
</item>
<item>
<title>Debugging a kdump kernel crash</title>
<link>https://rustylife.github.io/2023/10/19/veeamsnap-kernel-crash.html</link>
<pubDate>Thu, 19 Oct 2023 00:00:00 +0000</pubDate>
<guid>https://rustylife.github.io/2023/10/19/veeamsnap-kernel-crash.html</guid>
<description>Debugging a kernel bug could be a challenging task.
Let&rsquo;s say a bug lies within the memory management subsystem, slub allocator or page allocator. Depending on the debugging tools that you have chosen for troubleshooting, these tools might be calling into the mm subsystem, because they themselves need to allocate memory to show you the trace/debug output that you are interested in, and, therefore, they might be hitting the very same bug and not producing any trace/debug output at all.</description>
</item>
<item>
<title>Debugging a futex crash</title>
<link>https://rustylife.github.io/2023/08/15/futex-crash.html</link>
<pubDate>Tue, 15 Aug 2023 00:00:00 +0000</pubDate>
<guid>https://rustylife.github.io/2023/08/15/futex-crash.html</guid>
<description>I was enjoying my quiet afternoon, when an interesting application core has been submitted to me for research.
And what made it interesting is that I did not have to load proprietary/private symbols for the application that crashed.
The first thing to check is whether the file is indeed a core file, and it turns out it is not.
rusty@nuc10:~/futex$ file veeamagent.0.crash veeamagent.0.crash: ASCII text, with very long lines (44565) rusty@nuc10:~/futex$ head veeamagent.</description>
</item>
<item>
<title>Linux kernel stack, PID 0 swapper processes</title>
<link>https://rustylife.github.io/2022/01/06/linux-kernel-stack.html</link>
<pubDate>Thu, 06 Jan 2022 00:00:00 +0000</pubDate>
<guid>https://rustylife.github.io/2022/01/06/linux-kernel-stack.html</guid>
<description>https://www.youtube.com/watch?v=Pe8FiIVAwfY</description>
</item>
</channel>
</rss>