From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Christian Loehle <CLoehle@hyperstone.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] mmc: block: ensure error propagation for non-blk
Date: Mon, 19 Jun 2023 09:46:38 +0200 [thread overview]
Message-ID: <2023061927-shrubbery-presuming-5480@gregkh> (raw)
In-Reply-To: <CAPDyKFq8Q4J3=udE2=VXAfWZhvJuOYJ=4N9B6NFWUys8oxvb3Q@mail.gmail.com>
On Wed, Jun 14, 2023 at 12:20:39PM +0200, Ulf Hansson wrote:
> On Tue, 13 Jun 2023 at 14:43, Christian Loehle <CLoehle@hyperstone.com> 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@hyperstone.com>
>
> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>
All now queued up, thanks.
greg k-h
next prev parent reply other threads:[~2023-06-19 7:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 12:43 [PATCH] mmc: block: ensure error propagation for non-blk Christian Loehle
2023-06-14 10:20 ` Ulf Hansson
2023-06-19 7:46 ` gregkh [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-06-13 12:37 Christian Loehle
2023-06-14 10:20 ` Ulf Hansson
2023-06-05 13:46 Christian Loehle
2023-06-05 19:50 ` gregkh
2023-06-06 12:58 ` Christian Loehle
2023-06-06 13:05 ` gregkh
2023-06-05 12:14 Christian Loehle
[not found] <30da2b2257ee48d3808d6ae5f1972b9e@hyperstone.com>
2023-06-01 9:45 ` gregkh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023061927-shrubbery-presuming-5480@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=CLoehle@hyperstone.com \
--cc=stable@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox