Can't apply udev rules when ckb-next-daemon is running
Closed, InvalidPublic
Actions

Assigned To

None

Authored By

	Tzigamm
	Feb 15 2020, 12:05 PM

Description

I've been having this problem for a while now, after each update when eopkg tried to apply the udev rules I got this error message:

 [✓] Reloading udev rules                                               success
 [✗] Applying udev rules                                                 failed

A copy of the command output follows:

Failed to write 'change' to '/sys/devices/virtual/input/input56/uevent': Cannot allocate memory
Failed to write 'change' to '/sys/devices/virtual/input/input57/uevent': Cannot allocate memory

I figured it must have been a kernel bug or something so I didn't bother looking into it. But it been multiple months now so I looked at what those two virtual devices are:

tzig@solus-arrr ~ $ cat /sys/devices/virtual/input/input56/name 
ckb1: Corsair Gaming SABRE RGB Laser Mouse vKB
tzig@solus-arrr ~ $ cat /sys/devices/virtual/input/input57/name 
ckb1: Corsair Gaming SABRE RGB Laser Mouse vM

I unplugged my mouse and started sudo usysconf run -f, it applied rules without any issue
I then tried to sudo systemctl stop ckb-next-daemon, plugged in my mouse and ran sudo usysconf run -f again, usysconf applied udev rules fine.

Looked on ckb-next github for an issue resembling mine, I can't find any so it might be Solus specific

Related Objects

Mentioned In: T10245: Apply udev rules fails
Mentioned Here: D8855: Fixes #T8734 Can't apply udev rules when ckb-next-daemon is running

Event Timeline

Tzigamm created this task.Feb 15 2020, 12:05 PM

Herald added a project: Lacks Project. · View Herald TranscriptFeb 15 2020, 12:05 PM

On the next update that this happens, could you please provide the output from running:

sudo udevadm control --reload-rules

I want to make sure we aren't missing any output from usysconf.

DataDrake moved this task from Backlog to System and Configuration Fixes on the Software board.Feb 15 2020, 3:17 PM

I'm also having this issue right now when installing or uninstalling packages, and of course running usysconf.

sudo udevadm control --reload-rules

doesn't provide any output when I run it.

Just tried your command DataDrake, same as Hawkeye, no output whatsoever

Happens at udevadm trigger, not at reloading the rules.

You can reproduce it any time having ckb-next-daemon running and executing "sudo udevadm trigger".

Though, you see two errors, with the latest git version of ckb-next it's reduced to one error for me (had two before as well).

I opened a bug report at ckb-next, since I didn't find anything which could trigger this except for ckb-next-daemon returning something udevadm trigger does not like during the process. Maybe the people there can shed some light on this.
https://github.com/ckb-next/ckb-next/issues/581

Talked to the ckb-next people, very helpful lot!

Short trace (by the ckb-next people), where it sounds like we have an issue in the kernel itself or at least with the message passed to the kernel.

