On 03/17/2017 04:35 PM, Sami Tolvanen wrote: > On Fri, Mar 17, 2017 at 12:45:00PM +0100, Milan Broz wrote: >> it still does take at least two minutes and tons of logs until even >> udev scan finishes on a device with incorrect FEC attributes. > > If dm-verity is set up with invalid arguments so that the entire partition > is corrupt, it does take a while to determine this with FEC as it attempts > to correct both metadata and data blocks before giving up. It also depends > on the random read performance of the underlying hardware obviously. Sure, no problem with that. Just this testing device was the smallest possible size (4k) so almost 2 minutes for FEC repairs was quite unexpected :) >> And once it is finished, dm-verity crashes on dm-device removal... > > That's interesting, I haven't seen this before. Looks like something goes > wrong at the very end of dm_bufio_client_destroy. I'm not familiar enough > with dm_bufio internals to immediately tell why though. > >> Could we please have all crucial fixes upstream? > > Sorry, there are no other pending fixes remaining in our tree. Ok, so it is a new bug then. Sorry for being grumpy, I was just trying to setup trivial verity device to test activation code in veritysetup (this part was not in initial commit at all) and every attempt to test table format ended in kernel OOPs. We should fix all this problems because it smells like a DoS problem (someone modifies on-disk FEC data to intentionally crash kernel). Anyway, Michal (our student intern) should help with testing (and veritysetup code as well), so if you have any patches, please send it to the dm-devel list and cc him. Thanks! Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
