All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <mbroz@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Torsten Kaiser <just.for.lkml@googlemail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Alasdair G Kergon <agk@redhat.com>
Subject: Re: 2.6.24-rc2-mm1: kcryptd vs lockdep
Date: Tue, 20 Nov 2007 15:40:30 +0100	[thread overview]
Message-ID: <4742F1DE.1090902@redhat.com> (raw)
In-Reply-To: <64bb37e0711192255j3fabd3d9g94544b3d518828a2@mail.gmail.com>

Torsten Kaiser wrote:
> On Nov 19, 2007 10:00 PM, Milan Broz <mbroz@redhat.com> wrote:
>> Torsten Kaiser wrote:
>>> Anything I could try, apart from more boots with slub_debug=F?
> 
> One time it triggered with slub_debug=F, but no additional output.
> With slub_debug=FP I have not seen it again, so I can't say if that
> would yield more info.
> 
>> Please could you try which patch from the dm-crypt series cause this ?
>> (agk-dm-dm-crypt* names.)
>>
>> I suspect agk-dm-dm-crypt-move-bio-submission-to-thread.patch because
>> there is one work struct used subsequently in two threads...
>> (io thread already started while crypt thread is processing lockdep_map
>> after calling f(work)...)
> 
> After reverting only
> agk-dm-dm-crypt-move-bio-submission-to-thread.patch I also have not
> seen the 'held lock freed' message again.

Ok, then I have question: Is the following pseudocode correct
(and problem is in lock validation which checks something
already initialized for another queue) or reusing work_struct
is not permitted from inside called work function ?

(Note comment in code "It is permissible to free the struct
work_struct from inside the function that is called from it".)

struct work_struct work;
struct workqueue_struct *a, *b;

do_b(*work) 
{
	/* do something else */
}

do_a(*work)
{
	/* do something */
	INIT_WORK(&work, do_b);
	queue_work(b, &work);
}


INIT_WORK(&work, do_a);
queue_work(a, &work);

Milan
--
mbroz@redhat.com

  reply	other threads:[~2007-11-20 14:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-19  7:23 2.6.24-rc2-mm1: kcryptd vs lockdep Torsten Kaiser
2007-11-19  7:56 ` Ingo Molnar
2007-11-19 19:34   ` Torsten Kaiser
2007-11-19 21:00     ` Milan Broz
2007-11-20  6:55       ` Torsten Kaiser
2007-11-20 14:40         ` Milan Broz [this message]
2007-11-20 23:36           ` Alasdair G Kergon
2007-11-23 10:21         ` Torsten Kaiser
2007-11-23 22:42       ` Torsten Kaiser
2007-11-24  3:49         ` Alasdair G Kergon
2007-11-24  4:03           ` Alasdair G Kergon
2007-11-24  6:38             ` Herbert Xu
2007-11-24  4:57           ` Torsten Kaiser
2007-11-24  4:13         ` Alasdair G Kergon
     [not found] <20071120234605.GG23667@elte.hu>
2007-11-21 15:58 ` Oleg Nesterov
2007-11-21 16:06   ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4742F1DE.1090902@redhat.com \
    --to=mbroz@redhat.com \
    --cc=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=just.for.lkml@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.