From: Andreas Hindborg <a.hindborg@kernel.org>
To: "John Garry" <john.g.garry@oracle.com>
Cc: "Jens Axboe" <axboe@kernel.dk>,
"Oliver Mangold" <oliver.mangold@pm.me>,
<linux-block@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] block: set bi_vcnt when cloning bio
Date: Tue, 18 Feb 2025 12:40:57 +0100 [thread overview]
Message-ID: <87r03vfpkm.fsf@kernel.org> (raw)
In-Reply-To: <f4f4fff4-5055-47f7-9f24-6b1780920f4d@oracle.com> (John Garry's message of "Tue, 18 Feb 2025 10:40:35 +0000")
"John Garry" <john.g.garry@oracle.com> writes:
> On 15/02/2025 10:58, Andreas Hindborg wrote:
>> When cloning a bio, the `bio.bi_vcnt` field is not cloned. This is a
>> problem if users want to perform bounds checks on the `bio.bi_io_vec`
>> field.
>
> Is this fixing a potential problem? Or fixing a real issue?
It is fixing a problem I ran into in rnull, the rust null block
implementation. When running with debug assertions enabled, a bound
check on `bi_io_vec` fails for split bio, because `bio_vcnt` becomes
zero in the cloned bio.
I can work around this by not using a slice type to represent
`bi_io_vec` in rust, not a big deal.
But I am genuinely curious if there is a reason for not setting
`bi_vcnt` during a clone. As far as I can tell, it should be safe to
set. `bi_vcnt` being zero does not seem to have any effect other than to
puzzle developers debugging the code.
Maybe I missed something?
Best regards,
Andreas Hindborg
next prev parent reply other threads:[~2025-02-18 11:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-15 10:58 [PATCH] block: set bi_vcnt when cloning bio Andreas Hindborg
2025-02-18 10:40 ` John Garry
2025-02-18 11:40 ` Andreas Hindborg [this message]
2025-02-18 17:12 ` John Garry
2025-02-18 18:20 ` Andreas Hindborg
2025-02-18 22:21 ` Bart Van Assche
2025-02-19 14:19 ` John Garry
2025-02-20 6:11 ` 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=87r03vfpkm.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=axboe@kernel.dk \
--cc=john.g.garry@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.mangold@pm.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.