From: Guenter Roeck <linux@roeck-us.net>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Tejun Heo <tj@kernel.org>
Subject: linux-next: tracebacks in workqueue.c/__flush_work()
Date: Sat, 2 Feb 2019 14:20:23 -0800 [thread overview]
Message-ID: <18a30387-6aa5-6123-e67c-57579ecc3f38@roeck-us.net> (raw)
Commit "workqueue: Try to catch flush_work() without INIT_WORK()" added
a warning if flush_work() is called without worker function.
This results in the following tracebacks, typically observed during
system shutdown.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 101 at kernel/workqueue.c:3018 __flush_work+0x2a4/0x2e0
Modules linked in:
CPU: 0 PID: 101 Comm: umount Not tainted 5.0.0-rc4-next-20190201 #1
fffffc0007dcbd18 0000000000000000 fffffc00003338a0 fffffc00003517d4
fffffc00003517d4 fffffc0000e56c98 fffffc0000e56c98 fffffc0000ebc1d8
fffffc0000ec0bd8 ffffffffa8024010 0000000000000bca 0000000000000000
fffffc00003d3ea4 fffffc0000e56c98 fffffc0000e56c60 fffffc0000ebc1d8
fffffc0000ec0bd8 0000000000000000 0000000000000001 0000000000000000
fffffc000782d520 0000000000000000 fffffc000044ef50 fffffc0007c4b540
Trace:
[<fffffc00003338a0>] __warn+0x160/0x190
[<fffffc00003517d4>] __flush_work+0x2a4/0x2e0
[<fffffc00003517d4>] __flush_work+0x2a4/0x2e0
[<fffffc00003d3ea4>] lru_add_drain_all+0xe4/0x190
[<fffffc000044ef50>] shrink_dcache_sb+0x70/0xb0
[<fffffc0000478dc4>] invalidate_bh_lru+0x44/0x80
[<fffffc00003a94fc>] on_each_cpu_cond+0x5c/0x90
[<fffffc0000478d80>] invalidate_bh_lru+0x0/0x80
[<fffffc000047fe7c>] invalidate_bdev+0x3c/0x70
[<fffffc0000432ca8>] reconfigure_super+0x178/0x2c0
[<fffffc000045ee64>] ksys_umount+0x664/0x680
[<fffffc000045ee9c>] sys_umount+0x1c/0x30
[<fffffc00003115d4>] entSys+0xa4/0xc0
[<fffffc00003115d4>] entSys+0xa4/0xc0
---[ end trace 613cea34708701f1 ]---
The problem is seen with several (but not all) architectures. Affected
architectures/platforms are:
alpha
arm:versatilepb
m68k
mips, mips64 (boot from IDE drive or MMC, SMP disabled)
parisc (nosmp builds)
sparc, sparc64 (nosmp builds)
There may be others; several of my tests fail with build failures.
If/when it is seen, the problem is persistent.
Common denominator seems to be that SMP is disabled. It does appear that
for_each_cpu() ignores the mask for nosmp builds, but I don't really
understand why.
Guenter
next reply other threads:[~2019-02-02 22:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-02 22:20 Guenter Roeck [this message]
2019-02-03 1:21 ` linux-next: tracebacks in workqueue.c/__flush_work() Tetsuo Handa
2019-02-03 23:46 ` Rusty Russell
2019-02-06 6:31 ` Tetsuo Handa
2019-02-06 14:36 ` Guenter Roeck
2019-02-06 14:57 ` Tetsuo Handa
2019-02-06 16:23 ` Guenter Roeck
2019-02-06 16:38 ` Tetsuo Handa
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=18a30387-6aa5-6123-e67c-57579ecc3f38@roeck-us.net \
--to=linux@roeck-us.net \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=tj@kernel.org \
/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.