linux-kernel - Re: [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180917205634.6a320cad@aktux>
Date:   Mon, 17 Sep 2018 20:56:34 +0200
From:   Andreas Kemnade <andreas@...nade.info>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     kishon@...com, lee.jones@...aro.org, daniel.thompson@...aro.org,
        wsa@...-dreams.de, linux-omap@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access

Hi Dmitry,

On Mon, 17 Sep 2018 10:51:31 -0700
Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:

> Hi Andreas,
> 
> On Mon, Sep 17, 2018 at 07:22:54AM +0200, Andreas Kemnade wrote:
> > When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS,
> > the counter will be incremented but the resume callback not called,
> > so enumeration and charging will not start properly.
> > To avoid that happen, wait and try again later.
> > 
> > Practically this happens when the device is woken up from suspend by
> > plugging in usb.
> > 
> > Signed-off-by: Andreas Kemnade <andreas@...nade.info>
> > ---
> >  drivers/phy/ti/phy-twl4030-usb.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c
> > index a44680d64f9b..1f3cf4e48383 100644
> > --- a/drivers/phy/ti/phy-twl4030-usb.c
> > +++ b/drivers/phy/ti/phy-twl4030-usb.c
> > @@ -552,6 +552,15 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
> >  
> >  	status = twl4030_usb_linkstat(twl);
> >  
> > +	/* we might get here too early when runtime is not ready yet
> > +	 * and we will get an EACCESS later, so try again later
> > +	 */  
> 
> How exactly can this happen? What disables (and later re-enables)
> runtime PM? 
If the whole resume process is started by plugging in usb, the
interrupt will be triggered still in the resume process so that 
runtime resume is not yet possible, pm_runtime_get_sync() returns
EACCESS

> How can we guarantee that the interrupt will be
> re-triggered?
> 
The interrupt will not be re-triggered but the handler will be
called at some other places...

> > +	if (!pm_runtime_enabled(twl->dev)) {
> > +		cancel_delayed_work(&twl->id_workaround_work);
> > +		schedule_delayed_work(&twl->id_workaround_work, HZ);
> > +		return IRQ_HANDLED;
> > +	}
> > +
... for example by this delayed work which is already there.

Regards,
Andreas

Content of type "application/pgp-signature" skipped