From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (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 317811A2656 for ; Tue, 3 Sep 2024 09:58:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725357486; cv=none; b=fR0QMI/EC3OLiFox6Tc+3HrvEPM+XdriSyxe9gwQ8031ruAZJpUo8K4ZY1rUo7rgi7lhkq8XPIGbxszSarTpygjZiFo4y+T8a6lCZM6wlaoJOgLjuKXUj9hQ52IjMGuv5ycBgKdgokwTJYds8gW5dFmvPbDL/q789YZFi/gAqAQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725357486; c=relaxed/simple; bh=JpqUEURrVrtIG+qV2DIJf8rEzT0OhRvDn4t/5r7SbP0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VF32Ty1nRI4yY9y7uZRUy+OARUT0RFTSCCKa3gYsuJc3StjrGVTtgjL5zrS7wH4ibQ6ZhwUEScNVElsw3QsJoguAVhEzqjtjj7GFrW/Ylrs0xzE6qT1MbSEv32cJt0PfOdAbwK0kakX23Ocm7ZZG8oejPmqP+WaadWpAM4/oZHg= 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=mJf03Zln; arc=none smtp.client-ip=185.70.40.131 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="mJf03Zln" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725357482; x=1725616682; bh=JpqUEURrVrtIG+qV2DIJf8rEzT0OhRvDn4t/5r7SbP0=; 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=mJf03Zln/4TaruErEIo8kyEXoJ493h/c3qXFTlOdd1LDFucS+2oLEAk699lcYjw0D 8eCX6ZlU0jrIk0xDEKvEMsn1vyqanVMJfK1DkpiAINXngIOhGQpPebU9W+ScPMmIjd R/gwtb7izGSjsH9vROHLdoz+wSfLruKNcxTRVwBS3SFmT1Lq97S7ZJiT7Hv6s6EtdJ Xd8r0CQJrcqM8Aaeu+4EIMgUl5UPdlfJtnbsjH6ulPz33bOQwLxktLIhX5OHCuNT0I cwRnBYHT2rldsVtyri1YPf2vaJdx64UPfJbzxX9Z++haMQSkDpbYFOMso1Qt05wbpF Z7bYaq8HgnNlA== Date: Tue, 03 Sep 2024 09:57:58 +0000 To: Alice Ryhl From: Benno Lossin Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] rust: sync: require `Send` and `Sync` for `Backend::State` Message-ID: In-Reply-To: References: <20240903091700.172734-1-benno.lossin@proton.me> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 2a6a3ca701125dc3fbec0550c3a493562316a39c 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 03.09.24 11:30, Alice Ryhl wrote: > On Tue, Sep 3, 2024 at 11:17=E2=80=AFAM Benno Lossin wrote: >> >> `Lock` implements `Send` and `Sync` when `T` is `Send` or `Sync` >> respectively. Since this does not depend on `B`, creating a `Lock` that >> is `Send` and `Sync`, but with a `!Sync` or `!Send` state is possible. >> This is a soundness issue, thus add the bounds to the respective impls. >> >> Signed-off-by: Benno Lossin >=20 > Currently, B::State is set directly to `bindings::spinlock_t` or > `bindings::mutex` and these types are pretty unlikely to be Send/Sync > on all kernel configurations. If you're going to make this change, you > will need to change these types. Oh yeah you are correct. I did try to compile it, but maybe I missed some config options, since it didn't complain? > Considering that B::State is already stored in Opaque meaning that we > don't run its destructor either, it's not really treated as a normal > field right now. Perhaps it would be better to change the safety > requirements of the `Backend` trait to impose restrictions on the > thread safety of B::State? Yes that sounds like a better idea. --- Cheers, Benno