[PATCH 4/6] crypto: talitos - fix GFP flag usage

[Kim Phillips]

On Thu, 17 Jul 2008 10:51:43 -0500
Kumar Gala <galak at kernel.crashing.org> wrote:

> 
> On Jul 17, 2008, at 10:27 AM, Kim Phillips wrote:
> 
> > On Thu, 17 Jul 2008 07:26:14 -0500
> > Kumar Gala <galak at kernel.crashing.org> 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