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 C5CAAC4332F for ; Fri, 14 Oct 2022 19:09:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33B806B0072; Fri, 14 Oct 2022 15:09:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EA976B0075; Fri, 14 Oct 2022 15:09:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B2BC6B0078; Fri, 14 Oct 2022 15:09:07 -0400 (EDT) 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 032BF6B0072 for ; Fri, 14 Oct 2022 15:09:06 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C7C9EAA370 for ; Fri, 14 Oct 2022 19:09:06 +0000 (UTC) X-FDA: 80020492692.28.58F2620 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) by imf10.hostedemail.com (Postfix) with ESMTP id 5D84AC0021 for ; Fri, 14 Oct 2022 19:09:06 +0000 (UTC) Received: by mail-qv1-f49.google.com with SMTP id l19so3839364qvu.4 for ; Fri, 14 Oct 2022 12:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PSBBubo8IAbN+yxQgMGavzYe4lqgiZmQwmoNccc+Tn4=; b=F5Xlc3cB3hD+HemKoUoTCn6rUhK1cLvebZc7zGnOdkHD1l1qiFITFPwghAoVxRqtB2 wX1K2pDVCWFT9c5ESJ9ynoOhPSADnfXeM0ux4tvIeRZM/Fj8AS7Mgr/YEoRkVOk9NBol qZLYuS+9+7U6Wx++SXhVg93i5BQzaGhNmZwe4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=PSBBubo8IAbN+yxQgMGavzYe4lqgiZmQwmoNccc+Tn4=; b=YYOpElSfiD36yOtJqRhetoy6a/gf6QDpDdHweYOCx0GNjWcMWJsr8D9n1jqSpx8csa YZdhasBO56mINb6UbAhwOAFpaJvP8koeGGqH6iY4WS8nYaN40Hs0yIBblUHijXRDLqDx w/yl5+oSU6UHEegYC5KTXkLp73CGSwWT3KXIiPOH4Vqii7P8yKg2QXoCljbdnz8E4/Ci 4vrwJdk4rxYwgiS6WSXahJeZG5K6Q8fajhEASfqYsHxpJmD3KfEs6QIT4T7GSfqLWP4+ 3GVlwzIQiFPl/rcd1rnQpTIW3yzntB/X4yOZg5P+A65R+E0w+U2ngTJu8saB6WhBOtWi WWfw== X-Gm-Message-State: ACrzQf0Z/aqbnaCcr1o98ZIg1OTTnTJ5MQCB13WZzWA72ffeZoy+QVWT aJYN8q4DkrcfVmTSxeQm8Nk/VUXmNXg+Jw== X-Google-Smtp-Source: AMsMyM7doxgRxk60Yw3NoNusMw26Lk/ld4XARl/BXkJvL1c9ZUGcVr+denuQgdWliwPjrK6w3X4RRw== X-Received: by 2002:a0c:e552:0:b0:4b1:86f0:89d5 with SMTP id n18-20020a0ce552000000b004b186f089d5mr5369383qvm.97.1665774544444; Fri, 14 Oct 2022 12:09:04 -0700 (PDT) Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com. [209.85.219.176]) by smtp.gmail.com with ESMTPSA id g3-20020a05620a40c300b006eed14045f4sm1420937qko.48.2022.10.14.12.09.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 12:09:02 -0700 (PDT) Received: by mail-yb1-f176.google.com with SMTP id 81so6692497ybf.7 for ; Fri, 14 Oct 2022 12:09:02 -0700 (PDT) X-Received: by 2002:a05:6902:124f:b0:66e:e3da:487e with SMTP id t15-20020a056902124f00b0066ee3da487emr6177123ybu.310.1665774542040; Fri, 14 Oct 2022 12:09:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Fri, 14 Oct 2022 12:08:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [BUG?] X86 arch_tlbbatch_flush() seems to be lacking mm_tlb_flush_nested() integration To: Jann Horn Cc: Andy Lutomirski , Linux-MM , Mel Gorman , Rik van Riel , kernel list , Kees Cook , Ingo Molnar , Sasha Levin , Andrew Morton , Will Deacon , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665774546; 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=PSBBubo8IAbN+yxQgMGavzYe4lqgiZmQwmoNccc+Tn4=; b=kAc+v4u+4gp1YVRAN0rdVzRq+fgYKk3BlXnHWVQ5SfymxaosJiognH+ziR/0JtwnTXROq7 6QZX1OOUo2j9n+p9R9Q4kR5X8E/1sGmfGApmwTjrNKJEqspCOa4xRy7j/BXPTG/Icd73Zb ZcT6+iDq5z/8YHbVOsJkobtYNz3LR1k= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=google header.b=F5Xlc3cB; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665774546; a=rsa-sha256; cv=none; b=Ff1+JcZEr18bgQEgHHlozRkc/6gFAMgVpeAkN3PBxu0jchxEF3l3aDzMIXqb8l43kLSVLQ tK1d8ZhWomQt9flGsjliibzkv0VbP+n6o8t2YfNpgpkh03ls2w450O4GcNUnd1mckZcfWZ LikiVtJW0wxLW88WpdG8kVFMzb4HcWI= X-Rspam-User: X-Rspamd-Queue-Id: 5D84AC0021 X-Stat-Signature: fpnbrmdphpba3k4bfwkqi43cga9jxgpf Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=google header.b=F5Xlc3cB; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org X-Rspamd-Server: rspam10 X-HE-Tag: 1665774546-906791 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 Fri, Oct 14, 2022 at 11:20 AM Jann Horn wrote:\ > > The effect would be that after process B removes a mapping with > munmap() and creates a new mapping in its place, it would still see > data from the old mapping when trying to access the new mapping. > > Am I missing something that protects against this scenario? While I don't think that scenario is something you can trigger in practice without enormously bad luck, I don't see anything that would protect against it. Afaik, the whole vmscan thing never takes the vm lock, only the file lock (to protect mapping->i_map) or the anonvma lock (to protect anon_vma->rb_root). And none of that ends up serializing with a new mmap() that doesn't even install a new page in the page tables (and just gets an old TLB entry). There are zero shared data structures outside of the mm itself. Now, munmap() *could* serialize with it, because at least munmap has access to the data structures and their locks. But it doesn't do any deferred flushes that I can see, so while it's serialized, it doesn't help. And it wouldn't help to do try_to_unmap_flush() from munmap either, since the deferred flushing is per-thread, and the munmap is done from a different thread. So if you're missing something, then I am too. All this flushing is very careful to flush before actually releasing the page, which is our really traditional TLB flush bug. But yeah, that's not the only race - we should flush before replacing the mapping too. Mel? I think the batched flushing goes back to you many many years ago. I hope Jann and me are just being stupid and missing something obvious. Linus