From: Marc Zyngier <marc.zyngier@arm.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Guenter Roeck <linux@roeck-us.net>, <linux-usb@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] usb: typec: fusb302: Fix debugfs mutex initialisation
Date: Tue, 19 Mar 2019 12:18:07 +0000 [thread overview]
Message-ID: <20190319121807.68c858f7@why.wild-wind.fr.eu.org> (raw)
In-Reply-To: <20190319114511.GS7752@kuha.fi.intel.com>
On Tue, 19 Mar 2019 13:45:11 +0200
Heikki Krogerus <heikki.krogerus@linux.intel.com> wrote:
> On Mon, Mar 18, 2019 at 05:49:06PM +0000, Marc Zyngier wrote:
> > Running a kernel with the fusb302 driver and lockdep enabled
> > leads to an unpleasant warning:
> >
> > [ 4.617477] INFO: trying to register non-static key.
> > [ 4.617930] the code is fine but needs lockdep annotation.
> > [ 4.618418] turning off the locking correctness validator.
> > [ 4.618913] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc1-00007-g3542533f3fc9 #13
> > [ 4.619620] Hardware name: rockchip evb_rk3399/evb_rk3399, BIOS 2019.04-rc3-00124-g2feec69fb1 03/15/2019
> > [ 4.620454] Call trace:
> > [ 4.620693] dump_backtrace+0x0/0x138
> > [ 4.621028] show_stack+0x24/0x30
> > [ 4.621336] dump_stack+0xbc/0x104
> > [ 4.621649] register_lock_class+0x594/0x598
> > [ 4.622036] __lock_acquire+0x80/0x11b8
> > [ 4.622384] lock_acquire+0xdc/0x260
> > [ 4.622711] __mutex_lock+0x90/0x8a0
> > [ 4.623037] mutex_lock_nested+0x3c/0x50
> > [ 4.623394] _fusb302_log+0x88/0x1f0
> > [ 4.623721] fusb302_log+0x7c/0xa0
> > [ 4.624033] tcpm_init+0x5c/0x190
> > [ 4.624336] tcpm_init+0x3c/0x130
> > [ 4.624640] tcpm_register_port+0x574/0x878
> > [ 4.625019] fusb302_probe+0x2c8/0x590
> >
> > Despite what the message says, the code isn't fine, as it tries to
> > make use of the fusb302_log facility pretty early. This requires the
> > logbuffer_lock mutex to be initialised, but that only happens much
> > later. Boo.
> >
> > Hoist the fusb302_debugfs_init call before tcpm_register_port so that
> > we can enjoy a working mutex. At Guenter's request, also add teardown
> > of the debugfs facility on the error path.
> >
> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>
> After applying this there was no more "fusb302" debugfs directory, and
> attempt to unload the fusb302 module dead locked. Also, attempt to
> reboot caused this to happen on my GDPWin board after applying the
> patch:
>
> BUG: Dentry 0000000012f2a05d{i=149,n=i2c-fusb302} still in use (1) [unmount of sysfs sysfs]
> WARNING: CPU: 3 PID: 1639 at fs/dcache.c:1529 umount_check.cold.55+0x2e/0x3a
> Modules linked in: intel_xhci_usb_role_switch roles pi3usb30532 typec i915 intel_gtt intel_cht_int33fe [last unloaded: tcpm]
> CPU: 3 PID: 1639 Comm: umount Not tainted 5.1.0-rc1-heikki+ #916
> Hardware name: Default string Default string/Default string, BIOS 5.11 05/25/2017
> RIP: 0010:umount_check.cold.55+0x2e/0x3a
> ...
OK, that's interesting. On my system, I do have the debugfs file:
root@city-of-tiny-lites:~# cat /sys/kernel/debug/fusb302/4-0022
[ 4.517682] sw reset
[ 4.520379] fusb302 device ID: 0x81
[ 4.523544] pd := off
[ 4.523593] vbus is already Off
[ 4.523603] charge is already Off
[ 4.523615] vconn is already Off
[ 4.524274] pd header := Sink, Device
[ 4.525948] cc1=Open, cc2=Open
[ 4.530345] pd := off
[ 4.530378] vbus is already Off
[ 4.530388] charge is already Off
[ 4.530405] vconn is already Off
[ 4.530931] pd header := Sink, Device
[ 4.533773] cc := Open
[ 4.642347] start drp toggling
I don't use any module though, so maybe there is something there. I'll
investigate.
> Note. Your patch has also a conflict with patches from Hans, I
> think with this one: https://patchwork.kernel.org/patch/10847275/
> I can take care of that, but you can also rebase the next version on
> top of my typec-next branch to solve that problem:
> https://github.com/krohei/linux/commits/typec-next
>
> I think I need to add that to the MAINTAINERS file.
Fair enough. I'll come back once I know what happens here...
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2019-03-19 12:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-18 17:49 [PATCH v2] usb: typec: fusb302: Fix debugfs mutex initialisation Marc Zyngier
2019-03-18 18:18 ` Guenter Roeck
2019-03-19 11:45 ` Heikki Krogerus
2019-03-19 12:18 ` Marc Zyngier [this message]
2019-03-20 16:07 ` Marc Zyngier
2019-03-20 16:34 ` Heikki Krogerus
2019-03-21 13:24 ` Heikki Krogerus
2019-03-21 16:02 ` Marc Zyngier
2019-03-22 8:38 ` Heikki Krogerus
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=20190319121807.68c858f7@why.wild-wind.fr.eu.org \
--to=marc.zyngier@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
/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).