On 10/03/2017 10:08 PM, Mikulas Patocka wrote: > > It would be interesting to know, why Milan wants the table load to fail. I mentioned this on IRC: the only situation I care about in load is that size (dm-table length) is unaligned to optional sector_size. create fails in this case, load should imho fail as well. ... if we say that dmsetup table output is always directly usable (as a mapping table), then why should there be an exception for dmsetup table --inactive? (now it can print apparently invalid mapping) Anyway, I am ok if it fails in resume - but do not keep the device suspended after the fail! > It could be possible to check the validity of the alignment in the > cryptsetup tool and not attempt to load invalid tables at all. Is there > any reason, why we need to detect the misalignment in the kernel? Cryptsetup already rejects such a mapping before even calling dm-ioctl. But anyone can use dmsetup tool to do that. I just think that incompatible sector vs. device size should be rejected in target constructor. (IOW my former patch for dm-crypt that rejects only this exact situation without doing more device-related tests like your generalized patch in table_load.) Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
