6813d561b2
The new CBFS stack was written to try to isolate cases of single file corruption as far as possible and still make other files avaialble (at least as long as verification is disabled and they can still be found at all). For most cases of header corruption, it will just continue trying to parse the next file. However, in cases where parts of the file extend beyond the end of the rdev, we have been relying on the range checking of the rdev API rather than doing it explicitly. This is fine in general, but it causes the problem that these errors cannot be distinguished from I/O errors, and I/O errors always make the whole cbfs_walk() fail. That means we will not return a successful result from cbfs_mcache_build(), and leads to an odd discrepancy in how certain kinds of corrupted CBFSes are treated with and without mcache. This patch adds an explicit range check to make the behavior consistent. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ice2b6960284bd0c19be35b0607e5e32791e7a64c Reviewed-on: https://review.coreboot.org/c/coreboot/+/57271 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com> |
||
|---|---|---|
| .. | ||
| include/commonlib/bsd | ||
| cbfs_mcache.c | ||
| cbfs_private.c | ||
| elog.c | ||
| lz4.c.inc | ||
| lz4_wrapper.c | ||