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 81B05C5479D for ; Mon, 2 Jan 2023 12:29:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD8718E0002; Mon, 2 Jan 2023 07:29:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C87B38E0001; Mon, 2 Jan 2023 07:29:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4F858E0002; Mon, 2 Jan 2023 07:29:44 -0500 (EST) 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 A3C068E0001 for ; Mon, 2 Jan 2023 07:29:44 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6718B80464 for ; Mon, 2 Jan 2023 12:29:44 +0000 (UTC) X-FDA: 80309790288.11.9AD62B0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 52A86100006 for ; Mon, 2 Jan 2023 12:29:42 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VmmbLYxd; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf05.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672662582; 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:dkim-signature; bh=SsQgSClMPCuWXDoBAs08rfcVfM2ikXYgEDtEpVkmjqs=; b=uLkI2/p7v2NItQYVXC5Q5HFcVlKHUAg1a0OHFEwddxrIto/UEzTc+KvX6iBTg49WqXlwXX SS0K6qCS4C9/rOzdKuQqJtRLxCEisWL2obZR04L+5Sqj6QhRO55lq5fQBSJuoByQSL7Gq5 bKT7io9VTI4imKdRB9rfFyj3ZaqD8/g= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VmmbLYxd; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf05.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672662582; a=rsa-sha256; cv=none; b=7bPCZpny/7zFLIDODWdptl3ddaAvdqBelWBEdXodgLlm+X5KOlFC1KZzNXAaVErubL1RL/ /qHQyK1IR1yFhD5536PGPq9HYCY/NxiZj7N0n3kkhKD4xkibXkurM0Hw8Nhv2vXttuLVCI /GP4iPEqgKtQfuu1xuc2sA6sDRpKcJc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672662581; h=from:from: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=SsQgSClMPCuWXDoBAs08rfcVfM2ikXYgEDtEpVkmjqs=; b=VmmbLYxdnGkQtPzn4hbT147b5+kEP+4rfgok0goIpqcqyX+Qtuj2IbeV1p54YWPrCOAKVW T8uobDO8s03pnElcI7S/jgyRklE+2n6bnzE1MoG55nJVOUpBmAoV8TP/scztVqZS0sJKe3 uad8LaXcUnAlj5SUgkjFCb4spdYWUPI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-404-zKHSCAONNn22bwmVPFOegg-1; Mon, 02 Jan 2023 07:29:40 -0500 X-MC-Unique: zKHSCAONNn22bwmVPFOegg-1 Received: by mail-wm1-f70.google.com with SMTP id l9-20020a7bc349000000b003d35aa4ed8eso6306329wmj.0 for ; Mon, 02 Jan 2023 04:29:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SsQgSClMPCuWXDoBAs08rfcVfM2ikXYgEDtEpVkmjqs=; b=k4W7DZ3Zs9ceqcx072PFDecPLXnXKI0JxaLBrQDsmoh33GxqJ7w3E3MVni4uh9odkl o+aZ4jAkNaFpw/0LzDp75nlJZrgN4CD8//BMjuVc/L9/I6vfZFuhwP8yeqc2QrWvXgkM xn9wklRp1c/XStotVOAA9vqwA203jn+i6QZY/8msqr1ytlF5/Yy4j3XtdJdpW5r0/pvH UL9qqZ65FX6mLLGGyBLXalAEiV80LgUjzP3udJ/mM2oFlOw7P2paJ30O38waQT54bmRZ 9Sc8ETLQmlqKja3B9/dW2mvgAiiH1oDgcF+nIICi9VpGWEjHIyvvKgM2rDJifDcMHi6g 7p/A== X-Gm-Message-State: AFqh2koRtJHYJKqpIUpG3ELlKOhcmtdxXkVkS4khmDLS61vvub4i4py8 IUs3WhW89cHgxyZYkFx6Q/JCStAgwPIYX7YORHXB6mU0/jBVCxYa1gyfsTkSoFMwOktPb3As6CM urLCjbA8KQoU= X-Received: by 2002:a5d:4244:0:b0:268:d5af:66dc with SMTP id s4-20020a5d4244000000b00268d5af66dcmr24978214wrr.68.1672662579427; Mon, 02 Jan 2023 04:29:39 -0800 (PST) X-Google-Smtp-Source: AMrXdXu+tTkmy+8dDuXq3ZCkiQC/4wDsyInMKvU7jFQ8qpCPA3OEuu8gZfGHnTqc0LbQHeZkuaJfOg== X-Received: by 2002:a5d:4244:0:b0:268:d5af:66dc with SMTP id s4-20020a5d4244000000b00268d5af66dcmr24978202wrr.68.1672662579114; Mon, 02 Jan 2023 04:29:39 -0800 (PST) Received: from ?IPV6:2003:cb:c703:500:9382:2e5a:fea:8889? (p200300cbc703050093822e5a0fea8889.dip0.t-ipconnect.de. [2003:cb:c703:500:9382:2e5a:fea:8889]) by smtp.gmail.com with ESMTPSA id t18-20020a5d42d2000000b00288a3fd9248sm14298080wrr.91.2023.01.02.04.29.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jan 2023 04:29:38 -0800 (PST) Message-ID: <57f7576b-542b-6ec0-fc5b-5a8c3bed5868@redhat.com> Date: Mon, 2 Jan 2023 13:29:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 To: Muhammad Usama Anjum , Cyrill Gorcunov , Andrew Morton Cc: Nadav Amit , Andrea Arcangeli , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel@collabora.com, Peter Xu , Paul Gofman References: <20220725142048.30450-1-peterx@redhat.com> <20220725142048.30450-2-peterx@redhat.com> <40cc5f89-fa10-e107-671e-84bdcf7a4430@collabora.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v4 1/3] mm/mprotect: Fix soft-dirty check in can_change_pte_writable() In-Reply-To: <40cc5f89-fa10-e107-671e-84bdcf7a4430@collabora.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 52A86100006 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: n6asj155ifiupneuyu5enkgt756tzqqm X-HE-Tag: 1672662582-653647 X-HE-Meta: U2FsdGVkX19mUruoEW/ZlcEw4XXyKPyuXObU+5YtTzc/TdUFz1RYAw6WghGfAdU9eGRE7ehmLf7AX+mz/KfNLa5qOuNPeG7FI6nbjxnxmvOL5C+kmKmi31lcgOVcdcjfj1J3cy/V9W72110ieMX+B5YP5AlTF++JvfrtzwYnRzcIhit5yTIe03uDZhc0sbs5B1Bq/QjltaK24ZG/EoPZOurM0/PEXWMfRcrH8eUZz/olC0kslb7Re68DlUyckCzI7AxagcjqeImZ1uYJHOszphevYbwy69jFyytixxAJajnpK0xBhxiTGUUIsISPQWmJPeK+tAiwfILV7cTleIr/iAg4tT7ArPYIhVhqLeVOj3Kd08KEoaQLU/o9OLV/ephtLq42SiM2YgZJaZUzy8NOgDwyORRdX+PivYWg2EYJPXcEAVeceuOu3nWdoAjzz8FiTHqoz4xt/v5CRlzsP/kyWe5A79iDUKTcyKihNfWc/fuyA7lEjUvN/99BCJ8BlqD3ST5QLoU8pim8erG4c2d2UExEEouxmOrOUT5TcMaGNZLGeUGeQL52Y0Z/VtWS3VkYrxac9XbRKRCi9gWcB1XnLv4NI6HLwcY/GoojlBWn3e+9kcI9fgfp3tnB6tK/Cc1FudWb0tCgqR5BSLzCCwmH1tjI5SU/I04cjCLUc2CaswhLp4AB4RzIwbB4CiNB+uGtrYqeZAkV3glbVHbfFoIiFsIahogMoVPvesyjRKa3U/6FDQAqEo71QBbAt3Dog4CZ2/9pQZqLdChr4QOXewmrdyQmrwq+s58wwKXfOtc1zZvJsNDTzRJbTcMUhTwzdJhEv93uhXbfiFWFCebP6tq1TSmW/6yrh8SjeSr8dSVO25y9J0PQ6BP6vaHKJL2k1dhsdZx2pgBlAnszCVRwJmmLuFpHFj+ddmmVRE4B5cWcW5nzA2JQNTNbT6sAQHkxgzuBbUvlq7SF/jx3Sn3nyxc t9s89Fn4 rpw3DyEBrXzRAfLvsOlbAzkxcVCZeLb79OcZG8yHNdD+rwXtOkhukNtudZdw2WmFU764PLX/OHsABqNRt2JN9MUtBi+caUSyYMIKJYJkHhrBZwIEuW2NJHFBoqkTuaitYjoUrskusTzJ9uNjoaOJyAPnxDMFsplLu42g9WNbq3hgNytTiDwVGAkHGDZBUxySYeLc9exj6poq5Rg/Wlt1UoAutHBRkpkO6juv8A6/yoGTlGeOnTz3ijafSaVbZ3vVIED2jzBUPgy57jlM= 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 28.12.22 15:14, Muhammad Usama Anjum wrote: > On 12/19/22 5:19 PM, Muhammad Usama Anjum wrote: >> Addition of vma_soft_dirty_enabled() has tinkered with the soft-dirty PTE >> bit status setting. The internal behavior has changed. The test case was >> shared by David >> (https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@redhat.com/). >> The explanation is as following: >> >> _Before_ addition of this patch(76aefad628aae), >> m = mmap(2 pages) >> clear_softdirty() >> mremap(m + pag_size) >> mprotect(READ) >> mprotect(READ | WRITE); >> memset(m) >> After memset(), >> PAGE-1 PAGE-2 >> VM_SOFTDIRTY set set >> PTE softdirty flag set set >> /proc//pagemap view set set >> >> >> _After_ addition of this patch(76aefad628aae) >> m = mmap(2 pages) >> clear_softdirty() >> mremap(m + page_size) >> mprotect(READ) >> mprotect(READ | WRITE); >> memset(m) >> After memset(), >> PAGE-1 PAGE-2 >> VM_SOFTDIRTY set set >> PTE softdirty flag *not set* set >> /proc//pagemap view set set >> >> The user's point of view hasn't changed. But internally after this patch, >> the soft-dirty tracking in PTEs gets turn off if VM_SOFTDIRTY is set. The >> soft-dirty tracking in the PTEs shouldn't be just turned off when mprotect >> is used. Why? Because soft-dirty tracking in the PTEs is always enabled >> regardless of VM_SOFTDIRTY is set or not. Example: >> >> m = mem(2 pages) >> At this point: >> PAGE-1 PAGE-2 >> VM_SOFTDIRTY set set >> PTE softdirty flag not set not set >> /proc//pagemap view set set >> memset(m) >> At this point: >> PAGE-1 PAGE-2 >> VM_SOFTDIRTY set set >> PTE softdirty flag set set >> /proc//pagemap view set set >> >> This example proves that soft-dirty flag on the PTE is set regardless of >> the VM_SOFTDIRTY. > > Hi Andrew and Cyrill, > > Peter doesn't agree with me here that this change in behavior should be > reverted etc. Please comment. For the records, I agree with Peter: As 76aefad628aa ("mm/mprotect: fix soft-dirty check in can_change_pte_writable()") documents, this patch fixed real problems. /proc/pagemap works as expected right now such that we don't have an under-indication. Internal representation is an implementation detail. Whatever we do, there must not be an under-indication of softdirty. That is the ABI guaranteed (especially for anonymous memory). "No over-indication" was never the ABI guarantee. For your use case, you want to reduce over-indication. I suggested looked into alternatives. -- Thanks, David / dhildenb