From: Changheun Lee <nanich.lee@samsung.com>
To: bvanassche@acm.org
Cc: axboe@kernel.dk, bgoncalv@redhat.com, hch@lst.de,
jaegeuk@kernel.org, linux-block@vger.kernel.org,
ming.lei@redhat.com, nanich.lee@samsung.com, yi.zhang@redhat.com
Subject: Re: [PATCH v2] block: Improve limiting the bio size
Date: Wed, 28 Apr 2021 16:21:23 +0900 [thread overview]
Message-ID: <20210428072123.3155-1-nanich.lee@samsung.com> (raw)
In-Reply-To: <c5f47617-f06a-d598-1794-118447e8e2b0@acm.org>
> On 4/26/21 9:12 PM, Changheun Lee wrote:
> > Actually I checked "bio->bi_disk" at first as below. It works well.
>
> Agreed that the bi_disk pointer needs to be checked.
>
> > I think "bi_bdev->bd_disk" checking might be needed too.
>
> bio_max_size() occurs in the hot path. Since if-tests have a runtime
> cost I'd like to keep the number of if-tests inside bio_max_size() to a
> minimum.
>
> I only found one bd_disk assignment in the kernel tree, namely inside
> bdev_alloc(). The two bdev_alloc() calls I found inside the kernel tree
> pass a valid disk pointer to bdev_alloc(). So I think it is not
> necessary to check the disk pointer inside bio_max_size().
>
> Thanks,
>
> Bart.
I think bio->bi_bdev should be null in bio_copy_kern(), or bio_map_kern()
logically. Because it is simple buffer mapping in driver layer. Actually
bio->bi_bdev is null in my test environment. So bio->bi_bdev check only is
enough as Bart's patch.
Actually I don't know why NULL pointer dereference is occurred with Bart's
patch in blk_rq_map_kern(). And same problem have not occured yet in my
test environment with Bart's patch.
Maybe I missed something, or missunderstood?
Thanks,
Changheun Lee.
next prev parent reply other threads:[~2021-04-28 7:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-25 4:30 [PATCH v2] block: Improve limiting the bio size Bart Van Assche
2021-04-25 7:36 ` Yi Zhang
2021-04-25 16:19 ` Jens Axboe
2021-04-26 6:32 ` Yi Zhang
2021-04-26 8:34 ` Changheun Lee
2021-04-26 16:17 ` Bart Van Assche
2021-04-27 0:28 ` Changheun Lee
2021-04-27 2:46 ` Bart Van Assche
2021-04-27 4:12 ` Changheun Lee
2021-04-27 14:59 ` Bart Van Assche
2021-04-28 7:21 ` Changheun Lee [this message]
2021-04-28 15:52 ` Bart Van Assche
2021-04-29 6:39 ` Changheun Lee
2021-05-03 9:28 ` Changheun Lee
2021-05-03 16:35 ` Bart Van Assche
2021-04-26 12:54 ` Jens Axboe
2021-04-26 23:43 ` Changheun Lee
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=20210428072123.3155-1-nanich.lee@samsung.com \
--to=nanich.lee@samsung.com \
--cc=axboe@kernel.dk \
--cc=bgoncalv@redhat.com \
--cc=bvanassche@acm.org \
--cc=hch@lst.de \
--cc=jaegeuk@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=yi.zhang@redhat.com \
/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