Re: [PATCH v1 02/16] mm/memory: remove "zap_details" parameter from zap_page_range_single()

"David Hildenbrand (Arm)" <[email protected]> Wed, 4 Mar 2026 09:47:06 +0100

Newsgroups	org.kernel.vger.linux-sgx,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.kernel.vger.bpf,org.kernel.vger.kvm,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-rdma,org.kernel.vger.linux-s390,org.kernel.vger.netdev,org.kernel.vger.rust-for-linux,org.kvack.linux-mm,org.ozlabs.lists.linuxppc-dev
Message-ID	<[email protected]>

On 3/3/26 21:49, Miguel Ojeda wrote:
> On Mon, Mar 2, 2026 at 4:41 PM Alice Ryhl <[email protected]> wrote:
>>
>> It's not relevant in this patch, but another thing that may be useful is
>> to add CLIPPY=1 to the make invocation when building normally. This
>> causes additional warnings to be checked using a tool called clippy.
> 
> Yes, please do use `CLIPPY=1` -- the build should be Clippy clean
> modulo exceptional cases that may slip through (and soon linux-next
> will probably start reporting those warnings too).

Understood. One thing I realized is that most (or all?) defconfigs will
not enable rust.

$ make defconfig
...
$ grep RUST .config
CONFIG_RUST_IS_AVAILABLE=y
# CONFIG_RUST is not set
CONFIG_HAVE_RUST=y
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_TRUSTED_KEYS is not set
# CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT is not set
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set

That could imply that it might not receive as much build testing from
people/build bots.

-- 
Cheers,

David