On Tue, 3 Oct 2017, Alasdair G Kergon wrote: > On Tue, Oct 03, 2017 at 02:08:04PM -0400, Mike Snitzer wrote: > > Not sure why you're putting such value on that behaviour. The earlier > > we catch invalid tables the better off we are. Failing at resume time > > sucks (always has). > > Validation code shouldn't be making assumptions about things that lie > completely outside its control and falsely failing operations that would > actually succeed if they were allowed to proceed. The existing > kernel/userspace interface does not require userspace to load devices in > any particular sequence. We could have provided a tree-based kernel/userspace > interface with stronger requirements like these, but the fact is, we haven't. > Perhaps we will one day. > > As a minimum, you would need to change the patch to validate against the > inactive tables of underlying devices instead of the live ones - i.e. assume > that userspace already loaded all the underlying devices (and will resume them > all before the one being validated gets resumed). Currently no such > ordering requirement is imposed on userspace, so you'd also need a > compatibility flag to enable the stronger contraints. > > This patch can break valid userspace code. > > Alasdair It would be interesting to know, why Milan wants the table load to 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? Mikulas -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
