From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 38A7F408000 for ; Tue, 26 May 2026 15:03:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779807791; cv=none; b=UDFuSbDYv6K1EAqxO4hgofZuUzsziC8DdXIaalVJQf+o1tiW2Vbxkqa71FjboyIwmEv9WrWdSiccQXb1t6Iwmeqe64xbR/wNpOC8a0M1zDes2PLmhz5Bq8bJh7JzgmLv+cSDAMmZhgEVmIpJQ63QpFgDJ6qoaugHxFvIG8qCXSI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779807791; c=relaxed/simple; bh=ICDwcl9L6q9y1CfG5kqdxmin//l8F4ZI7JbykfR+QdI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=W2NtdpLBnOEQ3+yoj6hLNJg9iNt4g/7t5gTF8ZOa9/7Ek7DrhGKvEvXBK+pcVp0etX2mw2KKc+Uft02E+jqU2jYKw2Nl1ETf/fQYHmeAFjq2cqNwZ9UWd9GQzwXZtGGaQgbX3MREMGaVLCXi9JYwkz0Jm3oCl/QIbFdK/pxDiBE= 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=VHEVSqVP; arc=none smtp.client-ip=209.85.128.52 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="VHEVSqVP" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4906869f0cbso20800905e9.1 for ; Tue, 26 May 2026 08:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779807789; x=1780412589; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=8iMitWWCqZ/up88QzDubBPwbYtpSjPJrOVW3+OZm20A=; b=VHEVSqVPE3LUYaTfqMEH4MUhkgMFH0k1OXW56RMnLenGst4NjifcJsyUmpxykzW6UE N0yzRQbNMNXQa41BDt38fMdJGO8Mmn1MkWI1g45tPNbyy/kb91AcTyuUVwVDdcd3gKha PXFFidwj9ujhfimfRWqzleVlPGA+5kvR+bDZMhIDC1rX1K8AbJOlUKDML0T4ad70SH9j PH/o5uBzTxa+djBwkr+jPEDTQkCxpj6m9Bx5qNWQgOV+z0zwJyt3Dp4hUr8rLuephxV3 Z98DBYUkS8A2UQENZIQoZAguZvnW0+8rNp6UliiMCN7UGNCNjK7JYKCUs4AJ9eMZKhwQ paHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779807789; x=1780412589; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8iMitWWCqZ/up88QzDubBPwbYtpSjPJrOVW3+OZm20A=; b=R88gms8yhbDWLibjLPPy0dlRZkHayydyDQtxskr6oz4pOvVbxccXCGM0GlqVJC3H4R i0NVOEL65RDoRUuW76b5xFdcdEkiip85hSMpR9Xe4jg1iC+BflpP3cGNK2cr3khMmOiX MjODeNyB4UC/MXKF7aZ40cGW2zuyXqRHjsj279rOOFJ3UCx7rttjF1gHbNlYloWvYsa4 abqeqWS2Lsh4/nIs0zfC1MowtZIfKtC3UCs1dbrdkvaR3MrVNu9A4Tt9G+T1i0K0eyZg utdgKBAsmTIbwQrdWfqskJLiQoqq1vj56TKWFNXgzlZL0kl6f9o9u/i+SuSxVOlfQJzb pRwA== X-Forwarded-Encrypted: i=1; AFNElJ/SOAIycAt2ZtKD0ZFWrxz/jZDSj2QZ2QMulWwMJdAA/+Ngmb24XBre0PNMK74DhNvT8QXZmBNQ74abWa0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx2hIWFumjJTTESXlIFnSgPKi+9wCICXXkkJ+Zuu26xWLamcSXs 6ZAtogxjrw0prWze0j4F+XfB1+1N+Liwy7e9BkyzSsB67ayyjTz+EQp1 X-Gm-Gg: Acq92OGEvxMq67T1K/bf48caGWpuqXAoi11WwTg5qhtUHAeJa9mDUseY5zMgW8TkghF umsO/5ylUyK00F4SxB8IPB4tT+/42jIyT1sCAcR1KC3l/k5ijRA/NArlmN/Dn87qgOZqTz1TyD5 Kw9d/cDtvnTJaSiKJ/HhrSsRl1fCu7XDLHXDcA4B3ofH5YehC0Rh6o94o2fn32AE9D1irugfpca 4WOKH3NJPELBYIRJnKxbHNykVGtJdro74Kw8+p9ZthY8eATy1RbmFlcCT3JQO/VIw4zl5gVGwJv 8L6ParPU9uhlbdjXg5rCKOrB/Vk/ksXwAkj2u6YIVrsgLCxDSLfm3zmeO45/11qWpF3EV7kvT/v MLk062dpsatdDmgB3ecdBpusSVypT5sk8irYTQpnoYR7SwXxlyudTu646EBKXd5kkLeg1dzDJRd VOa+hvNQp2s4COLsXhY3zJHReONI3MxGhD19rRMO8zffozEjmR1A3LsDRtX4IH4pmo X-Received: by 2002:a05:600c:4e43:b0:48f:e230:2a1d with SMTP id 5b1f17b1804b1-49042ae77b4mr334732975e9.32.1779807788363; Tue, 26 May 2026 08:03:08 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4904561f682sm354998435e9.13.2026.05.26.08.03.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2026 08:03:08 -0700 (PDT) Date: Tue, 26 May 2026 16:03:06 +0100 From: David Laight To: Miguel Ojeda Cc: Aary Milind Kinge , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Miguel Ojeda , Alice Ryhl , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, driver-core@lists.linux.dev Subject: Re: [PATCH v2] rust: devres: optimize type name allocation and fix truncation Message-ID: <20260526160306.15351508@pumpkin> In-Reply-To: References: <20260526094329.533943-1-kingeaary@gmail.com> <20260526115825.1480768-1-kingeaary@gmail.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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 On Tue, 26 May 2026 14:37:44 +0200 Miguel Ojeda wrote: > On Tue, May 26, 2026 at 1:58=E2=80=AFPM Aary Milind Kinge wrote: > > > > The unconditional 128-byte const array allocation for every unique > > `Devres` caused unnecessary .rodata bloat in production builds, =20 >=20 > Wasn't the string deduplicated? >=20 > > terminator), the copy routine now appends "..." at the end =E2=80=94 co= pying =20 >=20 > Did an LLM assist this patch? If so, please add a tag: >=20 > https://docs.kernel.org/process/generated-content.html > https://docs.kernel.org/process/coding-assistants.html >=20 > Moreover, this should be sent to the right maintainers and reviewers, > e.g. at least to "DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS". Cc'ing > them here, but also please Cc all the "RUST" entry. >=20 > > + let mut buf =3D [0u8; 128]; =20 >=20 > Why is there a hardcoded literal? Please use constants where possible, > deriving the rest of the literals from that. >=20 > > + let mut len =3D 0; > > + while len < 128 && static_buf[len] !=3D 0 { > > + len +=3D 1; > > + } > > + > > + // SAFETY: `static_buf` is promoted to static memory, and we v= erified the null byte. =20 >=20 > This should explain why this is all OK, e.g. why it doesn't go out of > bounds (a local-only reading of the loop above would appear to make it > so). I'm no rust expert (or novice) but that code all looks like run-time initialisers rather that the static data you really want. Can you generate the '\0' terminated C 'string' by including an explicit zero byte in the rust one? -- David