[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15622.1525102698@warthog.procyon.org.uk>
Date: Mon, 30 Apr 2018 16:38:18 +0100
From: David Howells <dhowells@...hat.com>
To: Christoph Hellwig <hch@....de>
Cc: dhowells@...hat.com, Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-rtc@...r.kernel.org, Alessandro Zummo <a.zummo@...ertech.it>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
jfs-discussion@...ts.sourceforge.net,
linux-afs@...ts.infradead.org, linux-acpi@...r.kernel.org,
netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
Jiri Slaby <jslaby@...e.com>, linux-ext4@...r.kernel.org,
Alexey Dobriyan <adobriyan@...il.com>,
megaraidlinux.pdl@...adcom.com, drbd-dev@...ts.linbit.com
Subject: Re: simplify procfs code for seq_file instances V2
Note that your kernel hits the:
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(ptrval) (fs_reclaim){?.+.}, at: fs_reclaim_acquire+0x12/0x35
{HARDIRQ-ON-W} state was registered at:
fs_reclaim_acquire+0x32/0x35
kmem_cache_alloc_node_trace+0x49/0x2cf
alloc_worker+0x1d/0x49
init_rescuer.part.7+0x19/0x8f
workqueue_init+0xc0/0x1fe
kernel_init_freeable+0xdc/0x433
kernel_init+0xa/0xf5
ret_from_fork+0x24/0x30
bug, as described here:
https://groups.google.com/forum/#!msg/syzkaller-bugs/sJC3Y3hOM08/aO3z9JXoAgAJ
David
Powered by blists - more mailing lists