From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Christoph Fritz <chf.fritz@googlemail.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>,
linux-rtc@vger.kernel.org, stable@vger.kernel.org,
Stefan Riedmueller <s.riedmueller@phytec.de>,
Alessandro Zummo <a.zummo@towertech.it>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14 ?
Date: Fri, 22 Dec 2017 14:05:33 +0100 [thread overview]
Message-ID: <20171222130533.GE18255@piout.net> (raw)
In-Reply-To: <1513947027.1940.13.camel@googlemail.com>
On 22/12/2017 at 13:50:27 +0100, Christoph Fritz wrote:
> Hey Troy and Alexandre,
>
> any objections asking Greg to add following recent v4.15 changes into
> stable branch 4.14?
>
No objection, they can be safely backported.
> 05a03bf rtc: m41t80: remove unneeded checks from m41t80_sqw_set_rate
> 13bb1d7 rtc: m41t80: avoid i2c read in m41t80_sqw_is_prepared
> 2cb90ed rtc: m41t80: avoid i2c read in m41t80_sqw_recalc_rate
> c8384bb rtc: m41t80: fix m41t80_sqw_round_rate return value
> de6042d rtc: m41t80: m41t80_sqw_set_rate should return 0 on success
>
> Without these patches, deadlock warnings showing up in 4.14:
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.14.8-00011-gd203938 #11 Not tainted
> ------------------------------------------------------
> kworker/1:2/133 is trying to acquire lock:
> (prepare_lock){+.+.}, at: [<c04951d0>] clk_prepare_lock+0x80/0xf4
>
> but task is already holding lock:
> (i2c_register_adapter){+.+.}, at: [<c069305c>] i2c_adapter_lock_bus+0x14/0x18
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (i2c_register_adapter){+.+.}:
> rt_mutex_lock+0x44/0x5c
> i2c_adapter_lock_bus+0x14/0x18
> i2c_transfer+0xa8/0xbc
> i2c_smbus_xfer+0x214/0x5cc
> i2c_smbus_read_byte_data+0x3c/0x4c
> m41t80_sqw_recalc_rate+0x24/0x58
> clk_register+0x3c8/0x638
> m41t80_probe+0x224/0x378
> i2c_device_probe+0x1dc/0x26c
> driver_probe_device+0x278/0x300
> __driver_attach+0xbc/0xc0
> bus_for_each_dev+0x74/0xa8
> driver_attach+0x20/0x28
> bus_add_driver+0x188/0x210
> driver_register+0x80/0x100
> i2c_register_driver+0x40/0x8c
> m41t80_driver_init+0x18/0x20
> do_one_initcall+0x44/0x17c
> kernel_init_freeable+0x11c/0x1dc
> kernel_init+0x10/0x11c
> ret_from_fork+0x14/0x20
>
> -> #0 (prepare_lock){+.+.}:
> lock_acquire+0x78/0x98
> __mutex_lock+0x54/0x988
> mutex_lock_nested+0x24/0x2c
> clk_prepare_lock+0x80/0xf4
> clk_core_get_rate+0x14/0x64
> clk_get_rate+0x1c/0x20
> i2c_imx_start+0x20/0x1cc
> i2c_imx_xfer+0x38/0xb84
> __i2c_transfer+0x138/0x27c
> i2c_transfer+0x78/0xbc
> i2c_master_send+0x44/0x54
> regmap_i2c_write+0x18/0x34
> _regmap_raw_write+0x56c/0x668
> _regmap_bus_raw_write+0x74/0x94
> _regmap_write+0x60/0x9c
> _regmap_update_bits+0xc8/0xcc
> regmap_update_bits_base+0x58/0x7c
> regulator_set_voltage_sel_regmap+0x50/0xa0
> _regulator_do_set_voltage+0x280/0x35c
> regulator_set_voltage_unlocked+0xec/0x254
> regulator_set_voltage_unlocked+0x1e8/0x254
> regulator_set_voltage+0x30/0x5c
> imx6q_set_target+0xb8/0x4e0
> __cpufreq_driver_target+0x224/0x540
> od_dbs_update+0xa0/0x168
> dbs_work_handler+0x34/0x60
> process_one_work+0x194/0x41c
> worker_thread+0x34/0x538
> kthread+0x11c/0x158
> ret_from_fork+0x14/0x20
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(i2c_register_adapter);
> lock(prepare_lock);
> lock(i2c_register_adapter);
> lock(prepare_lock);
>
> *** DEADLOCK ***
>
> 7 locks held by kworker/1:2/133:
> #0: ("events"){+.+.}, at: [<c014144c>] process_one_work+0x128/0x41c
> #1: ((&policy_dbs->work)){+.+.}, at: [<c014144c>] process_one_work+0x128/0x41c
> #2: (&policy_dbs->update_mutex){+.+.}, at: [<c06da1a0>] dbs_work_handler+0x28/0x60
> #3: (&rdev->mutex){+.+.}, at: [<c04a8cac>] regulator_lock_supply+0x24/0x44
> #4: (&rdev->mutex/1){+.+.}, at: [<c04a8cac>] regulator_lock_supply+0x24/0x44
> #5: (da9062_core:870:(config)->lock){+.+.}, at: [<c055f2c8>] regmap_lock_mutex+0x14/0x18
> #6: (i2c_register_adapter){+.+.}, at: [<c069305c>] i2c_adapter_lock_bus+0x14/0x18
>
> Thanks
> -- Christoph
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-12-22 13:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 12:50 rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14 ? Christoph Fritz
2017-12-22 13:05 ` Alexandre Belloni [this message]
2017-12-22 14:47 ` rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14 Christoph Fritz
2018-01-04 11:07 ` Greg Kroah-Hartman
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=20171222130533.GE18255@piout.net \
--to=alexandre.belloni@free-electrons.com \
--cc=a.zummo@towertech.it \
--cc=chf.fritz@googlemail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-rtc@vger.kernel.org \
--cc=s.riedmueller@phytec.de \
--cc=stable@vger.kernel.org \
--cc=troy.kisky@boundarydevices.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;
as well as URLs for NNTP newsgroup(s).