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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84A0EC433F5 for ; Tue, 16 Nov 2021 22:12:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D1DE61B68 for ; Tue, 16 Nov 2021 22:12:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1D1DE61B68 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 96D506B0071; Tue, 16 Nov 2021 17:12:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 91BEE6B0072; Tue, 16 Nov 2021 17:12:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E3326B0074; Tue, 16 Nov 2021 17:12:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0099.hostedemail.com [216.40.44.99]) by kanga.kvack.org (Postfix) with ESMTP id 6B0196B0071 for ; Tue, 16 Nov 2021 17:12:36 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 32F8C876EB for ; Tue, 16 Nov 2021 22:12:26 +0000 (UTC) X-FDA: 78816193092.09.67D424F Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf29.hostedemail.com (Postfix) with ESMTP id B1B8E9000273 for ; Tue, 16 Nov 2021 22:12:25 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 9CB8561B68; Tue, 16 Nov 2021 22:12:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1637100744; bh=sx0HLIqmlswLWaFMWwqzqyyM4q03qEs2R9uLP0xdVEI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Gnxw4c881xQwt/vLucLONVtnF+Km6q2WrwlL+dy8nNTF4mDLm6Mj9DG+Cs7jAw0ef fNRYlBCx3hytI+y4sp2Mf0eIhmC2pGcakEQ7nBlRD0JI7UCIPGMOujQ3ezpUaHHpdG 7w9xS119eenRNLMLPk5Ue+zAvVVcb2Rs+jHRhEgw= Date: Tue, 16 Nov 2021 14:12:22 -0800 From: Andrew Morton To: Ard Biesheuvel Cc: linux-mm@kvack.org, Quanyang Wang , Linus Walleij , Thomas Gleixner , Russell King Subject: Re: [PATCH resend] kmap_local: don't assume kmap PTEs are linear arrays in memory Message-Id: <20211116141222.43a1aea5bee1f9b16ed7ba75@linux-foundation.org> In-Reply-To: <20211116094737.7391-1-ardb@kernel.org> References: <20211116094737.7391-1-ardb@kernel.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B1B8E9000273 X-Stat-Signature: bj8e5k7d6eoyhoudaq91m1ncbma9eoah Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Gnxw4c88; dmarc=none; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1637100745-358506 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, 16 Nov 2021 10:47:37 +0100 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. > > 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. A Fixes: link would be helpful. kmap_local() was a year ago, so is a -stable backport desired here?