From: Thierry Reding <thierry.reding@gmail.com>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: linux-pwm@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Phong Hoang <phong.hoang.wz@renesas.com>
Subject: Re: [PATCH] pwm: Avoid deadlock warning when removing PWM device
Date: Tue, 12 Mar 2019 12:54:58 +0100 [thread overview]
Message-ID: <20190312115458.GL31026@ulmo> (raw)
In-Reply-To: <1552360594-21547-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
[-- Attachment #1: Type: text/plain, Size: 4011 bytes --]
On Tue, Mar 12, 2019 at 12:16:34PM +0900, Yoshihiro Shimoda wrote:
> From: Phong Hoang <phong.hoang.wz@renesas.com>
>
> This patch fixes deadlock warning if removing PWM device
> when CONFIG_PROVE_LOCKING is enabled.
>
> This issue can be reproceduced by the following steps on
> the R-Car H3 Salvator-X board if the backlight is disabled:
>
> # cd /sys/class/pwm/pwmchip0
> # echo 0 > export
> # ls
> device export npwm power pwm0 subsystem uevent unexport
> # cd device/driver
> # ls
> bind e6e31000.pwm uevent unbind
> # echo e6e31000.pwm > unbind
>
> [ 87.659974] ======================================================
> [ 87.666149] WARNING: possible circular locking dependency detected
> [ 87.672327] 5.0.0 #7 Not tainted
> [ 87.675549] ------------------------------------------------------
> [ 87.681723] bash/2986 is trying to acquire lock:
> [ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
> [ 87.694528]
> [ 87.694528] but task is already holding lock:
> [ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
> [ 87.707405]
> [ 87.707405] which lock already depends on the new lock.
> [ 87.707405]
> [ 87.715574]
> [ 87.715574] the existing dependency chain (in reverse order) is:
> [ 87.723048]
> [ 87.723048] -> #1 (pwm_lock){+.+.}:
> [ 87.728017] __mutex_lock+0x70/0x7e4
> [ 87.732108] mutex_lock_nested+0x1c/0x24
> [ 87.736547] pwm_request_from_chip.part.6+0x34/0x74
> [ 87.741940] pwm_request_from_chip+0x20/0x40
> [ 87.746725] export_store+0x6c/0x1f4
> [ 87.750820] dev_attr_store+0x18/0x28
> [ 87.754998] sysfs_kf_write+0x54/0x64
> [ 87.759175] kernfs_fop_write+0xe4/0x1e8
> [ 87.763615] __vfs_write+0x40/0x184
> [ 87.767619] vfs_write+0xa8/0x19c
> [ 87.771448] ksys_write+0x58/0xbc
> [ 87.775278] __arm64_sys_write+0x18/0x20
> [ 87.779721] el0_svc_common+0xd0/0x124
> [ 87.783986] el0_svc_compat_handler+0x1c/0x24
> [ 87.788858] el0_svc_compat+0x8/0x18
> [ 87.792947]
> [ 87.792947] -> #0 (kn->count#58){++++}:
> [ 87.798260] lock_acquire+0xc4/0x22c
> [ 87.802353] __kernfs_remove+0x258/0x2c4
> [ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0
> [ 87.811836] remove_files.isra.1+0x38/0x78
> [ 87.816447] sysfs_remove_group+0x48/0x98
> [ 87.820971] sysfs_remove_groups+0x34/0x4c
> [ 87.825583] device_remove_attrs+0x6c/0x7c
> [ 87.830197] device_del+0x11c/0x33c
> [ 87.834201] device_unregister+0x14/0x2c
> [ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c
> [ 87.843509] pwmchip_remove+0xf4/0x13c
> [ 87.847773] rcar_pwm_remove+0x28/0x34
> [ 87.852039] platform_drv_remove+0x24/0x64
> [ 87.856651] device_release_driver_internal+0x18c/0x21c
> [ 87.862391] device_release_driver+0x14/0x1c
> [ 87.867175] unbind_store+0xe0/0x124
> [ 87.871265] drv_attr_store+0x20/0x30
> [ 87.875442] sysfs_kf_write+0x54/0x64
> [ 87.879618] kernfs_fop_write+0xe4/0x1e8
> [ 87.884055] __vfs_write+0x40/0x184
> [ 87.888057] vfs_write+0xa8/0x19c
> [ 87.891887] ksys_write+0x58/0xbc
> [ 87.895716] __arm64_sys_write+0x18/0x20
> [ 87.900154] el0_svc_common+0xd0/0x124
> [ 87.904417] el0_svc_compat_handler+0x1c/0x24
> [ 87.909289] el0_svc_compat+0x8/0x18
I'm not sure I understand this correctly. The above looks like pwm_lock
is held as part of the syscall writing 0 to the export attribute and the
second callchain looks like it's originating from the write to the
unbind attribute for the driver. But pwm_request_from_chip() should have
already released the lock before it returned, so how can the above
situation even happen?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-03-12 11:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-12 3:16 [PATCH] pwm: Avoid deadlock warning when removing PWM device Yoshihiro Shimoda
2019-03-12 8:38 ` Geert Uytterhoeven
2019-03-12 9:23 ` Uwe Kleine-König
2019-03-12 9:49 ` Geert Uytterhoeven
2019-03-12 9:54 ` Uwe Kleine-König
2019-03-12 11:47 ` Thierry Reding
2019-03-12 11:54 ` Thierry Reding [this message]
2019-03-12 12:09 ` Geert Uytterhoeven
2019-03-12 12:45 ` Thierry Reding
2019-03-13 7:01 ` Yoshihiro Shimoda
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=20190312115458.GL31026@ulmo \
--to=thierry.reding@gmail.com \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=phong.hoang.wz@renesas.com \
--cc=yoshihiro.shimoda.uh@renesas.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