#1141355 linux-image-6.1.0-49-amd64: procfs deadlock triggered by drop_caches on 6.1.0-49-amd64 (regression from 6.1.0-37)

Package:
src:linux
Source:
src:linux
Submitter:
Julian Rilli
Date:
2026-07-03 18:31:03 UTC
Severity:
normal
Tags:
#1141355#5
Date:
2026-07-03 09:29:13 UTC
From:
To:
Dear Maintainer,

After booting into 6.1.0-49-amd64, commands that access /proc or the
kernel ring buffer (dmesg -T, ps -ef, systemctl status) block
indefinitely, making the SSH session unresponsive.

The issue is triggered by:
  sync; echo 3 > /proc/sys/vm/drop_caches
(run via cronjob every hour)

This is a regression. Kernel 6.1.0-37-amd64 ran for 396 days with the
identical cronjob and configuration without any issues.

Steps to reproduce:
  1. Boot 6.1.0-49-amd64
  2. Run: sync; echo 3 > /proc/sys/vm/drop_caches
  3. Run: dmesg -T (or ps -ef, or systemctl status ssh)
  4. Command blocks indefinitely, SSH session becomes unresponsive

Expected: Commands complete normally (as with 6.1.0-37)
Actual: Commands block, require new SSH session or reboot

Workaround: Boot 6.1.0-37-amd64 or disable drop_caches cronjob.

Environment:
- Hypervisor: KVM/QEMU (i440FX + PIIX)
- Block device: virtio_blk (vda, 1.5 TB ext4)
- RAM: 20 GB (524 MB used at time of issue)
- CPUs: 6
- Docker installed (containers running)
- tinc VPN running
- No D-state processes visible during hang
- No filesystem errors (errors_count = 0)
- /proc/stat, /proc/loadavg still readable durin

#1141355#10
Date:
2026-07-03 18:28:19 UTC
From:
To:
Control: tag -1 moreinfo

How long did you actually wait, approximately?

vm.drop_caches is an API for testing and not for production use, so I
think it is a good idea to disable that cron job anyway.


[...]
[...]

Please provide a kernel log showing use of drop_caches and the
subsequent hang.

Also, the next version (package version 6.1.176-1, kernel version string
6.1.0-50-amd64) will be available very soon, so please test whether that
fixes this for you.

Ben.