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 DEC65C0218D for ; Sun, 26 Jan 2025 20:28:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34FA0280109; Sun, 26 Jan 2025 15:28:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3000D280101; Sun, 26 Jan 2025 15:28:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EE82280109; Sun, 26 Jan 2025 15:28:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0032E280101 for ; Sun, 26 Jan 2025 15:28:25 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A46491C78B8 for ; Sun, 26 Jan 2025 20:28:25 +0000 (UTC) X-FDA: 83050740570.11.869FED9 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf02.hostedemail.com (Postfix) with ESMTP id C69308000D for ; Sun, 26 Jan 2025 20:28:23 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bXeIOD53; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737923303; a=rsa-sha256; cv=none; b=zkdm782ybS1WJy1MWpaIwupKmbjlqxcJoWLqgRuLI7DyyvrpGsalnjGwEeUyD19hW9oHqw G+hmeHBt81bXFV++K0MMdD0ndXyT7GiDgAFbxZ0jWtGSg88D2zUfsC2gZPZPRFb01wqoZm 3Z1eGk5EP4rj5EiTstAYNZjhZexyfoA= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bXeIOD53; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737923303; 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=/fuOemPeHf82tYw4L82oPf1R2tiFXPm8M1M6oFL6y7E=; b=B2QOg7p0n3SnE/cdESgMyeMdv8SA7SmwgyhviTB1fR2jm+x9NsRMdCy/Wy42eZhxLMOCih 7COA2IYirzklleZcwT+DfB1v3h0BXywxAYCxLKZHbAGpBaOGG6xcSn60m0a6K3EFin2nUI +2Z5hkwSr/8m3tMOAcDZ3dHrbJ0sCZw= Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-2ef7733a1dcso902984a91.3 for ; Sun, 26 Jan 2025 12:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737923302; x=1738528102; 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=/fuOemPeHf82tYw4L82oPf1R2tiFXPm8M1M6oFL6y7E=; b=bXeIOD532mFwfMVllo40i/LS88Z9xTpvxrQuZhxupdrXwF7NCuFqyn5S42QdrsBbeF AxWVuH66fFFXvISGdwu2+hYRKedWogFobQkRDFJd/RJha6ippp9EIzpLW59fYUwYKjya ud4sricJSURlbicau9PjhiBG9hZ0jP/64aBt0d38DYd5gwh3oGLGruFLm6EFQm+682z2 ewjldKEejxInJ+VXJj+4I3zHpzGvR3rH94w+qK/qIneJOhWfbOX6+bvieQ6oPaVHWwTZ ufLIkjoVk0iginQWLq1rX4XoqAUGdvfCBetZd+l8QG4iwNMUGvyu5BhAFpZhkonx5QfE MZXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737923302; x=1738528102; 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=/fuOemPeHf82tYw4L82oPf1R2tiFXPm8M1M6oFL6y7E=; b=MW++5Mq83eCuUSywQRVu1/9i6q2nEELMKXvBclmi7YGkJ7zZ6rwS183uwIzgfXQBj5 EQf10zCHySQqtIrxkrwa9GWDilcrnPmACT0EYFwuiLH/Nl99tiFG2yIdF34/g0UO/NEI vVhhxi81ztbCPwF0FXPuaZlvg7yJc+LZZeYKEy0LSeq4OGt1ON1n6OEEmilKab9zbzpc sC04QLsJjmvXa6SAqm6whUaeXsA3UxQLUdAO3Ugir8/jF7doslffXTaMRWCr5M9vYq4p 0ppv1bc8RYE0dSsLYYCFkZM3jLS/H8eQmEFWTAfhGirokg7f6jMTaZFXrSvcfCgXqTuI 7fGA== X-Forwarded-Encrypted: i=1; AJvYcCXgmbiyhBnoICxA6tiTWuvGBIvbI+HA4hSH7wwoKdoAYbvvl2TOt7xZUvoTYlFRJMWu7g94wbMlPQ==@kvack.org X-Gm-Message-State: AOJu0Yz8/YomdtWMSRJ4hyjxBDwUiTYQFWWp3xzO/4xFNwoEE+AEq/3Q 83MGwFwpkZ51odBDa9zK3ABzIWMpfcjjvXl76CPJOXsYacuAB7O27r09cqL1Jka9dSgzZJ+8jT5 eDyvdJZ7xaWxMYZXXt8WzAnVUN40= X-Gm-Gg: ASbGncvglKDfElKWrl5nBzMhprO7oeeAZkzdqeaz5XYtCPqQGxuC5bYyVEj7tdnpMkN LbDlX1J5nGaRRzcPun05cSXPDZOtx9brB9O8V59iaqx3SoN4mJRzF40lulvd1/g== X-Google-Smtp-Source: AGHT+IEPv6sJDDhiY47r9rGAf5q/XfElXvkpnd8oy5nfzGr+m/r0VDdGbzc6I8QeVns4ODtsI2pMDYTKFBsjit/TQeI= X-Received: by 2002:a17:90b:2e8b:b0:2ee:b665:12ce with SMTP id 98e67ed59e1d1-2f782c561fbmr20992587a91.1.1737923302405; Sun, 26 Jan 2025 12:28:22 -0800 (PST) MIME-Version: 1.0 References: <20250124162248.60104eec848619a187242392@linux-foundation.org> In-Reply-To: From: Miguel Ojeda Date: Sun, 26 Jan 2025 21:28:09 +0100 X-Gm-Features: AWEUYZmMuLqELedibeFOYeUnW9YSynLGvn2hlU7yK40dMVZ0aNvGaZhd631In6c Message-ID: Subject: Re: [GIT PULL] MM updates for 6.14-rc1 To: Linus Torvalds Cc: Uros Bizjak , Miguel Ojeda , Andrew Morton , linux-mm@kvack.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C69308000D X-Stat-Signature: doznimq8tah6t6qenagzdi7s9z6wmu1b X-Rspam-User: X-HE-Tag: 1737923303-377838 X-HE-Meta: U2FsdGVkX1/G1mcHn8q51rDTncFQW/z3fI9P7acDq46L9a6aodygEy3c5A3iWsdbVbdbBmNVdjhBWGUcHZ7wft4S8XQr8Cem8Xh8+HhxjelYHRE1+NzwzM0E2v6+vu9UdQtyehl3HaeaU29/wUSwvL503s+8NP79XT8EmKoYEosPe/nfOZGqY4kHHCWCbgCUe6Rm+/ejTuHBD0+CzFnC80DwXE6ePwEDgO6hANUTYJg03tX2sW/l1uJ6yWAxdj29UQxS6CtpHF53b30ujnEfo/0dWSKH9O9Fbct6FvF41b6NAelpLwvQKwlhAm3Imo/ehTPvyEmpNG7A6fB6Xmpsetym6fNkSWGSop0MKGlLOjfhPq4VZZnnY52xiDhZoV0AYDeYQAA2vpJ+BxVHD5m+5yGattlzLZvWpjLtV2WBecHEltsT7d4ryWZZrSq0fl1GkzXCuTJgZXqwnkGFZ51x7MYU2WwQArL3pm2QgKKI8Im8kROAh1Ry9FD8kQuuThrQ6limzDXRhSRlMP6pmQVXtHHSoqYgglVN7aNLDO3Lj6HtmAPtWWRHHNcIZ6zy/Iw3byEvdLQgx+qSOAT/t+6MTwJpFo3AYFof7XA4nIjSyfpv9ZJ5xiAKKqVZH6R4d4Cy2rCWNnxtYl06uzICMHF0nDI+T3DlJX70pIKsHYXEppfzETO6FzjhIxSqdDOCJLmrdJCxEcwXrJX0wO9ojTbpTTrKSSFRgPn7oqjLH6Qu8EU01klIj86C2aFF3rcYh+883hjboW5o+VE/23gSxfFisHmF0i4G4xrVlSmVWTpNP94raZkfegCts7QOKKkfpk5J7e0vpn2v3O2cf9eX5FsNWlVX4NjPQJUJ8DAKrcBNnUjYCODM0AabqsW1fQu/X8LcnGU3dOrb8SIcC7jS7b54eDZdj+J6kiGZknAyhII20HE4YYUkeSCj9FgPQwjraXErTJSSuVnjljCdk6Ujwqs dfs+xUBQ jbU4kF9g4ognpMpFO/rd8mVZgkHO8yGU+IC3bNOHVX3Y06D4AGYRjTnjQru58u+smvN5y0lgI1pgmrae0Kjw6Gbbq+FD9BOQa5owFUd7x0TyrfUDVWb9RMiJ2yXKD+ZklXLh46if6H1Rs9Lewaw5GB5EAer8NFLJfqJKEM8vS9f9KILFUBwovmt022ZkUkFacgHjMM1KiI648JTykyGnycm4j0J20prXT1BoQ/TRvp0ispx6WowzzxPvLYrSdXm1FCy49lqAoz9DquvnY7Das9hD1gZohk/IEO5uJCD+GG9jjObQkMU7Vs3JDaVNr+UR+zyzGDng7NjSs8lqa0hkm1HJXnBnRSu6acC8p6klqTkTIK7yW0QQf1fOM9nb7jYjDrNaIbmEfc6ebRfzfKqxUkLfLo/CXP1WXthbZLQSRTd/BRGVTucTT71oo6VRhfuLwWUnq X-Bogosity: Unsure, tests=bogofilter, spamicity=0.471000, 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 Sun, Jan 26, 2025 at 7:30=E2=80=AFPM Linus Torvalds wrote: > > Let's add Miguel to the participants. Miguel, see > > https://lore.kernel.org/all/CAHk-=3DwhddBhfi5DUi370W3pYs+z3r2E7KYuHjwR= =3Da1eRig5Gxg@mail.gmail.com/ Thanks for the Cc -- I build linux-next with Rust enabled with some configs/compilers/arches variations, and I also have a run using Fedora's latest container image for rust-next, but not the combination of both (and I mostly do Clang builds). I will add a couple distro builds for linux-next in my matrix, one including GCC, so that hopefully at least you don't get blocked with something like this. > for my "this doesn't work" report, and then Uros' suggested fix in > > https://lore.kernel.org/all/CAFULd4a-2F_zKMeR0Yjo2WhRLmyoOQ1VdR2qdV34B= rM-b_cQCQ@mail.gmail.com/ RUSTC_LLVM_VERSION is indeed not necessarily bindgen's libclang. One can see the latter's version with: bindgen --version --verbose Though in `scripts/rust_is_available.sh` we use this to support older ones: bindgen scripts/rust_is_available_bindgen_libclang.h 2>&1 | sed -nE 's:.*clang version ([0-9]+\.[0-9]+\.[0-9]+).*:\1:p' So we could easily add a `BINDGEN_LLVM_VERSION` if we go that route. (We also fetch bindgen's Clang version in `rust/Makefile` already to tweak a flag, so this could be useful anyway.) We could also do a `BINDGEN_CLANG_HAS_TYPEOF_UNQUAL`, i.e. mimicking the `CC` one. A bigger hammer is using the `#define` we already pass when using `bindgen`, i.e. `!defined(__BINDGEN__)`, in the source code. I tried this one quickly and seems to work, but we would need it in both places `__CHECKER__` is. > That does seem to work, but I'd admittedly be happier if we could just > find some way to dynamically disable/enable __typeof_unqual__ based on > which compiler is used, rather than make it a config option. So that > bindgen would not see it, but a recent enough C compiler would. > > We already use '__has_attribute()' for some of these things. There's a > '__has_extension()' thing that comes from clang but that gcc also > supports. > > But I can't find the list of extensions that that model supports, and > I guess typeof_unqual isn't on that list if I find it. In LLVM it seems to be at `clang/include/clang/Basic/Features.def`, but from a quick look at that and the commits that added `typeof_unqual` I don't see it (but it seems it could have been there, indeed, given other keywords are listed there): https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basi= c/Features.def In GCC I see a few at `gcc/c-family/c-common.cc` (`has_feature_table`) and `gcc/c/c-objc-common.cc` (`c_feature_table`). I can't see `typeof_unqual`. > This does show that our whole "CC_HAS_XYZ" is kind of broken for the > Rust integration in general. Yes, bindgen being libclang-only is one of the main reasons why we call GCC builds with Rust enabled "very experimental" (and why Rust doesn't work with GCC's randstruct plugin and things like that). Ideally bindgen would have a way to parse code using GCC (https://github.com/rust-lang/rust-bindgen/issues/1949), or perhaps it could fetch layout information in a completely different way, e.g. building a C file that computes it. There have been some discussions and even some code written about this over the years, but so far nothing really usable yet. Cheers, Miguel