linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Lei Wen <adrian.wenl@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, leiwen@marvell.com,
	wwang27@marvell.com
Subject: Re: workqueue panic in 3.4 kernel
Date: Mon, 11 Mar 2013 22:12:15 -0700	[thread overview]
Message-ID: <20130312051215.GU14556@mtj.dyndns.org> (raw)
In-Reply-To: <CALZhoSQBH3RxSoaVDCYoCyRVRndht-Rk0rh_w5Dbp6+5T_auSw@mail.gmail.com>

Hello,

On Tue, Mar 12, 2013 at 01:08:15PM +0800, Lei Wen wrote:
> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> index 8afab27..425d5a2 100644
> --- a/include/linux/workqueue.h
> +++ b/include/linux/workqueue.h
> @@ -189,12 +189,16 @@ static inline unsigned int work_static(struct
> work_struct *work) { return 0; }
>   * NOTE! No point in using "atomic_long_set()": using a direct
>   * assignment of the work data initializer allows the compiler
>   * to generate better code.
> + *
> + * We take the assumption that work should not be inited if it already
> + * hold the pending bit, or bug would be reported.
>   */
>  #ifdef CONFIG_LOCKDEP
>  #define __INIT_WORK(_work, _func, _onstack)                            \
>         do {                                                            \
>                 static struct lock_class_key __key;                     \
>                                                                         \
> +               BUG_ON(work_pending(_work));                            \

You're initializing random piece of memory which may contain any
garbage and triggering BUG if some bit is set on it. No, you can't do
that. debugobj is the right tool for debugging object lifetime issues
and is already supported.

Thanks.

-- 
tejun

  parent reply	other threads:[~2013-03-12  5:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05  7:31 workqueue panic in 3.4 kernel Lei Wen
2013-03-05 16:32 ` Tejun Heo
2013-03-06 14:39   ` Lei Wen
2013-03-06 19:14     ` Tejun Heo
2013-03-07  1:15       ` Lei Wen
2013-03-07 15:22         ` Lei Wen
2013-03-07 15:49           ` Tejun Heo
2013-03-07 16:07             ` Thomas Gleixner
     [not found]               ` <CALZhoSQBH3RxSoaVDCYoCyRVRndht-Rk0rh_w5Dbp6+5T_auSw@mail.gmail.com>
2013-03-12  5:12                 ` Tejun Heo [this message]
2013-03-12  5:18                   ` Lei Wen
2013-03-12  5:24                     ` Tejun Heo
2013-03-12  5:34                       ` Lei Wen
2013-03-12  5:40                         ` Tejun Heo
2013-03-12  6:01                           ` Lei Wen
2013-03-12  6:13                             ` Tejun Heo
2013-03-12  6:41                               ` Lei Wen

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=20130312051215.GU14556@mtj.dyndns.org \
    --to=tj@kernel.org \
    --cc=adrian.wenl@gmail.com \
    --cc=leiwen@marvell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wwang27@marvell.com \
    /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).