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=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 57139C2D0E4 for ; Mon, 23 Nov 2020 17:51:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B9ECB2076E for ; Mon, 23 Nov 2020 17:51:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="GSuPM32r" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9ECB2076E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DE5326B00C5; Mon, 23 Nov 2020 12:51:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D94A46B00C6; Mon, 23 Nov 2020 12:51:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C844E6B00C7; Mon, 23 Nov 2020 12:51:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id 9BB966B00C5 for ; Mon, 23 Nov 2020 12:51:16 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3132C181AEF1D for ; Mon, 23 Nov 2020 17:51:16 +0000 (UTC) X-FDA: 77516424552.16.hand62_250f64827367 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 093A2100E6903 for ; Mon, 23 Nov 2020 17:51:16 +0000 (UTC) X-HE-Tag: hand62_250f64827367 X-Filterd-Recvd-Size: 3400 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Nov 2020 17:51:15 +0000 (UTC) Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EC25C2076E; Mon, 23 Nov 2020 17:51:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606153874; bh=gL0uiEnF5ux/DIVy6Bn9QO6COR6evZ2fenQNwK12ESU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GSuPM32rdgh1Eft5jyCUi0yPVLGiv9SiWloey5rvN1O9eDA82uOpvf3C7PvUlOC67 rLVepbViX/bb58GNXTbean7fkWU7n28Fms/41ypy6NB4gFpd/UPthavrCcZ+bbUVag 0zsqh89VYuD/hSKd63/fgpumv+bL7LCQuZE0hcLk= Date: Mon, 23 Nov 2020 17:51:08 +0000 From: Will Deacon To: kernel test robot Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, Catalin Marinas , Yu Zhao , Minchan Kim , Peter Zijlstra , Linus Torvalds , Anshuman Khandual , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, 0day robot , lkp@lists.01.org Subject: Re: [tlb] e242a269fa: WARNING:at_mm/mmu_gather.c:#tlb_gather_mmu Message-ID: <20201123175107.GA11688@willie-the-truck> References: <20201120143557.6715-6-will@kernel.org> <20201122151158.GK2390@xsang-OptiPlex-9020> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201122151158.GK2390@xsang-OptiPlex-9020> User-Agent: Mutt/1.10.1 (2018-07-13) 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: Hmm, this is interesting but my x86-fu is a bit lacking: On Sun, Nov 22, 2020 at 11:11:58PM +0800, kernel test robot wrote: > commit: e242a269fa4b7aee0b157ce5b1d7d12179fc3c44 ("[PATCH 5/6] tlb: mmu_gather: Introduce tlb_gather_mmu_fullmm()") > url: https://github.com/0day-ci/linux/commits/Will-Deacon/tlb-Fix-access-and-soft-dirty-bit-management/20201120-223809 > base: https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git for-next/core [...] > [ 14.182822] WARNING: CPU: 0 PID: 1 at mm/mmu_gather.c:293 tlb_gather_mmu+0x40/0x99 This fires because free_ldt_pgtables() initialises an mmu_gather() with an end address > TASK_SIZE. In other words, this code: unsigned long start = LDT_BASE_ADDR; unsigned long end = LDT_END_ADDR; if (!boot_cpu_has(X86_FEATURE_PTI)) return; tlb_gather_mmu(&tlb, mm, start, end); seems to be passing kernel addresses to tlb_gather_mmu(), which will cause the range adjusment logic in __tlb_adjust_range() to round the base down to TASK_SIZE afaict. At which point, I suspect the low-level invalidation routine replaces the enormous range with a fullmm flush (see the check in flush_tlb_mm_range()). If that's the case (and I would appreciate some input from somebody who knows what an LDT is), then I think the right answer is to replace this with a call to tlb_gather_mmu_fullmm, although I haven't ever anticipated these things working on kernel addresses and whether that would do the right kind of invalidation for x86 w/ PTI. A quick read of the code suggests it should work out... Will