On 9/19/2015 12:02 PM, Alex Porosanu wrote: > caam_jr_enqueue() function returns -EBUSY once there are no > more slots available in the JR, but it doesn't actually save > the current request. This breaks the functionality of users > that expect that even if there is no more space for the request, > it is at least queued for later execution. In other words, all > crypto transformations that request backlogging > (i.e. have CRYPTO_TFM_REQ_MAY_BACKLOG set), will hang. Such an > example is dm-crypt. > The current patch solves this issue by setting a threshold after > which caam_jr_enqueue() returns -EBUSY, but since the HW job ring > isn't actually full, the job is enqueued. > Caveat: if the users of the driver don't obey the API contract which > states that once -EBUSY is received, no more requests are to be > sent, eventually the driver will reject the enqueues. > For well-behaved CryptoAPI users, like dm-crypt, this is not the > case, since the processing thread will sleep once -EBUSY is > received. > > Signed-off-by: Alex Porosanu <alexandru.porosanu@xxxxxxxxxxxxx> > > --- > v3: > - as per Herbert's observation, allow only # of backlogging slots > transformations w/MAY_BACKLOG flag set to be affined to a JR; > the total # of transformations that can be thus allocated is equal > to the # of JRs times the # of "backlogging slots". In the standard > configuration, this means 16 x 4 = 64 transformations. This won't work, since CRYPTO_TFM_REQ_MAY_BACKLOG is set per request (at request setup time), not per tfm. Horia -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
