From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Broz Subject: Re: dm-crypt: Reject sector_size feature if device length is not aligned to it Date: Tue, 3 Oct 2017 22:33:53 +0200 Message-ID: References: <20170913134556.23145-1-gmazyland@gmail.com> <20171003120508.GA9979@agk-dp.fab.redhat.com> <20171003180804.GA25465@redhat.com> <20171003190934.GB9979@agk-dp.fab.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mikulas Patocka , Alasdair G Kergon Cc: dm-devel@redhat.com, Mike Snitzer List-Id: dm-devel.ids 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