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 0A7A6ECAAD8 for ; Fri, 23 Sep 2022 15:38:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FB6080015; Fri, 23 Sep 2022 11:38:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5845280007; Fri, 23 Sep 2022 11:38:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4253780015; Fri, 23 Sep 2022 11:38:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3033580007 for ; Fri, 23 Sep 2022 11:38:50 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F367DA08CB for ; Fri, 23 Sep 2022 15:38:49 +0000 (UTC) X-FDA: 79943757978.06.B6E9D6C Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) by imf07.hostedemail.com (Postfix) with ESMTP id 819CF4001E for ; Fri, 23 Sep 2022 15:38:49 +0000 (UTC) Received: by mail-il1-f179.google.com with SMTP id v1so353121ilq.1 for ; Fri, 23 Sep 2022 08:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=IYqbNU1fZX4rzoxApDKFFKDnto7gL2nxgV8bIfOeFQo=; b=QgYgZ0SczN90S2LmGDoPyEcaSNhP800LDUhQmpMlD17ZLSVfdR/JKYP7ape2858og5 BAh2C9isGH3RrUg6KckDzrm//AEYKZmRt3TqC2fidYCHaLUZO8jKYxh1rNbqacfFY1OZ ACkiBWfHHS/Rtg3tDNCLTMx01tk8+YJGwlWvdJ/R+SxzBGjOHIsKvGtiJ7r36aA8FxO7 pWuXWUF3M2NtVqvOa5CWo3cO62pR4I92WbG4qnCklqGnL3d4QKKDm8HozZ/65W7zRRNv /4ws2MSB97r0rowNsVC34hrocLEqAxrnW/oHgVorGvjEa+JDc9e15SK++CbNu43R5Nm9 ivRA== 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:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=IYqbNU1fZX4rzoxApDKFFKDnto7gL2nxgV8bIfOeFQo=; b=xZANKPn89rPI0XM/e8bY6bu4gI4WPCaUMozm70nd75j3NZWAOvB8f8NDqElqMxM7/U 3hu595m+jrQHyYZnSriuplvfwGDxnJ8iU4WC9DjVAxYIvEyHh5c8rXth6j1VWWI2OtFM Y4cMSf2+pMQ4cdq7GeZWw33p0OftHEtIgbFwk4sfp+dkGniOWA/96e+SrpATzHnLdVWc HksXBIN8K7Ky1JxK++OiUxSnUu2dtLUJn/rpqa1eXxV83kqebkySSiesLQkHIR3HLKzI 05qKpZ/uJmfRdLEkPc46/1Q6MGTCDFLahh8pTMdPXLgDhzu0ctXIHs6+cbTSUmWO0lyG yyFw== X-Gm-Message-State: ACrzQf2Zx1q4m0+yKgVK4cTiAfp8ynJjBR4dA0O2v/lTFW+V0juSRQbY oDy+gCizJ/Eob62/ZPW5MtdeHvUhrCiXEsSCbW0ZGg== X-Google-Smtp-Source: AMsMyM4d/ic+EXhHlBsvB8fRatAdRHMpVHFKIEza947IkC134wotND2PFgIDPa+RKBjN0RImpPujGXCyVsPVVP4B8qg= X-Received: by 2002:a05:6e02:1e06:b0:2f6:2666:e8ca with SMTP id g6-20020a056e021e0600b002f62666e8camr4229393ila.173.1663947528664; Fri, 23 Sep 2022 08:38:48 -0700 (PDT) MIME-Version: 1.0 From: Jann Horn Date: Fri, 23 Sep 2022 17:38:12 +0200 Message-ID: Subject: some likely bugs in IOMMUv2 (in tlb_finish_mmu() nested flush and mremap()) To: Will Deacon , Jason Gunthorpe , Sean Christopherson , Joerg Roedel , jean-philippe.brucker@arm.com Cc: Linux-MM , kernel list , iommu@lists.linux.dev Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663947529; a=rsa-sha256; cv=none; b=SvxYSt7TPC+jnfVZsg/ljSZ8QWCfDbYj7X5N8A3XYn2inPzl5as3NV0hTSswge7EGUEsKV vPckpl4nzfeEsr7v/UAFP6usPvvDR8OZRu8sg71eESi4s33ikOzFKzgMO74ZJ4Uj1PyxU3 Jivz+ZvzU/4tW6gdHHXWyQMSPqEXcYU= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=QgYgZ0Sc; spf=pass (imf07.hostedemail.com: domain of jannh@google.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663947529; 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: references:dkim-signature; bh=IYqbNU1fZX4rzoxApDKFFKDnto7gL2nxgV8bIfOeFQo=; b=wDTeTRw3TQQIXNFRvYCFJZH/pUiEq7GN4zdInRRXO6fFHwgm4QpYW/M09scda07fH0A0h1 hERk7VAxbjQBFGJhVWoO4RHsx3P/yYcRD+ZH7vBeznOCTZEjLIzHUmmmTHg6pubceTJ9Uo e1wwB7qymVAmGlReji+oBIy+zHTYN8Q= X-Stat-Signature: yosfgamur15g1kzg7mira9zczic55cpf X-Rspamd-Queue-Id: 819CF4001E X-Rspam-User: X-Rspamd-Server: rspam08 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=QgYgZ0Sc; spf=pass (imf07.hostedemail.com: domain of jannh@google.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1663947529-664847 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi! I looked through some of the code related to IOMMUv2 (the thing where the IOMMU walks the normal userspace page tables and TLB shootdowns are replicated to the IOMMU through mmu_notifier_ops::invalidate_range). I think there's a bug in the interaction between tlb_finish_mmu() and mmu_notifier_ops::invalidate_range: In the mm_tlb_flush_nested() case, __tlb_reset_range() sets tlb->start and tlb->end *both* to ~0. Afterwards, tlb_finish_mmu() calls tlb_flush_mmu()->tlb_flush_mmu_tlbonly()->mmu_notifier_invalidate_range(), which will pass those tlb->start and tlb->end values to mmu_notifier_ops::invalidate_range callbacks. But those callbacks don't know about this special case and then basically only flush virtual address ~0, making the flush useless. (However, pretty much every place that calls tlb_finish_mmu() first calls mmu_notifier_invalidate_range_end() even though the appropriate thing would probably be mmu_notifier_invalidate_range_only_end(); and I think those two things probably cancel each other out?) Also, from what I can tell, the mremap() code, in move_page_tables(), only invokes mmu_notifier_ops::invalidate_range via the mmu_notifier_invalidate_range_end() at the very end, long after TLB flushes must have happened - sort of like the bug we had years ago where mremap() was flushing the normal TLBs too late (https://bugs.chromium.org/p/project-zero/issues/detail?id=1695).