Hey Greg,
The fix should be applied to all stable trees.
I backported one that works for
4.14
4.19
5.4
5.10
And one for
5.15
Regards,
Christian
-----Original Message-----
From: gregkh@xxxxxxxxxxxxxxxxxxx <gregkh@xxxxxxxxxxxxxxxxxxx>
Sent: Monday, June 5, 2023 9:50 PM
To: Christian Loehle <CLoehle@xxxxxxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
Subject: Re: [PATCH] mmc: block: ensure error propagation for non-blk
CAUTION: this mail comes from external!/ACHTUNG: Diese Mail kommt von extern!
On Mon, Jun 05, 2023 at 01:46:16PM +0000, Christian Loehle wrote:
> commit 003fb0a51162d940f25fc35e70b0996a12c9e08a upstream.
>
> Requests to the mmc layer usually come through a block device IO.
> The exceptions are the ioctl interface, RPMB chardev ioctl and
> debugfs, which issue their own blk_mq requests through blk_execute_rq
> and do not query the BLK_STS error but the mmcblk-internal
> drv_op_result. This patch ensures that drv_op_result defaults to an
> error and has to be overwritten by the operation to be considered
> successful.
>
> The behavior leads to a bug where the request never propagates the
> error, e.g. by directly erroring out at mmc_blk_mq_issue_rq if
> mmc_blk_part_switch fails. The ioctl caller of the rpmb chardev then
> can never see an error (BLK_STS_IOERR, but drv_op_result is unchanged)
> and thus may assume that their call executed successfully when it did not.
>
> While always checking the blk_execute_rq return value would be
> advised, let's eliminate the error by always setting drv_op_result as
> -EIO to be overwritten on success (or other error)
>
> Fixes: 614f0388f580 ("mmc: block: move single ioctl() commands to
> block requests")
> Signed-off-by: Christian Loehle <cloehle@xxxxxxxxxxxxxx>
> ---
> drivers/mmc/core/block.c | 5 +++++
> 1 file changed, 5 insertions(+)
What stable tree(s) do you want this applied to?
thanks,
greg k-hAttachment:
smime.p7s
Description: S/MIME cryptographic signature
