Attention is currently required from: Julius Werner, Jan Dabros. Jakub Czapiga has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/56813 )
Change subject: tests: Add lib/cbfs-lookup-test test case ......................................................................
Patch Set 11:
(2 comments)
File tests/lib/cbfs-lookup-test.c:
https://review.coreboot.org/c/coreboot/+/56813/comment/0981640f_d3237801 PS4, Line 139: },
Right, but here I actually meant alignment in relation to the start of the rdev (cbfs_walk() should skip headers not on an alignment boundary, test should verify that behavior).
I added offset of CBFS_ALIGNMENT at the beginning of CBFS in test_cbfs_cbmem_alloc(). I think that this was not covered. We had test with garbage data, but not with no data (zeros) at the beginning.
one where it exceeds the available size by a little bit
It's already done in test_cbfs_file_bigger_than_rdev()
and one where it uses a number very close to UINT32_MAX
Now test_cbfs_file_length() (formetly test_cbfs_length_uint32_max()) is parametrized by state.ex.file_length. There are new cases: - len = UINT32_MAX - len = UINT32_MAX - offsetof(struct cbfs_test_file, attrs_and_data) - len = UINT32_MAX - offsetof(struct cbfs_test_file, attrs_and_data) / 2 - len = UINT32_MAX - offsetof(struct cbfs_test_file, attrs_and_data) * 2 - len = UINT32_MAX - offsetof(struct cbfs_test_file, attrs_and_data) - 1
Test locks for len = UINT32_MAX - offsetof(struct cbfs_test_file, attrs_and_data) + 1, because (offset + data_offset + data_length) == 0 for this case, so cbfs_walk() will be stuck in an infinite loop of looking-up this file and then overflowing to lookup it again, and again.
https://review.coreboot.org/c/coreboot/+/56813/comment/5dcba5ac_34e41a5f PS4, Line 148: __aligned(CBFS_ALIGNMENT);
Sorry, not quite sure what you mean. […]
I was referring to alignment in the flash memory. But if we are using rdev to read data, then driver underneath should handle unaligned access. I was thinking "too close to hardware"