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 99979C54E58 for ; Sat, 9 Mar 2024 02:19:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D30396B0071; Fri, 8 Mar 2024 21:19:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CB9386B0072; Fri, 8 Mar 2024 21:19:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B32EA6B0074; Fri, 8 Mar 2024 21:19:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9E6AC6B0071 for ; Fri, 8 Mar 2024 21:19:24 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 76E5CA077F for ; Sat, 9 Mar 2024 02:19:24 +0000 (UTC) X-FDA: 81875893848.18.8A0F33C Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) by imf12.hostedemail.com (Postfix) with ESMTP id B74D440009 for ; Sat, 9 Mar 2024 02:19:22 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IisLuH7U; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of 3KcfrZQoKCJwUKONU6DIA9CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--yosryahmed.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3KcfrZQoKCJwUKONU6DIA9CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--yosryahmed.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709950762; a=rsa-sha256; cv=none; b=xS5+i38XRmFuBtx7FkfUK2miv62qIVj854YTxNKYu9eb0H9hh5LYfTJDPOb1M2d+xRnVfV 698D9buBs+eRONhuO4GV8nFiTNbn4DmaJHJJ9UTFJK0yojaGRDQzvDdAgwEZh/soNSKxvV am426WRaKF4LYvdtD8PNYeEOFgWSAnM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IisLuH7U; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of 3KcfrZQoKCJwUKONU6DIA9CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--yosryahmed.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3KcfrZQoKCJwUKONU6DIA9CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--yosryahmed.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709950762; 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=rQYhZoz7SpBOGR+3G/7N8yPJRQiuzCkFrb6/L7sC9O0=; b=IL42WQ1SluTXlCKkqhcSWEtPgq7TkIFoC9QtRwf2XaarQIbWabIFdWcRwsnJ0UjjVsmFhM vsa2h4w2HO23kGhJvREy6urZ0qc21yk/9kVTdnZjniFCvpSKATlv4SzFdW2bHclXu1qTdg euhNqZX9RrzLQI9e8iEVp1Y5rpjfLBI= Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-60a012e6888so27379657b3.2 for ; Fri, 08 Mar 2024 18:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709950761; x=1710555561; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=rQYhZoz7SpBOGR+3G/7N8yPJRQiuzCkFrb6/L7sC9O0=; b=IisLuH7U9htXO+iqs9DxnvUQLl1vLNbdGDh/lP97z7CbIvKmh0zOpr1ZnoGyRmgCsY oYUau+JVFflLAKg/ECqwKSSwNwGcxjZd7Ln1I/uLGk7cGydCzPZg+3zHwIWhieF3fgwF yohu4gObq4TyqhBXGOP3KEo4WF7o+6juEpRiEnVN7MeXu4miYCX3BXNPJcoUoF91nI6F tPqjPv05y2KC0BsYD66zMMKjIKDWqQLMA1AKLqQyUqtTaCUGxKEDCsDWxEzwDq/zvnQN tyEzOoGnjp43Bck+AaaSUi1LqAQ0MyBwcMO8PYmZvm4vAafkSM94eFbh6Rf6Gn0PGYfM T/fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709950761; x=1710555561; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rQYhZoz7SpBOGR+3G/7N8yPJRQiuzCkFrb6/L7sC9O0=; b=W9anWbufLon5RwqKa9FaJ5mc/mkkxFcplIMTEOAAljHqOe/C5FZY+99abgbWc1PC1R sYX67XWoRzSgeRiq5LavybG4Vakdjx3LH/hMe2nzuemmrhxC2LSIxaCY/VuJT0Np5GJJ XR8+pO3bPtlqB+dNIC/JExiywWoQTa4+aNr0hTR04DcjSnjmcBdMVdee4bBYLqiOLFZp amC7r5rgvPOHExYVC/kfPefaTtB7XlrYCrsvLRzFF4/nj5LL5pGE9GiJyTFZ7yT1h78y H77WWOxICX5O2aRLlbQN8XVPmd92748FGZVFt3DHX7Q+DW1sKOcB8nPq0S+3uYpe25wu GfWQ== X-Forwarded-Encrypted: i=1; AJvYcCV998FORO9rCxdcywz5TL57CBAZ4FnrDiPYPQMffrVgOh5fj5w0PwHYhQYPkrNabS2ibIjrES2SA2mZCX+mRuBWxIM= X-Gm-Message-State: AOJu0YzU9KKCyegPJl8F+/Z1YdxQogdzJp+1Z3mcfmr+u083aFn7CPTM Txj60IdaB9nrufwfL68kxfwSnNtmErUyDoJM1u0d3A4PgCdoIgy5quClZUvwGaHSBKwu5B0HbJp SMHBNRicd2FqKZLvqgQ== X-Google-Smtp-Source: AGHT+IFMwveIVMUrOovocNj61UNOQCcJqfm8adIbbc+JT16kdYXLBkLZVCN3460E7Ul9r8VrXyU+CNAy4r3p8608 X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:29b4]) (user=yosryahmed job=sendgmr) by 2002:a05:690c:f0d:b0:60a:1705:b286 with SMTP id dc13-20020a05690c0f0d00b0060a1705b286mr109921ywb.1.1709950761719; Fri, 08 Mar 2024 18:19:21 -0800 (PST) Date: Sat, 9 Mar 2024 02:19:19 +0000 In-Reply-To: <35b670e2-9ef5-4d3a-b6ea-f8016dfa088d@intel.com> Mime-Version: 1.0 References: <20240307133916.3782068-1-yosryahmed@google.com> <20240307133916.3782068-3-yosryahmed@google.com> <420fcb06-c3c3-4e8f-a82d-be2fb2ef444d@app.fastmail.com> <35b670e2-9ef5-4d3a-b6ea-f8016dfa088d@intel.com> Message-ID: Subject: Re: [RFC PATCH 2/3] x86/mm: make sure LAM is up-to-date during context switching From: Yosry Ahmed To: Dave Hansen Cc: Andy Lutomirski , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "Peter Zijlstra (Intel)" , "Kirill A. Shutemov" , "the arch/x86 maintainers" , linux-mm@kvack.org, Linux Kernel Mailing List Content-Type: text/plain; charset="us-ascii" X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B74D440009 X-Stat-Signature: dd8gkui78tiwah4dcm8z9zbg1b677szy X-HE-Tag: 1709950762-27167 X-HE-Meta: U2FsdGVkX19Kk+8VonexuJGHvIyFWeLQfdoRgqivZPc2gYbn3zFdlyv5GuydLIOxNTQT8CuNVXx6gdRi9ldXQVlPfyEN4CbvLVkxVbOARbsCPaNvmLTbuI2sYeyGPJXAjQNFrhLSU/Lh0otMkx06LRfgMza4B0YmFcA1EfRVERKy1o61cJiodTbUOCdNg1P/CVjx6qhK5TAxL9mt8CfG20OEWll8dHbm+QNvPQpGjWEiDmXvIcWng+APZUpduEQ7wWje6RYji2C4ocl8SSkAMAgu/21ySttGIL6030wYBGQCtUSIY12SfhZqfbHginYwxIk6QC3hYZEXVwOeBKTgDn07LHMWgz0gMZL5cEqqo5XLPSqr7xrtYoFNAgxMERX87HFhVUXyzDe1I9rVCsp3lTYctQnt2Fm6qajyQstpQCsnIxgzJm0HPWx6oW19GiDFtXPicvsidil5qBW3Ur8PKfkWN+AQF3UZ5/7f24c+D3CsQNDSJESW3qRdAhnonssKg7EJH3OHE6jkauzZ4YQ3ZRwfQR68W9pPd5t6IXPa4b0ktgJ0BBa4jGe57+V4PGecIC8nNMQ+/MYLiflEsxSyr+esu3u6AlHTKxWkFKHUwZaZfjNyeMcDaxjfZvH3+aPG/0nEICAFTCJaMXyEGlCetjIPU2bdgvS3calwZHCp9o41/2eMbX3Nrn955zh9XDfkOJmDIIvw+LQU1M+aRC+UYnJ0EwO3V5ujp3AV22YYWY32tDl7MfFDjgcaAqO0QkVaw6+P2uw0FmlCYas8OCdlUF/UZSqMS4RaJZMiO3qM2/e8hGNPcDRewWjn4yq+j3jcK82cG64dAr9Qt8/RDa56ri1Ofdlwh8qdHYjnmdRTTpkARr8n1z8aRL4mtWdpmnrwYYz9vgjc59QSxh4mm1hpm8V57W/m+qpYPQwPNoLYSwlgf8esugQSMnnMzLOYce/WsLkac/6K7wMKv67QaSN bFIh1+Rz hwD7lU2ox/KQICyWDExGtzv/rZeB/YbUK5ZQ9Oy6f8cttjUvlPUU7ygLbMwFHnKsf6ytcx/r9lJHzX840CLa/6OtzndOXNtfhq4Ia0PLu98lCvyaglY0hJ5BnKPipUmKDwr2GdWvk4muP+dVi1+i2J8ZTq4Oek9/eQuwB6ObtTWIvWat+QZKNUtlLTOcpXX5i8vPy9ofh/GUSu8zVN2H8I6fhBxyaSbQ1Owtf31RzO//OEu05cofjehyOWxG8qshgoaeiWGDXgaAyZDCo9+Y97HUYFkWZ2ZDrJ/2BkTR8/SKj7tHUV+DUGaYV20lM2O993Ns65/bTQq/ClnPlY+epvIKQc0zi4KmabBeKOtdVTxh9gw+/bH9az+IWxRlxOe/yzucebvhgN2l8muncBaNKff4VAcGHpc38DFsUVTXe38oxp7l0am8V2VSA/phYyIPU5w0RAiQqwaIXYV9O5a4phvTLz3oFoz0TgYP99FKL29UyxnyQstj19M8eKc6gRtSD6gJtJtpGlGjyLHzD+64aSnPj3ybPqmeeMPajArZQ0xWi8c0aQ0TmNNMe6Unp5CjMXsAHlwkKauGa/t2fmx8iBd96yLB23ggvoaL2V2Kg2ahQyQ/BiVrJ/nMS+w== 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 Fri, Mar 08, 2024 at 07:23:58AM -0800, Dave Hansen wrote: > On 3/7/24 17:34, Andy Lutomirski wrote: > >> Fix this by making sure we write a new CR3 if LAM is not > >> up-to-date. No problems were observed in practice, this was found > >> by code inspection. > > I think it should be fixed with a much bigger hammer: explicit IPIs. > > Just don't ever let it get out of date, like install_ldt(). > I guess it matters whether the thing that matters is having a persistent > inconsistency or a temporary one. IPIs will definitely turn a permanent > one into a temporary one. > > But this is all easier to reason about if we can get rid of even the > temporary inconsistency. > > Wouldn't this be even simpler than IPIs? > > static inline unsigned long set_tlbstate_lam_mode(struct mm_struct *mm) > { > unsigned long lam = READ_ONCE(mm->context.lam_cr3_mask); > > + /* LAM is for userspace only. Ignore it for kernel threads: */ > + if (tsk->flags & PF_KTHREAD) > + return 0; > > this_cpu_write(cpu_tlbstate.lam, lam >> X86_CR3_LAM_U57_BIT); > this_cpu_write(tlbstate_untag_mask, mm->context.untag_mask); > return lam; > } Hmm I don't see how this fixes the problem addressed by this patch. I think this fixes the problem addressed by patch 1, where CR3 and cpu_tlbstate.lam may get out of sync if LAM enablement races with switch_mm_irqs_off(). However, this patch is fixing a deeper problem (an actual bug). Precisely this situation: CPU 1 CPU 2 /* kthread */ kthread_use_mm() /* user thread */ prctl_enable_tagged_addr() /* LAM enabled */ context_switch() /* to CPU 1 */ switch_mm_irqs_off() /* user thread */ ---> LAM is disabled here <--- When switch_mm_irqs_off() runs on CPU 1 to switch from the kthread to the user thread, because the mm is not actually changing, we may not write CR3. In this case, the user thread runs on CPU 1 with LAM disabled, right? The IPI would fix this problem because prctl_enable_tagged_addr() will make sure that CPU 1 enables LAM before it returns to userspace. Alternatively, this patch fixes the problem by making sure we write CR3 in switch_mm_irqs_off() if LAM is out-of-date. I don't see how skipping set_tlbstate_lam_mode() for kthreads fixes this problem. Do you mind elaborating?