On Wed, Sep 02, 2009 at 06:47:49PM -0500, Brad Bosch wrote:
>
> Assume the worker thread is executing between the dequeue in
> async_chainiv_do_postponed and the clear_bit call in
> async_chainiv_schedule_work. Further assume that we are processing
> the last item on the queue so durring this time
Herbert Xu writes:
> On Wed, Sep 02, 2009 at 09:08:38AM -0500, Brad Bosch wrote:
> >
> > Assume the worker thread is executing between the dequeue in
> > async_chainiv_do_postponed and the clear_bit call in
> > async_chainiv_schedule_work. Further assume that we are processing
>
> It cann
On Wed, Sep 02, 2009 at 09:08:38AM -0500, Brad Bosch wrote:
>
> Assume the worker thread is executing between the dequeue in
> async_chainiv_do_postponed and the clear_bit call in
> async_chainiv_schedule_work. Further assume that we are processing
It cannot. The worker thread can only execute
(resent due to bounce notification for vger)
Herbert Xu writes:
> On Tue, Sep 01, 2009 at 10:42:44AM -0500, Brad Bosch wrote:
> >
> > Now, ctx-err may be used by both async_chainiv_postpone_request to
> > store the return value from skcipher_enqueue_givcrypt and by
> > async_chainiv_givencryp
Herbert Xu writes:
> On Tue, Sep 01, 2009 at 10:42:44AM -0500, Brad Bosch wrote:
> >
> > Now, ctx-err may be used by both async_chainiv_postpone_request to
> > store the return value from skcipher_enqueue_givcrypt and by
> > async_chainiv_givencrypt_tail to store the return value from
> > cr
On Tue, Sep 01, 2009 at 10:42:44AM -0500, Brad Bosch wrote:
>
> Now, ctx-err may be used by both async_chainiv_postpone_request to
> store the return value from skcipher_enqueue_givcrypt and by
> async_chainiv_givencrypt_tail to store the return value from
> crypto_ablkcipher_encrypt at the same t
Herbert Xu writes:
> On Mon, Aug 31, 2009 at 11:11:42AM -0500, Brad Bosch wrote:
> >
> > OK. I was looking for something subtle because the crash takes a long
> > time to happen. But do you agree that the race I described above also
> > a real bug?
>
> No I don't think it is. CHAINV_STAT
On Mon, Aug 31, 2009 at 11:11:42AM -0500, Brad Bosch wrote:
>
> OK. I was looking for something subtle because the crash takes a long
> time to happen. But do you agree that the race I described above also
> a real bug?
No I don't think it is. CHAINV_STATE_INUSE guarantees that only
one entity
Herbert Xu writes:
> Thanks for the detailed analysis and patch!
No problem, thanks for looking at it!
>
> > The null dereference occurs when subreq is dereferenced in
> > async_chainiv_do_postponed(). My guess is that the
> > skcipher_givcrypt_request block has been freed and subsequently
Hi Brad:
On Thu, Aug 27, 2009 at 05:13:04PM -0500, Brad Bosch wrote:
>
> I seem to have found a bug in chainiv.c. The following oops occured
> while using blowfish and hmac-sha with UDP. The patch (against
> 2.6.27.30) after the oops output below is an completely untested
> possible fix. We wi
10 matches
Mail list logo
