----- Original Message ----- > v2: adjust the patch header to be more succinct > > diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c > index f6979ad..9b931b4 100644 > --- a/drivers/md/dm-table.c > +++ b/drivers/md/dm-table.c > @@ -1264,6 +1264,15 @@ combine_limits: > (unsigned long long) ti->len); > } > > + /* > + * If a table doesn't have any component devices (e.g. multipath > + * loses all paths) don't allow the queue_limits to be left at > + * their maximum (as established by blk_set_stacking_limits() so > + * limits could be inherited from component devices). > + */ > + if (limits->max_sectors == UINT_MAX) > + blk_set_default_limits(limits); > + > return validate_hardware_logical_block_alignment(table, limits); > } > > -- > 1.7.1 > > Instead of setting to defaults, how about maintaining previous limits? The initial queue setup sets defaults when a queue is first configured, and this maintains known, working limits if all paths are temporarly lost. For example, I have a test setup with a lower than normal max segment list. It can fail a test with the previous patch as the default limits exceed the hardware limits. But this setup will work if we leave queue limits unchanged in the special case of there being no target devices. David Jeffery diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 4e09b6f..89ec9ee 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -2425,6 +2425,15 @@ struct dm_table *dm_swap_table(struct mapped_device *md, struct dm_table *table) goto out; } + /* + * If a table doesn't have any component devices (e.g. multipath + * loses all paths) don't allow the queue_limits to be left at + * their maximum (as established by blk_set_stacking_limits()). + * Instead, maintain the previous limits. + */ + if (limits.max_sectors == UINT_MAX) + limits = md->queue->limits; + map = __bind(md, table, &limits); out: -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
