From: Oleg Nesterov <oleg@tv-sign.ru>
To: Alasdair G Kergon <agk@redhat.com>, Milan Broz <mbroz@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Johannes Berg <johannes@sipsolutions.net>,
Torsten Kaiser <just.for.lkml@googlemail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.24-rc2-mm1: kcryptd vs lockdep
Date: Wed, 21 Nov 2007 18:58:42 +0300 [thread overview]
Message-ID: <20071121155842.GA864@tv-sign.ru> (raw)
In-Reply-To: <20071120234605.GG23667@elte.hu>
Alasdair G Kergon wrote:
>
> - But what happens if kcryptd_crypt_write_convert_loop() calls
> INIT_WORK/queue_work twice?
Can't find this function. But "INIT_WORK + queue_work" twice is very
wrong of course.
Milan Broz wrote:
>
> 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);
(just in case, in that particular case PREPARE_WORK() should be used)
INIT_WORK(w) can be used if we know that "w" is not pending, and nobody
else can write to this work (say, queue_work(w) or cancel_work_sync(w)).
So currently the code above should work correctly.
However, I'd say it is not correct, INIT_WORK() can throw out some debug
info for example, or the implementation could be changed.
I'm not sure about CONFIG_LOCKDEP (Johannes cc'ed). INIT_WORK() does
lockdep_init_map(->lockdep_map) but run_workqueue() has a local copy,
looks ok.
Oleg.
next parent reply other threads:[~2007-11-21 15:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071120234605.GG23667@elte.hu>
2007-11-21 15:58 ` Oleg Nesterov [this message]
2007-11-21 16:06 ` 2.6.24-rc2-mm1: kcryptd vs lockdep Johannes Berg
2007-11-24 10:53 ` [PATCH] debug_check_no_locks_freed: fix in_range() checks Oleg Nesterov
2007-11-24 12:18 ` Torsten Kaiser
2007-11-24 12:25 ` Oleg Nesterov
2007-11-24 12:35 ` Alasdair G Kergon
2007-11-24 12:22 ` Ingo Molnar
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
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
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=20071121155842.GA864@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=johannes@sipsolutions.net \
--cc=just.for.lkml@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbroz@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).