Re: [PATCH 2/2] mmc: core: Turn mmc_alloc|free_host() into static functions

[Ulf Hansson]

On Wed, Sep 16, 2026 at 12:00 PM Johan Hovold <johan@xxxxxxxxxx> wrote:
>
> On Wed, Sep 16, 2026 at 11:36:25AM +0200, Ulf Hansson wrote:
> > On Wed, Sep 16, 2026 at 9:43 AM Johan Hovold <johan@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Sep 15, 2026 at 03:20:46PM +0200, Ulf Hansson wrote:
> > > > From: Ulf Hansson <ulfh@xxxxxxxxxx>
> > > >
> > > > As there are no longer any users of these functions, let's make them
> > > > internal to the mmc core.
> > >
> > > Why would you want to do that? The devres helpers should just be simple
> > > wrappers around these and sometimes devres just isn't a good fit.
> >
> > At the moment there seems to be no need for them. I would rather keep
> > API/interfaces as simple as possible, so I prefer to remove them at
> > this point.
> >
> > If we see a need for them, we can always add them back.
>
> Devres generally only works when all resources are device managed.
> Therefore you should always provide the underlying non-devres manages
> interface as well so that you don't force devres on drivers where it
> could cause trouble.
>
> > > Especially with the work cancellations present in mmc_free_host() (which
> > > I have pointed out elsewhere should not be there), a driver may need to
> > > free the host before tearing down other non-devres managed resources
> > > during unbind.
> >
> > Can you please point me to such an example so I can try to understand better?
>
> We just discussed the renesas driver which can schedule rescan work
> before registering the host controller. [1]

That isn't a problem, but it's not the right thing to do as
host->rescan_disable is set.

>
> If such a driver also has non-devres managed resources that are freed
> before the work is cancelled you have a use-after-free.

If you are referring to the mmc rescan work; mmc_rescan() will just
bail out as host->rescan_disable has been set as soon as
mmc_remove_host() is called (see mmc_stop_host()). In other words, I
don't see how a use-after-free would be possible in this regard.

If you are referring to an internal work for the host, yes that needs
to be managed correctly. Although, that doesn't matter whether the mmc
host has been allocated with the resource managed variant or not.

>
> > > This may even be needed for greybus which currently destroys the
> > > connection before freeing the host.
> >
> > I looked closer at gb_sdio_remove() (the greybus sdio driver's
> > ->remove() callback) and I think the problem isn't about freeing the
> > host.
> >
> > Instead it seems like the call to mmc_remove_host() is done too late.
> > To me it looks like when the mmc core tries to power off the card
> > gracefully, through mmc_remove_host() the driver has already moved
> > into a state where it no longer accepts any requests.
>
> Yes, that looks wrong, but that's a separate issue.
>
> I only pointed at greybus as an example of a driver which has non-devres
> managed resources. If there is (rescan) work still scheduled after
> probe() or remove() returns, there's a potential use-after-free.

See above. This should not be an issue, at least it has nothing to do
whether we are using managed resources or not.

For the mmc_rescan() work to access the host internal data (for
potential causing a use-after-free), the host must have been
"started". See mmc_start|stop_host().

>
> Johan
>
>
> [1] https://lore.kernel.org/lkml/ap7CaVj82BJZgjf6@xxxxxxxxxxxxxxxxxxxx/

Kind regards
Uffe