On Wed, Mar 02, 2022 at 06:46:03PM +0800, Yongji Xie wrote: > On Tue, Mar 1, 2022 at 11:43 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > On Mon, Feb 28, 2022 at 02:57:20PM +0800, Xie Yongji wrote: > > > Currently we have a BUG_ON() to make sure the number of sg > > > list does not exceed queue_max_segments() in virtio_queue_rq(). > > > However, the block layer uses queue_max_discard_segments() > > > instead of queue_max_segments() to limit the sg list for > > > discard requests. So the BUG_ON() might be triggered if > > > virtio-blk device reports a larger value for max discard > > > segment than queue_max_segments(). > > > > Hmm the spec does not say what should happen if max_discard_seg > > exceeds seg_max. Is this the config you have in mind? how do you > > create it? > > > > One example: the device doesn't specify the value of max_discard_seg > in the config space, then the virtio-blk driver will use > MAX_DISCARD_SEGMENTS (256) by default. Then we're able to trigger the > BUG_ON() if the seg_max is less than 256. > > While the spec didn't say what should happen if max_discard_seg > exceeds seg_max, it also doesn't explicitly prohibit this > configuration. So I think we should at least not panic the kernel in > this case. > > Thanks, > Yongji Oh that last one sounds like a bug, I think it should be min(MAX_DISCARD_SEGMENTS, seg_max) When max_discard_seg and seg_max both exist, that's a different question. We can - do min(max_discard_seg, seg_max) - fail probe - clear the relevant feature flag I feel we need a better plan than submitting an invalid request to device. -- MST
