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 7E037C433EF for ; Thu, 25 Nov 2021 11:02:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECA0E6B0074; Thu, 25 Nov 2021 06:02:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E79246B0075; Thu, 25 Nov 2021 06:02:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D68566B007B; Thu, 25 Nov 2021 06:02:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) by kanga.kvack.org (Postfix) with ESMTP id C6B486B0074 for ; Thu, 25 Nov 2021 06:02:24 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8A38F82319BB for ; Thu, 25 Nov 2021 11:02:14 +0000 (UTC) X-FDA: 78847163388.16.2EA296D Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf14.hostedemail.com (Postfix) with ESMTP id 437756008091 for ; Thu, 25 Nov 2021 11:00:57 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1637838056; 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: in-reply-to:in-reply-to:references:references; bh=xn8es9Y5ZohXJbqqtiOR7FjNUjmAIwFtzRZu2sltLvc=; b=TWYOkXgrhxsvDPdCRWuMLp3365uHO8Wndv3gEHaWYwDt17B83puMg/ZwTRhZyf4j7Yw4Pe Wq589EnD4w7BGldkAbFF13wjnz4S6Nu906iiU7YsHRSY31DESHE1XxDVxsW3DFoNnPFmAM QvdLepKj2+7CFBE18WratoRGYe/639F6n/XY4ETAZHSv2YtSJZiR9qHfrLE63MlSED6I8m zr5mUPHz8yUeJsUqp7eXrBATf+szkTfR39jlj0huRy4of+GJtE2G97+EsR38ATJV6T/dQK gkE7p8BaV2PxpqQSrZP6zUOI+UbuacG7XSx1ky6Oz02Erfe2apzEgWmLOO4Hcg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1637838056; 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: in-reply-to:in-reply-to:references:references; bh=xn8es9Y5ZohXJbqqtiOR7FjNUjmAIwFtzRZu2sltLvc=; b=CzxuESaCtwtWNGtkAFGdiUpyNbA9GFXleu90nwDvidRyhgEkVf/bf4GEK23WG6wZVn5mmy tWxJP0Bid6CVYtDQ== To: Ard Biesheuvel , linux-mm@kvack.org Cc: Ard Biesheuvel , Quanyang Wang , Linus Walleij , Russell King , Andrew Morton Subject: Re: [PATCH resend] kmap_local: don't assume kmap PTEs are linear arrays in memory In-Reply-To: <20211116094737.7391-1-ardb@kernel.org> References: <20211116094737.7391-1-ardb@kernel.org> Date: Thu, 25 Nov 2021 12:00:56 +0100 Message-ID: <875ysgmrdj.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: p64f5j3zt33a6wnwjuh87oxnhr8pwqqr X-Rspamd-Queue-Id: 437756008091 X-Rspamd-Server: rspam07 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=TWYOkXgr; dkim=pass header.d=linutronix.de header.s=2020e header.b=CzxuESaC; spf=pass (imf14.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-HE-Tag: 1637838057-732017 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: On Tue, Nov 16 2021 at 10:47, Ard Biesheuvel wrote: > The kmap_local conversion broke the ARM architecture, because the new > code assumes that all PTEs used for creating kmaps form a linear array > in memory, and uses array indexing to look up the kmap PTE belonging to > a certain kmap index. > > On ARM, this cannot work, not only because the PTE pages may be > non-adjacent in memory, but also because ARM/!LPAE interleaves hardware > entries and extended entries (carrying software-only bits) in a way that > is not compatible with array indexing. > > Fortunately, this only seems to affect configurations with more than 8 > CPUs, due to the way the per-CPU kmap slots are organized in memory. Ooops. I completely missed that detail. Sorry for the wreckage. > Work around this by permitting an architecture to set a Kconfig symbol > that signifies that the kmap PTEs do not form a lineary array in memory, > and so the only way to locate the appropriate one is to walk the page > tables. > +static pte_t *kmap_get_pte(unsigned long vaddr, int idx) > { > + if (IS_ENABLED(CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY)) > + /* > + * Set by the arch if __kmap_pte[-idx] does not produce > + * the correct entry. > + */ > + return virt_to_kpte(vaddr); Nit. The above is not a one line statement (even if it is from a compiler perspective). /* * Does the architecture have non-linear KMAP pte entries which * cannot be accessed by index? */ if (IS_ENABLED(CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY)) return virt_to_kpte(vaddr); or if (IS_ENABLED(CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY)) { /* PTE entries cannot be accessed by index. */ return virt_to_kpte(vaddr); } are readable but this is really breaking the brain OCR: if (IS_ENABLED(CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY)) /* * Set by the arch if __kmap_pte[-idx] does not produce * the correct entry. */ return virt_to_kpte(vaddr); if (!__kmap_pte) Other than that. Reviewed-by: Thomas Gleixner