Re: [dm-crypt] The weird bug again: semid XXXXXX: semop failed for cookie 0xdeadbeef: incorrect semaphore state

["Thomas Bächler" <thomas@archlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

Am 16.08.2011 23:44, schrieb Milan Broz:
> On 08/16/2011 10:45 PM, Thomas Bächler wrote:
>> I am getting reports of this error again:
>>
>> semid 491524: semop failed for cookie 0xd4dc159: incorrect semaphore state
>> Failed to set a proper state for notification semaphore identified by
>> cookie value 223199577 (0xd4dc159) to initialize waiting for incoming
>> notifications.
>>
>> This issue is so weird that I don't know where to start. Apparently,
>> this problem appears whenever chromium is running, and disappears when
>> you quit chromium. I'm confused about this. Very confused.
> 
> I know that this bug is still there. I think that the problem is:
> 
> - kernel, in response to devmapper library request, send uevent with cookie
> - kernel reports failure (despite uevent was sent), I guess it is
> some memory allocation error later
> - libdevmapper takes error path, destroying semaphore, which was already
> destroyed in udev rules
> 
> So my guess is that connection with chromium just it perhaps allocates most
> of system memory and some allocation in kernel perhaps fail then.

Then this would probably be reproducible with other programs, too. So
far, the connection has been only made with chromium. I would love to
find another test case though.

> The final state should be correct, so you can (I hope) ignore that error
> for now.

Don't the LUKS commands abort after this error? (Don't remember).

> It is not a cryptsetup bug but I would like to fix it anyway,
> the problem is the bug appears and disappears quite randomly.
> 
> Does anyone see this bug in some other libdevmapper user?
> (lvm, multipath, kpartx, ... ?)

I have only seen this with cryptsetup so far.

> (Another possibility is that you have broken udev rules and
> "dmsetup udevcomplete" is called twice there, but I do not think it
> the issue.)

Udev rules are all taken directly from upstream udev and device-mapper.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]