From: Greg KH <gregkh@linuxfoundation.org>
To: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org, tiwai@suse.de,
alsa-devel@alsa-project.org, jani.nikula@intel.com,
Imre Deak <imre.deak@intel.com>,
Russell King <rmk+kernel@arm.linux.org.uk>,
"Rafael J . Wysocki" <rafael@kernel.org>,
intel-gfx@lists.freedesktop.org,
Russell King <rmk+kernel@armlinux.org.uk>
Subject: Re: [Intel-gfx] [PATCH v2] component: do not leave master devres group open after bind
Date: Tue, 5 Oct 2021 16:35:55 +0200 [thread overview]
Message-ID: <YVxiyzNrKG8S1GDb@kroah.com> (raw)
In-Reply-To: <20210922085432.2776886-1-kai.vehmanen@linux.intel.com>
On Wed, Sep 22, 2021 at 11:54:32AM +0300, Kai Vehmanen wrote:
> In current code, the devres group for aggregate master is left open
> after call to component_master_add_*(). This leads to problems when the
> master does further managed allocations on its own. When any
> participating driver calls component_del(), this leads to immediate
> release of resources.
>
> This came up when investigating a page fault occurring with i915 DRM
> driver unbind with 5.15-rc1 kernel. The following sequence occurs:
>
> i915_pci_remove()
> -> intel_display_driver_unregister()
> -> i915_audio_component_cleanup()
> -> component_del()
> -> component.c:take_down_master()
> -> hdac_component_master_unbind() [via master->ops->unbind()]
> -> devres_release_group(master->parent, NULL)
>
> With older kernels this has not caused issues, but with audio driver
> moving to use managed interfaces for more of its allocations, this no
> longer works. Devres log shows following to occur:
>
> component_master_add_with_match()
> [ 126.886032] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000323ccdc5 devm_component_match_release (24 bytes)
> [ 126.886045] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000865cdb29 grp< (0 bytes)
> [ 126.886049] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 grp< (0 bytes)
>
> audio driver completes its PCI probe()
> [ 126.892238] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 pcim_iomap_release (48 bytes)
>
> component_del() called() at DRM/i915 unbind()
> [ 137.579422] i915 0000:00:02.0: DEVRES REL 00000000ef44c293 grp< (0 bytes)
> [ 137.579445] snd_hda_intel 0000:00:1f.3: DEVRES REL 00000000865cdb29 grp< (0 bytes)
> [ 137.579458] snd_hda_intel 0000:00:1f.3: DEVRES REL 000000001b480725 pcim_iomap_release (48 bytes)
>
> So the "devres_release_group(master->parent, NULL)" ends up freeing the
> pcim_iomap allocation. Upon next runtime resume, the audio driver will
> cause a page fault as the iomap alloc was released without the driver
> knowing about it.
>
> Fix this issue by using the "struct master" pointer as identifier for
> the devres group, and by closing the devres group after
> the master->ops->bind() call is done. This allows devres allocations
> done by the driver acting as master to be isolated from the binding state
> of the aggregate driver. This modifies the logic originally introduced in
> commit 9e1ccb4a7700 ("drivers/base: fix devres handling for master device")
>
> BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/4136
> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
> Acked-by: Imre Deak <imre.deak@intel.com>
> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> drivers/base/component.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
What commit does this "fix:"? And does it need to go to stable
kernel(s)?
thanks,
greg k-h
next prev parent reply other threads:[~2021-10-05 14:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 8:54 [Intel-gfx] [PATCH v2] component: do not leave master devres group open after bind Kai Vehmanen
2021-09-22 10:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success for component: do not leave master devres group open after bind (rev2) Patchwork
2021-09-22 12:52 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-09-28 10:22 ` [Intel-gfx] [PATCH v2] component: do not leave master devres group open after bind Takashi Iwai
2021-09-28 10:45 ` Kai Vehmanen
2021-10-05 14:35 ` Greg KH [this message]
2021-10-06 13:47 ` Kai Vehmanen
2021-10-13 13:09 ` Greg KH
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=YVxiyzNrKG8S1GDb@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alsa-devel@alsa-project.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=rafael@kernel.org \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=rmk+kernel@armlinux.org.uk \
--cc=tiwai@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox