From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f54.google.com (mail-yx1-f54.google.com [74.125.224.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93456402444 for ; Mon, 11 May 2026 16:53:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778518418; cv=none; b=ErZtK50wNji4UmWjCakKWpsYUVkACTSiixfU5O0annP/1MNqBkGO0j2CXtV6PMAG9t8IfX9Rwuq3G7PuNj0gbE8nXXnwie04OlM6lMAGgqvh81ZIC2ffJlYY4OyclVsjjxqEJbZywd3S30LzCvjtKZ6Pj2T6vOqG9LxKjxXQXDQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778518418; c=relaxed/simple; bh=ieprNEftwYIz0PEqwv+lZWIWv+anmUqRT4shxU8WfRo=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=EWBsBRQ2PhWbLeoW9emxCRmc8vJkk/+jDEKtzgoWxaHIKWhbSjI5FyPASPmCoJ92vfag2aumit46zaRm5D4GaQn1xO570xd2z7lG9P6q2zq9w8ptZSUYcHAtPcg95/gUtr5CF15BLmjrX7pKg6nx2XLjY1AxBSMrTlWnFcYtQd0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QXxt+CQE; arc=none smtp.client-ip=74.125.224.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QXxt+CQE" Received: by mail-yx1-f54.google.com with SMTP id 956f58d0204a3-65dbe04fc1bso1332344d50.1 for ; Mon, 11 May 2026 09:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778518416; x=1779123216; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=NNCfA4B6oVFfF4KvBVDRI03KRMfSBcZ5kzx5bM73bqs=; b=QXxt+CQEjLku2UKObxsPapcNlZziNxFFWeNSfm3/Z9M0Jao8RIA16xFHRMbt/zGCYM SDGGjIqI3BjRTf24Oo7PIM30H7NMfxnkbpZasXgR385xFSt7zIB+a1+VHEQivIi+T5fq VEc8EIYSLhjZjqKmYoEOEmuHRffvPI+8YUObqArghi9HdZ8ORSedFcpmOjOF2qRJfWe8 czNXay0mZZsSaiPHyYmcX4ZA9xT6gNy72Yzexk1aQH4Gb8uDCIauWJQUT14xlXFhRH1h GQJIEwjXaoOw3unV98ztiQwOx3y6iS5l8k9iCfP3Q6RSAAFAjfqACEL2O9RBpakEivch HtxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778518416; x=1779123216; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=NNCfA4B6oVFfF4KvBVDRI03KRMfSBcZ5kzx5bM73bqs=; b=o/HnDyr+D3oerTSORCD+FZcbDQRzrwOcLPmMAcaB/8eNpqg36XrH5u6XhrMcnmkF4G Clhn12w0/BEANcaTZV2r71g84EQNs1wSZESP8Vck4jyeeO8sTKk5EPUdiAQEvnfallS3 rF5qMD3kCwSjsiOQUm8RD0+CbClcuE6E1Aqt9a5HvXaMVboGMEW+gZCHlZyELBln/oyQ G1rL+RMCXMHXUt5tGbc50iow8Ka/jwGWip2jrbmw1sWzptPaYtGwoY/GMv1CmsltxjPR MjotwsoHHN2oCFy14fRkHOraIaDqGUEyFQd1SuQXPjvBZRbo3cVJHLmcUSfR/QQ5I2zr 0PGg== X-Forwarded-Encrypted: i=1; AFNElJ8gmbYvHMJP9lgqwjH9RqX+A/kCPwyRPNuO6s/GJXfoxq4mHouYR/gV4Dy4bSiqQVcRQlzp43+1l5G/pyc=@vger.kernel.org X-Gm-Message-State: AOJu0YysE3lPdXmYMYpm/MJN8H0I8HHU/X152Pn03gQLxMR+p7HTQuZ3 P0L3vs8olkPI/kUGvSYVDrXilbe2PpjY40so1nl8zhFiJkFz0lwBfJv+ X-Gm-Gg: Acq92OEjURJpO/ovXU0k/frFPrqH9gliNciPveIPQd0pU1iWp39pb2QgS4hyAliYPiC G258U678e2phs9cMVJzSqxMa5CNL4ZahH8weCHy2mbQlRKRoPEhaNy0wUWnxmbu70kd7apctDqV FfQty5tExcOcoIgEr+aC0x5BYp00tdTq9CQ1C5DXYloeYQTrG6H8YN5a9RzsAam9Yp+ymO4apOy uv7+iJh0NXsUwOXoOSQupQnchRWJIdDzJMEuAWP+XYNycP++ZLHu+Dd9Lk1EIxSYlpBd1K5+U8h 89BFBYJdYKlSlfOeKbsr6E4z+dhCrJoi3zsvfsvrl8KpPs5jMEBRBBwP96WjSK7ltzYuH+7fGtO ZFtXpYoBYrg5IRUiv0fEqFDW/X2Xxp1Plrp0XDFcjnFELSt+C//lAXk5jSpfCVaDPWo/Uk3xTLy UgjZVOQKmy3cmvkjBA7bSXKDGLxfTIhXHst9EhQYsIE6kgNq288VS531ka6X7Wy3K0Cbh4mvDiA B1W X-Received: by 2002:a05:690e:12c8:b0:64a:ef61:188c with SMTP id 956f58d0204a3-65d94c95f02mr14194008d50.47.1778518415568; Mon, 11 May 2026 09:53:35 -0700 (PDT) Received: from gmail.com (172.235.85.34.bc.googleusercontent.com. [34.85.235.172]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-65d96c0e243sm5516726d50.19.2026.05.11.09.53.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 09:53:34 -0700 (PDT) Date: Mon, 11 May 2026 12:53:34 -0400 From: Willem de Bruijn To: Daniel Zahka , Jakub Kicinski , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Willem de Bruijn Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: In-Reply-To: <20260508-nsim-psp-crypto-v1-1-4b50ed09b794@gmail.com> References: <20260508-nsim-psp-crypto-v1-0-4b50ed09b794@gmail.com> <20260508-nsim-psp-crypto-v1-1-4b50ed09b794@gmail.com> Subject: Re: [PATCH net-next 1/6] netdevsim: psp: reset spi on key rotation and check for exhaustion on alloc Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Daniel Zahka wrote: > The PSP spec states that the lower 31b of the SPI need to be > non-zero. Though not in the spec, I think it is reasonable to reset > the lower 31b of the spi space after a key rotation, and to also > decline to generate session keys when the lower 31b saturate. Since this is already a 6 patch series, these two independent changes could be separate patches. Agreed on both points btw. > Assisted-by: Claude:claude-opus-4.7 > Signed-off-by: Daniel Zahka > --- > drivers/net/netdevsim/psp.c | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/netdevsim/psp.c b/drivers/net/netdevsim/psp.c > index 6936ecb8173e..5073bda60883 100644 > --- a/drivers/net/netdevsim/psp.c > +++ b/drivers/net/netdevsim/psp.c > @@ -132,14 +132,14 @@ nsim_rx_spi_alloc(struct psp_dev *psd, u32 version, > struct netlink_ext_ack *extack) > { > struct netdevsim *ns = psd->drv_priv; > - unsigned int new; > int i; > > - new = ++ns->psp.spi & PSP_SPI_KEY_ID; > - if (psd->generation & 1) > - new |= PSP_SPI_KEY_PHASE; > + if ((ns->psp.spi ^ (ns->psp.spi + 1)) & PSP_SPI_KEY_PHASE) { > + NL_SET_ERR_MSG(extack, "SPI space exhausted"); > + return -ENOSPC; > + } Can this all be more readable without the use of XORs? This is not hot path code that needs to be optimized. if (ns->psp.spi & PSP_SPI_KEY_ID == INT32_MAX) { NL_SET_ERR_MSG(extack, "SPI space exhausted"); return -ENOSPC; } > - assoc->spi = cpu_to_be32(new); > + assoc->spi = cpu_to_be32(++ns->psp.spi); > assoc->key[0] = psd->generation; > for (i = 1; i < PSP_MAX_KEY; i++) > assoc->key[i] = ns->psp.spi + i; > @@ -162,6 +162,10 @@ static int nsim_assoc_add(struct psp_dev *psd, struct psp_assoc *pas, > > static int nsim_key_rotate(struct psp_dev *psd, struct netlink_ext_ack *extack) > { > + struct netdevsim *ns = psd->drv_priv; > + > + ns->psp.spi = (ns->psp.spi & PSP_SPI_KEY_PHASE) ^ PSP_SPI_KEY_PHASE; > + /* Flip key phase and reset SPI to 0 within that space * (will be pre-incremented, as 0 is an invalid SPI) */ if (ns->psp.spi & PSP_SPI_KEY_PHASE) ns->psp.spi = 0; else ns->psp.spi = PSP_SPI_KEY_PHASE; Even while making the code more self evident I still feel it needs a comment to explain all that is going on. Maybe it can be more self-evident. Or maybe you find the XOR just as readable already. Your call. A comment might be helpful either way. > return 0; > } > > > -- > 2.52.0 >