From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 88BBD35942; Thu, 20 Feb 2025 13:51:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=163.172.96.212 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740059523; cv=none; b=DCndAtN64FZvFuVGsmpL3J7ywjcdZX386xCjC9fyxsAyKKyldvdjoLnDUCPeZ5t+T+3pgu6QDvIM/EcnnFgXP4AxliIaK+/0kFM4fFdhZnsuaH5hABk+w1XUV2yN9aL9Dj9e7QYPNXgMqT0eZNR6qGzu0nNEsio300r81kpe9zY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740059523; c=relaxed/simple; bh=UnilBy2RnRb9X3rZBbiCd90PGFsBjYwR6gwfmw/GDyo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=F521U50Trm0KqxAMniKoKKRaWEpSJnoXBbuhTILvhA6MOiJ5DKG7BjXXORM2KBqAetT7pjFS/Ce+TikKmAx+5NpuJgBF9LHwFptA/fTcbc/en3pGUUZzU76/+GJ6kd2BMLYpMnCO/eC+2X6VtilRcKjjoWiiQIHqtHW9BVMTsc0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; arc=none smtp.client-ip=163.172.96.212 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 51KDpngr031624; Thu, 20 Feb 2025 14:51:49 +0100 Date: Thu, 20 Feb 2025 14:51:49 +0100 From: Willy Tarreau To: "H. Peter Anvin" Cc: Greg KH , Jan Engelhardt , Boqun Feng , Miguel Ojeda , Christoph Hellwig , rust-for-linux , Linus Torvalds , David Airlie , linux-kernel@vger.kernel.org, ksummit@lists.linux.dev Subject: Re: Rust kernel policy Message-ID: <20250220135149.GB31486@1wt.eu> References: <326CC09B-8565-4443-ACC5-045092260677@zytor.com> <2025021954-flaccid-pucker-f7d9@gregkh> <2nn05osp-9538-11n6-5650-p87s31pnnqn0@vanv.qr> <2025022052-ferment-vice-a30b@gregkh> <9B01858A-7EBD-4570-AC51-3F66B2B1E868@zytor.com> Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B01858A-7EBD-4570-AC51-3F66B2B1E868@zytor.com> User-Agent: Mutt/1.10.1 (2018-07-13) On Thu, Feb 20, 2025 at 05:23:54AM -0800, H. Peter Anvin wrote: > In the NASM codebase I long ago started using nasm_new() and nasm_zero() > macros for this purpose, and structure copies really can just be aasignment > statements. People writing C seem to have a real aversion for using > structures as values (arguments, return values or assignments) even though > that has been valid since at least C90 and can genuinely produce better code > in some cases. I do use them in some of my code, particularly dual-value return types. They have the benefit of often working with a register pair and coming at zero cost, while allowing to support both a status and a value. I've even made a strings library ("ist") that uses (ptr,len) and passes that as arguments and returns that. That's super convenient because you can chain your operations on a single line (e.g. to concat elements) and the resulting code remains efficient and compact. The real issue with structure assignment (in the kernel) is that the compiler knows what to copy and will usually not do anything of holes so that's how we can easily leak uninitialized data to userland. But outsize of this specific case that could be instrumented, I like and encourage this practice! Willy