[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80ba65b6-d0c2-2d3a-779b-a134af8a9054@lge.com>
Date: Tue, 5 Dec 2017 13:58:09 +0900
From: Byungchul Park <byungchul.park@....com>
To: Jan Kara <jack@...e.cz>,
syzbot
<bot+045a1f65bdea780940bf0f795a292f4cd0b773d1@...kaller.appspotmail.com>
Cc: akpm@...ux-foundation.org, hannes@...xchg.org, jlayton@...hat.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
mgorman@...hsingularity.net, npiggin@...il.com, rgoldwyn@...e.com,
syzkaller-bugs@...glegroups.com, peterz@...radead.org,
kernel-team@....com
Subject: Re: possible deadlock in generic_file_write_iter (2)
On 12/4/2017 5:33 PM, Jan Kara wrote:
> Hello,
>
> adding Peter and Byungchul to CC since the lockdep report just looks
> strange and cross-release seems to be involved. Guys, how did #5 get into
> the lock chain and what does put_ucounts() have to do with sb_writers
> there? Thanks!
Hello Jan,
In order to get full stack of #5, we have to pass a boot param,
"crossrelease_fullstack", to the kernel. Now that it only informs
put_ucounts() in the call trace, it's hard to find out what exactly
happened at that time, but I can tell #5 shows:
When acquire(sb_writers) in put_ucounts(), it was on the way to
complete((completion)&req.done) of wait_for_completion() in
devtmpfs_create_node().
If acquire(sb_writers) in put_ucounts() is stuck, then
wait_for_completion() in devtmpfs_create_node() would be also
stuck, since complete() being in the context of acquire(sb_writers)
cannot be called.
This is why cross-release added the lock chain.
--
Thanks,
Byungchul
Powered by blists - more mailing lists