http://bugzilla.suse.com/show_bug.cgi?id=939571
http://bugzilla.suse.com/show_bug.cgi?id=939571#c35
Takashi Iwai
Hmm ... wild guess ... in drivers/input/evdev.c I found with evdev_flush()
if (!evdev->exist || client->revoked) retval = -ENODEV; else retval = input_flush_device(&evdev->handle, file);
... could it be that close() does trigger flushing the device and the client has no permission anymore for doing that?(!) Normally close(2) does not trigger a flush but I've no idea how this is handled for this kind of devices? Maybe the is a pending I/O handler triggered to late.
A good catch. The flush is always called at close internally in filp_close(), and this is taken as a return code. The file itself is closed no matter which error is returned. (In reply to Dr. Werner Fink from comment #34)
IMHO this is more a kernel issue. I can work around this in the pam systemd module, nevertheless it is not clear if the file descriptor becomes leaked after the system call close(2) had failed with ENODEV.
The file is closed no matter flush returns an error, so there should be no leak. It's just an unexpected return code. I'll bring the error code problem to upstream, but let's keep working and see whether this is really the culprit of the whole problem. My guess is that the close() error is rather a red herring. It brings logind assert on systemd-210. But the problem persists with systemd-219 on Tumbleweed that doesn't kill logind, too. -- You are receiving this mail because: You are on the CC list for the bug.