lp:~sforshee/ubuntu/+source/linux/+git/groovy

Owned by Seth Forshee
Get this repository:
git clone https://git.launchpad.net/~sforshee/ubuntu/+source/linux/+git/groovy
Only Seth Forshee can upload to this repository. If you are Seth Forshee please log in for upload directions.

Branches

Name Last Modified Last Commit
veeam 2020-11-17 18:12:40 UTC
UBUNTU: SAUCE: blk-filter -- Eliminate blk_filter_submit_bio_next()

Author: Seth Forshee
Author Date: 2020-09-23 15:50:33 UTC

UBUNTU: SAUCE: blk-filter -- Eliminate blk_filter_submit_bio_next()

I'm making some assumptions with this change since I don't have
the code for the modules which hook into it. But what I obseved
is that the implementation appears to be recursive:

 - blk_filter_submit_bio() is called
 - Highest-altitude filter's submit_bio callback is called
 - blk_filter_submit_bio_next() is not called from the kernel,
   so it must be a call for filter drivers. Its purpose appears
   to be to continue processing with the next-lowest altitude
   filter, so presumably it would be called from a filter's
   submit_bio callback.
 - After the lowest registered filter has been called,
   blk_filter_submit_bio_altitude() will submit the bio to the
   block driver.

So it certainly looks to me like the code will end up calling
blk_filter_submit_bio_altitude() recursively until the bio is
finally passed on to the bdev. The recursion is bounded by
BLK_FILTER_ALTITUDE_MAX, but I still don't think it's a great
idea since we don't know how much stack the filter drivers might
use, and it seems easy enough to implement the same thing
iteratively.

Therefore this patch changes blk_filter_submit_bio_altitude() to
use an iterative approach. Basically it just starts at the
supplied altitude and iterates downward, calling the submit_bio
callback if a filter is registered at that altitude, and at the
end proceeds with the bio submission.

I'm honestly concerned that in the original implementation a
filter could stop the block io submission. I suspect that's not
intended but just a consequence of the recursive implementation,
and that furthermore the only reason the submit_bio callback
returns anything at all is to pass on the eventual return code
from generic_make_request() (submit_bio_noacct() in later
kernels). Therefore I've changed the submit_bio callback to
return void and made the generic_make_request() call
unconditional.

With this in place it looks like blk_filter_submit_bio_altitude()
isn't really needed as a separate function from
blk_filter_submit_bio(), so they are folded into a single
function.

One other thing that I observed, but did not change. size_t seems
like overkill for altitude, which is currently capped at 4. It's
hard to imagine ever wanting more filters than could be contained
in an int.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

11 of 1 result
This repository contains Public information 
Everyone can see this information.

Subscribers