From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (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 7B3D523A5; Sat, 28 Oct 2023 16:37:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ryhl.io header.i=@ryhl.io header.b="MLN9dH3Y"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="a1lCYYoR" Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14535ED; Sat, 28 Oct 2023 09:37:54 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B70C73200312; Sat, 28 Oct 2023 12:37:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 28 Oct 2023 12:37:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ryhl.io; h=cc:cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1698511072; x=1698597472; bh=dMa7bkda/jUzx0xX9fiF353eZ/NQo4woDy/ hHwVKMRo=; b=MLN9dH3YBA+tgJQfIbJgmZBbrKlBo6fTui7Fwsm/86yHJrW283q 844IWDT/W+PMPiGyQOFyst9/l3xxxqb1byVgAJe2SBzEXlUMQSjKAAf4ASE6o22W 7dASywHzD3GC04m/SCFWTqCFKRsfUQfAy8rcrGYgZZN3S11rkqH6mP7S4coPtBrf knxiceI2/x4q+Vtur/E4aldZdViafpdABkuPoUjjkl7ZsdUlmNJomC58icxVr15I bY62dwC5q2CyekqFqq0DUuO01f6Gqdatdm0O8FA796wd7mhaBHGKpIqkol6wowXc n7sbOxAlsQgtajlxbr3m/Ho/p2Br64lt8FQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698511072; x=1698597472; bh=dMa7bkda/jUzx0xX9fiF353eZ/NQo4woDy/ hHwVKMRo=; b=a1lCYYoRN3GQ5t/4tlbqR1Q5tD87I6Te/cBcAfy0I6C2dj5KoD4 rFdTVrSSAddteIXiUxbbU8rRpwI5imZ5kSJa8k61tapjao3ZgK5a1FVuyK/ufr4Z YupMeRWVGyQiJyGt5iabCIi5FLCW9VEOnQsji+NdicRv2+o/SDztXbnJ5u2rJxYs qGAWZBfGGWZA9eavIc/at3CAv+RXZil6mAnS8t2p9QYUHWlN93IbZBW7jX13gfnK LcrUx0U/vbp/fg3IBVDgQxIcnQvdjWPrQDbfllXGVcqrJ3O8jsj8NNTIbTmjzQ1q MeqOmxnTd8Ye9FGG8WX/lwS0Dh7kFaDyeXQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleeigdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomheptehlihgt vgcutfihhhhluceorghlihgtvgesrhihhhhlrdhioheqnecuggftrfgrthhtvghrnhephf eghfelgeffleegffffveegtdfhleetgeefveeihedufedtffffledufefhgeehnecuffho mhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhhitggvsehrhihhlhdrihho X-ME-Proxy: Feedback-ID: i56684263:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 28 Oct 2023 12:37:49 -0400 (EDT) Message-ID: <4b19dd7d-b946-4a5c-8746-f7e9c2f55d25@ryhl.io> Date: Sat, 28 Oct 2023 18:39:04 +0200 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 04/19] rust: fs: introduce `FileSystem::super_params` Content-Language: en-US, da To: Benno Lossin , Wedson Almeida Filho Cc: Alexander Viro , Christian Brauner , Matthew Wilcox , Kent Overstreet , Greg Kroah-Hartman , linux-fsdevel@vger.kernel.org, rust-for-linux@vger.kernel.org, Wedson Almeida Filho References: <20231018122518.128049-1-wedsonaf@gmail.com> <20231018122518.128049-5-wedsonaf@gmail.com> From: Alice Ryhl In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/18/23 18:34, Benno Lossin wrote:>> + from_result(|| { >> + // SAFETY: The C callback API guarantees that `fc_ptr` is valid. >> + let fc = unsafe { &mut *fc_ptr }; > > This safety comment is not enough, the pointer needs to be unique and > pointing to a valid value for this to be ok. I would recommend to do > this instead: > > unsafe { addr_of_mut!((*fc_ptr).ops).write(&Tables::::CONTEXT) }; It doesn't really need to be unique. Or at least, that wording gives the wrong intuition even if it's technically correct when you use the right definition of "unique". To clarify what I mean: Using `ptr::write` on a raw pointer is valid if and only if creating a mutable reference and using that to write is valid. (Assuming the type has no destructor.) Of course, in this case you *also* have the difference of whether you create a mutable to the entire struct or just the field. >> + // SAFETY: This is a newly-created inode. No other references to it exist, so it is >> + // safe to mutably dereference it. >> + let inode = unsafe { &mut *inode }; > > The inode also needs to be initialized and have valid values as its fields. > Not sure if this is kept and it would probably be better to keep using raw > pointers here. My understanding is that this is just a safety invariant, and not a validity invariant, so as long as the uninitialized memory is not read, it's fine. See e.g.: https://github.com/rust-lang/unsafe-code-guidelines/issues/346 Alice