(please don't top post!) On Tue, Aug 26 2008, Abhijeet Joglekar wrote: > Ok, removing that works too. > > Shouldn't the BUG_ON be checking upto bqt->real_max_depth instead of > bqt->depth? > > BUG_ON(find_first_bit(bqt->tag_map, bqt->real_max_depth) < > bqt->real_max_depth); > > > In cases where the tag map gets resized to a value less than the > originally allocated tag map, blk_queue_resize_tags seems to be setting > bqt->max_depth to the new_depth. > > There could still be outstanding tags max_depth <= t <= real_max_depth > which might not get freed, which the BUG_ON will not capture if it > checks against max_depth. max_depth is fine, it's the safer choice. For the real_max_depth to potentially catch any extra offenders, you would have to do a resize to a larger depth, get bunch of IO issued, then resize down and shut down the queue. Using real_max_depth should work as well, but then you have to audit the ending of tags > max/real_max_depth. It looks ok, though. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
