> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> Sent: Wednesday, February 6, 2019 9:08 AM
> To: Adrian Hunter <adrian.hunter@xxxxxxxxx>
> Cc: Zak Hays <zak.hays@xxxxxxxxxxx>; Christoph Hellwig <hch@xxxxxx>;
> linux-mmc@xxxxxxxxxxxxxxx; linux-block <linux-block@xxxxxxxxxxxxxxx>;
> Linus Walleij <linus.walleij@xxxxxxxxxx>
> Subject: Re: [PATCH] mmc: block: handle complete_work on separate
> workqueue
>
> On Wed, 6 Feb 2019 at 13:43, Adrian Hunter <adrian.hunter@xxxxxxxxx>
> wrote:
> >
> > On 6/02/19 2:00 PM, Ulf Hansson wrote:
> > > + Adrian, Linus
> > >
> > > On Tue, 5 Feb 2019 at 17:53, Zachary Hays <zhays@xxxxxxxxxxx> wrote:
> > >>
> > >> The kblockd workqueue is created with the WQ_MEM_RECLAIM flag
> set.
> > >> This generates a rescuer thread for that queue that will trigger when
> > >> the CPU is under heavy load and collect the uncompleted work.
> > >>
> > >> In the case of mmc, this creates the possibility of a deadlock as
> > >> other blk-mq work is also run on the same queue. For example:
> > >>
> > >> - worker 0 claims the mmc host
> > >> - worker 1 attempts to claim the host
> > >> - worker 0 schedules complete_work to release the host
> > >> - rescuer thread is triggered after time-out and collects the dangling
> > >> work
> > >> - rescuer thread attempts to complete the work in order starting with
> > >> claim host
> > >> - the task to release host is now blocked by a task to claim it and
> > >> will never be called
> > >>
> > >
> > > Adrian, I need your help to understand more of this. The above
> > > description doesn't add up to me.
> > >
> > > In principle, already when "worker 1 attempts to claim the host" as
> > > described above, it should succeed and should *not* need to wait for
> > > the host to be released. Right?
> >
> > If it is the same queue, then yes. Although in that case there is only 1
> > work for the hw queue so there cannot be another worker. There could be
> > another attempt to send a request directly, but that will not block - if the
> > host controller is busy, BLK_STS_RESOURCE will be returned from -
> >queue_rq().
> >
>
> Right.
>
> > >
> > > The hole point with the commit 6c0cedd1ef95 ("mmc: core: Introduce
> > > host claiming by context"), was to allow the mmc host to be
> > > re-claimable for blk I/O requests, no matter from what worker/thread
> > > the claim/release is done from.
> > >
> > > Is it not working as expected you think? What am I missing here?
> >
> > I assumed we were talking about a situation where there are multiple
> > internal eMMC partitions each with their own disk and queue. In that case,
> > a queue waits if there is another queue that is using the eMMC.
>
> Of course! I totally forgot about this case, that is most certainly
> what must be happening!
>
> >
> > We should clarify whether that is the scenario we are looking at. Zachary?
>
> Yes, please.
Yes, this is the case. There are multiple partitions on the eMMC.
>
> Assuming this is the case, I would also prefer an updated changelog
> that describe this scenario.
I will update the commit message to clarify this and resubmit.
> Adrian, thanks a lot for you help!
>
> [...]
>
> Kind regards
> Uffe
