On Thu, 17 Jul 2008 10:51:43 -0500 Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx> wrote: > > On Jul 17, 2008, at 10:27 AM, Kim Phillips wrote: > > > On Thu, 17 Jul 2008 07:26:14 -0500 > > Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx> wrote: > > > >> > >> On Jul 17, 2008, at 7:17 AM, Herbert Xu wrote: > >> > >>> On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote: > >>>> > >>>> On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote: > >>>> > >>>>> use GFP_ATOMIC when necessary; use atomic_t when allocating > >>>>> submit_count. > >>>> > >>>> why? > >>> > >>> You mean why are atomics required? Yes that is a good question. > >> > >> Yep. the commit message isn't explaining why, just what :) > > > > In honouring requests that don't have the CRYPTO_TFM_REQ_MAY_SLEEP > > set, > > afaict, it's the standard non-wait variant GFP that drivers use (see > > the ixp4xx driver for e.g.). > > so GFP_ATOMIC and atomic_t aren't related. I can understand the need > for GFP_ATOMIC, but I don't get why something needs to be declared > atomic_t. I see what the source of confusion is now; it appears I missed this atomic_t clean-up when making the patchseries; the atomic_t fix belongs in the previous "preempt overflow interrupts" patch (3/6). atomic_t is needed for atomic operations which protect resource contention on submit_count, which subsequently represents submission slot availability on a particular SEC channel for multiple, potentially simultaneous, users. Kim -- 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
