diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 07:27:52 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 07:27:52 +0000 |
| commit | d0c85e36e4de67af628d54e9ab577cc3fad7796a (patch) | |
| tree | f8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/gemma3:12b/kernel/1813045 | |
| parent | 7f4364274750eb8cb39a3e7493132fca1c01232e (diff) | |
| download | qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip | |
add deepseek and gemma results
Diffstat (limited to 'results/classifier/gemma3:12b/kernel/1813045')
| -rw-r--r-- | results/classifier/gemma3:12b/kernel/1813045 | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/kernel/1813045 b/results/classifier/gemma3:12b/kernel/1813045 new file mode 100644 index 000000000..b265cdc5f --- /dev/null +++ b/results/classifier/gemma3:12b/kernel/1813045 @@ -0,0 +1,17 @@ + +qemu-ga fsfreeze crashes the kernel + +We use mainly Cloudlinux, Debian and Centos. +We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot. +The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening: + +When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation: +1) freeze loopback fs + ---> send async reqs to loopback thread +2) freeze main fs +3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash. + +I believe this is the culprit: + +/dev/loop0 /tmp ext3 rw,nosuid,noexec,relatime,data=ordered 0 0 +/dev/loop0 /var/tmp ext3 rw,nosuid,noexec,relatime,data=ordered 0 0 \ No newline at end of file |