[40677.318139] ------------[ cut here ]------------
[40677.318141] add_uevent_var: buffer size too small
[40677.318183] WARNING: CPU: 2 PID: 25639 at lib/kobject_uevent.c:670 add_uevent_var+0xfa/0x110
[40677.318183] Modules linked in: pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc kvm_amd kvm mxm_wmi irqbypass rc_pixelview snd_emu10k1_synth snd_emux_synth crct10dif_pclmul snd_seq_midi_emul crc32_pclmul snd_seq_virmidi ghash_clmulni_intel tuner_simple tuner_types snd_emu10k1 snd_hda_codec_hdmi joydev tuner input_leds tda7432 snd_hda_intel aesni_intel tvaudio snd_util_mem snd_hda_codec snd_ac97_codec bttv ac97_bus snd_hda_core aes_x86_64 glue_helper crypto_simd snd_hwdep tveeprom snd_pcm_oss videobuf_dma_sg snd_mixer_oss cryptd videobuf_core tea575x snd_pcm amdgpu rc_core v4l2_common videodev fam15h_power mc emu10k1_gp gameport snd_seq_midi snd_seq_midi_event sp5100_tco snd_rawmidi gpu_sched snd_seq i2c_algo_bit ttm snd_seq_device drm_kms_helper snd_timer syscopyarea sysfillrect sysimgblt fb_sys_fops drm snd parport_serial soundcore wmi vhba(OE) parport_pc ppdev lp parport autofs4 hid_generic usbhid hid uas usb_storage i2c_piix4 tg3 firewire_ohci ahci
[40677.318216]  firewire_core pata_acpi libahci floppy
[40677.318220] CPU: 2 PID: 25639 Comm: udevadm Tainted: G           OE     5.3.8-uwuvyouwofty #1
[40677.318221] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./990FX Extreme4, BIOS P2.70 06/05/2014
[40677.318223] RIP: 0010:add_uevent_var+0xfa/0x110
[40677.318224] Code: 48 83 c4 50 5b 41 5c 5d c3 48 c7 c7 c8 fe 44 8d e8 a4 ad 69 ff 0f 0b b8 f4 ff ff ff eb d2 48 c7 c7 f0 fe 44 8d e8 8f ad 69 ff <0f> 0b b8 f4 ff ff ff eb bd e8 88 aa 69 ff 0f 1f 84 00 00 00 00 00
[40677.318225] RSP: 0018:ffffa68042cf7d40 EFLAGS: 00010286
[40677.318227] RAX: 0000000000000000 RBX: ffff9573ee690000 RCX: 0000000000000006
[40677.318227] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff95751ea974d0
[40677.318228] RBP: ffffa68042cf7da0 R08: 0000000000000542 R09: 0000000000000034
[40677.318229] R10: 0000000000000000 R11: ffffa68042cf7be8 R12: 0000000000000005
[40677.318230] R13: ffff95751ac75300 R14: ffff9573e832f218 R15: 0000000000000000
[40677.318231] FS:  00007f27fc15b880(0000) GS:ffff95751ea80000(0000) knlGS:0000000000000000
[40677.318232] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[40677.318233] CR2: 000055c381d8bcf0 CR3: 000000049a2c8000 CR4: 00000000000406e0
[40677.318234] Call Trace:
[40677.318239]  ? dev_uevent+0xba/0x2e0
[40677.318241]  kobject_uevent_env+0x360/0x790
[40677.318244]  ? do_filp_open+0xa7/0x100
[40677.318245]  kobject_synth_uevent+0x2bb/0x32b
[40677.318247]  uevent_store+0x1c/0x30
[40677.318249]  ? _cond_resched+0x15/0x30
[40677.318251]  kernfs_fop_write+0x108/0x190
[40677.318253]  vfs_write+0xa5/0x1a0
[40677.318255]  ksys_write+0x59/0xd0
[40677.318257]  do_syscall_64+0x55/0x130
[40677.318260]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[40677.318262] RIP: 0033:0x7f27fc039317
[40677.318263] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[40677.318264] RSP: 002b:00007fff329c4948 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[40677.318266] RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 00007f27fc039317
[40677.318266] RDX: 0000000000000007 RSI: 00007fff329c4a00 RDI: 0000000000000003
[40677.318267] RBP: 00007fff329c4a00 R08: 0000000000000007 R09: 7269762f73656369
[40677.318268] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000007
[40677.318269] R13: 000055c381dc97c0 R14: 0000000000000007 R15: 00007f27fc1138a0
[40677.318270] ---[ end trace 0412a24c9ab61437 ]---
[40677.318272] synth uevent: /devices/virtual/input/input71: failed to send uevent
[40677.318273] input input71: uevent: failed to send synthetic uevent

This all boils down to the following kernel code in kobject_uevent.c:

int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...)
{
	va_list args;
	int len;

	if (env->envp_idx >= ARRAY_SIZE(env->envp)) {
		WARN(1, KERN_ERR "add_uevent_var: too many keys\n");
		return -ENOMEM;
	}

	va_start(args, format);
	len = vsnprintf(&env->buf[env->buflen],
			sizeof(env->buf) - env->buflen,
			format, args);
	va_end(args);

	if (len >= (sizeof(env->buf) - env->buflen)) {
		WARN(1, KERN_ERR "add_uevent_var: buffer size too small\n");
		return -ENOMEM;
	}

	env->envp[env->envp_idx++] = &env->buf[env->buflen];
	env->buflen += len + 1;
	return 0;
}

To get a clue why this is happening there we'll probably need somebody familiar with input interfaces in the kernel, since for me it seems as if the udev message with args would have to exceed bounds of kobj_uevent_env->buf, which is why the error seems to occur. At least if I don't misread the code.

Created a report at systemd, mayhap we get another step closer with that since it points for me to a too long udev message:
https://github.com/systemd/systemd/issues/15784

ckb-next KitsuWhooa said he'll probably patch the daemon with a workaround "tomorrow". If that happens and the workaround fixes our issue I'll try to patch up ckb-next with the patch and request it for release until we find the real root cause of the issue.

Systemd guys say it's a kernel bug - so there we go, kernel bug report for uinput:
https://bugzilla.kernel.org/show_bug.cgi?id=207695

ckb-next devs did make good on their promise.

I did test it, and indeed, that fixes the issue.

Submittet patch with arcanist:
https://dev.getsol.us/D8855

Should be fixed with todays update. Should not occur after todays update, so the errors shouldn't appear on the next package installs / updates after ckb was updated. Cany any of you confirm it?

Due to a lack of response, I guess this can be closed.

Staudey mentioned this in T10245: Apply udev rules fails.Apr 28 2022, 10:45 PM

TClark77 closed this task as Invalid.Fri, Jul 21, 2:29 AM

	F5919616: image.png
	May 11 2020, 10:23 PM

Can't apply udev rules when ckb-next-daemon is runningClosed, InvalidPublicActions

Description

Related Objects

Event Timeline

Can't apply udev rules when ckb-next-daemon is running
Closed, InvalidPublic
Actions