From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DD7DC5475B for ; Tue, 12 Mar 2024 02:17:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 653266B0166; Mon, 11 Mar 2024 22:17:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6031F6B0167; Mon, 11 Mar 2024 22:17:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47D246B0173; Mon, 11 Mar 2024 22:17:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 32D856B0166 for ; Mon, 11 Mar 2024 22:17:11 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D3102C0E0A for ; Tue, 12 Mar 2024 02:17:10 +0000 (UTC) X-FDA: 81886774620.19.E93D3F2 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf20.hostedemail.com (Postfix) with ESMTP id 5037A1C0009 for ; Tue, 12 Mar 2024 02:17:07 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=huBkhiiT; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of luto@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=luto@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710209829; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=huqsfs/gqHP7WNpddQZKi41pXn9innZVvk5Ci35Lw5w=; b=RqrQsMZPTNpXve4q1p1+qOucR6uKV5iiI1eWPU5P8xFGWLgxa2LmQdzYQwjKtJF70b33QP cKSrVLOdKQBeCmB2+ni5TIeFl8gXQb5hBpd3IGJHMzUkfev2FcPy2dBJ+5QN7P52qPXZHX wmefVPkqH9pR3jQAoybW3p6nY6lFjWM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=huBkhiiT; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of luto@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=luto@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710209829; a=rsa-sha256; cv=none; b=IUlgUhaA/LB4iLknKm28XzBLQRQZRFEfLvCTBkYOIKMub2sKcxUHLEAYm0uLuXlP8XjV0g qmEuLXvYAToSunRQCrc9eF+B9xZY1N9in+rI60kJz02G20UXdGsO/47ZTUrwFPHBlG2B4H DCS4ikEonGjef34GTv6qBfp2F5JOI5s= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 8D4E0CE10BD; Tue, 12 Mar 2024 02:17:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4444C43394; Tue, 12 Mar 2024 02:17:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1710209822; bh=nSh75CPRfKS/KL7VFhltqLjVu/hr3RGaBOR3B0hYW/s=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=huBkhiiTA5S9HmQdAz+YrCxpH/IQehNtOh7w2PTzltt0go99V/DabiOpzcoAG64Mu GApvujeEwz3sVn/HLhYcBhDNRwqnikgR3odA3GYaxUe1TWbwmo5buu/0tJmDEwsI3Q vGtC8EpLF5KvdcTGC50Jm117aCxYyrLbZGVcUbJK6dJgvjk+NP+CpVfPJsliuUDgGh DmZY3sToD57tJaVbEynw1X2MfkaiCWrBJVNDOmZTugSwoc5hr0I8ZpjCA0gWwHlO/b nCIrMDhdwIctg+esf/ZG9b6ADCgmRmVyYPM0nsJQe8THgOmx7nwEOWM2frhw36LVrV Mjf3tOp1YVrog== Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfauth.nyi.internal (Postfix) with ESMTP id C05B5120006A; Mon, 11 Mar 2024 22:17:00 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute3.internal (MEProxy); Mon, 11 Mar 2024 22:17:00 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjedvgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepudevffdvgedvfefhgeejjeelgfdtffeukedugfekuddvtedvudei leeugfejgefgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 328E931A0065; Mon, 11 Mar 2024 22:16:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b MIME-Version: 1.0 Message-Id: <0645946c-f4f5-43b1-a9a0-03ed139036b3@app.fastmail.com> In-Reply-To: References: <20240311164638.2015063-1-pasha.tatashin@soleen.com> <20240311164638.2015063-12-pasha.tatashin@soleen.com> <3e180c07-53db-4acb-a75c-1a33447d81af@app.fastmail.com> <08EFDEDB-7BBB-4D9C-B7E5-D7370EC609BE@gmail.com> Date: Mon, 11 Mar 2024 19:16:38 -0700 From: "Andy Lutomirski" To: "H. Peter Anvin" , "Dave Hansen" , "Nadav Amit" Cc: "Pasha Tatashin" , "Linux Kernel Mailing List" , linux-mm , "Andrew Morton" , "the arch/x86 maintainers" , "Borislav Petkov" , "Christian Brauner" , bristot@redhat.com, "Ben Segall" , "Dave Hansen" , dianders@chromium.org, dietmar.eggemann@arm.com, eric.devolder@oracle.com, hca@linux.ibm.com, "hch@infradead.org" , "Jacob Pan" , "Jason Gunthorpe" , jpoimboe@kernel.org, "Joerg Roedel" , juri.lelli@redhat.com, "Kent Overstreet" , kinseyho@google.com, "Kirill A. Shutemov" , lstoakes@gmail.com, mgorman@suse.de, mic@digikod.net, michael.christie@oracle.com, "Ingo Molnar" , mjguzik@gmail.com, "Michael S. Tsirkin" , "Nicholas Piggin" , "Peter Zijlstra (Intel)" , "Petr Mladek" , "Rick P Edgecombe" , "Steven Rostedt" , "Suren Baghdasaryan" , "Thomas Gleixner" , "Uladzislau Rezki" , vincent.guittot@linaro.org, vschneid@redhat.com Subject: Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5037A1C0009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: m7gasb6uz1tj1ebpms357y81hd9q777s X-HE-Tag: 1710209827-69400 X-HE-Meta: U2FsdGVkX1/6GUEc8jLibTYnuMAxU46gef8qcGGBozupDEtve8ZmnOM7OwzdhkfW9rw/0UYt7e0sY+cE4BRJIrCwgIANVEkCl0YhFQE3v0OHaBRyom0yWZSbSMz64jlCGVSItQa3taM6wB1AQmL6tXOMD4gtxbcknk5UQrov26Pkb4PPw5iuJPU210r+ctq78c9KFTBn4yV78O7JQPswqh1dIPjSUIaZ/ZcTH3h7KM+Ub3X9WCQOgl09K6EktFUZBTzWvwHVsFgbcRwGDSk0UUVRYt4Nv/EQJvGcjJiIq4U4TlRZQn46FvA+KbhVSC0+so9Vw9FqUjr7QsvMH+bW5RtinItSJxywama30IcM4r5sxogd2QVxbbK0Xkbko1D94JntNCRNszyG/Ujh3NFVveyjqupag2tnixuH/PbI8hKjR/p8vv3nUROlXuwJzf1Fn6SABeo8jkFOs6LpjbVCgdFJkoATg8TSA+fXmi3z/s+gLr6zAFmGZWWsIiUQw8Cymev3R8sjVqSSU93nmvzlcebQBP+z4smwtz8hwapksVRfLKUYT0OJDy99eGslov6zlo8KZpvWzQzYM1T963r8HHUyNE1o1tJFcLcBcpRMmLSNcvk7gyItTZgAqz/pNL6D84UzsrD4vVmVWGc7/sYikee0nXwyo06rxgWcsBxphNqzh+JhA4zhgLwuAprPMVfhFNg8xuf5bBuCIyznBeMCXiTFqX7VRR0UaamdPIba60W8zeE0V8NJbRAhUUB5xbS5gmXj4zs1s7nooKIX3kLnJ9zif24oWM9bQqknoy1kyNQaUrQWTc3JUExhHT7/W5hKLtuDQ6A7DlyhGrdz1Trlo0NIiPcMKzihm3Do+i2OpxEGWzWKgYZBtHtEZEB6E9tTL4+JXS5WVpubNCrQuqxKwb0U4Y9F/RRYdS7uxXIoQ2roz6JlxbN0aIIBmdJsA+NKxYLhuNL9wcgP6E/Hgwx N9gn5D/6 +Ygl6DgmeOuMpmLoFltJn9aNfog== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Mar 11, 2024, at 6:25 PM, H. Peter Anvin wrote: > On March 11, 2024 5:53:33 PM PDT, Dave Hansen = wrote: >>On 3/11/24 16:56, Nadav Amit wrote: >>> So you can look on the dirty-bit, which is not being set >>> speculatively and save yourself one problem. >>Define "set speculatively". :) >> >>> If software on one logical processor writes to a page while software >>> on another logical processor concurrently clears the R/W flag in the >>> paging-structure entry that maps the page, execution on some >>> processors may result in the entry=E2=80=99s dirty flag being set (d= ue to the >>> write on the first logical processor) and the entry=E2=80=99s R/W fl= ag being >>> clear (due to the update to the entry on the second logical >>> processor). >> >>In other words, you'll see both a fault *AND* the dirty bit. The write >>never retired and the dirty bit is set. >> >>Does that count as being set speculatively? >> >>That's just the behavior that the SDM explicitly admits to. > > Indeed; both the A and D bits are by design permissive; that is, the=20 > hardware can set them at any time. > > The only guarantees are: > > 1. The hardware will not set the A bit on a not present late, nor the = D=20 > bit on a read only page. Wait a sec. What about setting the D bit on a not-present page? I always assumed that the actual intended purpose of the D bit was for t= hings like file mapping. Imagine an alternate universe in which Linux u= sed hardware dirty tracking instead of relying on do_wp_page, etc. mmap(..., MAP_SHARED): PTE is created, read-write, clean user program may or may not write to the page. Now either munmap is called or the kernel needs to reclaim memory. So t= he kernel checks if the page is dirty and, if so, writes it back, and th= en unmaps it. Now some silly people invented SMP, so this needs an atomic operation: = xchg the PTE to all-zeros, see if the dirty bit is set, and, if itt's se= t, write back the page. Otherwise discard it. Does this really not work on Intel CPU?