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: Tue, 27 Apr 2021 09:28:57 +0900 [thread overview]
Message-ID: <20210427002857.8038-1-nanich.lee@samsung.com> (raw)
In-Reply-To: <34286266-1c03-35bc-94e8-08bd0ac3400a@acm.org>
> On 4/26/21 1:34 AM, Changheun Lee wrote:
> > Should we check queue point in bio_max_size()?
> > __device_add_disk() can be called with "register_queue=false" like as
> > device_add_disk_no_queue_reg(). How about below?
> >
> > unsigned int bio_max_size(struct bio *bio)
> > {
> > struct request_queue *q;
> >
> > q = (bio->bi_bdev) ? bio->bi_bdev->bd_disk->queue : NULL;
> > return q ? q->limits.bio_max_bytes : UINT_MAX;
> > }
>
> How could bio_max_size() get called from inside __device_add_disk() if
> no request queue is registered? Did I perhaps miss something?
>
> Thanks,
>
> Bart.
__device_add_disk() do not call bio_max_size(). I just imagined bio
operation on disk without request queue. Disk can be added without queue via
device_add_disk_no_queue_reg(). It might be my miss-understood about it.
I didn't check bio operation is possible on disk without request queue yet.
Thanks,
Changheun Lee.
next prev parent reply other threads:[~2021-04-27 0:47 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
[not found] ` <CGME20210426085241epcas1p46ed8de18a98c40218dacd58fc4b25ff9@epcas1p4.samsung.com>
2021-04-26 8:34 ` Changheun Lee
2021-04-26 16:17 ` Bart Van Assche
[not found] ` <CGME20210427004655epcas1p15cc4b2be6312c4762272474908607722@epcas1p1.samsung.com>
2021-04-27 0:28 ` Changheun Lee [this message]
2021-04-27 2:46 ` Bart Van Assche
[not found] ` <CGME20210427043022epcas1p47f11139bc1e08925bcbbdca79e5c8e36@epcas1p4.samsung.com>
2021-04-27 4:12 ` Changheun Lee
2021-04-27 14:59 ` Bart Van Assche
[not found] ` <CGME20210428073921epcas1p2b161b5ccc9d7ec61c1200155da95c5b9@epcas1p2.samsung.com>
2021-04-28 7:21 ` Changheun Lee
2021-04-28 15:52 ` Bart Van Assche
[not found] ` <CGME20210429065701epcas1p363667a6f0c598f27bb5afde32473ea39@epcas1p3.samsung.com>
2021-04-29 6:39 ` Changheun Lee
[not found] ` <CGME20210503094654epcas1p3ce7761e2f0fc304d1c08a9b0bf0485ff@epcas1p3.samsung.com>
2021-05-03 9:28 ` Changheun Lee
2021-05-03 16:35 ` Bart Van Assche
2021-04-26 12:54 ` Jens Axboe
[not found] ` <CGME20210427000106epcas1p3f39e318e9211bf3378b3e4afad2de56e@epcas1p3.samsung.com>
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=20210427002857.8038-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;
as well as URLs for NNTP newsgroup(s).