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 B60ACC6FD1D for ; Thu, 30 Mar 2023 13:56:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FF5C6B0071; Thu, 30 Mar 2023 09:56:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AF2B900002; Thu, 30 Mar 2023 09:56:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0771C6B007B; Thu, 30 Mar 2023 09:56:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EE8596B0071 for ; Thu, 30 Mar 2023 09:56:57 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 996F7A09C4 for ; Thu, 30 Mar 2023 13:56:57 +0000 (UTC) X-FDA: 80625715674.08.CFC2B67 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf15.hostedemail.com (Postfix) with ESMTP id 8E615A000E for ; Thu, 30 Mar 2023 13:56:55 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf15.hostedemail.com: domain of steven.price@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=steven.price@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680184616; 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; bh=Br1GY68qjJ0Wp1rtpij4lPP6LdlgTTBnhFV6CEdD1oc=; b=kON2e0YMOx25DXY4lF1/0O8qJnpQ6bxyVmJ7FkGhuC+m8VXKF3D+b+qs7eueVxCwuMLCE5 nujahrNcnKLYy9AWLUeZmUNvjMcfslt389TpgixJbT8f3wXnzIpbpVMiBd5qKtRjgRYglZ lJusMNKkwszkz/0KBFW4hxSyLoBuNAI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf15.hostedemail.com: domain of steven.price@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=steven.price@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680184616; a=rsa-sha256; cv=none; b=DXHI34XjcP3ELnEqR13toGiTsyfvP7ef32VIrieWaqQi32xHFxfCrhM4YVVed6HV78tvNY Td9YQxbhBLvb7Vc0yKfzf6HUk1+47YDe9jddJmlfRfLoFzZgPRr6FkV04EgJRKlY0Kupt8 rEKCUN3sB/0tNAvsriDeiBisG3k9Cwg= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DC2632F4; Thu, 30 Mar 2023 06:57:38 -0700 (PDT) Received: from [10.1.35.23] (e122027.cambridge.arm.com [10.1.35.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6F77F3F663; Thu, 30 Mar 2023 06:56:52 -0700 (PDT) Message-ID: Date: Thu, 30 Mar 2023 14:56:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [BUG] Usersapce MTE error with allocation tag 0 when low on memory To: Catalin Marinas , =?UTF-8?B?UXVuLXdlaSBMaW4gKOael+e+pOW0tCk=?= Cc: "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "surenb@google.com" , "david@redhat.com" , =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , "kasan-dev@googlegroups.com" , =?UTF-8?B?S3Vhbi1ZaW5nIExlZSAo5p2O5Yag56mOKQ==?= , =?UTF-8?B?Q2FzcGVyIExpICjmnY7kuK3mpq4p?= , "gregkh@linuxfoundation.org" References: <5050805753ac469e8d727c797c2218a9d780d434.camel@mediatek.com> Content-Language: en-GB From: Steven Price In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8E615A000E X-Stat-Signature: 19zddnwkj8d7q59dykmud5b1a86rru1a X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1680184615-684718 X-HE-Meta: U2FsdGVkX18KQPM3tKo75VaY3BkT19DmqgN2OqpV2zSysPp27XxmZIwE8ChXl3uAWzY3/Ug8sg+HLcFH+l66I/nTkb1szdf4geD11NGZsr0cjdMhN/rsWLE8A4KOWSs+8X6Q39mzDHemoUeL9ygmQXgEEFjuubqWWCXnMD1HYXLkBUaOAbLakUVodm4VuA2Wj1R6J/jOFyRMdbMF499dTeW1ALY+DkWgpRRQwK9zDSPKcZuR+8OF9AwF3tBbvB5AqeP8JPl+Urg+/+/Y6TnuZeIQoA6uRor87gnh9fsUHNJFRQkx0R9DFyiQ9lqC9wiMK/9Fm9v1yPNGaTj68FxAoUlX4v6Kn4/GazMXlp6qx4XuyKqTu/6MXEKVfRAunT6fp52e6Ja5wqBkaFBeY+0e9wkaqcFiG3M7s25kz+GJfxBUsnPPo2Oj6U68g/C2pf+YAWWD0fuF1cDm5KAKOkvuIXMDPTC+Wi3SLB5Ml2kcfDIm4RQZ8UIpQQQ0m7fDdZRvS56mPRG6y85yyarfnCJ2gYTWgLWVRdN3NF4GP+frZT2qnDxiJfKj8J0/ZQ6Z1FNP/4mmRFOYKv0q6FvgktTha8d4ds2qCrV6SdFAk2vFc6796xDdkwXPCBpllq5x5pmhP4QzejOV2mJWkTH4CTjsVNC0Sh7iMqcnA8L4k9OH8yWZDJIBWoLZv5We7FaezBf0zVF6la9JasaTzeK2qnCqbFrFJTAT5s+Va3ocFwIyq2+RqxvTafhHlN6IGcOuDGvmXuimrJff1957yy4mf0Fvk6bOK2xx26+rcz3PXuRskmE6X92DIgAHImNVjQ4duQVarTaJ+GzGaBnVxrF2lNhDCXmu01wzInuSlJeHFkczh4zW4RaLAR9b26fOPICytcldi809gjZg1nGg5m4WdJjxGHLZIwFlexbbbeDLRb6+OeLcqcLPX3FQs0CI4ZYn80qLWFqyfPjQKPybBvwn8IU 42abVrYK eBU2nGk+lU3zm7vcf4oRNvQWmwKW+HGoZhuOZg8Av7FsHoismkZHSMCf6D6h5aIZ+1E1NkPIA3t6z5nAUzwPwjjAllfociRumpbndymjExt1uydJKPlnyq5/E2nKY85d5K8GP859VYMiV3O0mt7t6Zje3USsZbTi7WAPw0vnvQVH8acj+Mm0XEeAAWgBD2IwCh4F74s7OO0DyALNQ3+yJErAjDkFPIvdSAf/dwTJV/TJlvuw6+dpUoZvSIA== 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 29/03/2023 17:54, Catalin Marinas wrote: > + Steven Price who added the MTE swap support. > > On Wed, Mar 29, 2023 at 02:55:49AM +0000, Qun-wei Lin (林群崴) wrote: >> >> Having compared the differences between Kernel-5.15 and Kernel-6.1, >> We found the order of swap_free() and set_pte_at() is changed in >> do_swap_page(). >> >> When fault in, do_swap_page() will call swap_free() first: >> do_swap_page() -> swap_free() -> __swap_entry_free() -> >> free_swap_slot() -> swapcache_free_entries() -> swap_entry_free() -> >> swap_range_free() -> arch_swap_invalidate_page() -> >> mte_invalidate_tags_area() -> mte_invalidate_tags() -> xa_erase() >> >> and then call set_pte_at(): >> do_swap_page() -> set_pte_at() -> __set_pte_at() -> mte_sync_tags() -> >> mte_sync_page_tags() -> mte_restore_tags() -> xa_load() >> >> This means that the swap slot is invalidated before pte mapping, and >> this will cause the mte tag in XArray to be released before tag >> restore. This analysis looks correct to me. The MTE swap code works on the assumption that the set_pte_at() will restore the tags to the page before the swap entry is removed. The reordering which has happened since has broken this assumption and as you observed can cause the tags to be unavailable by the time set_pte_at() is called. >> After I moved swap_free() to the next line of set_pte_at(), the problem >> is disappeared. >> >> We suspect that the following patches, which have changed the order, do >> not consider the mte tag restoring in page fault flow: >> https://lore.kernel.org/all/20220131162940.210846-5-david@redhat.com/ I'm not sure I entirely follow the reasoning in this patch, so I'm not sure whether it's safe to just move swap_free() down to below set_pte_at() or if that reintroduces the information leak. I also wonder if sparc has a similar issue as the arch_do_swap() callback is located next to set_pte_at(). >> Any suggestion is appreciated. The other possibility is to add a(nother) callback for MTE in arch_do_swap() that calls mte_restore_tags() on the page before the swap_free() call rather than depending on the hook in set_pte_at(). Steve