Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1681388 > unrolled thread

[PATCH 1/2] mmc: block: Preinitialize ret in mmc_blk_issue_drv_op()

Back to article view | Back to linux.kernel

Contents

  [PATCH 1/2] mmc: block: Preinitialize ret in mmc_blk_issue_drv_op() Geert Uytterhoeven <geert@linux-m68k.org> - 2017-07-05 11:10 +0200
    [PATCH 2/2] mmc: block: Let MMC_IOC_MULTI_CMD return zero again for zero entries Geert Uytterhoeven <geert@linux-m68k.org> - 2017-07-05 11:10 +0200
    Re: [PATCH 1/2] mmc: block: Preinitialize ret in mmc_blk_issue_drv_op() Arnd Bergmann <arnd@arndb.de> - 2017-07-05 14:10 +0200
      Re: [PATCH 1/2] mmc: block: Preinitialize ret in mmc_blk_issue_drv_op() Geert Uytterhoeven <geert@linux-m68k.org> - 2017-07-05 17:10 +0200

#1681388 — [PATCH 1/2] mmc: block: Preinitialize ret in mmc_blk_issue_drv_op()

With gcc 4.1.2:

    drivers/mmc/core/block.c: In function ‘mmc_blk_issue_drv_op’:
    drivers/mmc/core/block.c:1178: warning: ‘ret’ may be used uninitialized in this function

Indeed, if mq_rq->ioc_count is zero, an uninitialized value will be
stored in mq_rq->drv_op_result and passed to blk_end_request_all().

Can mq_rq->ioc_count be zero?
  - mmc_blk_ioctl_cmd() sets ioc_count to 1, so this is safe,
  - mmc_blk_ioctl_multi_cmd() obtains ioc_count from user space in
    response to the MMC_IOC_MULTI_CMD ioctl, and does allow zero.

Preinitialize ret to -EINVAL to fix this for current and future callers.

Fixes: 0493f6fe5bdee8ac ("mmc: block: Move boot partition locking into a driver op")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
I assume -EINVAL is the error we want to return here if ioc_count is
zero.
Or should it return success (zero), like mmc_blk_ioctl_multi_cmd() used
to do?
---
 drivers/mmc/core/block.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 0cfac2d391073922..9472e89af3efa37e 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1175,7 +1175,7 @@ static void mmc_blk_issue_drv_op(struct mmc_queue *mq, struct request *req)
 	struct mmc_queue_req *mq_rq;
 	struct mmc_card *card = mq->card;
 	struct mmc_blk_data *md = mq->blkdata;
-	int ret;
+	int ret = -EINVAL;
 	int i;
 
 	mq_rq = req_to_mmc_queue_req(req);
@@ -1206,7 +1206,6 @@ static void mmc_blk_issue_drv_op(struct mmc_queue *mq, struct request *req)
 	default:
 		pr_err("%s: unknown driver specific operation\n",
 		       md->disk->disk_name);
-		ret = -EINVAL;
 		break;
 	}
 	mq_rq->drv_op_result = ret;
-- 
2.7.4

[toc] | [next] | [standalone]

#1681402 — [PATCH 2/2] mmc: block: Let MMC_IOC_MULTI_CMD return zero again for zero entries

With gcc 4.1.2:

    drivers/mmc/core/block.c: In function ‘mmc_blk_ioctl_cmd_issue’:
    drivers/mmc/core/block.c:630: warning: ‘ioc_err’ may be used uninitialized in this function

Indeed, if mq_rq->ioc_count is zero, an uninitialized value will be
stored in mq_rq->drv_op_result and passed to blk_end_request_all().

Can mq_rq->ioc_count be zero?
  - mmc_blk_ioctl_cmd() sets ioc_count to 1, so this is safe,
  - mmc_blk_ioctl_multi_cmd() obtains ioc_count from user space in
    response to the MMC_IOC_MULTI_CMD ioctl, and does allow zero.

