On Fri, Jun 22, 2007 at 02:29:48PM +0200, Sebastian Siewior (linux-crypto@xxxxxxxxxxxxxxxx) wrote: > * Evgeniy Polyakov | 2007-06-22 15:57:26 [+0400]: > > >On Fri, Jun 22, 2007 at 03:28:44PM +0800, Herbert Xu (herbert@xxxxxxxxxxxxxxxxxxx) wrote: > >> > + * Actually I need to think about how to handle the case, when queue is full. > >> > + * So far error (-EINVAL) is returned. > >> > + */ > >> > >> OK you need to provide a software queue here. Since you already > >> have a hardware queue, you may choose to have a queue with a > >> (advisory) maximum length of zero. However, a queue is still > >> necessary since requests with the MAY_BACKLOG flag must never > >> be discarded. > >> > >> This is (or will be) used by users such as dm-crypt that must be > >> able to add at least one request but can throttle themselves > >> afterwards . > > > >What will prevent crypto user from filling that queue with crypto > >requests more and more when hardware is not capable to work with such > >rate? > > Nothing, the hw signalizes with -EBUSY such a state and the crypto user > has to slow down. > If the crypto user continues such a behavior, the system will go OOM > (this is atleast my understanding). That is what is returned right now - -EBUSY if queue is full and -EINVAL if there are some more serious errors, but there is no way dm-crypt will recover from error. -- Evgeniy Polyakov - 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
