From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B00C283A17 for ; Sat, 17 Aug 2024 13:20:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723900804; cv=none; b=Mp9rsVTbzqj7QubvZfkosc33o7nvE7xirqRng879OiYdpQ4lOoqLY7143/ebIeuzT0hB+DHvmrqUG8iCCvprqh2M6wz4ec/IopA7Vq5hac54mOTtdrrWEP7PRHRE9A49zlv+sGym3Rtt8NxGoEEyCgGJOyZvOSS/dupJ0gUk5rM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723900804; c=relaxed/simple; bh=mPLPgPLHO6Ixud7oOpd/z/JGbxH2aQkAFVO52+GRYik=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bN2+2bfW7wOdzSTFtU/86c62a4A1q6dDx+mbmtgIorrFG3MUxGVQw03nbtRbUrWgFyG4MnrZ7BwrHA6Zk6Xe3Kcou91hakIHSUdFXlMH1Yi/U9FeUAaRIQkogCX3A6wmr5ml3DPGoSGkCf+yR2daZqTaF8UBAJ46pXcC3CILHvU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=g2XMO8Kr; arc=none smtp.client-ip=185.70.40.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="g2XMO8Kr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1723900799; x=1724159999; bh=j/PPS3EYuNHFT3+6UMf12p/CM7ltsg2HQQvZIYDDvrY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=g2XMO8KrGCemhep3mXA0XstRJkQG4mViRXVMJOTlbUtQX520QNQqN9r6JMwMna8Xq XbnVwnVDh6YM0IVFsqguVYgnAKYuEz2GLxRS4xfWNFH4Lv5YCE/HXjWT4OF5cI20Dq LvnQam9XXddIi7DxFZWLboTBeWE+OGzwzxU6vMgtFD9vRSolPErnt7LksY1hkAKgIy uLffKcoXtUMQjV8w6YoajX4pQD7IF9pPgW6k/5UMMbGezMywFyOon+GTUHkv8O0ZcG rSjI8ehM4dAxKOXHvIcBhoqMvIpbb3pSLNPGUe/aJ0TjGH5OGW8+z201JfskKhj8qN P9qearbDqczDA== Date: Sat, 17 Aug 2024 13:19:55 +0000 To: Greg Kroah-Hartman , Sami Tolvanen From: Benno Lossin Cc: Masahiro Yamada , Luis Chamberlain , Miguel Ojeda , Matthew Maurer , Alex Gaynor , Wedson Almeida Filho , Gary Guo , Petr Pavlu , Neal Gompa , Hector Martin , Janne Grunau , Asahi Linux , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved structure fields Message-ID: In-Reply-To: <2024081705-overarch-deceptive-6689@gregkh> References: <20240815173903.4172139-21-samitolvanen@google.com> <20240815173903.4172139-37-samitolvanen@google.com> <2024081600-grub-deskwork-4bae@gregkh> <2024081705-overarch-deceptive-6689@gregkh> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 985bccfc1600ca44c1aa5ffd0d6fb059413f58a3 Precedence: bulk X-Mailing-List: rust-for-linux@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 17.08.24 09:41, Greg Kroah-Hartman wrote: > On Fri, Aug 16, 2024 at 08:50:53AM -0700, Sami Tolvanen wrote: >> On Fri, Aug 16, 2024 at 12:20=E2=80=AFAM Greg Kroah-Hartman >> wrote: >>> On Thu, Aug 15, 2024 at 05:39:20PM +0000, Sami Tolvanen wrote: >>> Especially as I have no idea how you are going to do >>> this with the rust side of things, this all will work for any structure= s >>> defined in .rs code, right? >> >> Yes, Rust structures can use the same scheme. Accessing union members >> might be less convenient than in C, but can presumably be wrapped in >> helper macros if needed. >=20 > That feels ripe for problems for any rust code as forcing a helper macro > for a "normal" access to a structure field is going to be a lot of churn > over time. Is the need for a macro due to the fact that accessing a > union is always considered "unsafe" in rust? If that's the case, ick, > this is going to get even messier even faster as the need for sprinkling > unsafe accesses everywhere for what used to be a normal/safe one will > cause people to get nervous... The reason for union field access being unsafe in Rust is that you can easily shoot yourself in the foot. For example: union Foo { a: bool, b: i32, } let foo =3D Foo { b: 3 }; println!("{}", unsafe { foo.a }); This is UB, since `3` is of course not a valid value for `bool`. With unions the compiler doesn't know which variant is active. Since unions are unsafe in Rust, we don't really use them directly (in the `kernel` crate, we have 0 union definitions). Instead we use certain unions from the stdlib such as `MaybeUninit`. But the fields of that union are private and never accessed. In general, unions in Rust are very important primitive types, but they are seldomly used directly. Instead enums are used a lot more, since you don't need to roll your own tagged unions. For this use-case (the one in the patch), I don't really know if we want to copy the approach from C. Do we even support exporting kABI from Rust? If yes, then we I would recommend we tag it in the source code instead of using a union. Here the example from the patch adapted: #[repr(C)] // needed for layout stability pub struct Struct1 { a: u64, #[kabi_reserved(u64)] // this marker is new _reserved: u64, } And then to use the reserved field, you would do this: =20 #[repr(C)] pub struct Struct1 { a: u64, #[kabi_reserved(u64)] b: Struct2, } #[repr(C)] pub struct Struct2 { b: i32, v: i32, } The attribute would check that the size of the two types match and gendwarfksyms would use the type given in "()" instead of the actual type. --- Cheers, Benno