All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm <linux-mm@kvack.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>,
	 Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	 upstream+pagemap <upstream+pagemap@sigma-star.at>,
	 adobriyan <adobriyan@gmail.com>,
	 wangkefeng wang <wangkefeng.wang@huawei.com>,
	 ryan roberts <ryan.roberts@arm.com>, hughd <hughd@google.com>,
	 peterx <peterx@redhat.com>, avagin <avagin@google.com>,
	 lstoakes <lstoakes@gmail.com>, vbabka <vbabka@suse.cz>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 usama anjum <usama.anjum@collabora.com>,
	 Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable
Date: Thu, 7 Mar 2024 15:42:49 +0100 (CET)	[thread overview]
Message-ID: <2055158015.23529.1709822569814.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <a73c78be-8cdc-4f0e-b72f-e5255c906a5f@redhat.com>

----- Ursprüngliche Mail -----
> Von: "David Hildenbrand" <david@redhat.com>
>> One destructive way to find out in a writable mapping if the page would
>> actually get remapped:
>> 
>> 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
>> 
>> 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 such.
 
>> 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 thread
had the CPU.
My idea was having a tool to check before the applications enters the critical phase.

>>> I fully understand that my use case is a corner case and anything but mainline.
>>> While developing my debug tool I thought that improving the pagemap interface
>>> might help others too.
>> 
>> 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. :)
 
> 
> [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() implementations.
That's a tradeoff I can live with.

Thanks,
//richard

  reply	other threads:[~2024-03-07 14:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 23:23 [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable Richard Weinberger
2024-03-06 23:23 ` [PATCH 2/2] [RFC] pagemap.rst: Document write bit Richard Weinberger
2024-03-07 10:52   ` David Hildenbrand
2024-03-07 11:10     ` Richard Weinberger
2024-03-07 11:15       ` David Hildenbrand
2024-03-10 22:14   ` Lorenzo Stoakes
2024-03-07 10:44 ` [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable Muhammad Usama Anjum
2024-03-07 10:52 ` David Hildenbrand
2024-03-07 11:10   ` Richard Weinberger
2024-03-07 11:20     ` David Hildenbrand
2024-03-07 11:51       ` Richard Weinberger
2024-03-07 11:59         ` David Hildenbrand
2024-03-07 12:09           ` David Hildenbrand
2024-03-07 14:42             ` Richard Weinberger [this message]
2024-03-10 21:55 ` Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2055158015.23529.1709822569814.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@google.com \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=peterx@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=upstream+pagemap@sigma-star.at \
    --cc=usama.anjum@collabora.com \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.