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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