firmware-utils: mkmylofw broken since 9. Apr 2021

[Rafał Miłecki]

On 13.04.2021 00:46, Sven Roederer wrote:
> since some days my master builds failing for ath79-generic. I was able to
> narrow it to running "mkmylofw for compex_wpj344-16m".
> The tool runs till the drive is full, currently my "compex_wpj344-16m-
> squashfs-cpximg-6a08.bin.new" is 161GB and growing ...
> 
> Has anyone else seen this?
> I'll check to see which of the relevant 6 commit trigger this during the next
> days.

This is caused by the commit a2f66229450d ("firmware-utils: fix few
random warnings").
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a2f66229450dc2f7647c19ac83f3948e809406c2

Above change fixed C macro and affected following line of code:
len = ALIGN(len,4) - block->size;

In compex_wpj344-16m case we have
len: 0
block->size: 5967872
which results in len calculation as follows:
len = ALIGN(0,4) - 5967872

Old macro resulted in:
(0+(4-1))   &   ~(4-1) - 5967872
                        ^ subtraction happens first

New macro results in:
((0+(4-1)) & ~(4-1))   -   5967872
            ^ AND happens first

With new macro final len value is -5967872
That results in write_out_padding() trying to write a lot of data.

So the old code was working accidentally. It resulted in calculating len
incorrectly but somehow that unexpected "0" value was working just fine.

The original code comes from Florian from the 2007 commit 7b564bfdcbef
("Fix potential unligned access with MyLoader based devices, thanks
Juhos")

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=7b564bfdcbef05f68d8a658caf832c6832705e1f

Sven, Florian: any chance you know how that code:
/* align next block on a 4 byte boundary */
len = ALIGN(len,4) - block->size;

was meant to behave originally?