From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>, Jonathan Corbet <corbet@lwn.net>,
linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 8/9] block: add configurable error injection
Date: Tue, 2 Jun 2026 10:42:35 +0100 [thread overview]
Message-ID: <ah6li1JOGrpXor9W@kbusch-mbp> (raw)
In-Reply-To: <20260602054615.3788425-9-hch@lst.de>
On Tue, Jun 03, 2026 at 07:45:40AM +0200, Christoph Hellwig wrote:
> +static int error_inject_add(struct gendisk *disk, enum req_op op,
> + sector_t start, u64 nr_sectors, blk_status_t status,
> + unsigned int chance)
> +{
> + struct blk_error_inject *inj;
> +
> + if (op == REQ_OP_LAST)
> + return -EINVAL;
> + if (status == BLK_STS_OK)
> + return -EINVAL;
> + if (U64_MAX - nr_sectors < start)
> + return -EINVAL;
> +
> + if (!nr_sectors)
> + nr_sectors = U64_MAX;
> +
...
> +
> + inj->op = op;
> + inj->start = start;
> + inj->end = start + nr_sectors - 1;
When nr_sectors is 0, it is reset to U64_MAX so overflows if start > 1.
I think you want to remove overriding nr_sectors to U64_MAX and do:
if (!nr_sectors)
inj->end = U64_MAX;
else if (U64_MAX - nr_sectors < start )
return -EINVAL;
else
inj->end = start + nr_sectors - 1;
> + inj->status = status;
> + inj->chance = chance;
> +
> + /*
> + * Add to the front of the list so that newer entries can partially
> + * override other entries. This also intentional allows duplicate
> + * entries as there is no real reason to reject them.
> + */
> + mutex_lock(&disk->error_injection_lock);
> + if (!disk_live(disk)) {
> + mutex_unlock(&disk->error_injection_lock);
> + return -EINVAL;
I think we've leaked 'inj' in this error case.
> + }
> + list_add(&inj->entry, &disk->error_injection_list);
The __blk_error_inject interates this list with
"list_for_each_entry_rcu", so shouldn't this be list_add_rcu to match?
> + mutex_unlock(&disk->error_injection_lock);
> +
> + bdev_set_flag(disk->part0, BD_MAKE_IT_FAIL);
> + return 0;
> +}
<snip>
> +static const match_table_t opt_tokens = {
> + { Opt_add, "add", },
> + { Opt_removeall, "removeall", },
> + { Opt_op, "op=%s", },
> + { Opt_start, "start=%u" },
> + { Opt_nr_sectors, "nr_sectors=%u" },
Shouldn't start and nr_sectors use %llu?
> +static ssize_t blk_error_injection_write(struct file *file,
> + const char __user *ubuf, size_t count, loff_t *pos)
> +{
...
> + options = memdup_user_nul(ubuf, count);
> + if (!options)
> + return -ENOMEM;
> +
On failure, memdup_user_nul returns an ERR_PTR rather than NULL.
if (IS_ERR(options))
return PTR_ERR(options);
> + case Removeall:
> + if (option_mask & ~Opt_removeall)
> + return -EINVAL;
Leaking "options"? Should this be:
if (option_mask & ~Opt_removeall) {
ret = -EINVAL;
goto out_free_options;
}
?
> + error_inject_removall(disk);
> + break;
> + default:
> + ret = -EINVAL;
> + }
> +
> + if (!ret)
> + ret = count;
> +out_free_options:
> + kfree(options);
> + return ret;
> +}
next prev parent reply other threads:[~2026-06-02 9:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 5:45 configurable block error injection Christoph Hellwig
2026-06-02 5:45 ` [PATCH 1/9] block: remove ALLOW_ERROR_INJECTION for should_fail_bio Christoph Hellwig
2026-06-02 5:45 ` [PATCH 2/9] block: consolidate the calls to should_fail_bio Christoph Hellwig
2026-06-02 5:45 ` [PATCH 3/9] block: refactor should_fail_bio and should_fail_request Christoph Hellwig
2026-06-02 5:45 ` [PATCH 4/9] block: move the FAIL_MAKE_REQUEST symbol from lib/ to block/ Christoph Hellwig
2026-06-02 5:45 ` [PATCH 5/9] block: add a macro to initialize the status table Christoph Hellwig
2026-06-02 5:45 ` [PATCH 6/9] block: add a "tag" for block status codes Christoph Hellwig
2026-06-02 5:45 ` [PATCH 7/9] block: add a str_to_blk_op helper Christoph Hellwig
2026-06-02 5:45 ` [PATCH 8/9] block: add configurable error injection Christoph Hellwig
2026-06-02 9:42 ` Keith Busch [this message]
2026-06-02 14:46 ` Christoph Hellwig
2026-06-02 17:56 ` Randy Dunlap
2026-06-02 5:45 ` [PATCH 9/9] block: move the fail request code Christoph Hellwig
2026-06-02 9:43 ` configurable block error injection Keith Busch
2026-06-02 9:58 ` Daniel Gomez
2026-06-02 15:05 ` Christoph Hellwig
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=ah6li1JOGrpXor9W@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.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