From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ionic.de (ionic.de [145.239.234.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE7E112E7F; Sun, 20 Jul 2025 10:54:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=145.239.234.145 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753008881; cv=none; b=ox9IbVyo/h0PyF/wErQg4M54bsvwg50YNDqPl14jm8bkoJHOB2lGTK/SUnIEZWTRPTt9Y4qSkQnYQGtDi10pMUiutvHP366Rk6P289nIOreU+WRiEneOh7e3uIt5Z2xGtioQ1+kV6NnHZc9BszTZgUYwMWB/cej85LNjeGw33NI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753008881; c=relaxed/simple; bh=bsx4MjC/xMe/JRYnsTAeDdsIFjvZS6CDMjQ0u/mAV7k=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=qI5l9zBUsiWOZ1jO7KC2uhPzfu+phQ87Bb4M8zFJBrLqOUNNI4ogRabthkelGbYDAj9+KGgkRNTk+/J5VFpfNJzGlEECbEZwa3QvdKlZICZ81Usa+/J2Yr9WVub23wxWhwuRxAMq3BnelJ4hFif+5fF5Stm+FSbgbPY6WitBTg8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ionic.de; spf=pass smtp.mailfrom=ionic.de; dkim=pass (1024-bit key) header.d=ionic.de header.i=@ionic.de header.b=lRhPbFuD; arc=none smtp.client-ip=145.239.234.145 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ionic.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ionic.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ionic.de header.i=@ionic.de header.b="lRhPbFuD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ionic.de; s=default; t=1753008875; bh=bsx4MjC/xMe/JRYnsTAeDdsIFjvZS6CDMjQ0u/mAV7k=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=lRhPbFuDW7q1oGFuRSQLddSjVyndEgVPHzROSZdb628Vxeby54sxZTGi8R2DxADPb /00UwBRWMEzrMpA9ZO6YTEIjPeN6jPg0yBy6ZRO+FIFzvqGiySwguMDGtXONDne+MW jkbTNvmsdKsC+BHSIijO/+KhFc/6eFQnHmN2gbBo= Received: from [172.24.215.49] (unknown [185.102.219.57]) by mail.ionic.de (Postfix) with ESMTPSA id 2E5851480B21; Sun, 20 Jul 2025 12:54:35 +0200 (CEST) Message-ID: Date: Sun, 20 Jul 2025 12:54:34 +0200 Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/10] QRTR Multi-endpoint support From: Ionic To: linux-arm-msm@vger.kernel.org, Manivannan Sadhasivam Cc: Eric Dumazet , Kuniyuki Iwashima , Paolo Abeni , Willem de Bruijn , "David S . Miller" , Jakub Kicinski , Simon Horman , linux-kernel@vger.kernel.org, netdev@vger.kernel.org References: Content-Language: en-US Organization: Root24 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit * On 7/19/25 20:59, Mihai Moldovan wrote: > NOTE: There is 32-bit unsafe use of radix_tree_insert in this patch set. > This follows the existing usage inside net/qrtr/af_qrtr.c in > qrtr_tx_wait(), qrtr_tx_resume() and qrtr_tx_flow_failed(). This was > done deliberately in order to keep the changes as minimal as possible > until it is known whether the approach outlined is generally acceptable. Since this is an actual problem and has to be eventually resolved, I'd like to ask for some guidance. The Radix Tree API is fixed to using unsigned long keys, and my best idea (and the easiest thing to implement) thus far is to just go with that and restrict node IDs, endpoint IDs and port numbers to sizeof(unsigned long) / 2 bytes, which for platforms with 32-bit longs would be 16 bits. Not quite ideal, but probably good enough at the very least for port numbers (I figure). Something like that: #define RADIX_TREE_HALF_INDEX_BITS (RADIX_TREE_INDEX_BITS >> 1) #define RADIX_TREE_HALF_INDEX_MAX_VALUE ((unsigned long)(-1) >> RADIX_TREE_HALF_INDEX_BITS) with checks to make sure that node IDs, endpoint IDs and port numbers fit within RADIX_TREE_HALF_INDEX_MAX_VALUE. Is this limitation acceptable? How big can node IDs get, also accounting for uncommon (and maybe also unrealistic) but conceivable use cases? Mihai