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 F1EFDE7717D for ; Wed, 11 Dec 2024 13:29:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 517086B027D; Wed, 11 Dec 2024 08:29:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C5C66B027E; Wed, 11 Dec 2024 08:29:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 367BC6B027F; Wed, 11 Dec 2024 08:29:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 170AA6B027D for ; Wed, 11 Dec 2024 08:29:45 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8F29D140BE8 for ; Wed, 11 Dec 2024 13:29:44 +0000 (UTC) X-FDA: 82882759638.08.9A9BBB4 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf24.hostedemail.com (Postfix) with ESMTP id 99E6F180018 for ; Wed, 11 Dec 2024 13:29:39 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=wAuzY6gq; spf=pass (imf24.hostedemail.com: domain of linus.walleij@linaro.org designates 209.85.167.44 as permitted sender) smtp.mailfrom=linus.walleij@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733923772; 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=u7zPCRbNobZB2rLY4klNUfuL4Nc1TSS5AqwC+M05YI8=; b=wPj8WkAfBKTCkdllAzHI4eg9n/ZRwvJiS+femDB1O26dSjLNo3HnGI+oOXuSAx/1Izjhfk s65gP3KbgXUTBxC/6AYvrL6GX26GuBm4E4ACIqZQtUQFnx7ffBUETssiqrly/HTEfk7Xds BkmrIm3w6riCQ7zRKYxvLfgMbOgOtL0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=wAuzY6gq; spf=pass (imf24.hostedemail.com: domain of linus.walleij@linaro.org designates 209.85.167.44 as permitted sender) smtp.mailfrom=linus.walleij@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733923772; a=rsa-sha256; cv=none; b=OL05lpt3agS0SjaO86rAGlvlCO4oGbxhFEMESCRRPl7L2gSD44UwRxHDvGme1ZDh7nLO3s 7/xlfMiHMhoLhTCvzgbSdMy79uiLIRmUAeJWaNiL3m3HwPc1ILQQjflHAIRPZjvFUc/HSW FHxYWjoenYFkmCWWd/0CNDh6cn7+ww8= Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-5401c68b89eso812940e87.0 for ; Wed, 11 Dec 2024 05:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733923781; x=1734528581; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=u7zPCRbNobZB2rLY4klNUfuL4Nc1TSS5AqwC+M05YI8=; b=wAuzY6gqZdc+oSlGZfYCnIyccAIOJXoGvkqiph4cDAms6k7cwqWMGmy8cslImGx3OA nYa+hw1NGtx2ciL2cmktlHVjMgnVy7tZjUUPqw7FqFB0sx1U+ahvyP2UhtjlJYzD3lRO +0ivjNhOvaeIXjRm7SoCsD0sCSvrX6xRPMlMr22Su58O1oYFVnvkE9WWIqhlOf9pSQH9 eDZdUfz6nRpCkEk2OfwFvdbkzbKK664OJQ4o20kbiai53hAfF5tZJ3NFpzCUtvw5aBBA h0Cm4nnKAD5WymG8jeK+wRe9/aLZWLbrLldeoAuwuFdTeGlyKmpJB6tvjrxeMnTxp4eR YGvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733923781; x=1734528581; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u7zPCRbNobZB2rLY4klNUfuL4Nc1TSS5AqwC+M05YI8=; b=I0IM8j806Dp2y23doHPNoO4rsYJHQXBYGc1DJv0fLjPgHdS0//7GRmm0XALv/lE3jV JLO4M7800aORh/tLFhnSweiaDtrd5zqIi59uw8By7jZH5GLHZ2cs8NrnBUDFhbrLOcNY RxK4bh9ZT4eksUbMnZosOhRCcpSmc3apc88M5AOsc587o4Eqtt9/gbTXTssUl8SeZnOK ASz3KblB+8FqWPhOuURX9JNuXPuJBqByzLkGMSDjy0mcLelm7xwQM9wzf1DLUg92twbY YQBckgchtXUDghH80qmnKSL14zOCZ/9C79QnwQSuBL6ZnBjtyzWF+DZSg8y1wOHxUmkL U3Ew== X-Forwarded-Encrypted: i=1; AJvYcCW873llWZmHiUqGy9sGbXQNEAy++gzs185aS1wO3vumcurQOybd8ya1wvPE3wIR7GNQDVO3yIEkxg==@kvack.org X-Gm-Message-State: AOJu0Yz+zOksiYZWLAFJuutKB9ehMvpxtDk+2FQy6E7ugNXbtl+zVWC+ xdmwPO9AzBGNDEuYka9xQT/t81usPhirGIU8B9hE5szwcT+5VqCjlcyADR2HTnRwfe85n1v71/P YXdt8PqAb/OPEJHCaFHj+dzH4GNKeuuSNiyouiA== X-Gm-Gg: ASbGncvzJTyaG2ZmaLXNK0srvGRySpauRoIJlnvT81PKZ21FrbQUdHY875FKHEa6eoD lwwWC8gKI8ueX7EX8Fr6IAZJmZiKzH6MyUg== X-Google-Smtp-Source: AGHT+IFgSwAzChMV6MPtTrzqAT5fEZJhpVqpZ7rEneJDnxJfXq2+f607r/zOzxJe6hnLdIwQ0jSdAOyNE+c9jLtr2FA= X-Received: by 2002:a05:6512:3d9e:b0:53e:2246:c262 with SMTP id 2adb3069b0e04-5402a6ba964mr927083e87.0.1733923780650; Wed, 11 Dec 2024 05:29:40 -0800 (PST) MIME-Version: 1.0 References: <20241210160556.2341497-1-arnd@kernel.org> <20241210160556.2341497-3-arnd@kernel.org> In-Reply-To: <20241210160556.2341497-3-arnd@kernel.org> From: Linus Walleij Date: Wed, 11 Dec 2024 14:29:29 +0100 Message-ID: Subject: Re: [PATCH 2/4] ARM: Disable HIGHPTE on PREEMPT_RT kernels To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Arnd Bergmann , linux-mm@kvack.org, linux-rt-devel@lists.linux.dev, Ard Biesheuvel , Clark Williams , Jason Baron , Josh Poimboeuf , Mark Rutland , Matthew Wilcox , Peter Zijlstra , Russell King , Sebastian Andrzej Siewior , Steven Rostedt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 99E6F180018 X-Stat-Signature: 9yfs4sxm9zaxsykk58jw6fxijm8t389q X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1733923779-911159 X-HE-Meta: U2FsdGVkX1+8Ca8uV9xvZf0eaHBlY3GdzTCDh49tcbXpbgcH6mPVdFQ8qzt9EcLwb8/HMyaVVpc/gT7Mv6AgjqtyzBvF+PA3WTC0BU1EVw5uyzr3380vG/X0R02sORVjOSoVLDsLHTCwaW7GDpgiqrGi5fOCexcyBht7oWj+NdAawGA0uNVNrZFiEJ9v1UgthxaeLLzc4o7gZ9YWlQ/ucq8V2j1AeBkUk5ztElJrXcKOSDStFzD/cvEGxRF7GXhwgYbuPze0+7lLSpRVcImhHyDdTCKxzNUXecNm/ksQuLsr0bx9yzgPjIDVg8Rf/I4n8tPGWZDWJ8yA2pkNCq3uHRtY3UilfUSmIdeYZIf2B4KQUzuzvbCGK/Lf2KB3t4srsIFqWQLtbhSzpSg2MmhcBU39OfLXpOPZOkw0Xd+JMtkRQiwhgI/hJZ/Gs3nUiCZYmZ1IY5ld7x6xwmMJPOPu32QrTE5xWguF7Tex7VCYN9cwEg7VIeFqzoMQQl9ALQWlBzM01DBaXuK7pY/a3yRC68PmCNaF0cBijwBOktKm3VQHp9w/jQIfGDoVJFvjx1gtQMFTkkcWmVmNw0AKCkBWGUJJPQ/f0Ln+0DoNen/pRqqKNXQu/0rOGxuqePwypNQ57wU5X1zocTqtdWRZoxu93oI4NSdfEWtbiRcPsWNfJzZedEScyoU3Cflzl4Cn9QwT3HyIvAD9AqoZ09LNMJwEG7uSScpAnD7sTH3EQW8AkuSlNg+K3uzvqQbpqKqIRu2uYxxWw+z0FFYFBb/6zwAJv+UZTLxgzos7JqoVgTc1/X04yMTy9JHNp4WPayBqLpeC6ZTl9dbVKIQBi7ZO0VASFZoDQHXJ7tORQh2d2JHed+hNMfk799TYWMKsN9xaQtumchE54+kaYtgJw0NG7jpC+awoPgWfP0VYq0UW2eNKYFbLpzQgFvaL6v7gAFGgDKafQYmn5CkR1Uc6YXa/Nlh r+7uUDqw q8dDTE0aepNNI2TMsK/WyH6R0y3LANdvYScOmJ0CFOxi8yIjV1kPmNa/Vi7PqYgV3khQeFeDHEuoSqzm8nggsKetfoyv8U2CzpLu0oGf2Rg8/QoRCrH3RlZ/qtJrdtmcHf4xIxdhtXlE/ZRksksAhoVtGJ1RaocBqeer679qRoHgyoN2R/SSnJ/p+JoK46RPsZHXYbGR3nSdGAMP1rOh24fORc2PesWbTM70zjk6cmRYEx05hN7my4DG5HsFie8sCdIyB97w/fHQRXr0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.002591, 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 Tue, Dec 10, 2024 at 5:06=E2=80=AFPM Arnd Bergmann wro= te: > From: Sebastian Andrzej Siewior > > gup_pgd_range() is invoked with disabled interrupts and invokes There is no gup_pgd_range() in the kernel, is this patch a bit old? There is gup_fast_pgd_range(). See 23babe1934d7637b598e4c9d9f3876e318fa63a4 gup.c contains: get_user_pages_fast attempts to pin user pages by walking the page tables directly and avoids taking locks. (...) Let's consistently call the "fast-only" part of GUP "GUP-fast" and rename all relevant internal functions to start with "gup_fast", to make it clearer that this is not ordinary GUP. The current mixture of "lockless", "gup" and "gup_fast" is confusing. So fast GUP is supposed to be lockless, and should just not have this problem. So it can't be addressing gup_fast_pgd_range() right? > __kmap_local_page_prot() via pte_offset_map(), gup_p4d_range(). > With HIGHPTE enabled, __kmap_local_page_prot() invokes kmap_high_get() > which uses a spinlock_t via lock_kmap_any(). This leads to an > sleeping-while-atomic error on PREEMPT_RT because spinlock_t becomes a > sleeping lock and must not be acquired in atomic context. I think this needs to be inspected by David Hildenbrand, if he consistently rename the GPU functions to be "fast" and there is a lock somewhere deep in there, something must be wrong and violating the API contract. > The loop in map_new_virtual() uses wait_queue_head_t for wake up which > also is using a spinlock_t. > > Since HIGHPTE is rarely needed at all, turn it off for PREEMPT_RT > to allow the use of get_user_pages_fast(). > > [arnd: rework patch to turn off HIGHPTE instead of HAVE_PAST_GUP] HAVE_FAST_GUP I'm still confused, how can something that is supposed to be lockless "fast" acquire a spinlock? Something is odd here. > Signed-off-by: Sebastian Andrzej Siewior > --- > There is an open question about whether HIGHPTE is still needed > at all, given how rare 32-bit machines with more than 4GB > are on any architecture. If we instead decide to remove HIGHPTE > altogether, this patch is no longer needed. I'm more asking if HIGHPTE even acquires a spinlock anymore as it is supposed to be "fast"/lockless. If it does, it is clearly violatin= g the "fast" promise of the fast GUP API and should not exist. Yours, Linus Walleij