linux-kernel - Re: [PATCH] ACPI: PCI: Fix device reference counting in acpi_get_pci

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:   Wed, 19 Oct 2022 13:35:26 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: [PATCH] ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()

On Wed, Oct 19, 2022 at 11:02 AM Ville Syrjälä
<ville.syrjala@...ux.intel.com> wrote:
>
> On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > 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!