Bug 211173

Summary: zram device with zstd creation fails with enomem
Product: Memory Management Reporter: Zbigniew Jędrzejewski-Szmek (zbyszek)
Component: Page AllocatorAssignee: Andrew Morton (akpm)
Status: NEW ---    
Severity: normal CC: elxreno
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.8.15-301.fc33.x86_64 Subsystem:
Regression: No Bisected commit-id:

Description Zbigniew Jędrzejewski-Szmek 2021-01-13 11:35:14 UTC
I'm forwarding this on behalf of a user. I can't reproduce the issue myself.
Creation of a zram device (with zstd as the compression alg) occasionally
fails:

https://github.com/systemd/zram-generator/issues/50
https://github.com/systemd/zram-generator/issues/53

Jan 13 09:59:39 vultr.guest systemd[1]: Starting Create swap on /dev/zram3...
Jan 13 09:59:39 vultr.guest kernel: Can't allocate a compression stream
Jan 13 09:59:39 vultr.guest kernel: zram: Cannot initialise zstd compressing backend
Jan 13 09:59:39 vultr.guest zram-generator[997]: Error: Failed to configure disk size into /sys/block/zram3/disksize
Jan 13 09:59:39 vultr.guest zram-generator[997]: Caused by:
Jan 13 09:59:39 vultr.guest zram-generator[997]:     Cannot allocate memory (os error 12)

reported with kernels 5.8.14-300.fc33.x86_64, 5.8.15-301.fc33.x86_64.

zstd seems to be the requirement for this bug to occur. zram is enabled by default in Fedora,
and there haven't been reports of this issue occurring more frequently. Unless explicitly
configured, the kernel default lzo-lre is used, and the bug doesn't seem to occur then.

I wrote a patch to explicitly do 'modprobe crypto-zstd' before trying to configure the device,
but it has no effect. (And the error is ENOMEM, and not EINVAL which would happen if the
alg was not avaialable.)
Comment 1 Michael 2021-01-13 17:43:36 UTC
I have the same problem with kernel 5.10.7-200.fc33.x86_64.

Workaround: add module `zstd` to file `/etc/modules-load.d/99-zstd.conf` and run `dracut --force`.
Comment 2 Andrew Morton 2021-01-13 23:55:16 UTC
The kernel will normally emit a stack backtrace when memory allocation fails.  Is that available?  It might require tweaking `dmesg -n' to get it to come out...