lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z9L43xpibqHZ07vW@shredder>
Date: Thu, 13 Mar 2025 17:25:19 +0200
From: Ido Schimmel <idosch@...dia.com>
To: Paolo Abeni <pabeni@...hat.com>, wangyuli@...ontech.com
Cc: andrew+netdev@...n.ch, chenlinxuan@...ontech.com, czj2441@....com,
	davem@...emloft.net, edumazet@...gle.com, guanwentao@...ontech.com,
	kuba@...nel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, niecheng1@...ontech.com, petrm@...dia.com,
	zhanjun@...ontech.com
Subject: Re: [PATCH net 1/2] mlxsw: spectrum_acl_bloom_filter: Expand
 chunk_key_offsets[chunk_index]

On Thu, Mar 13, 2025 at 02:52:11PM +0100, Paolo Abeni wrote:
> On 3/12/25 2:20 PM, Ido Schimmel wrote:
> > On Tue, Mar 11, 2025 at 10:17:00PM +0800, WangYuli wrote:
> >> This is a workaround to mitigate a compiler anomaly.
> >>
> >> During LLVM toolchain compilation of this driver on s390x architecture, an
> >> unreasonable __write_overflow_field warning occurs.
> >>
> >> Contextually, chunk_index is restricted to 0, 1 or 2. By expanding these
> >> possibilities, the compile warning is suppressed.
> > 
> > I'm not sure why the fix suppresses the warning when the warning is
> > about the destination buffer and the fix is about the source. Can you
> > check if the below helps? It removes the parameterization from
> > __mlxsw_sp_acl_bf_key_encode() and instead splits it to two variants.
> > 
> > diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
> > index a54eedb69a3f..3e1e4be72da2 100644
> > --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
> > +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
> > @@ -110,7 +110,6 @@ static const u16 mlxsw_sp2_acl_bf_crc16_tab[256] = {
> >   * +-----------+----------+-----------------------------------+
> >   */
> >  
> > -#define MLXSW_SP4_BLOOM_CHUNK_PAD_BYTES 0
> >  #define MLXSW_SP4_BLOOM_CHUNK_KEY_BYTES 18
> >  #define MLXSW_SP4_BLOOM_KEY_CHUNK_BYTES 20
> >  
> > @@ -229,10 +228,9 @@ static u16 mlxsw_sp2_acl_bf_crc(const u8 *buffer, size_t len)
> >  }
> >  
> >  static void
> > -__mlxsw_sp_acl_bf_key_encode(struct mlxsw_sp_acl_atcam_region *aregion,
> > -			     struct mlxsw_sp_acl_atcam_entry *aentry,
> > -			     char *output, u8 *len, u8 max_chunks, u8 pad_bytes,
> > -			     u8 key_offset, u8 chunk_key_len, u8 chunk_len)
> > +mlxsw_sp2_acl_bf_key_encode(struct mlxsw_sp_acl_atcam_region *aregion,
> > +			    struct mlxsw_sp_acl_atcam_entry *aentry,
> > +			    char *output, u8 *len)
> >  {
> >  	struct mlxsw_afk_key_info *key_info = aregion->region->key_info;
> >  	u8 chunk_index, chunk_count, block_count;
> > @@ -243,30 +241,17 @@ __mlxsw_sp_acl_bf_key_encode(struct mlxsw_sp_acl_atcam_region *aregion,
> >  	chunk_count = 1 + ((block_count - 1) >> 2);
> >  	erp_region_id = cpu_to_be16(aentry->ht_key.erp_id |
> >  				   (aregion->region->id << 4));
> > -	for (chunk_index = max_chunks - chunk_count; chunk_index < max_chunks;
> > -	     chunk_index++) {
> > -		memset(chunk, 0, pad_bytes);
> > -		memcpy(chunk + pad_bytes, &erp_region_id,
> > +	for (chunk_index = MLXSW_BLOOM_KEY_CHUNKS - chunk_count;
> > +	     chunk_index < MLXSW_BLOOM_KEY_CHUNKS; chunk_index++) {
> 
> Possibly the compiler is inferring chunck count can be greater then
> MLXSW_BLOOM_KEY_CHUNKS?

I think so.

> 
> something alike:
> 
> 	chunk_index = min_t(0, MLXSW_BLOOM_KEY_CHUNKS - chunk_count, u8);
> 
> Could possibly please it?

I would like to get a warning if 'chunk_count' is larger than
'MLXSW_BLOOM_KEY_CHUNKS' since it should never happen.

I was able to reproduce the build failure and the following patch seems
to solve it for me. It removes the 'max_chunks' argument since it's
always 'MLXSW_BLOOM_KEY_CHUNKS' (3) and verifies that the number of
chunks that was calculated is never greater than it.

WangYuli, can you please test it?
Also, if you want it in net.git (as opposed to net-next.git), then it
needs a Fixes tag:

Fixes: 7585cacdb978 ("mlxsw: spectrum_acl: Add Bloom filter handling")

And I don't think we need patch #2.

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
index a54eedb69a3f..a1ab5b09a6c5 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
@@ -231,7 +231,7 @@ static u16 mlxsw_sp2_acl_bf_crc(const u8 *buffer, size_t len)
 static void
 __mlxsw_sp_acl_bf_key_encode(struct mlxsw_sp_acl_atcam_region *aregion,
 			     struct mlxsw_sp_acl_atcam_entry *aentry,
-			     char *output, u8 *len, u8 max_chunks, u8 pad_bytes,
+			     char *output, u8 *len, u8 pad_bytes,
 			     u8 key_offset, u8 chunk_key_len, u8 chunk_len)
 {
 	struct mlxsw_afk_key_info *key_info = aregion->region->key_info;
@@ -241,10 +241,14 @@ __mlxsw_sp_acl_bf_key_encode(struct mlxsw_sp_acl_atcam_region *aregion,
 
 	block_count = mlxsw_afk_key_info_blocks_count_get(key_info);
 	chunk_count = 1 + ((block_count - 1) >> 2);
+	if (WARN_ON_ONCE(chunk_count > MLXSW_BLOOM_KEY_CHUNKS)) {
+		*len = 0;
+		return;
+	}
 	erp_region_id = cpu_to_be16(aentry->ht_key.erp_id |
 				   (aregion->region->id << 4));
-	for (chunk_index = max_chunks - chunk_count; chunk_index < max_chunks;
-	     chunk_index++) {
+	for (chunk_index = MLXSW_BLOOM_KEY_CHUNKS - chunk_count;
+	     chunk_index < MLXSW_BLOOM_KEY_CHUNKS; chunk_index++) {
 		memset(chunk, 0, pad_bytes);
 		memcpy(chunk + pad_bytes, &erp_region_id,
 		       sizeof(erp_region_id));
@@ -262,7 +266,6 @@ mlxsw_sp2_acl_bf_key_encode(struct mlxsw_sp_acl_atcam_region *aregion,
 			    char *output, u8 *len)
 {
 	__mlxsw_sp_acl_bf_key_encode(aregion, aentry, output, len,
-				     MLXSW_BLOOM_KEY_CHUNKS,
 				     MLXSW_SP2_BLOOM_CHUNK_PAD_BYTES,
 				     MLXSW_SP2_BLOOM_CHUNK_KEY_OFFSET,
 				     MLXSW_SP2_BLOOM_CHUNK_KEY_BYTES,
@@ -379,7 +382,6 @@ mlxsw_sp4_acl_bf_key_encode(struct mlxsw_sp_acl_atcam_region *aregion,
 	u8 chunk_count = 1 + ((block_count - 1) >> 2);
 
 	__mlxsw_sp_acl_bf_key_encode(aregion, aentry, output, len,
-				     MLXSW_BLOOM_KEY_CHUNKS,
 				     MLXSW_SP4_BLOOM_CHUNK_PAD_BYTES,
 				     MLXSW_SP4_BLOOM_CHUNK_KEY_OFFSET,
 				     MLXSW_SP4_BLOOM_CHUNK_KEY_BYTES,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