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 C8534C5475B for ; Mon, 11 Mar 2024 23:34:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F8CD6B00A8; Mon, 11 Mar 2024 19:34:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A8A86B00AE; Mon, 11 Mar 2024 19:34:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4714C6B00AA; Mon, 11 Mar 2024 19:34:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 34E7A6B0158 for ; Mon, 11 Mar 2024 19:34:04 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D0652140592 for ; Mon, 11 Mar 2024 23:34:03 +0000 (UTC) X-FDA: 81886363566.02.F32F6B8 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf22.hostedemail.com (Postfix) with ESMTP id B2010C0004 for ; Mon, 11 Mar 2024 23:34:01 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=vS+l3KuH; dkim=pass header.d=linutronix.de header.s=2020e header.b=0gFjP9gc; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf22.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=1710200042; 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=MIw7l9VNfGqq4sdtjnnvblmtZxj6z+GMUpQZ0ibxA1g=; b=ar5WnQch2k7K+48a0M85q/O6Jh3guPLcfjpLit153T+ic5czUCh1R3FZclDnsRquBgxp99 Gi0arODt6rmjNhZ5vzlZPexR79tZ+I7jBDWy1QNi5VvVoeOiK48W/LHZnsvUC+A9XTi5nM HrJ6aoRv9gu/3AidQcs7Z0qzel979vo= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=vS+l3KuH; dkim=pass header.d=linutronix.de header.s=2020e header.b=0gFjP9gc; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf22.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=1710200042; a=rsa-sha256; cv=none; b=41VXSo1rIH/vRmTf+UlhzTc9rCePg/bygTrY6L9S8nZ8/sGaP++cW6X/ehoTKf+NNIuFdy oD6CNdADBL0ym6uOFHTrhprYiqdzF3RQQVGrFlE7XHRnyocJInk6WU+b0yPflW0dbsxx3S Z+dz9eluyREVpD009y+VxJmUjDns0V4= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1710200039; 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=MIw7l9VNfGqq4sdtjnnvblmtZxj6z+GMUpQZ0ibxA1g=; b=vS+l3KuHzoSjIJCPO78146fytSCTpgzxWZpwCYU0EKZZ6BRtn39CDliyzMHbnSwf/0TunE qF4ufjYpyeAgtYiakoJbJE9MnGRMr1rBRzeET/7jyHHt8yOaui6tx5+mykEGQddq5C/ipr OS/E/sTYB2TB7vItXhDJoe4nhNmS/4SIVM3pPTanCpMe2E468a9cVwPw17E+bwuj9P53Os quyrRc4PM7VKgLi/iSdA3FMb5t2JhxHtMlgFlTcAzaW/dpousjiqYmqIj3Act51yRe+InE ynd6WUwN/T7VPLGAqmpSJ8Bm50EWMOrNrb0XnYuybMHVjwH5OsqaiQPY1NI25w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1710200039; 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=MIw7l9VNfGqq4sdtjnnvblmtZxj6z+GMUpQZ0ibxA1g=; b=0gFjP9gcUjMNAgXkt9mSb0rnWrsmA2k/IePHaBi5pmWDDtFJiK/evfEKL0E61XQ/7bd2js Nk6xXc8jSkwIigDA== To: Pasha Tatashin , Andy Lutomirski Cc: Linux Kernel Mailing List , linux-mm@kvack.org, 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" , "H. Peter Anvin" , 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 , Uladzislau Rezki , 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> <3e180c07-53db-4acb-a75c-1a33447d81af@app.fastmail.com> Date: Tue, 12 Mar 2024 00:33:58 +0100 Message-ID: <87frwwpcm1.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B2010C0004 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: wjmf5yfwp9ygkttxbstywe5fuj9ecp5g X-HE-Tag: 1710200041-855191 X-HE-Meta: U2FsdGVkX1+OyL2v3d+nqi0rEm+114GZ5xX1DcuT5msCBn7YV38lfzEf4xADMQhkxUE34oYFfbEEd+P1Chj+MsnXIPAtLiFPMVmlhdk20Zw58hjmVQdZMAnnyA6MwNEG5gYetNvQl6QtcnKr9DABCaPRGABDAYok1VNQpfD9BoZxl3Z3DPeTyqHrZXWHaKz7JkJX+w3RwdbB96qr+qXu1Gwd9lEKhXgOSYPOhpRqNIuu4fim1b1l6mR8rJ8eg5ySonH/thAp3zcO/QyXb4jSBihWaui4i6Zg12kT+jBfOhzS3EoqBLCpaXMYIxCkmLKRzChO/CiB45X80mIK5Keh8EPG4alAZAXWZPjDzvqORbiUlLbsyniecZ+8f7SGNk6GX7PvHLKFYhgEPZh5dR4R/ulVX+KWlg3kT1/m2Hs9lKDeXQOrlf7weTSOakryMs6eQxL+t7CciLDOruVj0vlTKPO6+3Lyaq0E2yFPiwjJQjQMIBeQvZ1GgqgR9SWNhoyPwHIFY4FNJvSEe//H8zQzQjTJPTKy/VxuHNbeRKOfsOIpDnHHK43OhFRE8p3qvu3rxPS8xCf+ruOFVFEllRqHwufwNW99lLVQwToYEJxTXh0V3snCZdEe2pMMk6A/CPmELXL1UVviLQaDWZFHNxb54g8NKtmlc8GSbF0UbiGKpIv06Bz229oPLcI2APVFRW1eMeoyIBFlYUbyxLE08wtQ6k5eegw1eAI5E725pJ9OhmYh+wZoAKQtkwGmwIYq2uEVRnWiQn5g/fJoQ3gNnWx7LJmEkl+gXrsvJUxx9CswiVisfTxEc6TR8Pa+JPRyPUIHg9W4rzZWjTbXEEFnIg7pU8Ivtp20G5Qe5x5ns91wv/8= 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 19:10, Pasha Tatashin wrote: > On Mon, Mar 11, 2024 at 6:17=E2=80=AFPM Andy Lutomirski = wrote: >> Also, I think the whole memory allocation concept in this whole >> series is a bit odd. Fundamentally, we *can't* block on these stack >> faults -- we may be in a context where blocking will deadlock. We >> may be in the page allocator. Panicing due to kernel stack >> allocation would be very unpleasant. > > We never block during handling stack faults. There's a per-CPU page > pool, guaranteeing availability for the faulting thread. The thread > simply takes pages from this per-CPU data structure and refills the > pool when leaving the CPU. The faulting routine is efficient, > requiring a fixed number of loads without any locks, stalling, or even > cmpxchg operations. Is this true for any context including nested exceptions and #NMI? Thanks, tglx