Re: [PATCH v6 13/15] net: qrtr: limit endpoint range to 16 bits on 32-bit machines

["Juha-Matti Tilli" <juha-matti.tilli@iki.fi>]

On Sat, Sep 5, 2026, at 13:07, David Laight wrote:
> On Sat, 05 Sep 2026 07:21:33 +0300
> "Juha-Matti Tilli" <juha-matti.tilli@iki.fi> wrote:
> > 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