linux-kernel - Re: [PATCH 2/2] mmc: queue: Flush recovery work on cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPDyKFqw2CNS+M5iMcP-_FyBThrUvGbyECMrEJheUD4YP7fwEw@mail.gmail.com>
Date:   Fri, 7 Oct 2022 15:12:36 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Adrian Hunter <adrian.hunter@...el.com>,
        Christian Löhle <CLoehle@...erstone.com>
Cc:     Linux MMC List <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] mmc: queue: Flush recovery work on cleanup

On Thu, 6 Oct 2022 at 15:39, Christian Löhle <CLoehle@...erstone.com> wrote:
>
> To prevent any recovery work running after the queue cleanup flush it.
> Any recovery running post-cleanup dereferenced mq->card as NULL
> and was not meaningful to begin with.
>
> Cc: stable@...r.kernel.org
>
> Signed-off-by: Christian Loehle <cloehle@...erstone.com>
> ---
>  drivers/mmc/core/queue.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> index fefaa901b50f..a1b985d3dfda 100644
> --- a/drivers/mmc/core/queue.c
> +++ b/drivers/mmc/core/queue.c
> @@ -493,6 +493,13 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
>         if (blk_queue_quiesced(q))
>                 blk_mq_unquiesce_queue(q);
>
> +       /*
> +        * If the recovery completes the last (and only remaining) request in
> +        * the queue, and the card has been removed, we could end up here with
> +        * the recovery not quite finished yet, so flush it.
> +        */
> +       flush_work(&mq->recovery_work);
> +

Not sure if it really matters in this case, but isn't
cancel_work_sync() the more proper thing to call instead?

>         blk_mq_free_tag_set(&mq->tag_set);
>
>         /*

Kind regards
Uffe