Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Johan Hovold <johan@kernel.org>]

Hi Geert,

On Mon, Sep 07, 2026 at 02:17:45PM +0200, Geert Uytterhoeven wrote:
> Hi Johan,
> 
> On Mon, 17 Aug 2026 at 10:13, Johan Hovold <johan@kernel.org> wrote:
> > On Sun, Aug 16, 2026 at 05:38:09PM +0200, Jakov Novak wrote:
> > >  Currently, the function vub300_inactivity_timer_expired, which gets
> > >  called in a softirq context, calls a sleeping function in the following
> > >  call chain:
> > >
> > >  vub300_inactivity_timer_expired -> kref_put -> vub300_delete ->
> > >  mmc_free_host -> cancel_delayed_work_sync -> __cancel_work_sync ->
> > >  might_sleep -> BUG
> > >
> > >  Fix this by replacing kref_put(&vub300->kref, vub300_delete) with
> > >  vub300_queue_dead_work(vub300), which does the same thing, but in a
> > >  workqueue context.
> > >
> > > Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
> >
> > This isn't the commit that introduced the issue. The blocking call in
> > mmc_free_host() was added by commit 1036f69e2513 ("mmc: core: Cancel
> > delayed work before releasing host") in 2023.
> >
> > I didn't look at this in any detail, but having that call in
> > mmc_free_host() (e.g. rather than in mmc_remove_host()) looks wrong so
> > perhaps the fix really lies in MMC core.
> 
> mmc_remove_host() can only be called after a sucessful probe, while
> commit 1036f69e2513 fixed an issue where the last probe step failed
> with -EPROBE_DEFER.

Sure, but should you be scheduling rescan work before all resources have
been set up and the host has been registered?

Johan