Hello, On Mon, Nov 13, 2017 at 11:54:13AM -0800, Shaohua Li wrote: > I'm not sure how you are going to make this correct. The mechanism is very > fragile. So for example, 'q->make_request_fn(q, bio)' could just queue the bio > somewhere and handle in other context (both dm and md do this). The bio will be > called again with generic_make_request. In this case, the second time shouldn't > throttle the bio. The bio could be called again with generic_make_request but > with bdev changed. In this case, the second time should throttle the bio > (against the new bdev). There are a lot of different usages of bio. I'd rather > not depend on generic_make_request dispatches new bio immediately. That's why I > add a bdev in my patch. I see. Yeah, that makes sense. The cloned bios may get queued to a different request_queue asynchronously and without remembering the last queue, you can't tell whether it's a new queue or not. I'll drop this one and test with your patch. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
