From: Peng Fan <peng.fan@nxp.com>
To: Saravana Kannan <saravanak@google.com>,
Dong Aisheng <dongas86@gmail.com>
Cc: open list <linux-kernel@vger.kernel.org>,
Guenter Roeck <linux@roeck-us.net>,
gregkh <gregkh@linuxfoundation.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
dl-linux-imx <linux-imx@nxp.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
Aisheng Dong <aisheng.dong@nxp.com>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <kernel@pengutronix.de>
Subject: RE: Lockdep warning caused by "driver core: Fix sleeping in invalid context during device link deletion"
Date: Tue, 1 Sep 2020 06:07:01 +0000 [thread overview]
Message-ID: <DB6PR0402MB2760752E2666D486B40104B3882E0@DB6PR0402MB2760.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAGETcx_=Da7hVUCfOFd13Q6YAGPC65VSJD7BiCK_fCegYMCJbQ@mail.gmail.com>
> Subject: Re: Lockdep warning caused by "driver core: Fix sleeping in invalid
> context during device link deletion"
>
> On Wed, Aug 26, 2020 at 10:17 PM Saravana Kannan
> <saravanak@google.com> wrote:
> >
> > On Thu, Aug 20, 2020 at 8:50 PM Dong Aisheng <dongas86@gmail.com>
> wrote:
> > >
> > > Hi ALL,
> > >
> > > We met the below WARNING during system suspend on an iMX6Q SDB
> board
> > > with the latest linus/master branch (v5.9-rc1+) and next-20200820.
> > > v5.8 kernel is ok. So i did bisect and finally found it's caused by
> > > the patch below.
> > > Reverting it can get rid of the warning, but I wonder if there may
> > > be other potential issues.
> > > Any ideas?
> > >
> > > Defconfig used is: imx_v6_v7_defconfig
> > >
> >
> > ----- 8< ----- Snipped text that was a bit misleading
> >
> > >
> > > Error log:
> > > # echo mem > /sys/power/state
> > > [ 39.111865] PM: suspend entry (deep)
> > > [ 39.148650] Filesystems sync: 0.032 seconds
> > > [ 39.154034]
> > > [ 39.155537]
> ======================================================
> > > [ 39.161723] WARNING: possible circular locking dependency detected
> > > [ 39.167911] 5.9.0-rc1-00103-g7eac66d0456f #37 Not tainted
> > > [ 39.173315] ------------------------------------------------------
> > > [ 39.179500] sh/647 is trying to acquire lock:
> > > [ 39.183862] c15a310c (dpm_list_mtx){+.+.}-{3:3}, at:
> > > dpm_for_each_dev+0x20/0x5c
> > > [ 39.191200]
> > > [ 39.191200] but task is already holding lock:
> > > [ 39.197036] c15a37e4 (fw_lock){+.+.}-{3:3}, at:
> fw_pm_notify+0x90/0xd4
> > > [ 39.203582]
> > > [ 39.203582] which lock already depends on the new lock.
> > > [ 39.203582]
> > > [ 39.211763]
> > > [ 39.211763] the existing dependency chain (in reverse order) is:
> > > [ 39.219249]
> > > [ 39.219249] -> #2 (fw_lock){+.+.}-{3:3}:
> > > [ 39.224673] mutex_lock_nested+0x1c/0x24
> > > [ 39.229126] firmware_uevent+0x18/0xa0
> > > [ 39.233411] dev_uevent+0xc4/0x1f8
> > > [ 39.237343] uevent_show+0x98/0x114
> > > [ 39.241362] dev_attr_show+0x18/0x48
> > > [ 39.245472] sysfs_kf_seq_show+0x84/0xec
> > > [ 39.249927] seq_read+0x138/0x550
> > > [ 39.253774] vfs_read+0x94/0x164
> > > [ 39.257529] ksys_read+0x60/0xe8
> > > [ 39.261288] ret_fast_syscall+0x0/0x28
> > > [ 39.265564] 0xbed7c808
> > > [ 39.268538]
> > > [ 39.268538] -> #1 (kn->active#3){++++}-{0:0}:
> > > [ 39.274391] kernfs_remove_by_name_ns+0x40/0x94
> > > [ 39.279450] device_del+0x144/0x3fc
> >
> > Rafael/Greg,
> >
> > I'm not very familiar with the #0 and #2 calls stacks. But poking
> > around a bit, they are NOT due to the device-link-device. But the new
> > stuff is the above two lines that are deleting the device-link-device
> > (that's used to expose device link details in sysfs) when the device
> > link is deleted.
> >
> > Kicking off a workqueue to break this cycle is easy, but the problem
> > is that if I queue a work to delete the device, then the sysfs folder
> > won't get removed immediately. And if the same link is created again
> > before the work is completed, then there'll be a sysfs name collision
> > and warning.
> >
> > So, I'm kinda stuck here. Open to suggestions. Hoping you'll have
> > better ideas for breaking the cycle. Or point out how I'm
> > misunderstanding the cycle here.
> >
>
> Aisheng,
>
> Sent out a fix that I think should work.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flkml%2F20200831221007.1506441-1-saravanak%40google.com%
> 2FT%2F%23u&data=02%7C01%7Cpeng.fan%40nxp.com%7C3254604d7
> 41b4d1ce73b08d84dfb65af%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C637345089428077609&sdata=5lh8WO%2BYMh4C1sBn58Fsm
> XsjqjPj%2B%2FB71%2FENfMGDtTk%3D&reserved=0
>
> I wasn't able to reproduce it in my hardware. So, if you can test that patch
> (and respond to that thread), that'd be great.
I not found your patch in my mailbox, but anyway I tested it.
Tested-by: Peng Fan <peng.fan@nxp.com> (i.MX7ULP EVK)
Regards,
Peng.
>
> -Saravana
next prev parent reply other threads:[~2020-09-01 6:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 3:35 Lockdep warning caused by "driver core: Fix sleeping in invalid context during device link deletion" Dong Aisheng
2020-08-21 18:28 ` Saravana Kannan
2020-08-24 8:18 ` Aisheng Dong
2020-08-27 5:17 ` Saravana Kannan
2020-08-31 22:15 ` Saravana Kannan
2020-09-01 6:07 ` Peng Fan [this message]
2020-09-01 6:46 ` Saravana Kannan
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=DB6PR0402MB2760752E2666D486B40104B3882E0@DB6PR0402MB2760.eurprd04.prod.outlook.com \
--to=peng.fan@nxp.com \
--cc=aisheng.dong@nxp.com \
--cc=dongas86@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=m.szyprowski@samsung.com \
--cc=naresh.kamboju@linaro.org \
--cc=saravanak@google.com \
--cc=shawnguo@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 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).