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 03C67C54791 for ; Wed, 13 Mar 2024 16:12:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A622940025; Wed, 13 Mar 2024 12:12:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5553B940010; Wed, 13 Mar 2024 12:12:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41CCB940025; Wed, 13 Mar 2024 12:12:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2ECBC940010 for ; Wed, 13 Mar 2024 12:12:29 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BCC981A076D for ; Wed, 13 Mar 2024 16:12:28 +0000 (UTC) X-FDA: 81892508376.15.3917D13 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf15.hostedemail.com (Postfix) with ESMTP id B7186A0007 for ; Wed, 13 Mar 2024 16:12:26 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=uxeIdiLT; dkim=pass header.d=linutronix.de header.s=2020e header.b=yjeooXvy; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf15.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710346347; 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=ASMOFY2sHU4OyVeGqn7miLbsJxTIjNV+5Rjhy3Yhwt8=; b=uob4Wty/JP1a7g8QNbt4KiZVARZaL9gKqQjhHTn0ePyrvCmaUrLygBVbIkWAR1RW4tm5F/ OXsVOcV81dhCaBb8j/fHr++yN0W06LuBQgCzoFoLP4+NRoJFM83a0mmrcJBf7o4FMvBSPY +sqEkCKzIuMQI/kpLktEMqnIPOaunxg= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=uxeIdiLT; dkim=pass header.d=linutronix.de header.s=2020e header.b=yjeooXvy; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf15.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710346347; a=rsa-sha256; cv=none; b=4dbFOYUDSjQYZ78+q+cJoCKdwNNzZV11keBKv2V9Iwj4bC2V4YhvNzsQ2Gw05HSrwQPfg9 OksCXLdPmNsxVVcVt9gTFWxJlkzH9prarkq0RSWuqQz26LnUMYIetTMcOyCX09yHzwfBc6 sYUB7SYrJvGZHy9JA+gQXabjGaTtRNo= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1710346343; h=from:from: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; bh=ASMOFY2sHU4OyVeGqn7miLbsJxTIjNV+5Rjhy3Yhwt8=; b=uxeIdiLTBehtjVMz8KjE1Nc2jouZX5CS5uE5zfYl0LBe1P2LmwXbd5CiYggMdxt9esUxhH jq5Ct5lERrSu7Gk7E+1ezzIHfvCptt8/i5JiDNokOpTgVQtEGvJ8ySbUIQDWeflywEk1Z9 BrVR6oGlEq8vheF+fer4luM0E+HXgiGn7g5AXCeTip6/hakrSotVG59VPL5mkBiJ5BHaTI XAyMF7yJX275e1tl9pcqbPFv+wNua/EbFmG2vecK00tNIgnr3ou8EYwBOq0j7RfFs/j30e UcVmqaBO1eMFvgJxj3NqUteStfu4hHQZTNRenxxdjFt6n4Gt/Ooq2JnXysW4BA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1710346343; h=from:from: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; bh=ASMOFY2sHU4OyVeGqn7miLbsJxTIjNV+5Rjhy3Yhwt8=; b=yjeooXvyK1MtxUh1k6wG7KADFqd04eTFHuGgg08pp6BfDI4+3bz+UO7KKP8kHyHCSXO3dv /A5skhfMOJTzGsCA== To: Pasha Tatashin Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, x86@kernel.org, bp@alien8.de, brauner@kernel.org, bristot@redhat.com, bsegall@google.com, dave.hansen@linux.intel.com, dianders@chromium.org, dietmar.eggemann@arm.com, eric.devolder@oracle.com, hca@linux.ibm.com, hch@infradead.org, hpa@zytor.com, jacob.jun.pan@linux.intel.com, jgg@ziepe.ca, jpoimboe@kernel.org, jroedel@suse.de, juri.lelli@redhat.com, kent.overstreet@linux.dev, kinseyho@google.com, kirill.shutemov@linux.intel.com, lstoakes@gmail.com, luto@kernel.org, mgorman@suse.de, mic@digikod.net, michael.christie@oracle.com, mingo@redhat.com, mjguzik@gmail.com, mst@redhat.com, npiggin@gmail.com, peterz@infradead.org, pmladek@suse.com, rick.p.edgecombe@intel.com, rostedt@goodmis.org, surenb@google.com, urezki@gmail.com, vincent.guittot@linaro.org, vschneid@redhat.com Subject: Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks In-Reply-To: References: <20240311164638.2015063-1-pasha.tatashin@soleen.com> <20240311164638.2015063-12-pasha.tatashin@soleen.com> <87v85qo2fj.ffs@tglx> Date: Wed, 13 Mar 2024 17:12:22 +0100 Message-ID: <87bk7inmah.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: ti8i7ne53qsitbnzxiqmzhaq1z4y98my X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B7186A0007 X-HE-Tag: 1710346346-78524 X-HE-Meta: U2FsdGVkX1+lORxDKHj//crHTIEvpdNBoP9WsiaVsVgIVOFD7jFXsvCwrW2+D3u2Xfk2fbXM/NJ1CaRuzGf1E0IzkQTYClwJ28Ep5EVKvJ8BC+qvbwCgeYvv3Mi8PAUf/kwT8O/YtssMJryXW7tc0jaBlsuf2mBImyD1l8O5mR1ASXpJgw55GyPqUSyEmhRcGWyr7N800Phz3TjK5PwY3viIBIJJh1uz6ADLcDf2Pa830NGAe6KCa7C/ZwVA9GIP9mGqci7/Sfql/LQ/7BdrvpnWka6RqmJj9Ju79Ic+KYJ/QYlEFPIq8sduhqtu+Duf6lnZZQJs3cPSVj040r+8Z1Za3SBaMkgZTCyF+DMfKG61jFj8ttWagwY5i2TpjCr2AZczqz6ryIgBHB/9EJrVSLRcjoEFfOMD/+Fn1i3S/qyf8DGvxHYyPv4JlwhoQZcXOb6W4tJNV+De3M/3kVTQKxWIoyaYOjN5zyAgQkONx1B0QCYzZplKsGU5m417g75Xf+8XwjTGFAyoNqU8+MJuMdj2CJBepiGG+aTl2F9oRTnqEGXXa65rdNZCVodgX2WkOrLVnXtGDHCpIUY6mE//G6CyqrwzMkzJi7vEScgelbe5Odb/8l/OHezfnxR3OV6YLKlUrbYRVPsprYIX9w2tTTSOTyr3K33fJUmdxXmO1Ic5PlIITNSDdXPLzQtyNr2YQKSQU3ijFPmwxmHdqEQjXo8SYqlvp6tHmUSR4ZTlaaxmEI9c77iVXW3eIh9PEPl6sovks/ryK0kROHTejBK5QZCH8tXr6YY/uoEO+hbpfr6XZRTRHmD96066/gUbvSVCIOMZ1x/4Ce4= 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 Wed, Mar 13 2024 at 11:28, Pasha Tatashin wrote: > On Wed, Mar 13, 2024 at 9:43=E2=80=AFAM Pasha Tatashin > wrote: >> Here's a potential solution that is fast, avoids locking, and ensures at= omicity: >> >> 1. Kernel Stack VA Space >> Dedicate a virtual address range ([KSTACK_START_VA - KSTACK_END_VA]) >> exclusively for kernel stacks. This simplifies validation of faulting >> addresses to be part of a stack. >> >> 2. Finding the faulty task >> - Use ALIGN(fault_address, THREAD_SIZE) to calculate the end of the >> topmost stack page (since stack addresses are aligned to THREAD_SIZE). >> - Store the task_struct pointer as the last word on this topmost page, >> that is always present as it is a pre-allcated stack page. >> >> 3. Stack Padding >> Increase padding to 8 bytes on x86_64 (TOP_OF_KERNEL_STACK_PADDING 8) >> to accommodate the task_struct pointer. > > Alternatively, do not even look-up the task_struct in > dynamic_stack_fault(), but only install the mapping to the faulting > address, store va in the per-cpu array, and handle the rest in > dynamic_stack() during context switching. At that time spin locks can > be taken, and we can do a find_vm_area(addr) call. > > This way, we would not need to modify TOP_OF_KERNEL_STACK_PADDING to > keep task_struct in there. Why not simply doing the 'current' update right next to the stack switching in __switch_to_asm() which has no way of faulting. That needs to validate whether anything uses current between the stack switch and the place where current is updated today. I think nothing should do so, but I would not be surprised either if it would be the case. Such code would already today just work by chance I think, That should not be hard to analyze and fixup if necessary. So that's fixable, but I'm not really convinced that all of this is safe and correct under all circumstances. That needs a lot more analysis than just the trivial one I did for switch_to(). Thanks, tglx