On Mon, Dec 07 2015 at 1:07pm -0500, Milan Broz <mbroz@xxxxxxxxxx> wrote: > On 12/07/2015 05:31 PM, Sami Tolvanen wrote: > > On Mon, Dec 07, 2015 at 09:58:14AM -0500, Mike Snitzer wrote: > >> Great. Moving forward it'd be awesome if you could work to get your > >> verity FEC support regression tests into cryptsetup's tests. > > > > Sure. These tests would basically involve generating a valid disk > > image, corrupting it up to the theoretical maximum, and verifying that > > dm-verity can correct it. > > Does the code handle/report even the same type of data corruption > for RS blocks? Or this is just silently ignored until > data area corruption happens? > Sorry, I did not study the code here, I am just curious :) > > (IOW I mean if data are ok but recovery metadata is corrupted.) There is no preemptive accessing/checking of the RS blocks. Once a parity is needed for a given block, due to some corruption, the RS block will be accessed with: fec_decode_bufs -> fec_read_parity() -> fec_decode_rs8() -> decode_rs8() I'm not seeing any verification of the metadata in fec_read_parity() -- so it would seem that corrupt RS blocks would result in -EBADMSG being returned from decode_rs8() (by virtue of incorrect parity being passed to decode_rs8). Sami (or others) am I right? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
