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 75BCDC3DA49 for ; Tue, 23 Jul 2024 16:28:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3CA76B00D7; Tue, 23 Jul 2024 12:28:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EEBE66B00D8; Tue, 23 Jul 2024 12:28:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB3536B00D9; Tue, 23 Jul 2024 12:28:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BBDE56B00D7 for ; Tue, 23 Jul 2024 12:28:37 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6975E12029F for ; Tue, 23 Jul 2024 16:28:37 +0000 (UTC) X-FDA: 82371550674.03.3F4CCAE Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf14.hostedemail.com (Postfix) with ESMTP id CB4F510001B for ; Tue, 23 Jul 2024 16:28:34 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XzROSsI2; spf=pass (imf14.hostedemail.com: domain of ardb@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721752053; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QSjGgtxQcrD3JBmHz0yWhbQyg/fmHN08oNtUgE+OtkY=; b=mG/t7c3BEeb0VmE/ACbHp5h+R8cryD64xvnf68SoZ5S0tiHscNOEEO/l3xfyVqNw1J3EoL TNMAjOrEKaSjMNhB/PkXLBmqfOirnSW/XM1HVvUDtMs4EB6XW0jQGy+Rrba3eCRf3gNKfe Agb7CIDxWf7Xy3/Km+2+eDsHTClRI6E= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XzROSsI2; spf=pass (imf14.hostedemail.com: domain of ardb@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721752053; a=rsa-sha256; cv=none; b=sY7YL+OCU5QDJwOREqWSpYQ9//JDcELIBcrLuzCjTlqh/VaAqLz8lVpgmlxU1lYtkbXM4d rKp+bqQ+6rK+JaGeNGHUqVBCPyBLyP2I4I0/ytoMndazMZzkJZ1xo+4pkI8H4unp/LKeTb u3p5FRwKXCkXj/5QCTGE2J/+xcNyHIk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 9B08CCE1181 for ; Tue, 23 Jul 2024 16:28:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87D28C4AF0E for ; Tue, 23 Jul 2024 16:28:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1721752110; bh=/gSJutKx3HynlVdUOpttVICI3mk9PZE/4lHNjoI0+rw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XzROSsI2ja0hy5r/njAj1KXTgIh9v2P1FNMf0MYkF33nKpB0DRzhnITGHw2dAe8MV 2Nhwr/dLOCHe0jEYkpyYcbX4SRB6m2hO7uRAapBegRDWt3IPgeo75g4AWCx6OGMwPk oyTp+zCJKOsuCbzyyzRISU0nzzUhfElBBkJ3NqunEhDllvx57h+960wOK7sdJfmXXZ IqO8CtrwvkaAXREXMt96QP8t/SkQu38WzPx+ec2urnu9ybOGL3zyHNb1gY3v343Zf5 5Sj2JQjcEl4S/Mo8nTduhMsgirqJ4OIj9ZapY5sCQ2g9lePHZsrrPxlNSm7KMmnSks 2B0lsOuXCNUtg== Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2eeb1051360so57854071fa.0 for ; Tue, 23 Jul 2024 09:28:30 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUa8XAF219cB8VwH5NyzejqFPsv8tDRcRukJd0+T7OjvZncW337bxS0qseQNDO/aMjamXkucPxaHXshgk7ycPEtgwM= X-Gm-Message-State: AOJu0YxcB26yilRO4fu0kB0SDQpFQtoww9PkmudPslSv+G0R+mCIisTn g6DviDhL20Sp+FSS1b2vEnAg4RWZPRbke0u/F/ZGF04VHhy946kCF0WL0nHyQdUv1tJs26EIHe7 JnQfbP5w6OUAvL25Rc9kHY5cWue8= X-Google-Smtp-Source: AGHT+IEIZXkfujE7Kig6KzsuO0P0XYuDOqb7EP3O8/OuBFcMK1MWPhPRHD5+2nR8Vrq8QlBUgPO41D6glPniR07mTlc= X-Received: by 2002:a2e:a30d:0:b0:2f0:1bb6:dbce with SMTP id 38308e7fff4ca-2f01bb6e96emr33131481fa.41.1721752108819; Tue, 23 Jul 2024 09:28:28 -0700 (PDT) MIME-Version: 1.0 References: <50360968-13fb-4e6f-8f52-1725b3177215@asahilina.net> <20240718131428.GA21243@willie-the-truck> <20240723145214.GA26403@willie-the-truck> <20240723160543.GA26546@willie-the-truck> In-Reply-To: <20240723160543.GA26546@willie-the-truck> From: Ard Biesheuvel Date: Tue, 23 Jul 2024 18:28:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LPA2 on non-LPA2 hardware broken with 16K pages To: Will Deacon Cc: Asahi Lina , linux-mm@kvack.org, linux-kernel@vger.kernel.org, asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Catalin Marinas , ryan.roberts@arm.com, mark.rutland@arm.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CB4F510001B X-Stat-Signature: e6x9prmn474y143cd1rnbh7twinwwm65 X-Rspam-User: X-HE-Tag: 1721752114-473962 X-HE-Meta: U2FsdGVkX19TP87NII9+kqFvDFJ/+KajsO3bMkSRSXVP6Zjq2ULFznGrhXb6+/KrsjBK/nOt5tZH5g8CiriVkb3piJDJzzMygkbeAX5C2/b//WeqQLwy3e+gMRGOjT8fcfxNC02S4260t/BZc0fiBte+ItnFGvnf2CwWugnDHipQ4QoedH/TXHUDF6Doogpz3yG3NEQRB/MDMwgsuKWsItuGv9C1L6zA+7LGofwAjYUVpjwvxNMXK53Eg8QMlDrkMSqdTR49w8ruP7JftbMoX27Yx0NVeGTdA19jbS4orYS2Co563+irUpbpidHtSLnw9hVyWvXiFbBoO+z0NNAjM1ChdEHqOzLdRgdDrb/qRUSVn+/4igEodnQQzr6azwaf0jb1rDKZZ2GUdZehgv1RoYm0UR1qL4oHEnulS7grcrHgiUPB38lJu/QfqdjtYVZMQDwLekZAdgEHIcg8KPPQyml7iBZdWjQwg19gHUGm+YyD6teJukqveu8f8kyFUnPrNeBnEdVGYZbbZS0gRUARZ3IeC6GVt/UV1E/hvhZv3AIbZ4m9EGKVhYiP/c9EvDqBz74ZNXK7zsImuwGEBGWDg+KWRtNUu4hapxnMvkf9QAZ4Y8PrC2o/dw0P1E2nnxPFW6JdDDDhApSQLI+pcG1N8obl35LwDhY0nMgY9GJWW0vHVgBwbZUqMSZlz8l4P43etdlY7VmWl9M27wkqajwk/Xkrfr7JzBVKt7Hz7SvRo5yzORiWWqGIqvks/vJQY3qsWJvfOksdOTWIR6F3eT7qIqvFNO4iDVBCSVwhWNvjlZYOS5Pgh2WTRk+sOwb4Zy8n5UdNZqdIOSaubum9APAAFR5+PfXxAwc94GYePHOjj9vYAdyKhvs+u1IzY9b3dnCqWgIeBQ9FyxEImjaqlvOnT6WVwOBL0mkR/9aN20e9sl3ozDgYrWEEW7CUKgErEgG26PInfK9UaY7LsMoi6vz 1zydAupr DIQug2ypTWBJJA0GNqDguFvZw4icnvhKvpy6M6jjjYqfvE8LtRzR2oyFbbr1nBCh77aWIDnh5K2k3ZwJ+Hoi41aRF8ltUIEtnu3sZeC/jWrfb9vIpQbav3sqKtaQvPR8kYQgNTXwfydETmIR8S4h49kiH9TZ+y3EItASPc/CF4bWfO0c0uSUCF0ZNUMOD0U+pFuMwws8AGJI/VHTTWP8RJkBtwsmVWMgFXsDXDHSL8IpjYzIp469Vu64Ag4ursfPufOE83tq+AcIa47+QVvygCwC6bWQtDjvkvmAFsbhp7P/BnaR31g382BGrGA== 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 Tue, 23 Jul 2024 at 18:05, Will Deacon wrote: > > On Tue, Jul 23, 2024 at 05:02:15PM +0200, Ard Biesheuvel wrote: > > On Tue, 23 Jul 2024 at 16:52, Will Deacon wrote: > > > On Fri, Jul 19, 2024 at 11:02:29AM -0700, Ard Biesheuvel wrote: ... > > > > > > > > We might add > > > > > > > > if (pgtable_l4_enabled()) > > > > pgdp = &pgd; > > > > > > > > here to preserve the existing 'lockless' behavior when PUDs are not > > > > folded. > > > > > > The code still needs to be 'lockless' for the 5-level case, so I don't > > > think this is necessary. > > > > The 5-level case is never handled here. > > Urgh, yes, sorry. I've done a fantasticly bad job of explaining myself. > > > There is the 3-level case, where the runtime PUD folding needs the > > actual address in order to recalculate the descriptor address using > > the correct shift. In this case, we don't dereference the pointer > > anyway so the 'lockless' thing doesn't matter (afaict) > > > > In the 4-level case, we want to preserve the original behavior, where > > pgd is not reloaded from pgdp. Setting pgdp to &pgd achieves that. > > Right. What I'm trying to get at is the case where we have folding. For > example, with my patch applied, if we have 3 levels then the lockless > GUP walk looks like: > > > pgd_t pgd = READ_ONCE(*pgdp); > > p4dp = p4d_offset_lockless(pgdp, pgd, addr); > => Returns pgdp > p4d_t p4d = READ_ONCE(*p4dp); > > pudp = pud_offset_lockless(p4dp, p4d, addr); > => Returns &p4d, which is again the pgdp > pud_t pud = READ_ONCE(*pudp); > > > So here we're reloading the same pointer multiple times and my argument > is that if we need to add logic to avoid this for the > pgtable_l4_enabled() case, then we have bigger problems. > The 3-level case is not relevant here. My suggestion only affects the 4-level case: if (pgtable_l4_enabled()) pgdp = &pgd; which prevents us from evaluating *pgdp twice, which seems to me to be the reason these routines exist in the first place. Given that the 3-level runtime-folded case is the one we are trying to fix here, I'd argue that keeping the 4-level case the same as before is important. > > > Yes, we'll load the same entry multiple times, > > > but it should be fine because they're in the context of a different > > > (albeit folded) level. > > > > > > > I don't understand what you are saying here. Why is that fine? > > I think it's fine because (a) the CPU guarantees same address > read-after-read ordering and (b) We only evaluate the most recently read > value. It would be a problem if we mixed data from different reads but, > because the use is confined to that 'level', we don't end up doing that. > > Dunno, am I making any sense? > So what is the point of p?d_offset_lockless()? Is it a performance optimization that we don't care about on arm64? Or does this reasoning still only apply to the folded case?