[RFC,v3] average: change non-init state and add check for added values

The uninitialized state 0 involves the danger of reaching that state in
normal operation. Since the weight_rcp value needs to be bigger than one
(otherwise no averaging takes place), the final shifting in add ensures,
that the internal state never reach ULONG_MAX. Therefore use this value
to signal, that the ewma has no initial value.

The add function needs to check, that val is not to big, otherwise the new
value can overflow the internal state, which results in unexpected outputs.

Move the compile time checks into a separate macro, as they are used
multiple times and noise up the functions.

Signed-off-by: Benjamin Beichler <benjamin.beichler@uni-rostock.de>
---
 include/linux/average.h | 82 ++++++++++++++++++++++-------------------
 1 file changed, 45 insertions(+), 37 deletions(-)

On Mon, 2023-04-24 at 21:04 +0000, Benjamin Beichler wrote:
> The uninitialized state 0 involves the danger of reaching that state in
> normal operation. Since the weight_rcp value needs to be bigger than one
> (otherwise no averaging takes place), the final shifting in add ensures,
> that the internal state never reach ULONG_MAX. Therefore use this value
> to signal, that the ewma has no initial value.
> 
> The add function needs to check, that val is not to big, otherwise the new
> value can overflow the internal state, which results in unexpected outputs.

This seems nice to me, FWIW.

> Move the compile time checks into a separate macro, as they are used
> multiple times and noise up the functions.

Why do we even have those multiple times? Should be enough to have them
once, since we always compile the static inline functions?

johannes

Am 25.04.2023 um 20:18 schrieb Johannes Berg:
> ________________________________
>   Achtung! Externe E-Mail: Klicken Sie erst dann auf Links und Anhänge, nachdem Sie die Vertrauenswürdigkeit der Absenderadresse geprüft haben.
> ________________________________
>
> On Mon, 2023-04-24 at 21:04 +0000, Benjamin Beichler wrote:
>> The uninitialized state 0 involves the danger of reaching that state in
>> normal operation. Since the weight_rcp value needs to be bigger than one
>> (otherwise no averaging takes place), the final shifting in add ensures,
>> that the internal state never reach ULONG_MAX. Therefore use this value
>> to signal, that the ewma has no initial value.
>>
>> The add function needs to check, that val is not to big, otherwise the new
>> value can overflow the internal state, which results in unexpected outputs.
> This seems nice to me, FWIW.
Okay. I would split up the patch into sensible parts and send it later. 
You are also fine with the extra init function with explicit init value? 
Of course this one also needs the check, that it really fits into the 
internal state :-D
>
>> Move the compile time checks into a separate macro, as they are used
>> multiple times and noise up the functions.
> Why do we even have those multiple times? Should be enough to have them
> once, since we always compile the static inline functions?

Good question ... my assumption was, that the build-bug macro may not 
work, if the function is unused and maybe optimized away, but I'm not 
that familiar with those details. I'm more in favor with the 
static_asserts of C++, which have defined semantics. :-D

It would be nice to put the check into the struct, as some zero size bad 
member, but I found no example in the kernel, so maybe this is not 
easily doable.

One may argue, that we only put it in init and if the users do not use 
init, we call it shit-in-shit-out, but I'm not really in favor of that.

Anyone with more experiences on build time asserts in the kernel?

Benjamin

Am 26.04.2023 um 08:19 schrieb Benjamin Beichler:
> Am 25.04.2023 um 20:18 schrieb Johannes Berg:
>> ________________________________
>>   Achtung! Externe E-Mail: Klicken Sie erst dann auf Links und 
>> Anhänge, nachdem Sie die Vertrauenswürdigkeit der Absenderadresse 
>> geprüft haben.
>> ________________________________
>>
>> On Mon, 2023-04-24 at 21:04 +0000, Benjamin Beichler wrote:
>>> The uninitialized state 0 involves the danger of reaching that state in
>>> normal operation. Since the weight_rcp value needs to be bigger than 
>>> one
>>> (otherwise no averaging takes place), the final shifting in add 
>>> ensures,
>>> that the internal state never reach ULONG_MAX. Therefore use this value
>>> to signal, that the ewma has no initial value.
>>>
>>> The add function needs to check, that val is not to big, otherwise 
>>> the new
>>> value can overflow the internal state, which results in unexpected 
>>> outputs.
>> This seems nice to me, FWIW.
> Okay. I would split up the patch into sensible parts and send it 
> later. You are also fine with the extra init function with explicit 
> init value? Of course this one also needs the check, that it really 
> fits into the internal state :-D
>>
>>> Move the compile time checks into a separate macro, as they are used
>>> multiple times and noise up the functions.
>> Why do we even have those multiple times? Should be enough to have them
>> once, since we always compile the static inline functions?
>
> Good question ... my assumption was, that the build-bug macro may not 
> work, if the function is unused and maybe optimized away, but I'm not 
> that familiar with those details. I'm more in favor with the 
> static_asserts of C++, which have defined semantics. :-D
>
> It would be nice to put the check into the struct, as some zero size 
> bad member, but I found no example in the kernel, so maybe this is not 
> easily doable.
>
> One may argue, that we only put it in init and if the users do not use 
> init, we call it shit-in-shit-out, but I'm not really in favor of that.
>
> Anyone with more experiences on build time asserts in the kernel?
>
>
I just checked out of curiosity the kernel for static_assert, and voilà 
it already contains it as a wrapper to the C11 _Static_assert, which 
should work better than BUILD_BUG. I will transform it and remove the 
multiple insertions.

Benjamin