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
Herbert,
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 will be testing this fix starting tomorrow.
The null dereference occurs
11 matches
Mail list logo
