On Wed, Mar 19, 2025 at 10:18:39PM +0100, Mikulas Patocka wrote: > > > On Tue, 18 Mar 2025, Jens Axboe wrote: > > > > Yeah, it looks fine, but I feel it is still fragile, and not sure it is one > > > accepted solution. > > > > Agree - it'd be much better to have the bio drivers provide the same > > guarantees that we get on the request side, rather than play games with > > this and pretend that concurrent update and usage is fine. > > > > -- > > Jens Axboe > > And what mechanism should they use to read the queue limits? > * locking? (would degrade performance) > * percpu-rwsem? (no overhead for readers, writers wait for the RCU > synchronization) > * RCU? > * anything else? 1) queue usage counter is for covering fast IO code path - in __submit_bio(), queue usage counter is grabbed when calling ->submit_bio() - the only trouble should be from dm-crypt or thin-provision which offloads bio submission to other context, so you can grab the usage counter by percpu_ref_get(&q->q_usage_counter) until this bio submission or queue limit consumption is done 2) slow path: dm_set_device_limits which is done before DM disk is on, so it should be fine by holding limit lock. 3) changing queue limits from bio->end_io() or request completion handler - this usage need fix thanks, Ming
