linux-kernel - Re: [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy

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: <147700563857.2550.16732518381302920183@sboyd-linaro>
Date:   Thu, 20 Oct 2016 16:20:38 -0700
From:   Stephen Boyd <stephen.boyd@...aro.org>
To:     linux-usb@...r.kernel.org
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org,
        "Andy Gross" <andy.gross@...aro.org>,
        "Bjorn Andersson" <bjorn.andersson@...aro.org>,
        "Neil Armstrong" <narmstrong@...libre.com>,
        "Arnd Bergmann" <arnd@...db.de>, "Felipe Balbi" <balbi@...nel.org>,
        "Peter Chen" <peter.chen@....com>,
        "Kishon Vijay Abraham I" <kishon@...com>,
        devicetree@...r.kernel.org, "Rob Herring" <robh+dt@...nel.org>
Subject: Re: [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy

Quoting Stephen Boyd (2016-10-17 18:56:36)
> +
> +static int
> +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> +                             void *ptr)
> +{
> +       struct qcom_usb_hs_phy *uphy;
> +       int is_host;
> +       u8 addr;
> +
> +       uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> +       is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);

Please don't apply this patch. This call now deadlocks on v4.9-rc1
because of how extcon_get_cable_state_() now grabs a lock that is
already held here when we're inside the notifier. It's not really
required that we grab the lock in extcon there, but this has exposed a
flaw in the logic anyway. We don't know if the id pin is going to toggle
before or after this function is called, so we should really keep track
of both vbus and id state in this driver and then do the same ulpi
writes from two different notifiers for both vbus and id pin. We would
be duplicating work sometimes, but that's pretty much the best solution
I can come up with. Otherwise it's racy.