From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A6BFB1EDA3C for ; Mon, 19 May 2025 20:37:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747687052; cv=none; b=r3gMvM3CB1pRAXOt9knVFpKV4Ml+oCrXiSxfxHjsA/KWtIqkdTESBvDN69Y0rGjVDvsnoXg2gjoeg/3SDmz/dXEh29DyafNDe5cD4SYMZKjBe0RwuZU+Ckl28aV8QWeifSStTGoiNIrbl6hLsOCgDEHFHvkXRspsHnx+AyoEop4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747687052; c=relaxed/simple; bh=SC3p5hC8hMDNnCQGdXHPO8UFcYi9C6ed8jvNAt2Ai+8=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IcBn9ONm559PFj+NSzct1H85E2GGADJhv5iK7vvi/1s04nlgjk75h5W2Ks0rroI5EXvCMFPA5ZsGvi9qvtIqGEQmhSkz9x+ZUbo5KVj1I5nRJtFIsS72tf3ANtGx6jX6tm3JfU8W4YmoGEZgaK/+5ZDtTABBAiYwUwl7I6ZSzcE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=WD1EOKB8; arc=none smtp.client-ip=209.85.208.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WD1EOKB8" Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-601a67c6e61so14005a12.0 for ; Mon, 19 May 2025 13:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747687049; x=1748291849; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iwjd8j4QyED9qdYBTT0Bo1zt4l0EzpY7sgoCO0roN34=; b=WD1EOKB8s4rDAq2mwVZDLVhzZfbvcn6jjqKwOWtSz9mKpgG9eJO2epK83AdgbM3hCF 7+ec6fmypxjnG2UiK/bVtoOt1/GAat/FPbic5XW3ft8z5dIFoO/JgQyhUzXIocqu1lSw obrEpl+Iupb0GcoP2tJfIruDtWr/Xu+g1hKdcUMgT+H6oQSfG4nSJEnsET33LYoPEw4s y2Mp0/YUi/J8g/xAPt74yZY/MCG7nFk3aTFA28SVUSkuaDj5ovmUIZwPz17WPzhg5OkW KyCd9Uv5bkhNq5E7duV5CijT3OOw6WwvpXWVHykMDB3Dk9lQZDKNG+FcQkLyCsHOs3us Kglw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747687049; x=1748291849; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iwjd8j4QyED9qdYBTT0Bo1zt4l0EzpY7sgoCO0roN34=; b=g7qtE1jbqwmIjIyID+6kDpFkXgybNGAlk2V52qx2+B3MLaMTH0NfjUdxKDIwRmzgm4 DdpXQFo4BMwGT6/atGSM4QyfuewozXK9ewV+LGybg4SjXJWMzmAE6YwcMpsoDibw5/E1 tvouZDgEKayGAhGaPtwNemN5MiTVdPgi9/h2iertMmSV03Kon04ZIE4etOwun5A++VoU XExZCCrCXhDxYZ0b45qp8wL2s5MVO8nMNT2AlcPXudnILLyoUc1rD4BkIY2pKwkcpWOa OcsHXSlSS4J6pRxQsZSOvxdkV3WEnSVRzut6qBnsbS1QybV7jGuN/2HGlgQYZsX24ZsO p0Ug== X-Forwarded-Encrypted: i=1; AJvYcCXE96LReZpXjG80mHWKBN9KuTIjuTcALi9T/FH3bAQdH48OJRDhN+DOOTswV6pVANfztWoJr7IoZlBlX1qeMQ==@vger.kernel.org X-Gm-Message-State: AOJu0Ywwadl0u/IemRIkddIUZMNUmKaFSN+dOuNOwG0Rh+9oaQRd8wXw GIIE++ErIeH9s7eZ+pafDGPGw9GYMdU6L+OzKBH7Yt762TUCztmq33OOXp21+ZTPTteuULxucPl qVCOTXQLnAykEJJzK/eI93EhpCoktQOM2gPm5dgcK X-Gm-Gg: ASbGnctQgekhoAnUQwD/Bt70+a/usQpyzULpHOn9zcbdfbWa7FN29VFZHPhotymWeu7 M73M43tHXl6Ow3HaPgFRyyNW14U41JqnZpmnwJBEfPT5QmNHltemYN+LZ3MVBNHBEHyQm+O1Vbp nFbgO0e3cJrggWi8uhZsp4dwkXTHemThfSYlMHkFiyq2a4XIVvaHigUSOj8rM= X-Google-Smtp-Source: AGHT+IH/u+qfIXXPEN3rnOUSM7iuh6vPNGj/l4Qc8eijLUmuYTxdqiITZPnWGZ6jYGmXZIBgL5nCJB7y+EVSlPfjHBg= X-Received: by 2002:a50:9f08:0:b0:601:f23b:a377 with SMTP id 4fb4d7f45d1cf-601f23ba435mr105591a12.6.1747687048635; Mon, 19 May 2025 13:37:28 -0700 (PDT) Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250519161712.2609395-1-bqe@google.com> <20250519161712.2609395-4-bqe@google.com> In-Reply-To: From: Jann Horn Date: Mon, 19 May 2025 22:36:52 +0200 X-Gm-Features: AX0GCFvbm9GK3YytAYW5KkKwW8G7S0FDKQ4iXt9eAphqt0Pv4tDqgAplSmqLVuU Message-ID: Subject: Re: [PATCH v8 3/5] rust: add bitmap API. To: Burak Emir Cc: Yury Norov , Kees Cook , Rasmus Villemoes , Viresh Kumar , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , "Gustavo A . R . Silva" , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 19, 2025 at 10:08=E2=80=AFPM Burak Emir wrote: > On Mon, May 19, 2025 at 9:01=E2=80=AFPM Jann Horn wrot= e: > > On Mon, May 19, 2025 at 6:24=E2=80=AFPM Burak Emir wro= te: > > > + /// Set bit with index `index`, atomically. > > > + /// > > > + /// ATTENTION: The naming convention differs from C, where the c= orresponding > > > + /// function is called `set_bit`. > > > + /// > > > + /// # Safety > > > + /// > > > + /// This is a relaxed atomic operation (no implied memory barrie= rs, no > > > + /// ordering guarantees). The caller must ensure that this is sa= fe, as > > > + /// the compiler cannot prevent code with an exclusive reference= from > > > + /// calling atomic operations. > > > > How can atomic operations through an exclusive reference be unsafe? > > You can't have a data race between two atomic operations, and an > > exclusive reference should anyway prevent any concurrency, right? > > The atomic operations take a &self (shared reference). > > The patch is missing the implementation of Sync for now. With that, > one would get concurrent write access through shared references. > > The "unsafe" here should serve as reminder to argue why it is ok to > not have any ordering guarantees. > > The last sentence is supposed to say: when you have a &mut bitmap, you > can reborrow it as &bitmap, and then happily call this atomic op. > Even though it is unnecessary. But using an atomic op when you have a &mut reference is not a safety issue, right? You wrote a comment about behavior with exclusive references in the "# Safety" comment block. If that's not supposed to be a safety problem, this should probably not be in the "# Safety" section?