linux-kernel - Re: [WIP 0/3] Memory model and atomic API in Rust

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZhQjT4xdS3h-GbtC@casper.infradead.org>
Date: Mon, 8 Apr 2024 18:03:11 +0100
From: Matthew Wilcox <willy@...radead.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Philipp Stanner <pstanner@...hat.com>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	Boqun Feng <boqun.feng@...il.com>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	llvm@...ts.linux.dev, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...sung.com>,
	Alice Ryhl <aliceryhl@...gle.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Andrea Parri <parri.andrea@...il.com>,
	Will Deacon <will@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Nicholas Piggin <npiggin@...il.com>,
	David Howells <dhowells@...hat.com>,
	Jade Alglave <j.alglave@....ac.uk>,
	Luc Maranget <luc.maranget@...ia.fr>,
	Akira Yokosawa <akiyks@...il.com>,
	Daniel Lustig <dlustig@...dia.com>,
	Joel Fernandes <joel@...lfernandes.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	kent.overstreet@...il.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, elver@...gle.com,
	Mark Rutland <mark.rutland@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-arm-kernel@...ts.infradead.org, linux-fsdevel@...r.kernel.org
Subject: Re: [WIP 0/3] Memory model and atomic API in Rust

On Mon, Apr 08, 2024 at 09:55:23AM -0700, Paul E. McKenney wrote:
> On Mon, Apr 08, 2024 at 05:02:37PM +0100, Matthew Wilcox wrote:
> > In my ideal world, the compiler would turn this into:
> > 
> > 	newfolio->flags |= folio->flags & MIGRATE_MASK;
> 
> Why not accumulate the changes in a mask, and then apply the mask the
> one time?  (In situations where __folio_set_foo() need not apply.)

Yes, absolutely, we can, should and probably eventually will do this
when it gets to the top of somebody's todo list.  But it irks me that
we can't tell the compiler this is a safe transformation for it to make.
There are a number of places where similar things happen.

$ git grep folio_test.*folio_test

will find you 82 of them (where they happen to be on the same line)

                if (folio_test_dirty(folio) || folio_test_locked(folio) ||
                                folio_test_writeback(folio))
                        break;

turns into:

    1f41:       48 8b 29                mov    (%rcx),%rbp
    1f44:       48 c1 ed 04             shr    $0x4,%rbp
    1f48:       83 e5 01                and    $0x1,%ebp
    1f4b:       0f 85 d5 00 00 00       jne    2026 <filemap_range_has_writeback+0x1a6>
    1f51:       48 8b 29                mov    (%rcx),%rbp
    1f54:       83 e5 01                and    $0x1,%ebp
    1f57:       0f 85 c9 00 00 00       jne    2026 <filemap_range_has_writeback+0x1a6>
    1f5d:       48 8b 29                mov    (%rcx),%rbp
    1f60:       48 d1 ed                shr    $1,%rbp
    1f63:       83 e5 01                and    $0x1,%ebp
    1f66:       0f 85 ba 00 00 00       jne    2026 <filemap_range_has_writeback+0x1a6>

rather than _one_ load from rcx and a test against a mask.

> If it turns out that we really do need a not-quite-volatile, what exactly
> does it do?  You clearly want it to be able to be optimized so as to merge
> similar accesses.  Is there a limit to the number of accesses that can
> be merged or to the region of code over which such merging is permitted?
> Either way, how is the compiler informed of these limits?

Right, like I said, it's not going to be easy to define exactly what we
want.