From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (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 78A972F3C37 for ; Wed, 18 Feb 2026 09:31:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771407077; cv=none; b=pcz/n1ipJfTDQzdPLbF2HRg6QKpRLEjIoXjyjKMv8CHF1vWTQuDYufhPakVCDu3VqXOFrWPHIMZwtOa3uilqo8VTqBMkvHi4FMvP0+PteT29j63Hltkp73KMJCsbNqnc0AbuQU5czw6n9WcQjqKKYRb3cWGaQ3ceerXn79eSIeQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771407077; c=relaxed/simple; bh=ynAGL37s7FWBMrSgqUjiQMxCYwtmS+dVwdIirYlrhRY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Q+JRQJN0od2b1+lqlNV70JtSAKPFCeq2xrVWTs7saxGnU2KKkwyUqZjkna4rpKfIX81aANrIrZ6Ora4RHmjj+pd8slBako8AskA7jwPC1T58awrlllZxZb/Mk9WZ+1K0EIrS5g36aU18lDvFB/FLSc/l2eKO0+SBm9WRLEonzM4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=E0KiGf2B; arc=none smtp.client-ip=209.85.221.74 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=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="E0KiGf2B" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-435db9425ebso4427202f8f.1 for ; Wed, 18 Feb 2026 01:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771407075; x=1772011875; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=rFgVqtfti6/svD+1ZiUO3++RgsvWnRMRX+ORPut57vY=; b=E0KiGf2BcVd844C+NUaC0txq/SfrprjiBTSF5ysBUBkWUSb0w15JRoOh2GVw4Xf/xl a2iZWR0glWICf+bFdgrte4eEY5V+qAXQcRgAXlAEtWmJ6h8zfm0PQvdLNHFbA7baoizt hJoGQM+Rtc4LQ49wkrZIqVbx+xRiybdPMEJJnSwfDFtI1B/hXIWDKkqr4dXit+EbNsKM dnR7Y59QKT75mhqPUQiemy90T2O78G7OIpL7hyap0AQF1rcyqTbopuYhRFjKNS8QITzE CqDTUl/b6hbEAKMwuUptnHeGJB2fzs39YKYp3r/VJVP3Hy1rxJ1se8A+9BVxMNReF4Gv qSzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771407075; x=1772011875; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rFgVqtfti6/svD+1ZiUO3++RgsvWnRMRX+ORPut57vY=; b=dkPvgMJ504RefxR4kvdrUWGRtQdUN1lqfr0ilfgH5xDbXFpuDn1bHpgFHhf/m8lKtg M+JIal/OZgyLcmCzpNt1I9tS521tH3AxCgmI/vQmeMtUt2g/vS/XaPvXbi48SMdSp9dw l7qAOB+hQVy1mD+3csnDQe+GyCG5IuvfvmFVLzsmFOkRuCjG5tqg59geEzmnKJsmvqdx sZ70Y3D7+XdamJkvuTW/hQmoo5EGRwxQlDL+coBsey+BB1jSKxJL9sNAEmAI4HZx6ZuV qTHoGnkKZXEiK+XaUeCp5J+lco65tjWLa1klv6luiWvRpZb8GsBK6oU6VbeSvV9NOqsw /gjQ== X-Forwarded-Encrypted: i=1; AJvYcCWQTvoSTp02zfE9V+8ElPbygoPMcjykspa7eO9WsSbOOlCz45nGPOQ3dWjPrT4XYbU1y5Nuk8jmU6P+w00=@vger.kernel.org X-Gm-Message-State: AOJu0YxjnWx/IkLEhdTvFRLa/k6Z/M58a/1imaL62+qCDOZI6MxaQDmA /BEL+03Tr8l4xNWlbUa4mRlPYjpGVmYaZPTkEAMIRao2x4m+ibHfQSrtq1vNN7Ggd3tUZF+e1Nh maSR+kVY7jtp+DVXggw== X-Received: from wrs2.prod.google.com ([2002:a05:6000:642:b0:437:6bbf:a150]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:26c2:b0:435:e57a:9082 with SMTP id ffacd0b85a97d-43958e504afmr2125915f8f.46.1771407074382; Wed, 18 Feb 2026 01:31:14 -0800 (PST) Date: Wed, 18 Feb 2026 09:31:13 +0000 In-Reply-To: <20260218083754.GB2995752@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260217102557.GX1395266@noisy.programming.kicks-ass.net> <20260217110911.GY1395266@noisy.programming.kicks-ass.net> <20260217120920.GZ1395266@noisy.programming.kicks-ass.net> <20260217154800.GY2995752@noisy.programming.kicks-ass.net> <20260218083754.GB2995752@noisy.programming.kicks-ass.net> Message-ID: Subject: Re: [PATCH v2] rust: page: add byte-wise atomic memory copy methods From: Alice Ryhl To: Peter Zijlstra Cc: Gary Guo , Boqun Feng , Greg KH , Andreas Hindborg , Lorenzo Stoakes , "Liam R. Howlett" , Miguel Ojeda , Boqun Feng , "=?utf-8?B?QmrDtnJu?= 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 Content-Type: text/plain; charset="utf-8" On Wed, Feb 18, 2026 at 09:37:54AM +0100, Peter Zijlstra wrote: > On Tue, Feb 17, 2026 at 11:39:18PM +0000, Gary Guo wrote: > > > >> Are we really good? Consider this code: > > >> > > >> bool is_valid(struct foo *val) > > >> { > > >> // for the sake of example > > >> return val->my_field != 0; > > >> } > > >> > > >> struct foo val; > > >> > > >> void *ptr = kmap_local_page(p1); > > >> memcpy(ptr, val, sizeof(struct foo)); > > >> kunmap_local(p); > > >> barrier(); > > >> if (is_valid(&val)) { > > >> // use val > > >> } > > >> > > >> optimize it into this first: > > >> > > >> struct foo val; > > >> int my_field_copy; > > >> > > >> void *ptr = kmap_local_page(p1); > > >> memcpy(ptr, val, sizeof(struct foo)); > > >> my_field_copy = val->my_field; > > >> kunmap_local(p); > > >> barrier(); > > >> if (my_field_copy != 0) { > > >> // use val > > >> } > > >> > > >> then optimize it into: > > >> > > >> struct foo val; > > >> int my_field_copy; > > >> > > >> void *ptr = kmap_local_page(p1); > > >> memcpy(ptr, val, sizeof(struct foo)); > > >> my_field_copy = ((struct foo *) ptr)->my_field; > > >> kunmap_local(p); > > >> barrier(); > > >> if (my_field_copy != 0) { > > >> // use val > > >> } > > > > > > I don;t think this is allowed. You're lifting the load over the > > > barrier(), that is invalid. > > > > This is allowed. Compilers perform escape analysis and find out that > > "val" does not escape the function and therefore nothing can change "val". > > > > A simple example to demonstrate this effect is that > > > > int x = 0; > > x = 1; > > barrier(); > > do_something(x); > > > > is happily optimized into > > > > barrier(); > > do_something(1); > > > > by both GCC and Clang. The fact that the local variable here is a struct and > > memcpy is used to assign the value here does not make a fundamental difference. > > > > barrier() does nothing to local variables if pointers to them do not escape the > > local function. > > So how do we stop the compiler from doing this? Because I'm thinking > there's quite a bit of code that would be broken if this were done. > > Must we really go write things like: > > struct foo val, *ptr; > > ptr = kmap_local_page(page); > memcpy(ptr, val, sizeof(val)); > kunmap_local(ptr); > > ptr = RELOC_HIDE(&val, 0); > > if (ptr->field) { > ... > } > > That seems 'unfortunate'. It basically means we must never use local > stack for copies or somesuch. No I don't think RELOC_HIDE is what you want to be using here. The way to stop the compiler from doing this is to ensure that, in LLVM's eyes, the memcpy is either a volatile memcpy, an atomic memcpy, or an opaque function call. According to Gary's reply to my email on V3, it sounds like an explicit call to memcpy like this apparently falls into opaque function call, so it should be okay. Anyway, that's why using Rust's copy_nonoverlapping() isn't okay here. It emits a non-volatile non-atomic LLVM memcpy intrinsic, which permits these optimizations that we don't want in this case. By calling bindings::memcpy(), it falls into the opaque function call category instead, which fixes the problem. Alice