NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/47893: opencrypto user level requests uses different mutex for same flag variable
>Number: 47893
>Category: kern
>Synopsis: opencrypto user level requests uses different mutex for same
>flag variable
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Jun 05 11:45:00 +0000 2013
>Originator: Dr. Wolfgang Stukenbrock
>Release: NetBSD 6.1
>Organization:
Dr. Nagler & Company GmbH
>Environment:
System: NetBSD test-s0 5.1.2 NetBSD 5.1.2 (NSW-WS) #3: Fri Dec 21 15:15:43 CET
2012 wgstuken@test-s0:/usr/src/sys/arch/amd64/compile/NSW-WS amd64
Architecture: x86_64
Machine: amd64
>Description:
In opencrypto there is a special handling for userlevel request useing
the CRYPTO_F_USER flag.
It is set when the request is generated in cryptodev.c and passed to
the crypto stuff for processing.
On return to the ioctl function, this flag is removed again in order to
allow bypassing of the
return-queue to avoid additional context switches (in I think most of
the calls).
OK so far - sounds like a good idea.
But now crypto.c has introduce additional mutex structures for the
queue.
Now the crypto_ret_q_mtx is aquired by crypto_done() for setting
CRYPTO_F_DONE and checking this flag, but crypto_mtx is used
by the ioctl function for resetting the CRYPTO_F_USER flag.
We have a race condition here, because checking and resetting is no
longer synchonized and it may happen that we loose
the CRYPTO_F_DONE flag. This would end up in endless waiting of the
user-thread.
>How-To-Repeat:
found while validating/integrating private changes/patches into 6.1
>Fix:
I'm not useing user-level crypto (till now) and have no time to go
deeper into this - sorry.
The problems came up when the queue mutex structures are introduced in
crypto.c.
>Unformatted:
Home |
Main Index |
Thread Index |
Old Index