crypto: crypto4xx - add backlog queue support
Previously, If the crypto4xx driver used all available security contexts, it would simply refuse new requests with -EAGAIN. CRYPTO_TFM_REQ_MAY_BACKLOG was ignored. in case of dm-crypt.c's crypt_convert() function this was causing the following errors to manifest, if the system was pushed hard enough: | EXT4-fs warning (dm-1): ext4_end_bio:314: I/O error -5 writing to ino .. | EXT4-fs warning (dm-1): ext4_end_bio:314: I/O error -5 writing to ino .. | EXT4-fs warning (dm-1): ext4_end_bio:314: I/O error -5 writing to ino .. | JBD2: Detected IO errors while flushing file data on dm-1-8 | Aborting journal on device dm-1-8. | EXT4-fs error : ext4_journal_check_start:56: Detected aborted journal | EXT4-fs (dm-1): Remounting filesystem read-only | EXT4-fs : ext4_writepages: jbd2_start: 2048 pages, inode 498...; err -30 (This did cause corruptions due to failed writes) To fix this mess, the crypto4xx driver needs to notifiy the user to slow down. This can be achieved by returning -EBUSY on requests, once the crypto hardware was falling behind. Note: -EBUSY has two different meanings. Setting the flag CRYPTO_TFM_REQ_MAY_BACKLOG implies that the request was successfully queued, by the crypto driver. To achieve this requirement, the implementation introduces a threshold check and adds logic to the completion routines in much the same way as AMD's Cryptographic Coprocessor (CCP) driver do. Note2: Tests showed that dm-crypt starved ipsec traffic. Under load, ipsec links dropped to 0 Kbits/s. This is because dm-crypt's callback would instantly queue the next request. In order to not starve ipsec, the driver reserves a small portion of the available crypto contexts for this purpose. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Showing
Please register or sign in to comment