Received: by 2002:ab2:788f:0:b0:1ee:8f2e:70ae with SMTP id b15csp606208lqi; Thu, 7 Mar 2024 06:43:11 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVLBwtAf0BVcNJ98U4k838Y8SltfgBVmtRQuQ2SazL+mbBRsNMZg4m6ebIGQXV3KeVD4l79shMbmSXGrifhm/aR0ZicsovHjtb2W8GIzA== X-Google-Smtp-Source: AGHT+IEnasRFXT/sLgBsl4itI9YcdXBIX+lEbOg+t8Kp+czIM50jRwnT+FM7WfkNEULdKK99d+7I X-Received: by 2002:ad4:5a0f:0:b0:690:5745:5b49 with SMTP id ei15-20020ad45a0f000000b0069057455b49mr7199631qvb.11.1709822590897; Thu, 07 Mar 2024 06:43:10 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709822590; cv=pass; d=google.com; s=arc-20160816; b=xlA7n77eSXdzX0G6O8V1K84rtPJhJz8IJrT2cgWMVYSa9rQN2qw4VZKtLJDF93+3a1 NfgsI6tPlL+quOnV/5pRnEa9QykBJbDgqA56U0eeAAYj5Pl5I5T/XPicEeAQhR9gAkBM R0IYTrXtAmloMs0NL3gGWCJwQAjCxNBHZwi/fv7TYI4rFyDFD/gKAzRv3RwDVjLiEI+3 q51Thu2Zdn7Oi50OYFXQM2wMxpASPsIe1TDuvMd+sopoWa+y597GgGbtUXVWE8RByhVm q7j06h9UjgfpjYn5Or3MV37CtVO/l61FHJZvkNcAkSA0vqtLV0/ds1T4oIAW2fHvki/2 vrMA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=thread-index:thread-topic:content-transfer-encoding:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:subject :references:in-reply-to:message-id:cc:to:from:date; bh=Hriwqv1VafwSnAEQgWhG3BftPtOdGMoUT9XyeEe3nbQ=; fh=NbQL9aypssUAPqYRWwU2IsPGjFey30rgkoE3g8G6t9o=; b=IwfiqX4ZtzCnSXDwjZpGWjpE7UJX59NMlqtaODPLDJd69Gp9u+WrlpET3NCfQJJ+Gz I5itXRRoJKJ8QPdvmcueaIA84ohZwL09IdFt88Ql1oOFrHKjtzyGr8iHojw6yEex8LHz Z8RGid4rABS2Ug7wmHL1jkc4GnP5drpkoJwqtxf4zKjV2gfqYdftuYuOqp6EwnJ+SdHz /Chkm3B8Cqpb1KbqhaVuOqjgfPo1BrKBV18BdH4nhFuxKj/NLZMha9tIOmezOX2bhW5E wJunGthGBRxzx2jVU2Y4sDTp+jBcD/9rA0HqWbhVtq8AQVFe5hJ2JgQGe+2rzIfEaSsv 9kAQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-95758-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-95758-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id js5-20020a0562142aa500b0068fdddee980si16552732qvb.576.2024.03.07.06.43.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 06:43:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-95758-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-95758-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-95758-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 9CCD81C21DB1 for ; Thu, 7 Mar 2024 14:43:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 43F6112AAE3; Thu, 7 Mar 2024 14:42:57 +0000 (UTC) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41E5A1B94D; Thu, 7 Mar 2024 14:42:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.201.40.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709822576; cv=none; b=aRDVNX3o4agt4JmMBYLYAzj+MDpZqHQ8QoW++ZVF8wi9xBmDwAHmjSxQ4YBY8DpXFbs/ZynAswfbXA9N0XpeaUer6gLUJYPlZnkcL+uNK1LDZVM7tKF7KRlixeNaq8ZKpKxXC9+J8E+oE6wZ+1xCWfCI907c0l7xMXmlCGuEqDw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709822576; c=relaxed/simple; bh=Hriwqv1VafwSnAEQgWhG3BftPtOdGMoUT9XyeEe3nbQ=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=JPtZKRfQuQlJQbNPs930+AteCp/FadmERLyZHcNx4sHzxLiVPQ9BW8HyE8+VnkztBqh07Xv9j2zsLTG5XzZ9tjSIqm+oPCPCWtVs/m33UNDMbLiAHkarR5nnLCFPt04esQL4BWL7vfU50zIZAcdA8nFApxPojmUpsoAptRh2rb4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at; spf=fail smtp.mailfrom=nod.at; arc=none smtp.client-ip=195.201.40.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nod.at Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id DAC1B644CE97; Thu, 7 Mar 2024 15:42:50 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CIhG1qGm-RNL; Thu, 7 Mar 2024 15:42:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 58EF0644CE96; Thu, 7 Mar 2024 15:42:50 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7EDauf2v-cth; Thu, 7 Mar 2024 15:42:50 +0100 (CET) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 1DE0A644CE90; Thu, 7 Mar 2024 15:42:50 +0100 (CET) Date: Thu, 7 Mar 2024 15:42:49 +0100 (CET) From: Richard Weinberger To: David Hildenbrand Cc: linux-mm , linux-fsdevel , linux-kernel , Linux Doc Mailing List , upstream+pagemap , adobriyan , wangkefeng wang , ryan roberts , hughd , peterx , avagin , lstoakes , vbabka , Andrew Morton , usama anjum , Jonathan Corbet Message-ID: <2055158015.23529.1709822569814.JavaMail.zimbra@nod.at> In-Reply-To: References: <20240306232339.29659-1-richard@nod.at> <1058679077.23275.1709809843605.JavaMail.zimbra@nod.at> <7d9321db-a3c1-4593-91fa-c7f97bd9eecd@redhat.com> <1525238492.23321.1709812267495.JavaMail.zimbra@nod.at> <0644814b-869b-4694-bdb1-bab4e6186136@redhat.com> Subject: Re: [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF97 (Linux)/8.8.12_GA_3809) Thread-Topic: proc: pagemap: Expose whether a PTE is writable Thread-Index: ALtl01Wd8Zr0Arr/iwJcm8Sl/cTDKQ== ----- Urspr=C3=BCngliche Mail ----- > Von: "David Hildenbrand" >> One destructive way to find out in a writable mapping if the page would >> actually get remapped: >>=20 >> a) Read the PFN of a virtual address using pagemap >> b) Write to the virtual address using /proc/pid/mem >> c) Read the PFN of a virtual address using pagemap to see if it changed >>=20 >> If the application can be paused, you could read+write a single byte, >> turning it non-destructive. I'm not so sure whether this works well if a mapping is device memory or su= ch. =20 >> But that would still "hide" the remap-writable-type faults. Xenomai will tell me anyway when there was a page fault while a real time t= hread had the CPU. My idea was having a tool to check before the applications enters the criti= cal phase. >>> I fully understand that my use case is a corner case and anything but m= ainline. >>> While developing my debug tool I thought that improving the pagemap int= erface >>> might help others too. >>=20 >> I'm fine with this (can be a helpful debugging tool for some other cases >> as well, and IIRC we don't have another interface to introspect this), >> as long as we properly document the corner case that there could still >> be writefaults on some architectures when the page would not be >> accessed/dirty yet. Cool. :) =20 >=20 > [and I just recall, there are some other corner cases. For example, > pages in a shadow stack can be pte_write(), but they can only be written > by HW indirectly when modifying the stack, and ordinary write access > would still fault] Yeah, I noticed this while browsing through various pte_write() implementat= ions. That's a tradeoff I can live with. Thanks, //richard