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 EE6E1C369C2 for ; Fri, 25 Apr 2025 20:46:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D241E6B0005; Fri, 25 Apr 2025 16:46:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD2D96B0007; Fri, 25 Apr 2025 16:46:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B98F16B0008; Fri, 25 Apr 2025 16:46:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9CCEB6B0005 for ; Fri, 25 Apr 2025 16:46:20 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D96665C589 for ; Fri, 25 Apr 2025 20:46:21 +0000 (UTC) X-FDA: 83373748962.25.6C19FF9 Received: from bitwagon.com (bitwagon.com [74.82.39.175]) by imf07.hostedemail.com (Postfix) with ESMTP id 1A9024000F for ; Fri, 25 Apr 2025 20:46:19 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of jreiser@bitwagon.com designates 74.82.39.175 as permitted sender) smtp.mailfrom=jreiser@bitwagon.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745613980; 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=LPaBZYYAS6ItbRI0GgY7+LqunqwPKYMBn02m122UFmc=; b=lYRIxnOR7t/+2WTSkDNCrty+qVnRbaQvum7ZNBLdPCAaJiq1dW0+3xY6YC8yYkmKi0MyKl ZmBhprUBG3nm+YY85IB61BivK6vMe2eggFop3isqj9G+vbl0njKS0N73GCxvc9GcrhqsaK zv64m7fSRK3lprSzzczO9JmWind+sQk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of jreiser@bitwagon.com designates 74.82.39.175 as permitted sender) smtp.mailfrom=jreiser@bitwagon.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745613980; a=rsa-sha256; cv=none; b=NKESEAhl/AtK5CH9dZA8aBw2t6y673fDv8vuSvlxX6JCTjiYtbLVsuAMRTpbGYZohunv6K LBYeO+Z5t1vn8TjT/y+PCfc6Z1V7nY1XwHdLuWWnHBFKP+LwBm1pJ0p4RWdkySnKyL5Wye dazmLLd59Cjtv7j0WpE0W7OouC/omU8= Received: from 97.115.108.223 (97-115-108-223.ptld.qwest.net [97.115.108.223]) by bitwagon.com with ESMTPSA (TLS_AES_128_GCM_SHA256:TLSv1.3:Kx=any:Au=any:Enc=AESGCM(128):Mac=AEAD) (SMTP-AUTH username jreiser@bitwagon.com, mechanism PLAIN) for ; Fri, 25 Apr 2025 13:46:13 -0700 Message-ID: <02a0b963-0057-4292-ba14-642c1647a600@bitwagon.com> Date: Fri, 25 Apr 2025 13:45:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: John Reiser Subject: Re: msync() seems not to clean the data cache To: Matthew Wilcox Cc: linux-mm@kvack.org References: <9a70a70d-9dce-46a0-997e-b8a346e60902@bitwagon.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: y6awh4zz3b83n4qf3xur18pp1kt6a5wg X-Rspamd-Queue-Id: 1A9024000F X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1745613979-172599 X-HE-Meta: U2FsdGVkX1/WOJdieOiaULeAHuqKiV147JvQZDE2n5cInt5QfxwATPsSg4WF489hf836l6ZsilHGl9EPDKZKQH7W32Yfo/GvWNU0Bhf+QMExErasiy5m8y2YKnvpubTyRuNaeqJsi5Qx6xOHNFZ6IuxsfAfpyZAf9TupAK82ypDgiDiJu6sPMMkTMROVz3/jXxz7UiZ3uAdZVmd4SIp6nwyLXfqwG/tXVQoaXMPTkLR+wXFsVmCDylnEncpy/aL5Fcy8Jmt5bp16UwMjn/yUxp1pTvjd2oXl57lAUSEatzcTGldH1y8lzZxtZiV5uX+U2nrRwSJ/rRGRofiK5RKX7OGvPKwOc292C7gg6gSsimbmz4wofyK3pz35Cob4xlZcqbw4jmemftZr9eH0gNG7fSy3yA1etDwtRL9/b2CjwjcMz+i7qXveMlfEwtwd9pvzTrSs2jtiOdn9JmwWspg8bPjjZMUyov15J703x7+BMxJw5dbocDIPAOWVDiqK+IlQCdgGCTdZbE9ty87I07AvTzQujtpGiInxFrOyaex0lIIEwK2LKCuZhOaBw8XujxIMIoRMpIV44+UNe5/4VZI1mGBjTmO80ptauiuSj4i3qSYltCHh3UQk039/x+5evsP9X8CakSuw4y63aO07VN/PyrzFA4ts7jWx0/2HO7POr9DHwktJQh2wGLlp0LmGg4v8lRWYi6AWavNoX2Z3VmGPs6yGrcrVEZyqSzl2meWvgOn5p3KNyfJ2X/h+tYy3xzkgbkzqYZAhsuVLnw9QObobfJWi3xyzHMPSz/KSTHTj/MGeNS2dOM5WyN5HCIpbDeCe4neoOOwSMbz5s7RpVFibvMEwkqOAcyGkQNa4pC5FB1qxlou1RXioNGsvBCI+UcPwwMCzbdyz3osAi4XgOeTdjSBYr86Z3LjAdkDPDxCt5pNINGVfIj3Qlmy426QmxmabwwWRYVn7hF5nGtZ+hbz iSJIxexw rhJSWbcYgFYb4xnhsM4qAGTIMCIjHQA22WxDXo2gy3sTneSxGjE58+uu97LPjQWYhjdiQJTVCEwxRgsrCvYNJ9/V7hUmDmegXj4fvPLLoe+gk/PDroborDLFHxNAO7E3MDg6QlzJ5vU/9E9b0RZkbAPyxJIIqL5D2m8FtzaYpavqEM7lAF6jLJU84F0N9nPsyy08d+k1E8tjnuFWNr87rQLx5RMJEtYgW+gM3 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: List-Subscribe: List-Unsubscribe: On 4/25/25 12:31 PM, Matthew Wilcox wrote: > On Fri, Apr 25, 2025 at 12:17:37PM -0700, John Reiser wrote: >> The system call write() cleans the hardware data cache (writes any dirty >> values from the data cache into RAM memory) before passing to the VFS >> the region to be written. The system call msync() should do likewise. >> Currently msync() does not clean the hardware data cache, as seen on >> PowerPC, PowerPC64, and arm64; and probably any CPU that does not >> have a Write-through cache. (x86 and x86_64 do have write-through.) > > I think you're right; we don't flush before writeback. Does this > fix your problem? > > +++ b/mm/page-writeback.c > @@ -2432,6 +2432,7 @@ static bool folio_prepare_writeback(struct address_space *mapping, > if (!folio_clear_dirty_for_io(folio)) > return false; > > + flush_dcache_folio(folio); > return true; > } > > It looks promising, but I got lost tracing the logic by hand, especially for my seven $ARCH. Building and testing will take a while. The context is UPX support for Enforcing mode of SELinux, as outlined: fd = memfd_create("upx", MFD_EXEC); ftruncate(fd, length); maddr = mmap(0, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); decompress(maddr, length, compressed_input); msync(maddr, length); // fd was losing random data here munmap(maddr, length); // paranoia over VMA "hangover" maddr2 = mmap(maddr, length, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_FIXED, fd, 0); See bug report at https://github.com/upx/upx/issues/907 . Meanwhile explicit user-mode cache cleaning (using $ARCH-dependent system call, or hand code, or heuristics) is necessary because of the inertia of many many installed Linux instances.