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 BB534C54E58 for ; Tue, 12 Mar 2024 02:21:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 434038D0011; Mon, 11 Mar 2024 22:21:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E4048D000D; Mon, 11 Mar 2024 22:21:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 284D28D0011; Mon, 11 Mar 2024 22:21:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 149268D000D for ; Mon, 11 Mar 2024 22:21:42 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D7477A0C18 for ; Tue, 12 Mar 2024 02:21:41 +0000 (UTC) X-FDA: 81886786002.24.933F1CC Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf25.hostedemail.com (Postfix) with ESMTP id A3369A0006 for ; Tue, 12 Mar 2024 02:21:39 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none ("invalid DKIM record") header.d=zytor.com header.s=2024021201 header.b=MjinCQYJ; dmarc=pass (policy=none) header.from=zytor.com; spf=pass (imf25.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710210100; 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=25o8RezCz/80azo9KF9KOroEFSSWkg8pHxdIqDA7QWg=; b=C1CJpyGlfuHiDiHSnH/cnjdUuLI/L75ZsrG4Svv661WD4V/iZDnrbLokucPHC/F5JYlQGG 5dasy0etMG6/+C5eDPnenxSXF1941Yk0z3Bw+kmbO9hpVpRVQBhMvHJN/PDy3zvVUuBo70 Z6teJBiZf0CJ4UAEZ78i0Ti7yet2JDU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none ("invalid DKIM record") header.d=zytor.com header.s=2024021201 header.b=MjinCQYJ; dmarc=pass (policy=none) header.from=zytor.com; spf=pass (imf25.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710210100; a=rsa-sha256; cv=none; b=MBO7E8ixpZQxAaJzvsmbObdxNJ3aIUAvkyNDuFswY2MA5uAvjWavagbqKXdsc2mdHfIxiL 92a6w/ViebpF0AZvKVPaOzrvO5FlvuIB1ehh3cFQdptC4Wexm23cvrOaH/v9PDWwRuPg3Q mz2vXHu0kY8tL3sB06XggTaD1X33wzI= Received: from [127.0.0.1] ([76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 42C2KvjU1107798 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 11 Mar 2024 19:20:58 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 42C2KvjU1107798 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024021201; t=1710210062; bh=25o8RezCz/80azo9KF9KOroEFSSWkg8pHxdIqDA7QWg=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=MjinCQYJOwkr/GeS6myIyc5fiKaO2Jc6L1Aas4l12yyMkbi9pF+p3BmHPieTdqOkZ cGhZ0/0Ct+NBK+Ta954sRgeRzGlC0WPeICXOLDfBHReqMVl357P7jT+TYr+2GH/R1e JPaS5v8Ps3uU8nBBmWFIRiu7qb+1Ylkf2l46STFhRAEZrQ5AWPbrD5dw7d7pvFuoK/ nWbYe1zFwItOZ5VeNTWoyhGMSF7vxUaVH4IsAbcTMVwp+mzVJSDoJTPwkYuveTeQNR +uGe4p9G2m8nf/rVw4evqkBOahg2pka7mZfLvHMYdQcK3d46AP1XjtyttzxZqnxtsg 3s8ZDreVs1uww== Date: Mon, 11 Mar 2024 19:20:54 -0700 From: "H. Peter Anvin" To: Andy Lutomirski , 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 User-Agent: K-9 Mail for Android In-Reply-To: <0645946c-f4f5-43b1-a9a0-03ed139036b3@app.fastmail.com> 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> <0645946c-f4f5-43b1-a9a0-03ed139036b3@app.fastmail.com> Message-ID: <83E86178-FBC7-49C5-B624-8B8106D10CBC@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A3369A0006 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: r9bcx4p6mk8a5d6hzi1wdexim33czs54 X-HE-Tag: 1710210099-812498 X-HE-Meta: U2FsdGVkX1/uyQvztvPKkJET1I7fjlcwOOtIZJ76lcwdHgwtnMp3JrXrInBnZVSAO9bW9Si5YVI0z+PaUC6HMXL8mplpRUbT3NGuTu6NeI1xd6dC/Bpiusc9XoXAAdtDzJfKZuXZIJCQ62zqOXwfaw25j4IwBa1foJ8TjMUswVQ/MWXTztfCQndjjED+DUBzmi3CciLPNlQNyu9shstb6Xm7jEj+t7jn9FLxv0Jq9wosljEHemIprZBZjHJHFIOFB+O5j6WuRMigOAx40WMbJoUlZlFOaFPhBRSMFQeWgXyuauAHx2tl6VUSi5uYQ3qKlgvgZmjYpHEwRuKCyy04b6PDMbIzseJlae3yror844Vyb3l/JTS3DG+IALr6sm1A3HYSFLfqWgzdT3fHT2pVzXd7y4unbMbsMwiRWa7RcxPWakoOw4daMoT3N0uLXngTsTro/rBz2MjVmxCeJDReT1/i4ibAPqoRaNO48Dn64zIlIRvsruF+c0yDo9m+AEZQaFWPL6uAGNBtstfe5EqfDnujgjvPZAjN7I/sEl2YtCc67dPxizM1KYENlQjhGY7z9CPo06rGJ9EGJd2mhkoVOt0wB/SSRPuhRSitBDQD08QYfwK4PaS+70OkWBT0UzLF4lBPWBi3AmIKZAxOUR4qEzEFsv15l5ZUOfDfhugG6h1/Zwi86aN3ZIQOHWX5DE42RI/nBJpeYvp/D4KFN1hshTCrZc2rJ+vbOQJ6NzE3dD94havawDeCWFkDWT6zPq2RQ9C92a4pyoTVVd8/7igkSGpfPu3zY08Xi3xSJYt/Uqv5p1EcjllrTRnONjNaI+AcVSmS2H+8TABVXrHlAoPQ8JB21NfEol0DLYakAPGRpRbVl/Ch4xaGXKnbLASsVTfQkB6SkvNDEDQL5M6psuN+pdCBsQMsaVzcaH+krl4A+0p7uExjjOa5DDe8+KH+oS3t3TkvJCZ8WRrV9GXDaZo Y8kXNIoe 0uhrwxOoARpjaE89taS/07LHx/ydWHmqgQfytK6oXhebrVF9bLUZyiYZDECeikVLz5kJ7GAOYW9zniNH0bCi+ol0X/7xTWOt5Ijt8Be6pm2CG0iU7rqb2vES5TqRrLiMKxCn39mTm4y6+d9rS0BRFLlIUCqp453EDu3lscpW6OxNraDb+2oWLp8zgMnE9vt2P+vYu2iz9gz6tiZy69qfyCs63LQdkZkj3Bj0K3eR6hIbuyWB5LfiPrRx+hFXvJBforL31ZxxE8LUnzq84toXwJKQptFjH47RlTUbcUpe4kMLVSCJk6qO1Ap9sGK5Kuf4pKUuUYqaEFgTacSYPFvTc/eEfWwc9vQHyIgjCKH0cEo/i4uan/Y3eyDS9Z+HudBaQAP85 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 March 11, 2024 7:16:38 PM PDT, Andy Lutomirski wrote= : >On Mon, Mar 11, 2024, at 6:25 PM, H=2E 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=2E >>>Define "set speculatively"=2E :) >>> >>>> 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 (du= e to the >>>> write on the first logical processor) and the entry=E2=80=99s R/W fla= g being >>>> clear (due to the update to the entry on the second logical >>>> processor)=2E >>> >>>In other words, you'll see both a fault *AND* the dirty bit=2E The wri= te >>>never retired and the dirty bit is set=2E >>> >>>Does that count as being set speculatively? >>> >>>That's just the behavior that the SDM explicitly admits to=2E >> >> Indeed; both the A and D bits are by design permissive; that is, the=20 >> hardware can set them at any time=2E >> >> The only guarantees are: >> >> 1=2E The hardware will not set the A bit on a not present late, nor the= D=20 >> bit on a read only page=2E > >Wait a sec=2E 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 th= ings like file mapping=2E Imagine an alternate universe in which Linux use= d hardware dirty tracking instead of relying on do_wp_page, etc=2E > >mmap(=2E=2E=2E, MAP_SHARED): PTE is created, read-write, clean > >user program may or may not write to the page=2E > >Now either munmap is called or the kernel needs to reclaim memory=2E So = the kernel checks if the page is dirty and, if so, writes it back, and then= unmaps it=2E > >Now some silly people invented SMP, so this needs an atomic operation: x= chg the PTE to all-zeros, see if the dirty bit is set, and, if itt's set, w= rite back the page=2E Otherwise discard it=2E > >Does this really not work on Intel CPU? > Sorry, I should have been more clear=2E Hardware will not set a bit that would correspond to a prohibited access= =2E