mmc: block: ensure error propagation for non-blk
Subsystems (2)
PATCH 1/1 mmc: block: ensure error propagation for non-blk
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)
--- drivers/mmc/core/block.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/mmc/core/block.c +5 -0
@@ -243,6 +243,7 @@ static ssize_t power_ro_lock_store(struct device *dev, goto out_put; }req_to_mmc_queue_req (req)->drv_op =MMC_DRV_OP_BOOT_WP ; +req_to_mmc_queue_req (req)->drv_op_result = -EIO ;blk_execute_rq (mq->queue,NULL , req,0 ); ret =req_to_mmc_queue_req (req)->drv_op_result;blk_put_request (req);
@@ -671,6 +672,7 @@ static int mmc_blk_ioctl_cmd(struct mmc_blk_data *md, idatas[0 ] = idata;req_to_mmc_queue_req (req)->drv_op = rpmb ?MMC_DRV_OP_IOCTL_RPMB :MMC_DRV_OP_IOCTL ; +req_to_mmc_queue_req (req)->drv_op_result = -EIO ;req_to_mmc_queue_req (req)->drv_op_data = idatas;req_to_mmc_queue_req (req)->ioc_count =1 ;blk_execute_rq (mq->queue,NULL , req,0 );
@@ -741,6 +743,7 @@ static int mmc_blk_ioctl_multi_cmd(struct mmc_blk_data *md, }req_to_mmc_queue_req (req)->drv_op = rpmb ?MMC_DRV_OP_IOCTL_RPMB :MMC_DRV_OP_IOCTL ; +req_to_mmc_queue_req (req)->drv_op_result = -EIO ;req_to_mmc_queue_req (req)->drv_op_data = idata;req_to_mmc_queue_req (req)->ioc_count = num_of_cmds;blk_execute_rq (mq->queue,NULL , req,0 );
@@ -2590,6 +2593,7 @@ static int mmc_dbg_card_status_get(void *data, u64 *val)if (IS_ERR (req))return PTR_ERR (req);req_to_mmc_queue_req (req)->drv_op =MMC_DRV_OP_GET_CARD_STATUS ; +req_to_mmc_queue_req (req)->drv_op_result = -EIO ;blk_execute_rq (mq->queue,NULL , req,0 ); ret =req_to_mmc_queue_req (req)->drv_op_result;if (ret >=0 ) {
@@ -2628,6 +2632,7 @@ static int mmc_ext_csd_open(struct inode *inode, struct file *filp) goto out_free; }req_to_mmc_queue_req (req)->drv_op =MMC_DRV_OP_GET_EXT_CSD ; +req_to_mmc_queue_req (req)->drv_op_result = -EIO ;req_to_mmc_queue_req (req)->drv_op_data = &ext_csd;blk_execute_rq (mq->queue,NULL , req,0 ); err =req_to_mmc_queue_req (req)->drv_op_result;
--
2.37.3
[email protected]
maintainerQuoted 20 lines · Christian Loehle
commit
003fb0a51162d940f25fc35e70b0996a12c9e08aupstream.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_mqrequests throughblk_execute_rqand do not query theBLK_STSerror but the mmcblk-internaldrv_op_result. This patch ensures thatdrv_op_resultdefaults 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_rqifmmc_blk_part_switchfails. The ioctl caller of the rpmb chardev then can never see an error (BLK_STS_IOERR, butdrv_op_resultis unchanged) and thus may assume that their call executed successfully when it did not.While always checking the
blk_execute_rqreturn value would be advised, let's eliminate the error by always settingdrv_op_resultas-EIOto be overwritten on success (or other error)
Quoted 5 lines
Fixes 614f0388f580 ("mmc: block: move single ioctl() commands to block requests")Signed-off-by Christian Loehle <[email protected]>--- drivers/mmc/core/block.c | 5 +++++ 1 file changed, 5 insertions(+)
What stable tree(s) do you want this applied to?
thanks,
greg k-h
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: [email protected] <[email protected]>
Sent: Monday, June 5, 2023 9:50 PM
To: Christian Loehle <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] mmc: block: ensure error propagation for non-blk
CAUTION: this mail comes from external!/ACHTUNG: Diese Mail kommt von extern!
Quoted 20 lines · Christian Loehle
commit
003fb0a51162d940f25fc35e70b0996a12c9e08aupstream.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_mqrequests throughblk_execute_rqand do not query theBLK_STSerror but the mmcblk-internaldrv_op_result. This patch ensures thatdrv_op_resultdefaults 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_rqifmmc_blk_part_switchfails. The ioctl caller of the rpmb chardev then can never see an error (BLK_STS_IOERR, butdrv_op_resultis unchanged) and thus may assume that their call executed successfully when it did not.While always checking the
blk_execute_rqreturn value would be advised, let's eliminate the error by always settingdrv_op_resultas-EIOto be overwritten on success (or other error)
Quoted 6 lines
Fixes 614f0388f580 ("mmc: block: move single ioctl() commands toblock requests")
Signed-off-by Christian Loehle <[email protected]>--- drivers/mmc/core/block.c | 5 +++++ 1 file changed, 5 insertions(+)
What stable tree(s) do you want this applied to?
thanks,
greg k-h
[email protected]
maintainerQuoted 9 lines · Christian Loehle
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
How can I know which from which? Please give me us a hint somehow to know this...
Can you resend these, with that hint either in the subject line (i.e. [PATCH 5.15]), or below the --- line.
thanks,
greg k-h