From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1F21C52D7B for ; Wed, 14 Aug 2024 16:02:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B4E86B0088; Wed, 14 Aug 2024 12:02:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 764E56B0089; Wed, 14 Aug 2024 12:02:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62D526B008A; Wed, 14 Aug 2024 12:02:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 40D756B0088 for ; Wed, 14 Aug 2024 12:02:42 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D123EC0F1B for ; Wed, 14 Aug 2024 16:02:41 +0000 (UTC) X-FDA: 82451318922.30.80FA599 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf14.hostedemail.com (Postfix) with ESMTP id D70F210001E for ; Wed, 14 Aug 2024 16:02:39 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q2ZxuYGe; spf=pass (imf14.hostedemail.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723651287; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J7DaJyWm74H8+0ptv93yKtRvc3RFiY3qs13u3YpRi7w=; b=VbueDUa7PGqcr6CFI+JKuuhnjqfqo4ZfjK9aha4pj6VA4+XoyEq9viBUU/g20aKiL8fOM2 A7mDLtIHfRa+j2B9WOVwiO3T+HCdU8ihaswgjv0f+tzz7YjC/vHH7lpvOyrybKmnEzDwC+ Bi2+Pko7yC385ZgnW87uOYxcPQZSHog= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723651287; a=rsa-sha256; cv=none; b=CjJb0NuiyApa0n8gpd1zjCNNDePQ2TFbtfSEfacYkMAJAtFevjbp/S0HyDoGEJ+NSCN0H7 e2MIIOSsVDKaNynCWvNA0lEHRxQxr6cQr/eVzIUBAVacBgHy1JiSv0R47qUmIZjor8uZvR nX00+A7OHL/cl10GmuB2v9JLKsILkB0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q2ZxuYGe; spf=pass (imf14.hostedemail.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2f1a7faa4d5so399921fa.3 for ; Wed, 14 Aug 2024 09:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723651358; x=1724256158; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=J7DaJyWm74H8+0ptv93yKtRvc3RFiY3qs13u3YpRi7w=; b=Q2ZxuYGeR5B1/cv45ifAdFcQ9JUGuMhuOp7BB6VQtjGqlJn6bTj6FxVtit2qs5+WF7 86rv0ftIWnWizB+ShdNzyX5CqbcMjugjutHaak4NL//uRcXv2qzJNcFAFdBj+1n8Jx1X 54Aa9FBDPgf/4es+CKmV1/zhwlJySiTGTumqVHaL+xUdrMvEdsr0ZnQ2rCO/gLS7gz2Y B9WVkelDx9fXZnQnSX0JkjtI8ssJB+IZKpGFA8RTfy5d47lKX6pQabtxO7ckFMXOAoBA BPKU8ldDcxqzvu1mvdy2XBA3vgZJ1foUpb8xKMW9JoKkjN5IjI7X+IR/t1y1kIXfCFEc j4+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723651358; x=1724256158; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J7DaJyWm74H8+0ptv93yKtRvc3RFiY3qs13u3YpRi7w=; b=PxnQbVcZkK6+AbJyYf3vHuNRXIHq1HvyXT78DvF8eT1e18lDMKQVbm7C7TEa90p3Q6 WPsBdYfl2h/ov7wBCP/YoGgfyVz0U1fhBl/gZ4YgSkawa3+2T8/1RlsJQMCt5nHryfUt 0Tc/nF3/mNJkQNiv/mAOxpCfBrLj8LNqReQh9wKDd7eubJOcnXmrl4amzZ11aPdYzEMh 63AVA3LvdMdDEhXfkZSGuoBA89v1qusyaWQBY76ybbITV2OCA3Y9u5hWvpZJI9CuLkVJ RC8JNt4+eYSNwfGp2mEpWczR10hEUDa8WEaj1fQZgtTRmcruLlUm6SbkdarFOZJ5avbf P0zg== X-Forwarded-Encrypted: i=1; AJvYcCWrCPE01tN0xjpUPJJT2of4NobRDBCHzuG3QhKAsK7FfrnDWmYcUmWc5l2Y0kRD7YwRaUizPxGcGsO+We/AmQlDXLA= X-Gm-Message-State: AOJu0YynRfHZqiCnH+5YUGcPdouAvst9b5GxT8jyoff53+hvI0eYdM+v SHXzmeHTtcvVtfdPskpp3nnnla/zwv3h0maOZXU9TAUu3+VgA0/C7HtTZNxt04PYUs5BadMT4Z4 VOh/NvgCBgJ78wzwV81lHeXspd5E= X-Google-Smtp-Source: AGHT+IHPEfjt4tSwyaQ+mFcJTrUDUfvWWME9N3uFHGKGWzymbz/YnxR9JdVv75DKZqWaQHTCC/TZWw0TDjzoorJheVw= X-Received: by 2002:a2e:74f:0:b0:2ef:24dd:8d86 with SMTP id 38308e7fff4ca-2f3aa301363mr18379791fa.49.1723651357378; Wed, 14 Aug 2024 09:02:37 -0700 (PDT) MIME-Version: 1.0 References: <20240812182355.11641-1-dakr@kernel.org> <20240812182355.11641-5-dakr@kernel.org> In-Reply-To: From: Miguel Ojeda Date: Wed, 14 Aug 2024 18:02:22 +0200 Message-ID: Subject: Re: [PATCH v5 04/26] rust: alloc: implement `Allocator` for `Kmalloc` To: Danilo Krummrich Cc: Alice Ryhl , ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, benno.lossin@proton.me, a.hindborg@samsung.com, akpm@linux-foundation.org, daniel.almeida@collabora.com, faith.ekstrand@collabora.com, boris.brezillon@collabora.com, lina@asahilina.net, mcanal@igalia.com, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, airlied@redhat.com, ajanulgu@redhat.com, lyude@redhat.com, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: hzbg3tuyq7zfpr9h743oynz79eij8hoe X-Rspamd-Queue-Id: D70F210001E X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1723651359-123421 X-HE-Meta: U2FsdGVkX1/yD88raF9uQyu5dJmoxFN2360/hghigF4Wek0qDLDp4HqnwhTWEzCTaHfwwhLBbsCkpHQ8kZd3FUEHx/zcV7he+UPuTxVo58Ak+8LsfVvSz+sIjWqvvZkLvHY25c0OQPz+AM8kiNHEEVM11R+2gqX8B6XvSViCisYEM04JS32oU2WHSCPWnTMIDrKnvnjrX9hdZkwH0h+N54/eUQGfIZzc143pi30ZpmwRo2/IHHOi4786xQNpSrXUxmG3GGDH0HFQIhDb9RGl14J44vFS+m/ZEt+s+CFAfQAqdIzDi7qxLkropS21ZRaddNaFq39BynFZhGVeQiWF+D6eDVQ5oIXBNt8UcfFLPPyqZmvOACEiyR9rU5rEoHDts+Kptj6A5FjcJEq6RncfZvGJQDHPztIW42+2T8jxcezOiPGvI9HzzIKXKAnmkX5l5QyF3HX+ra/LJxmEuUkokxIdJ9GPJ57jI9MalGKP72LG3FPFy2AEXvdSZUtR3xlzqRlOpmLs5feS0f6ONdmPf2ssU0f0eqTLfVBToGTtkQIHGZh0DhG53yLCXeactkhcHNU/fyp54erFxUJgPV8HRzdUo3l+mcwpdk4Pgr+i00ISlF+TrDfoL8PUhUJiBwfE36HjV5eqne2yaFDTA2WmUs8vOT4ehPZ4QVWpO4e4SmK+mebhA2llMDhedz/PeorS3dbHbyMJDRLzzzy7TNqbMLmq3er+XwWWdRpYDTkhKGi0DbGszS3RTMa2Jl5HxYtWrkhp2D4NR8o8ov9XofKNQImq7IQXMweO5sTpzyDqkIjH13AbNKnt62W6B8J8EY5BMwIwL4H+YR/wC4KeFyLaJ0dTp2gmmfX3U+sWghiydrmHjALJfxmRhQwXve8q9EswRgAtaXoQDDcsRbkKN2RDw7b3c9ZsoitZAyaRk60MdrdWdNk80rgXb9t9zWEtYVfJPogiAbVrKxrV81f0tKq XqXGGVc2 uVD9cNoO9zhoN6NbspwbsZD6fGloqErVULfj6sM0Av8+Z6hyDml7vIndQF7p3M273nKA8ziPSVGmwmF/GoWFfSpcOGL3XlD77d2Uxb+Fqv1adH+CSqe+Q6OhtxrDqQ3JpJs3YyquEQwGjYqYUsFPA7Mv/48pvlFVMXHX8KqWlQX84Z2VUyxJ4C3wmNu8LrxERYU/9e/jLNNGIE1VMjLdXG2ONwQxsOlrbxjX8MJeFRt2OcyYPA/9RRIurR2p7yhRFVavQz9vw2wMtjIh5ApvcGe6pN1wjEDWsZQdmLvpzteJLkpfPN+iuP2GRlDddYoifmWgJpMGHeA77FoIKZInC4sdxYEU5uSm8NzyouZ01g6kILjjhaslPPz2JOg1o8efVoNYc4r8lnATrDga+c8ht81wYTUuQcJO82b8tIi0urRutVcOdt5MC2RWIFzJ+S68H2CfLaxHYR3SG118= X-Bogosity: Ham, tests=bogofilter, spamicity=0.124492, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Aug 14, 2024 at 5:20=E2=80=AFPM Danilo Krummrich = wrote: > > Indeed, and I think once they're honored we should add them again. > > It's just that I think as long as compiler attributes aren't honored, we = should > not have them in the first place to avoid confusion about whether they do= or do > not have any effect. In the C side, many attributes are not honored anyway, depending on the compiler (or tool like sparse), compiler version, etc. So it would be "OK" in that sense (even if here we may know there is no C caller). > It's not so much that I want to remove them for krealloc(), it's that I d= on't > want to intentionally add them for the vrealloc() and kvrealloc() helpers= , > knowing that they don't do anything (yet). One can think of them as "documentation", e.g. seeing `__must_check` tells you something about the function, so I don't think it would be bad to add them, if they are not too much work to maintain. I checked about `__must_check`, because it would be nice if it is used by `bindgen`, and it turns out it already does, but behind `--enable-function-attribute-detection` (apparently for performance reasons): int f(void); __attribute__((warn_unused_result)) int g(void); gives: extern "C" { pub fn f() -> ::std::os::raw::c_int; } extern "C" { #[must_use] pub fn g() -> ::std::os::raw::c_int; } So that one should be kept at the very least, and it is a good example of potential improvements later on based on these attributes. In general, I think it is not a bad idea to write this file like we would write other C files, even if it is not a regular C file. And adding more information to signatures is, after all, part of what we do with Rust overall! Cheers, Miguel