From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) (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 6430217993 for ; Tue, 17 Feb 2026 20:32:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771360337; cv=none; b=chVhYgw2Ct+kmRGP/mQnaCeVxDXcxQW+1fHzLyMM1kzPNDiq/QhRtmTPw03ccjTBtbS3zpWpN1Ta3lARZUoiQF+CDHCktgsi4BebJweCLLkQK9inrAOquBa7tl0UXW/YaZ/lfCqy7dmsioGQiSHjYetITv7Dh8+p4q2e3oNjD6M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771360337; c=relaxed/simple; bh=pe+I2F9ucO2XVDzx6psZJFYMTeglmSqaEEIYkf4h7vY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UrhdJy+mUQhGOp0+X413OqSIGCfSA+yOGS4b6JxdzKaWaBwPHLvxB32AvbrYqjt1IQJVVTk5HVjgJQ971xS5y4um8Yhl5k+ae1ZesdXlhMAdwQxmMjj+NhCkiDZ8vhphF/umdr0njGcsvsKOLCijHsme2+v406JQkQ8s4qIl7l8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=Nr+f8CfH; arc=none smtp.client-ip=209.85.167.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="Nr+f8CfH" Received: by mail-oi1-f194.google.com with SMTP id 5614622812f47-45f015a3259so1396261b6e.2 for ; Tue, 17 Feb 2026 12:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1771360334; x=1771965134; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=GTb6I/Y6Yeg69YIr2bHQGlJl+Mkv02foH8/PpQiTI8w=; b=Nr+f8CfHc7wpen03a1iuQ0xaKiHN4ozXHOCHi7X9aiP+eito5tnoX6omFWexF0v5Hn s8Mv77lXh7KZoioNloih0XMe7Eq+qgWymvJLTO/ekuLbxLO3ITnNmUR7qd49j4QWwT9K BOFhjPv+JFfW+C3mi/ivYooG3HDCU4xWt8fMPSCRZAMZXFk3trtu0AbT437UOXG7l/LO 0sMh0tRk0n/W/Pf0WfmCfmkj/6S3cZJs+JHMcprGJ0ELCYnSNCa7JC2eYRI8Wl3w1vZ4 e8+ZTIsKFL9tVrc5EdvoggeIfp+aQQ+85yPYD6JxuWB5Yk8gzPAga/zYem4xw0HuzR92 PGvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771360334; x=1771965134; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GTb6I/Y6Yeg69YIr2bHQGlJl+Mkv02foH8/PpQiTI8w=; b=jYy0OHhjJJ2DdT+cXU4uLhF4Vf7vlW+73q97/41nq4RbBWzAZC/YJL7NcfSDmKCTTb wHqXMWVjZdrApeNeVj/278yRw095Eq6vWEMHDci38ltCxuLz5fneb6B1TotKa9rdWOIl dLY63+QzpfleLoQr7TUfhialSgbFT3U/zPB3P8zPURGJwsC3/jfEiC+3s/obtqkq9njA reFp2jVq5Ud5Bkn/l4HHrflfX5hthYHEgRFZCJSe5P3hs7Oxvo5T5ib8uiVA/WTA81Sn LS9pEjDI8H9MS5jQmawHI5LDFsWIhhJHHKndo8m60UywuE+YB1gtuxfJ9Qf5tbqXUY/h dHVg== X-Forwarded-Encrypted: i=1; AJvYcCUvadwQZmyJEyMwAN2R1L13wEUMRESPwhgun4zfROz3wOUEGfo7u/0vf9bP3myXJjwsjn6Dhh0HHMmE4LE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx5HEHbhoc4zja0tLdUAlmDcnvv2C5hD5KXAtZAdyWwiBB5DxoS agD7w8r+b0wl9kVQ9FAmC8VYT1gHsCFXFlpnqyiYX0ETirbVovXyzKjZ8RseumINhlY= X-Gm-Gg: AZuq6aJDbvdQYHiqj8lQ51ge5N4V5tAtaYBhfdLdB5AOnah1nujh60+76Nngukn+XV9 zBzzRXSilfJMTIryAla0gdlsVPaTK5m+LrulO8VP6JrciraDDK8VIkxYjxZcpNkqiSM6MtVjqR+ fmHQhFYRDeb6kxuYatAeEtq4jqpMSB9Hjz9jeLZW+dyOhj0zVjPAx0t720zrhPiamuFOnMfWz4f u1P7PoTrJlcHtf9dRtqQFnSTJmKNGTNBFC0KXVjtsh/wl6G2iBE5r038J/8SS/vHrll1scfIQlM 0Cy09OXEFK/bm0NCKKjOhwmf1ljj9OfO6EyyVR/38jEnZakjFUEvY1npqccKQu57HTBh/pW+vAA 6NXymKDvq9DRjbl5cNpnjFUJrnQqRR1fECxu8H3GRSADNNyqQYvH8G81EM/hoV9wa4BuzxW8+uf ai64Z6em/c4zcqxoeJi9i7gE+c3B+sX7CelsgQ1aEW5YO+0HnySYyJQceZmc+zCOE7J6hwoq/Ja qem1LzB X-Received: by 2002:a05:6808:1793:b0:45c:96bb:1202 with SMTP id 5614622812f47-463b40b7374mr6464117b6e.58.1771360334150; Tue, 17 Feb 2026 12:32:14 -0800 (PST) Received: from [192.168.1.102] ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4636b065d5csm13412550b6e.13.2026.02.17.12.32.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Feb 2026 12:32:13 -0800 (PST) Message-ID: Date: Tue, 17 Feb 2026 13:32:11 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] rust: page: add byte-wise atomic memory copy methods To: Andreas Hindborg , Peter Zijlstra Cc: Alice Ryhl , Boqun Feng , Greg KH , Lorenzo Stoakes , "Liam R. Howlett" , Miguel Ojeda , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Trevor Gross , Danilo Krummrich , Will Deacon , Mark Rutland , linux-mm@kvack.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260217091348.GT1395266@noisy.programming.kicks-ass.net> <20260217094515.GV1395266@noisy.programming.kicks-ass.net> <20260217102557.GX1395266@noisy.programming.kicks-ass.net> <20260217110911.GY1395266@noisy.programming.kicks-ass.net> <87ecmjcw2v.fsf@kernel.org> <20260217160451.GA2995752@noisy.programming.kicks-ass.net> <878qcrcisb.fsf@kernel.org> Content-Language: en-US From: Jens Axboe In-Reply-To: <878qcrcisb.fsf@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/17/26 11:43 AM, Andreas Hindborg wrote: > "Peter Zijlstra" writes: > >> On Tue, Feb 17, 2026 at 02:56:40PM +0100, Andreas Hindborg wrote: >> >>> I'm processing disk IO in the Rust null block driver. The pages backing >>> the IO requests may be simultaneously mapped to user space, so there is >>> no way to guarantee that there is no concurrent memory operation to/from >>> the memory area. User space programs can do whatever. >>> >>> I don't have any control flow depending on the data I copy. I just store >>> it somewhere and return it if a read IO for the same sector arrive. >> >> Right, so IIRC the old DIO code used to have this problem. We'd end up >> writing whatever random state to disk if you did DIO of an mmap(). >> >> And if IIRC the current state of things is better in that we ensure the >> mapping becomes RO and we have writes fault and wait until the writeback >> is complete, ensuring things are somewhat more consistent. >> >> But you'd better ask Jens or someone that has looked at the various IO >> paths in the past 10 years or so :-) > > Oh, this is a really important detail that I did not find while trying > to follow the code path from user space. > > Cc: Jens Axboe > > @Jens is this so, are pages from user space that are part of a write > request mapped RO during the IO operation? No, there's no such thing. It'd make O_DIRECT writes much slower. Also see the recent stable pages merge that went into upstream this merge window: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4adc13ed7c281c16152a700e47b65d17de07321a which only really deals with the checksumming problem, but regardless it's in the same area of "userspace modifies page(s) while IO is in-flight". If you don't do checksums, and you rely on bufferA ending up on stable storage while having it in-flight and also modifying bufferA simultaneously from your application, you get to keep both broken pieces -- Jens Axboe