extmod/vfs: Skip littlefs detection if mp_vfs_blockdev_read_ext() fails.#19306
extmod/vfs: Skip littlefs detection if mp_vfs_blockdev_read_ext() fails.#19306projectgus wants to merge 1 commit into
Conversation
Otherwise 'buf' is read uninitialised. This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <angus@redyak.com.au> Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
Code size report: |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #19306 +/- ##
==========================================
- Coverage 98.47% 98.47% -0.01%
==========================================
Files 176 176
Lines 22845 22845
==========================================
- Hits 22497 22496 -1
- Misses 348 349 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This looks very reasonable to me, to check the return value (regardless of anything else, that seems like the right thing to do).
I very much doubt there's such a driver that this change would break. So I think it's OK. But I do see that code coverage is failing. Is there a way to test this change? Maybe try to auto-mount a block device that fails on all reads? |
Summary
I noticed in passing that
bufcan be read uninitialised while checking for littlefs, ifmp_vfs_blockdev_read_extfails.Rather than initialise
buf(expensive), have opted to check the return value of the read function.This work was funded through GitHub Sponsors.
Testing
Trade-offs and Alternatives
littlefs2ending up on the stack independently of the internal flash is additionally low (and the first match will return, so a stale copy should never end up being checked on the second iteration.)buf, but as mentioned above, this is more expensive than checking the return value.mp_vfs_blockdev_read_extand returns the result to littlefs2 it seems like such a port block driver would already not work with littlefs.Generative AI
I did not use generative AI tools when creating this PR.