From: Praveen Kumar <kumarpraveen@linux.microsoft.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
axboe@kernel.dk, lalita.muppana@microsoft.com,
schakrabarti@linux.microsoft.com,
Michael Kelley <mikelley@microsoft.com>,
longli@microsoft.com, KY Srinivasan <kys@microsoft.com>
Subject: Re: [PATCH] blk-mq: export blk_mq_submit_bio symbol
Date: Fri, 10 Sep 2021 17:24:10 +0530 [thread overview]
Message-ID: <fa6012fa-ea5a-e292-12b3-c457a212a52c@linux.microsoft.com> (raw)
In-Reply-To: <YTmgEAEx69PR/RMy@infradead.org>
On 09-09-2021 11:18, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 11:06:53AM +0530, Praveen Kumar wrote:
>> There are use-cases like replication where need to hook the blk I/O
>> operations for devices and perform specific operation and fallback to
>> its original I/O operations.
>> Prior to v5.9 there was make_request_fn and then blk_mq_submit_bio
>> exported apis, which provided infrastructure to drivers to develop these
>> features. However in v5.10-rc1 with below commit the API was removed
>> from the export list.
>>
>> Previous commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.10-rc1&id=681cc5e8667e8579a2da8fa4090c48a2d73fc3bb
>>
>> This patch exports the blk_mq_submit_bio symbol to provide flexibility
>> to the drivers.
>
> Please send your users of this "feature" to this list for inclusion
> and we'll help you to massage them into a non-broken version.
>
Thank you for the response and appreciate your help. Providing a bit of
details below.
The disk replication solution which I mentioned, hooks all the block i/o
operation using make_request_fn for specific device request queue and do
some massaging and then call the standard block operations.
The flow is something like below :
replication_func_init (struct block_device *bdev)
... orig_queue = bdev_get_queue(bdev) // save the original state
... orig_request_fn = orig_queue->request_fn;
... orig_queue->make_request_fn = custom_function(say "replicate_request_func")
replicate_request_func(...) {
... does some driver specific massaging
... // calls original
if (orig_queue->make_request_fn)
orig_queue->make_request_fn(...)
else
blk_mq_make_request(...)
...
Now, the current implementation have make_request_fn moved to submit_bio, one
probable approach is to somehow, update the original submit_bio to custom
"replicate_submit_bio_func" and then handle the case likewise as done in
"replicate_request_func". But, "blk_mq_submit_bio" is not exported symbol..
Second, "submit_bio_noacct" is the next approach which we thought can be used
for submit the bio, but, for case where original submit_bio is NULL, we will
end calling recursively the new submit_bio, and panic.
replicate_submit_bio_func
... does some driver specific massaging
... // calls exported symbol
submit_bio_noacct
__submit_bio_noacct(bio)
__submit_bio
disk->fops->submit_bio(bio) -> updated API
replicate_submit_bio_func
submit_bio_noacct
Hope, the provided information helps understanding the problem. If not, please
do let us know, we will try to provide more details accordingly. Also, please
do provide your thoughts and suggestions how can we achieve the above kind of
functionality on latest kernel version.
Further, we were trying to understand the history over the removal of make_request_fn
in the queue within blk_mq_init_allocated_queue API, but didn't find much. Can you
please provide any information regarding the same. Also, is there a possibility of have
similar kind of implemenation for submit_bio ?
...
- q->make_request_fn = blk_mq_make_request;
...
Patch : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/block/blk-mq.c?h=v5.14&id=8cf7961dab42c9177a556b719c15f5b9449c24d1
Regards,
~Praveen.
next prev parent reply other threads:[~2021-09-10 11:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-09 5:36 [PATCH] blk-mq: export blk_mq_submit_bio symbol Praveen Kumar
2021-09-09 5:48 ` Christoph Hellwig
2021-09-10 11:54 ` Praveen Kumar [this message]
2021-09-09 16:16 ` Chaitanya Kulkarni
2021-09-13 4:24 ` Praveen Kumar
2021-09-13 6:09 ` Christoph Hellwig
2021-09-13 7:03 ` Praveen Kumar
2021-09-20 5:30 ` Prasad Muppana
2021-09-20 20:25 ` Chaitanya Kulkarni
2021-09-22 5:45 ` Prasad Muppana
2021-09-22 14:29 ` Jens Axboe
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=fa6012fa-ea5a-e292-12b3-c457a212a52c@linux.microsoft.com \
--to=kumarpraveen@linux.microsoft.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=kys@microsoft.com \
--cc=lalita.muppana@microsoft.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=mikelley@microsoft.com \
--cc=schakrabarti@linux.microsoft.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).