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

Thomas Bächler thomas at archlinux.org
Tue Aug 16 23:55:12 CEST 2011


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20110816/291e7278/attachment.asc>


More information about the dm-crypt mailing list