All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Loic Poulain <loic.poulain@oss.qualcomm.com>
Cc: vkoul@kernel.org, kishon@kernel.org,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	dmitry.baryshkov@oss.qualcomm.com, neil.armstrong@linaro.org,
	konrad.dybcio@oss.qualcomm.com,
	Abel Vesa <abel.vesa@oss.qualcomm.com>
Subject: Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
Date: Fri, 13 Feb 2026 11:45:06 +0100	[thread overview]
Message-ID: <aY8Asvu-1u0e02oJ@hovoldconsulting.com> (raw)
In-Reply-To: <CAFEp6-3yk3sPXj+hGuWvAFsFJAXjH4kWLV8k_5_v9Hax0XxaOg@mail.gmail.com>

On Fri, Feb 13, 2026 at 10:45:32AM +0100, Loic Poulain wrote:
> On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > > Enabling runtime PM before attaching the hsphy instance as driver data
> > > can lead to a NULL pointer dereference in runtime PM callbacks that
> > > expect valid driver data. There is a small window where the suspend
> > > callback may run after PM runtime enabling and before runtime forbid.
> >
> > So here too, the commit should reflect that this cannot really happen in
> > practice.
> 
> This happened  in practice in the qcom‑qusb2 PHY driver, with the same
> code flow.
> Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
> Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/

Thanks for the link.

> I know it may sound unlikely, but this crash has been reported
> several times during boot‑stress testing. I haven’t investigated
> deeply enough to determine whether it’s caused by an unfortunate
> preemption window or a racing CPU.

But I'm literally asking for *what* would trigger the suspend in that
initial window between enable() and forbid() cause I don't see it.

A racing user space daemon re-enabling runtime PM after forbid() is
the only thing I can think of that could trigger this.

Johan

WARNING: multiple messages have this Message-ID (diff)
From: Johan Hovold <johan@kernel.org>
To: Loic Poulain <loic.poulain@oss.qualcomm.com>
Cc: vkoul@kernel.org, kishon@kernel.org,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	dmitry.baryshkov@oss.qualcomm.com, neil.armstrong@linaro.org,
	konrad.dybcio@oss.qualcomm.com,
	Abel Vesa <abel.vesa@oss.qualcomm.com>
Subject: Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
Date: Fri, 13 Feb 2026 11:45:06 +0100	[thread overview]
Message-ID: <aY8Asvu-1u0e02oJ@hovoldconsulting.com> (raw)
In-Reply-To: <CAFEp6-3yk3sPXj+hGuWvAFsFJAXjH4kWLV8k_5_v9Hax0XxaOg@mail.gmail.com>

On Fri, Feb 13, 2026 at 10:45:32AM +0100, Loic Poulain wrote:
> On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > > Enabling runtime PM before attaching the hsphy instance as driver data
> > > can lead to a NULL pointer dereference in runtime PM callbacks that
> > > expect valid driver data. There is a small window where the suspend
> > > callback may run after PM runtime enabling and before runtime forbid.
> >
> > So here too, the commit should reflect that this cannot really happen in
> > practice.
> 
> This happened  in practice in the qcom‑qusb2 PHY driver, with the same
> code flow.
> Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
> Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/

Thanks for the link.

> I know it may sound unlikely, but this crash has been reported
> several times during boot‑stress testing. I haven’t investigated
> deeply enough to determine whether it’s caused by an unfortunate
> preemption window or a racing CPU.

But I'm literally asking for *what* would trigger the suspend in that
initial window between enable() and forbid() cause I don't see it.

A racing user space daemon re-enabling runtime PM after forbid() is
the only thing I can think of that could trigger this.

Johan

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-02-13 10:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-05 16:02 [PATCH v3 0/5] phy: qcom: Fix possible NULL-deref and runtime PM race conditions Loic Poulain
2026-02-05 16:02 ` Loic Poulain
2026-02-05 16:02 ` [PATCH v3 1/5] phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot Loic Poulain
2026-02-05 16:02   ` Loic Poulain
2026-02-13  8:47   ` Johan Hovold
2026-02-13  8:47     ` Johan Hovold
2026-02-05 16:02 ` [PATCH v3 2/5] phy: qcom: qmp-usbc: " Loic Poulain
2026-02-05 16:02   ` Loic Poulain
2026-02-09 13:18   ` Dmitry Baryshkov
2026-02-09 13:18     ` Dmitry Baryshkov
2026-02-05 16:02 ` [PATCH v3 3/5] phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend Loic Poulain
2026-02-05 16:02   ` Loic Poulain
2026-02-09 13:18   ` Dmitry Baryshkov
2026-02-09 13:18     ` Dmitry Baryshkov
2026-02-13  9:02   ` Johan Hovold
2026-02-13  9:02     ` Johan Hovold
2026-02-05 16:02 ` [PATCH v3 4/5] phy: qcom: qmp-usb-legacy: Prevent unnecessary PM runtime suspend at boot Loic Poulain
2026-02-05 16:02   ` Loic Poulain
2026-02-09 13:18   ` Dmitry Baryshkov
2026-02-09 13:18     ` Dmitry Baryshkov
2026-02-05 16:02 ` [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Loic Poulain
2026-02-05 16:02   ` Loic Poulain
2026-02-13  9:07   ` Johan Hovold
2026-02-13  9:07     ` Johan Hovold
2026-02-13  9:45     ` Loic Poulain
2026-02-13  9:45       ` Loic Poulain
2026-02-13 10:45       ` Johan Hovold [this message]
2026-02-13 10:45         ` Johan Hovold
2026-02-13 15:04         ` Loic Poulain
2026-02-13 15:04           ` Loic Poulain
2026-02-13 20:15           ` Vladimir Oltean
2026-02-13 20:15             ` Vladimir Oltean
2026-02-16 10:47             ` Johan Hovold
2026-02-16 10:47               ` Johan Hovold
2026-02-17 10:40               ` Loic Poulain
2026-02-17 10:40                 ` Loic Poulain
2026-02-16 10:41           ` Johan Hovold
2026-02-16 10:41             ` Johan Hovold
2026-05-11 14:02 ` [PATCH v3 0/5] phy: qcom: Fix possible NULL-deref and runtime PM race conditions Vladimir Oltean
2026-05-11 14:02   ` Vladimir Oltean

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=aY8Asvu-1u0e02oJ@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=abel.vesa@oss.qualcomm.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=kishon@kernel.org \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=loic.poulain@oss.qualcomm.com \
    --cc=neil.armstrong@linaro.org \
    --cc=vkoul@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.