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 1302BC4332F for ; Sat, 15 Oct 2022 03:51:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED7FF6B0072; Fri, 14 Oct 2022 23:51:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E887A6B0075; Fri, 14 Oct 2022 23:51:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D01C36B0078; Fri, 14 Oct 2022 23:51:53 -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 B9ED26B0072 for ; Fri, 14 Oct 2022 23:51:53 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 89231A08ED for ; Sat, 15 Oct 2022 03:51:53 +0000 (UTC) X-FDA: 80021810106.26.0A165AD Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf05.hostedemail.com (Postfix) with ESMTP id 2CAD310002A for ; Sat, 15 Oct 2022 03:51:52 +0000 (UTC) Received: by mail-wr1-f42.google.com with SMTP id j7so10329716wrr.3 for ; Fri, 14 Oct 2022 20:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+ESb+w0sZ/kunb6ly4j7hr3fkhT75cLSi893Zn1ULp8=; b=qFjEoVO4aWz9hjMGNTVpmwzdk+zUvLfRe3wjG+chUX76xgBuHBrxkbbCtQ3nq2dZ0a U1bSOvnDe4MalILyZLg0DmrUNaU8IDtecosOopv1iFzty0MkGsiIMWQLykNcX2RRzeq4 lb5klPzNr/TDPsXPSjwnDG+e2h4KImUHKsc5oMdXcpIx+CgfWY9HDDbrOODVCYEF0FbM wnaoBdO1H2nxT7MZ25fV9haN828WP9fpUAgCEo5O0TMH/mM5Bi7ojEnyY28OMVp2Rft1 T7MOppLXMhwgE/bKBjoCjWzt1PK580Wo+E8rH/heMZ0R61s00yjbLy2GEziv9NZll7WQ 72KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+ESb+w0sZ/kunb6ly4j7hr3fkhT75cLSi893Zn1ULp8=; b=zsp9mfq+4vFJlINKK4yf6WaEK+NNCrDI9ZheGVNSTkt9qBbAp6FvNvClXdID3a4hPn +VJxLfDg4IRG1WZuM8pNB/8hfR3wW9gQYGtoNA2k+J/pmoJawzxQQP386lpvyG7Sj0B/ cipA9+mTDQxrjcLS0tDD5GKrKbruvn/lCQFFkCwkcK7IXi4LWsmYTOUUGGkSFPgF5rOL KKEsyKNZk97tnhOojOYypwp9EXfNcYAUWZhbCSw6Dc2Roe01ZMunhbZCysjiDFcynIqO gFTmu0p6+FBGVTlVJP75z5pksqBaU3Q+6Sp/jvJQYRyCaLteytvCfqVV28YvSYcyNwiq 0cyg== X-Gm-Message-State: ACrzQf0RSgLvBUborNvZl6Fjin233rk27bHJpAJ9z2qW2250Ojnm3xvi Xv2u56j0zIWJ6KJCA+D2WcE= X-Google-Smtp-Source: AMsMyM512CYhXqYkmtPrL0iSLTUq9tDLGI0xE6cFEH8JXxXL6Fro2nrx4Jm80Ak21HE6isp6SD51pw== X-Received: by 2002:a05:6000:144c:b0:230:816f:3167 with SMTP id v12-20020a056000144c00b00230816f3167mr418442wrx.532.1665805911395; Fri, 14 Oct 2022 20:51:51 -0700 (PDT) Received: from smtpclient.apple ([5.29.15.194]) by smtp.gmail.com with ESMTPSA id f16-20020a056000129000b0022dc6e76bbdsm3145105wrx.46.2022.10.14.20.51.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Oct 2022 20:51:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [BUG?] X86 arch_tlbbatch_flush() seems to be lacking mm_tlb_flush_nested() integration From: Nadav Amit In-Reply-To: Date: Sat, 15 Oct 2022 06:51:47 +0300 Cc: Andy Lutomirski , Linux-MM , Mel Gorman , Rik van Riel , kernel list , Kees Cook , Ingo Molnar , Sasha Levin , Andrew Morton , Will Deacon , Peter Zijlstra , Linus Torvalds Content-Transfer-Encoding: quoted-printable Message-Id: <0484E294-D6D6-45CE-87F7-5AFDA5309BA1@gmail.com> References: To: Jann Horn X-Mailer: Apple Mail (2.3696.120.41.1.1) ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qFjEoVO4; spf=pass (imf05.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665805913; a=rsa-sha256; cv=none; b=M31hOfBUUPISZcOWXbZerSCqnaWOZWlAGJcVKRqMJkjiKrs0i2zdKM6AcAWPFBPNPwb3xC ijERF3AT8azpG62lEeUsUfPLePc6Wp6K9AzLn3EQg9YhZ6VbY1VICfJwZe57rUNejAeIyL piF4VKV+7xw+ecP2RnUqvN7hAQjPLls= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665805913; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+ESb+w0sZ/kunb6ly4j7hr3fkhT75cLSi893Zn1ULp8=; b=RXxrhgDQ0wG9yW/mKZjuw3w+fHYmvt7Po/VE5/2hPfHeG4nGmNuE0nTpXBBCDXiNHE+LvS PwVROmmg9HHXzjn2A6gKaIjiOEZYOFAmFJfHgTl6UxdFciZfohkv01JqOXPZsdUHqeJ7MT 5/iXb0nBv2VNA9gWrghm1HJ63MMWN6Q= X-Rspam-User: X-Stat-Signature: 5ty43t3q4z5xcfmbs48j7c4zgmqn1zwc X-Rspamd-Queue-Id: 2CAD310002A Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qFjEoVO4; spf=pass (imf05.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam07 X-HE-Tag: 1665805912-674585 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 Oct 14, 2022, at 9:19 PM, Jann Horn wrote: > Hi! >=20 > I haven't actually managed to reproduce this behavior, so maybe I'm > just misunderstanding how this works; but I think the > arch_tlbbatch_flush() path for batched TLB flushing in vmscan ought to > have some kind of integration with mm_tlb_flush_nested(). >=20 > I think that currently, the following race could happen: >=20 > [initial situation: page P is mapped into a page table of task B, but > the page is not referenced, the PTE's A/D bits are clear] > A: vmscan begins > A: vmscan looks at P and P's PTEs, and concludes that P is not = currently in use > B: reads from P through the PTE, setting the Accessed bit and creating > a TLB entry > A: vmscan enters try_to_unmap_one() > A: try_to_unmap_one() calls should_defer_flush(), which returns true > A: try_to_unmap_one() removes the PTE and queues a TLB flush > (arch_tlbbatch_add_mm()) > A: try_to_unmap_one() returns, try_to_unmap() returns to = shrink_folio_list() > B: calls munmap() on the VMA that mapped P > B: no PTEs are removed, so no TLB flush happens Unless I am missing something, flush_tlb_batched_pending() is would be called and do the flushing at this point, no? IIUC the scenario, we had some similar cases in the past [1]. Discussing these scenarios required too many arguments for my liking, and I = would=E2=80=99ve preferred an easier-to-reason batching coordination between the batching mechanisms. I proposed some schemes in the past, but to be fair, I think all of them would have some extra overhead. [1] = https://lore.kernel.org/linux-mm/69BBEB97-1B10-4229-9AEF-DE19C26D8DFF@gmai= l.com/T/#u