zram-generator: Unable to start swap-create@ service with zstd compressor

Thank you for the extensive investigation. You are right, my code was checking the wrong thing.

This doesn’t mean that there is no kernel bug — the kernel does load the crypt module when necessary, so none of this should be necessary. But if it helps, then that’s good. Let’s continue the discussion in the pull request.

It doesn’t really matter if it’s Fedora or Ubuntu: everybody is using the same upstream kernel. Please sign up under https://bugzilla.kernel.org/show_bug.cgi?id=211173 if you can, this will help the bug get resolved. I’ll close this here, since it doesn’t seem to be a problem with the generator itself.

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]:     Cannot allocate memory (os error 12)

OK, so the issue is not because zstd is not loaded, but because kzalloc fails. The error message is from

	comp = zcomp_create(zram->compressor);
	if (IS_ERR(comp)) {
		pr_err("Cannot initialise %s compressing backend\n",
				zram->compressor);
		err = PTR_ERR(comp);
		goto out_free_meta;
	}

which calls

struct zcomp *zcomp_create(const char *compress)
{
	struct zcomp *comp;
	int error;

	if (!zcomp_available_algorithm(compress))
		return ERR_PTR(-EINVAL);

	comp = kzalloc(sizeof(struct zcomp), GFP_KERNEL);
	if (!comp)
		return ERR_PTR(-ENOMEM);

	comp->name = compress;
	error = zcomp_init(comp);
	if (error) {
		kfree(comp);
		return ERR_PTR(error);
	}
	return comp;
}

If the compression wasn’t available, EINVAL would be returned. We get ENOMEM either from kzalloc() or from zcomp_init(). Can you report a kernel bugzilla with your kernel version and other details?

I raised selinux, but actually I don’t think it can be related, since there’s no explicit modprobe involved. (And even if an explicit modprobe is done, the generator is running in init_t context, so it should have privs to do modprobe.)

I think a race condition, i.e. a kernel bug, is the most likely explanation. The PR would resolve the issue in that case.

I don’t get how it would be a race condition?

At the moment when echo zstd >/sys/block/zram0/comp_algorithm returns, I expect zstd module to be loaded by the kernel. This is what happens on my machines, but it clearly doesn’t always work this way.

Thanks for the reply! modprobe -r zram && modprobe zram didn’t work for me, but modprobe zstd did! Maybe we should detect this error, and show a possible solution instead of displaying Cannot allocate memory?

it’s just the configurator works from my console, but the service refuses to start.

I assume you checked the closed issue on zstd with same error message, but if not, you might want to look at this.