Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@kernel.org>
To:     Felix Fietkau <nbd@nbd.name>, linux-wireless@vger.kernel.org
Cc:     johannes@sipsolutions.net
Subject: Re: [PATCH 1/2] mac80211: fix overflow issues in airtime fairness code
In-Reply-To: <20220603164307.92189-1-nbd@nbd.name>
References: <20220603164307.92189-1-nbd@nbd.name>
Date:   Sun, 05 Jun 2022 19:18:14 +0200
Message-ID: <87bkv7owq1.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Felix Fietkau <nbd@nbd.name> writes:

> The airtime weight calculation overflows with a default weight value of 256
> whenever more than 8ms worth of airtime is reported.
> Bigger weight values impose even smaller limits on maximum airtime values.
> This can mess up airtime based calculations for drivers that don't report
> per-PPDU airtime values, but batch up values instead.
>
> Fix this by reordering multiplications/shifts and by reducing unnecessary
> intermediate precision (which was lost in a later stage anyway).
>
> The new shift value limits the maximum weight to 4096, which should be more
> than enough. Any values bigger than that will be clamped to the upper limit.
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>

The weights are UAPI, so I guess we could run into applications that
expect to be able to set a weight higher than 4096? I don't think this
is too likely, but maybe it is better to reject such attempts instead of
silently clamping the value, to flush out any breakage if it does occur?

-Toke