To avoid returning an uninitialized value, and as it is pointless to do
all this work when the MMC_IOC_MULTI_CMD ioctl is used with zero
entries, check for this early in mmc_blk_ioctl_multi_cmd(), and return
zero, like was returned before.

Fixes: 3ecd8cf23f88d5df ("mmc: block: move multi-ioctl() to use block layer")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Should mmc_blk_ioctl_multi_cmd() return -EINVAL instead for this case?
That would change behavior as seen from userspace, though.

Feel free to fold in the previous patch if deemed appropriate.
---
 drivers/mmc/core/block.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 9472e89af3efa37e..b236d345d53291f0 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -637,6 +637,9 @@ static int mmc_blk_ioctl_multi_cmd(struct block_device *bdev,
 			   sizeof(num_of_cmds)))
 		return -EFAULT;
 
+	if (!num_of_cmds)
+		return 0;
+
 	if (num_of_cmds > MMC_IOC_MAX_CMDS)
 		return -EINVAL;
 
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1681493

On Wed, Jul 5, 2017 at 11:07 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> With gcc 4.1.2:
>
>     drivers/mmc/core/block.c: In function ‘mmc_blk_issue_drv_op’:
>     drivers/mmc/core/block.c:1178: warning: ‘ret’ may be used uninitialized in this function
>
> Indeed, if mq_rq->ioc_count is zero, an uninitialized value will be
> stored in mq_rq->drv_op_result and passed to blk_end_request_all().
>
> Can mq_rq->ioc_count be zero?
>   - mmc_blk_ioctl_cmd() sets ioc_count to 1, so this is safe,
>   - mmc_blk_ioctl_multi_cmd() obtains ioc_count from user space in
>     response to the MMC_IOC_MULTI_CMD ioctl, and does allow zero.
>
> Preinitialize ret to -EINVAL to fix this for current and future callers.
>
> Fixes: 0493f6fe5bdee8ac ("mmc: block: Move boot partition locking into a driver op")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> I assume -EINVAL is the error we want to return here if ioc_count is
> zero.
> Or should it return success (zero), like mmc_blk_ioctl_multi_cmd() used
> to do?

I would suggest adding the initialization after "case MMC_DRV_OP_IOCTL:"
instead, to keep getting compile-time checks on the state of the 'ret'
variable. In that case, returning '0' is probably good.

      Arnd

[toc] | [prev] | [next] | [standalone]

#1681573

Hi Arnd,

On Wed, Jul 5, 2017 at 2:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Jul 5, 2017 at 11:07 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> With gcc 4.1.2:
>>
>>     drivers/mmc/core/block.c: In function ‘mmc_blk_issue_drv_op’:
>>     drivers/mmc/core/block.c:1178: warning: ‘ret’ may be used uninitialized in this function
>>
>> Indeed, if mq_rq->ioc_count is zero, an uninitialized value will be
>> stored in mq_rq->drv_op_result and passed to blk_end_request_all().
>>
>> Can mq_rq->ioc_count be zero?
>>   - mmc_blk_ioctl_cmd() sets ioc_count to 1, so this is safe,
>>   - mmc_blk_ioctl_multi_cmd() obtains ioc_count from user space in
>>     response to the MMC_IOC_MULTI_CMD ioctl, and does allow zero.
>>
>> Preinitialize ret to -EINVAL to fix this for current and future callers.
>>
>> Fixes: 0493f6fe5bdee8ac ("mmc: block: Move boot partition locking into a driver op")
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> ---
>> I assume -EINVAL is the error we want to return here if ioc_count is
>> zero.
>> Or should it return success (zero), like mmc_blk_ioctl_multi_cmd() used
>> to do?
>
> I would suggest adding the initialization after "case MMC_DRV_OP_IOCTL:"
> instead, to keep getting compile-time checks on the state of the 'ret'
> variable. In that case, returning '0' is probably good.

Makes sense, I actually did consider that, but went with (shared) -EINVAL.

Will send v2 shortly.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web