Hi,
On Tue, 5 Oct 2021, Greg KH wrote:
> 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.
[...]
> > 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.vehma...@linux.intel.com>
> > Acked-by: Imre Deak <imre.d...@intel.com>
> > Acked-by: Russell King (Oracle) <rmk+ker...@armlinux.org.uk>
>
> What commit does this "fix:"? And does it need to go to stable
> kernel(s)?
I didn't put a "Fixes" on the original commit 9e1ccb4a7700
("drivers/base: fix devres handling for master device") as it alone
didn't cause problems. It did open the door for possible devres issues
for anybody calling component_master_add_().
On audio side, this surfaced with the more recent commit 3fcaf24e5dce
("ALSA: hda: Allocate resources with device-managed APIs"). In theory one
could have hit issues already before, but this made it very easy to hit
on actual systems.
If I'd have to pick one, it would be 9e1ccb4a7700 ("drivers/base: fix
devres handling for master device"). And yes, given comments on this
thread, I'd say this needs to go to stable kernels.
Br, Kai
