On Sat, Sep 5, 2026, at 13:07, David Laight wrote:
On Sat, 05 Sep 2026 07:21:33 +0300
"Juha-Matti Tilli" [off-list ref] wrote:
quoted
Indeed, I will later post a new version with UINT16_MAX replaced by
65535.
Makes more sense anyway because it is an arbitrary bound (rather than
ensuring the result will fit in 16 bits.
Indeed, it might be better to use a different limit.
Well, on that I might disagree. As of this commit, the code will have to
cram that into 16 bits on 32-bit platforms. Only the later commit will
remove the restriction that lookups are limited to 32 bits total.
Node ids are 32-bit by definition, so 32+16=48 > 32, so u16 won't help.
Of course, there's the possibility that if the later commit is what we
want, that this will be squashed with the later commit.
I looked at most XA_LIMIT users and they seem to follow the policy that
allocations are limited to usually 16, 31 or 32 bits. And I found
USHRT_MAX -- that's what I was looking for instead of UINT16_MAX.
So I still think that "limited by kernel memory" is the best here. While
I can't envision a system with more than 65534 QRTR endpoints, I'm still
uncomfortable with setting the limit to a low value.
So, the next patchset will have USHRT_MAX. Soon my patchset of actually
having multiple ath11k/ath12k is ready for review so I'll post that too.
It fixes the memory leak in Mihai's original set.
BR, Juha-Matti