On 5/15/21 1:55 PM, Heinrich Schuchardt wrote:
On 5/15/21 6:36 PM, Sean Anderson wrote:
Some callers (e.g. cmd/fs.c) of fs_set_blk_dev may use a NULL dev_part_str. While blk_get_device_part_str handles this fine, part_get_info_by_dev_and_name does not. This fixes commands crashing when implicitly using bootdevice.
Fixes: 7194527b6a ("cmd: fs: Use part_get_info_by_dev_and_name_or_num to parse partitions") Reported-by: Heinrich Schuchardtxypron.glpk@gmx.de Signed-off-by: Sean Andersonseanga2@gmail.com
With this patch the reported error cannot be reproduced:
=> host bind 0 ../sandbox.img => setenv bootdevice 0:1 => ls host 148 boot.scr ...
But the unit test fails after issuing:
setenv bootdevice 0:1
=> ut dm dm_test_part Test: dm_test_part: part.c test/dm/part.c:47, dm_test_part(): -19 == part_get_info_by_dev_and_name_or_num("mmc", "", &mmc_dev_desc, &part_info, 1): Expected 0xffffffed (-19), got 0xffffffa3 (-93) Test: dm_test_part: part.c (flat tree) test/dm/part.c:47, dm_test_part(): -19 == part_get_info_by_dev_and_name_or_num("mmc", "", &mmc_dev_desc, &part_info, 1): Expected 0xffffffed (-19), got 0xffffffa3 (-93) Failures: 2 =>
We get 'No such device' instead of 'Protocol not supported'.
As the environment variable bootdevice influences the test result it should be unset when setting up the test and set to its original value when tearing down the test.
ugh...
This really should be handled by the unit test framework (e.g. do the equivalent of "env save; env default -a; ut; env load" but to some temporary location). Will send a v2 with a fix...
--Sean
Best regards
Heinrich