On Wed, Oct 19, 2022 at 11:02 AM Ville Syrjälä
<ville.syrjala@xxxxxxxxxxxxxxx> wrote:
>
> On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >
> > Commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") failed
> > to reference count the device returned by acpi_get_pci_dev() as
> > expected by its callers which in some cases may cause device objects
> > to be dropped prematurely.
> >
> > Add the missing get_device() to acpi_get_pci_dev().
> >
> > Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
>
> FYI this (and the rtc-cmos regression discussed in
> https://lore.kernel.org/linux-acpi/5887691.lOV4Wx5bFT@kreacher/)
> took down the entire Intel gfx CI.
Sorry for the disturbance.
> I've applied both fixes into our fixup branch and things are looking much
> healthier now.
Thanks for letting me know.
I've just added the $subject patch to my linux-next branch as an
urgent fix and the other one has been applied to the RTC tree.
> This one caused i915 selftests to eat a lot of POISON_FREE
> in the CI. While bisecting it locally I didn't have
> poisoning enabled so I got refcount_t undeflows instead.
Unfortunately, making no mistakes is generally hard to offer.
If catching things like this early is better, what about pulling my
bleeding-edge branch, where all of my changes are staged before going
into linux-next, into the CI?
> https://intel-gfx-ci.01.org/tree/drm-tip/index.html has a lot
> of colorful boxes to click if you're interested in any of the
> logs. The fixes are included in the CI_DRM_12259 build. Earlier
> builds were broken.
Thanks!
