Hi Aristo, On Wed, 23 Sept 2026 at 01:00, Aristo Chen <[email protected]> wrote: > > Hi Simon, > > On Sat, Sep 19, 2026 at 4:45 AM Simon Glass <[email protected]> wrote: > > > > Hi Aristo, > > > > On 2026-08-31T14:25:38, Aristo Chen <[email protected]> wrote: > > > test: boot: Check that rauc rejects over-long slot names > > > > > > Boot the RAUC bootflow after setting BOOT_ORDER to a 33-character slot > > > name, one more than fits the "BOOT_<slot>_LEFT" env-var name buffer. The > > > boot must now fail with -ENAMETOOLONG. > > > > > > Before the previous commit the name overflowed the stack buffer; as no > > > such variable exists the boot then failed with -ENOENT, hiding the > > > overflow. > > > > > > Also check the accepted side of the boundary: a 32-character name, the > > > longest that fits, must pass the length check and fail only with -ENOENT > > > because its BOOT_<slot>_LEFT variable does not exist. > > > > > > Signed-off-by: Aristo Chen <[email protected]> > > > > > > test/boot/bootflow.c | 23 +++++++++++++++++++++++ > > > 1 file changed, 23 insertions(+) > > > > Since the boundary is boot_left_name(), please exercise the scan path > > too - distro_rauc_read_bootflow() calls it against > > CONFIG_BOOTMETH_RAUC_BOOT_ORDER, which is what a user is most likely > > to hit. The current test only reaches find_active_slot() via > > BOOT_ORDER at boot time. > > During a scan the only names that reach boot_left_name() are the entries > of CONFIG_BOOTMETH_RAUC_BOOT_ORDER, a compile-time string ("A B" on > sandbox). The BOOT_ORDER entries seen at scan time go through get_slot() > in distro_rauc_scan_parts() instead, which marks the bootflow invalid > when a name does not match a configured slot, so no env-var name is > built from them. The test cannot change the Kconfig value at run time, > so covering the rejecting side of the scan path would need either a > dedicated sandbox configuration (which would require adapting or > excluding the existing rauc test, since the bootflow becomes invalid) > or a test hook that lets the scan path take an alternate default > order. The scan path's normal accepted-input case is exercised by every > scan in bootflow_rauc(), and it goes through the same helper the > boot-time test drives across the 32/33-char boundary. If you still > want the rejecting Kconfig scan path covered, I can add a dedicated > test configuration, although that seems disproportionate for this fix.
That seems OK to me...we are going to end up with more need to test internal functions, but most of the other tests don't, so it's not something you need to pioneer. I was a bit confused perhaps because patchwork died while I was checking the patches. > I re-checked both patches on top of current next (951132236b9): they > apply cleanly and bootflow_rauc passes, so I will hold off on a resend > unless you or Tom prefer one. Reviewed-by: Simon Glass <[email protected]> Regards, Simon
