Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1d7870e7-6b41-3eb6-910f-8df335b222bc@nbd.name>
Date:   Thu, 9 Jun 2022 17:33:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.9.1
Subject: Re: [PATCH 1/2] mac80211: fix overflow issues in airtime fairness
 code
Content-Language: en-US
To:     =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= <toke@kernel.org>,
        linux-wireless@vger.kernel.org
Cc:     johannes@sipsolutions.net
References: <20220603164307.92189-1-nbd@nbd.name> <87bkv7owq1.fsf@toke.dk>
From:   Felix Fietkau <nbd@nbd.name>
In-Reply-To: <87bkv7owq1.fsf@toke.dk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 05.06.22 19:18, Toke Høiland-Jørgensen wrote:
> 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?
Will do this in v2.

Thanks,

- Felix