From nobody Mon Nov 25 15:46:30 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 6527B2566; Sat, 26 Oct 2024 00:05:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729901158; cv=none; b=MN1a+IRZMWGXLnEIab5vwkedKl3r1ju/U+OxfzWuQRgyl6xB3RCBi5tvF/Mxox7CiAWlgqIdWfIqL5S32dmya/pSBszWDV4xU/h56MxBPSY/035631LKAtk/HSTYm05k3FdXGhanfbZs4Y6SQNNYzPYQhqSYSYR6RpQ7xUd/VPo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729901158; c=relaxed/simple; bh=yKoGU6wGxRX0DYXb3+4YUN6Ap5aFHiepvZOE46Xbjm8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=V7PfM+9I/IWdXdjSH6OYxYPhcXWYbXj8Ie2CqUo4FJU8ypQ7KkhTuJwCWr+o86Hl/Vz7A9MR8ULqht/gzBflco4m8Vnex90yNZqyXUo4KR13ZJn9tMbAN8W8Ro9TtIeHtdqezAHEYWlS6P8urMQblTRJddfC/gvJT1gOajjVY1o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=EhiO2fu+; arc=none smtp.client-ip=192.198.163.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="EhiO2fu+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729901156; x=1761437156; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=yKoGU6wGxRX0DYXb3+4YUN6Ap5aFHiepvZOE46Xbjm8=; b=EhiO2fu+9K4NFWQfgSPePu6h6zTdojGK2Q0G4s81kkwOyhTjqVk3ssmo KG8vgFfhYC7t97IYj7pxA2sUas7fcRkLcDWLMV1JY25MqSkHBFxyoQN8U cTRV12QlXlRitedTa5CY4ulSzjLCkOz7NqJPhiQQ9zXEfyH/esrluC6MO b8xLtObytbv6Mj73ENv63On8NDM6H5Q9GJ6G+2NPvnvCfK7pFzh4jLDUl lsGz7y0T/OYtdnNQfU/f7wSIodEQrOVlabytA6MmVSpIkmPxCfh3RVoTr 7eQCeJPEKJnj4aQhEYdzqIelaNAQ5Ut+P4H3L2fDWejOPhxHS30ynU4Pi A==; X-CSE-ConnectionGUID: omx8zgPiSi6/k5e87q1C6g== X-CSE-MsgGUID: kbqTN1EqT4GlVjwNjsyI2A== X-IronPort-AV: E=McAfee;i="6700,10204,11236"; a="40959122" X-IronPort-AV: E=Sophos;i="6.11,233,1725346800"; d="scan'208";a="40959122" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2024 17:05:53 -0700 X-CSE-ConnectionGUID: fjQIB0EUTMO1tmoWGDhKHw== X-CSE-MsgGUID: 3fn9s0DASJmEIrdExvuoBw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,233,1725346800"; d="scan'208";a="104386842" Received: from jekeller-desk.jf.intel.com ([10.166.241.20]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2024 17:05:53 -0700 From: Jacob Keller Date: Fri, 25 Oct 2024 17:04:54 -0700 Subject: [PATCH net-next v2 2/9] lib: packing: demote truncation error in pack() to a warning in __pack() 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: quoted-printable Message-Id: <20241025-packing-pack-fields-and-ice-implementation-v2-2-734776c88e40@intel.com> References: <20241025-packing-pack-fields-and-ice-implementation-v2-0-734776c88e40@intel.com> In-Reply-To: <20241025-packing-pack-fields-and-ice-implementation-v2-0-734776c88e40@intel.com> To: Vladimir Oltean , Andrew Morton , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Tony Nguyen , Przemek Kitszel , Masahiro Yamada Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Jacob Keller , Vladimir Oltean X-Mailer: b4 0.14.1 From: Vladimir Oltean Most of the sanity checks in pack() and unpack() can be covered at compile time. There is only one exception, and that is truncation of the uval during a pack() operation. We'd like the error-less __pack() to catch that condition as well. But at the same time, it is currently the responsibility of consumer drivers (currently just sja1105) to print anything at all when this error occurs, and then discard the return code. We can just print a loud warning in the library code and continue with the truncated __pack() operation. In practice, having the warning is very important, see commit 24deec6b9e4a ("net: dsa: sja1105: disallow C45 transactions on the BASE-TX MDIO bus") where the bug was caught exactly by noticing this print. Add the first print to the packing library, and at the same time remove the print for the same condition from the sja1105 driver, to avoid double printing. Signed-off-by: Vladimir Oltean --- drivers/net/dsa/sja1105/sja1105_static_config.c | 8 ++------ lib/packing.c | 26 ++++++++++-----------= ---- 2 files changed, 12 insertions(+), 22 deletions(-) diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/= dsa/sja1105/sja1105_static_config.c index baba204ad62f..3d790f8c6f4d 100644 --- a/drivers/net/dsa/sja1105/sja1105_static_config.c +++ b/drivers/net/dsa/sja1105/sja1105_static_config.c @@ -26,12 +26,8 @@ void sja1105_pack(void *buf, const u64 *val, int start, = int end, size_t len) pr_err("Start bit (%d) expected to be larger than end (%d)\n", start, end); } else if (rc =3D=3D -ERANGE) { - if ((start - end + 1) > 64) - pr_err("Field %d-%d too large for 64 bits!\n", - start, end); - else - pr_err("Cannot store %llx inside bits %d-%d (would truncate)\n", - *val, start, end); + pr_err("Field %d-%d too large for 64 bits!\n", + start, end); } dump_stack(); } diff --git a/lib/packing.c b/lib/packing.c index c29b079fdd78..2bf81951dfc8 100644 --- a/lib/packing.c +++ b/lib/packing.c @@ -59,8 +59,17 @@ static void __pack(void *pbuf, u64 uval, size_t startbit= , size_t endbit, */ int plogical_first_u8 =3D startbit / BITS_PER_BYTE; int plogical_last_u8 =3D endbit / BITS_PER_BYTE; + int value_width =3D startbit - endbit + 1; int box; =20 + /* Check if "uval" fits in "value_width" bits. + * The test only works for value_width < 64, but in the latter case, + * any 64-bit uval will surely fit. + */ + WARN(value_width < 64 && uval >=3D (1ull << value_width), + "Cannot store 0x%llx inside bits %zu-%zu - will truncate\n", + uval, startbit, endbit); + /* Iterate through an idealistic view of the pbuf as an u64 with * no quirks, u8 by u8 (aligned at u8 boundaries), from high to low * logical bit significance. "box" denotes the current logical u8. @@ -143,9 +152,6 @@ static void __pack(void *pbuf, u64 uval, size_t startbi= t, size_t endbit, int pack(void *pbuf, u64 uval, size_t startbit, size_t endbit, size_t pbuf= len, u8 quirks) { - /* width of the field to access in the pbuf */ - u64 value_width; - /* startbit is expected to be larger than endbit, and both are * expected to be within the logically addressable range of the buffer. */ @@ -153,19 +159,7 @@ int pack(void *pbuf, u64 uval, size_t startbit, size_t= endbit, size_t pbuflen, /* Invalid function call */ return -EINVAL; =20 - value_width =3D startbit - endbit + 1; - if (unlikely(value_width > 64)) - return -ERANGE; - - /* Check if "uval" fits in "value_width" bits. - * If value_width is 64, the check will fail, but any - * 64-bit uval will surely fit. - */ - if (value_width < 64 && uval >=3D (1ull << value_width)) - /* Cannot store "uval" inside "value_width" bits. - * Truncating "uval" is most certainly not desirable, - * so simply erroring out is appropriate. - */ + if (unlikely(startbit - endbit >=3D 64)) return -ERANGE; =20 __pack(pbuf, uval, startbit, endbit, pbuflen, quirks); --=20 2.47.0.265.g4ca455297942