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 X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2066AC433E6 for ; Tue, 2 Feb 2021 21:36:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 83AD164F67 for ; Tue, 2 Feb 2021 21:36:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83AD164F67 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CA5066B0005; Tue, 2 Feb 2021 16:36:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB52C6B006C; Tue, 2 Feb 2021 16:36:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A567A6B0070; Tue, 2 Feb 2021 16:36:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id 89D6C6B0005 for ; Tue, 2 Feb 2021 16:36:54 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3FF7F180AD804 for ; Tue, 2 Feb 2021 21:36:54 +0000 (UTC) X-FDA: 77774637948.20.floor57_3e04180275ce Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id A206C180BF326 for ; Tue, 2 Feb 2021 21:35:42 +0000 (UTC) X-HE-Tag: floor57_3e04180275ce X-Filterd-Recvd-Size: 5352 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Tue, 2 Feb 2021 21:35:42 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id s24so3108419pjp.5 for ; Tue, 02 Feb 2021 13:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FoA422evUbddlF75nQqEp1016LqOY8Nux/3DycG907Y=; b=KFi96diUBtHsM9QjTLOU/LYSXKZJ0HTUHilQzhM2H9rN7GHzNuqM6WUTNStZg1yvj4 KJRzyCsVm0T0IhcXrtMQXmpKpkqaC4zzt2rdNJulrse8lsfS08hLDWA0WWV+ffTb+0k0 gSfrLUp3v2xao9XYqMU/AIzvqaaW6004lwc9/AJ5z8/CF/LymuN3jOvMJxf1cyDkZF2F sw27/OtWBiUueWsn/ElrkrYSVGx/piNWTCmkSvUrREnbG3e9XJteSQAE1mBuZ57L3alV 9pxu6LQm0rhzEfMLwyh6+uZbb64g8Y/yOtH/VwDNEngd8byUzVVK00sTOAeRnlhazN9C Tp8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FoA422evUbddlF75nQqEp1016LqOY8Nux/3DycG907Y=; b=ZhdZ8Aqr1U3dtViwGYrcu9HXaZtACZmzRovJC9iK8qCaRgsG7OtclWAZUjDq42370u c5pOq7huAcXPhwMmX2Ocql+UvxVUVT5a3O2TKbNkQVmOLkhLYg96Tda25zV0h35WZtx1 XFuBFnY6SA7eFcKr2QhRlY+FLv//ymZXwQ+ziHIwSFGeT03oeEFedBXo2XibrGZNNBFY FOmYoYEFHlAmn3RndCc4IceUUphpZTj8iUKpCeTTghCv4AA7fS/mLedaCT8zuna7vkKe g2rlksDGanJoWwlJC//YdQhUIUoiMDsy05H3M6pLj56nngpncrQr11swZRe4iBDRM71O s01w== X-Gm-Message-State: AOAM530ql+DI69servnvVsIaX0+hbWGu+IXohNbKQ4jYCwycy8xA3nUm yG3ZRGk1nI/819keKQIR/fU= X-Google-Smtp-Source: ABdhPJxC7dnN1/A6L3fkfdNBAFGq503bH5flKJ3/GWe+kvTYfnaVSueYyGTs7ACApbhmTZiKxoyZhg== X-Received: by 2002:a17:90a:588d:: with SMTP id j13mr6445635pji.50.1612301741037; Tue, 02 Feb 2021 13:35:41 -0800 (PST) Received: from [192.168.88.245] (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id 21sm22259802pfu.136.2021.02.02.13.35.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Feb 2021 13:35:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: [RFC 01/20] mm/tlb: fix fullmm semantics From: Nadav Amit In-Reply-To: Date: Tue, 2 Feb 2021 13:35:38 -0800 Cc: Andrea Arcangeli , Andrew Morton , Andy Lutomirski , Dave Hansen , Thomas Gleixner , Will Deacon , Yu Zhao , Nick Piggin , X86 ML , Linux-MM , LKML Content-Transfer-Encoding: quoted-printable Message-Id: <5E9B0429-7E72-4E86-B91B-4718C4134B0F@gmail.com> References: <20210131001132.3368247-1-namit@vmware.com> <20210131001132.3368247-2-namit@vmware.com> <52673507-2C30-4AC6-8EBC-B5A313827FB0@gmail.com> To: Peter Zijlstra X-Mailer: Apple Mail (2.3608.120.23.2.4) 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 Feb 2, 2021, at 3:00 AM, Peter Zijlstra = wrote: >=20 > On Tue, Feb 02, 2021 at 01:32:36AM -0800, Nadav Amit wrote: >>> On Feb 1, 2021, at 3:36 AM, Peter Zijlstra = wrote: >>>=20 >>>=20 >>> https://lkml.kernel.org/r/20210127235347.1402-1-will@kernel.org >>=20 >> I have seen this series, and applied my patches on it. >>=20 >> Despite Will=E2=80=99s patches, there were still inconsistencies = between fullmm >> and need_flush_all. >>=20 >> Am I missing something? >=20 > I wasn't aware you were on top. I'll look again. Looking on arm64=E2=80=99s tlb_flush() makes me think that there is = currently a bug that this patch fixes. Arm64=E2=80=99s tlb_flush() does: /* * If we're tearing down the address space then we only care = about * invalidating the walk-cache, since the ASID allocator won't * reallocate our ASID without invalidating the entire TLB. */ if (tlb->fullmm) { if (!last_level) flush_tlb_mm(tlb->mm); return; }=20 But currently tlb_mmu_finish() can mistakenly set fullmm incorrectly (if mm_tlb_flush_nested() is true), which might skip the TLB flush. Lucky for us, arm64 flushes each VMA separately (which as we discussed separately may not be necessary), so the only PTEs that might not be = flushed are PTEs that are updated concurrently by another thread that also defer their flushes. It therefore seems that the implications are more on the correctness of certain syscalls (e.g., madvise(DONT_NEED)) without implications on security or memory corruptions. Let me know if you want me to send this patch separately with an updated commit log for faster inclusion.=