From: David Hildenbrand <david@redhat.com>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org,
linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
Russell King <linux@armlinux.org.uk>,
Masami Hiramatsu <mhiramat@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
"Liang, Kan" <kan.liang@linux.intel.com>,
Tong Tiangen <tongtiangen@huawei.com>
Subject: Re: [PATCH v3 3/3] kernel/events/uprobes: uprobe_write_opcode() rewrite
Date: Fri, 21 Mar 2025 14:17:12 +0100 [thread overview]
Message-ID: <69256f08-1d1c-45ac-945a-495ef4ffc558@redhat.com> (raw)
In-Reply-To: <Z91j_UwNhi2DQB3N@krava>
On 21.03.25 14:05, Jiri Olsa wrote:
> On Fri, Mar 21, 2025 at 12:37:13PM +0100, David Hildenbrand wrote:
>
> SNIP
>
>> +static int __uprobe_write_opcode(struct vm_area_struct *vma,
>> + struct folio_walk *fw, struct folio *folio,
>> + unsigned long opcode_vaddr, uprobe_opcode_t opcode)
>> +{
>> + const unsigned long vaddr = opcode_vaddr & PAGE_MASK;
>> + const bool is_register = !!is_swbp_insn(&opcode);
>> + bool pmd_mappable;
>> +
>> + /* For now, we'll only handle PTE-mapped folios. */
>> + if (fw->level != FW_LEVEL_PTE)
>> + return -EFAULT;
>> +
>> + /*
>> + * See can_follow_write_pte(): we'd actually prefer a writable PTE here,
>> + * but the VMA might not be writable.
>> + */
>> + if (!pte_write(fw->pte)) {
>> + if (!PageAnonExclusive(fw->page))
>> + return -EFAULT;
>> + if (unlikely(userfaultfd_pte_wp(vma, fw->pte)))
>> + return -EFAULT;
>> + /* SOFTDIRTY is handled via pte_mkdirty() below. */
>> + }
>> +
>> + /*
>> + * We'll temporarily unmap the page and flush the TLB, such that we can
>> + * modify the page atomically.
>> + */
>> + flush_cache_page(vma, vaddr, pte_pfn(fw->pte));
>> + fw->pte = ptep_clear_flush(vma, vaddr, fw->ptep);
>> + copy_to_page(fw->page, opcode_vaddr, &opcode, UPROBE_SWBP_INSN_SIZE);
>> +
>> + /*
>> + * When unregistering, we may only zap a PTE if uffd is disabled and
>> + * there are no unexpected folio references ...
>> + */
>> + if (is_register || userfaultfd_missing(vma) ||
>> + (folio_ref_count(folio) != folio_mapcount(folio) + 1 +
>> + folio_test_swapcache(folio) * folio_nr_pages(folio)))
>> + goto remap;
>> +
>> + /*
>> + * ... and the mapped page is identical to the original page that
>> + * would get faulted in on next access.
>> + */
>> + if (!orig_page_is_identical(vma, vaddr, fw->page, &pmd_mappable))
>> + goto remap;
>> +
>> + dec_mm_counter(vma->vm_mm, MM_ANONPAGES);
>> + folio_remove_rmap_pte(folio, fw->page, vma);
>> + if (!folio_mapped(folio) && folio_test_swapcache(folio) &&
>> + folio_trylock(folio)) {
>> + folio_free_swap(folio);
>> + folio_unlock(folio);
>> + }
>> + folio_put(folio);
>
> hi,
> it's probably ok and I'm missing something, but why do we call folio_put
> in here, I'd think it's done by folio_put call in uprobe_write_opcode
Hi!
We're zapping a page table mapping mapping (folio_remove_rmap_pte()), so
we have to drop that reference.
That's the folio_put(old_folio) in the old __replace_page().
Thanks!
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-03-21 13:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 11:37 [PATCH v3 0/3] kernel/events/uprobes: uprobe_write_opcode() rewrite David Hildenbrand
2025-03-21 11:37 ` [PATCH v3 1/3] kernel/events/uprobes: pass VMA instead of MM to remove_breakpoint() David Hildenbrand
2025-03-21 11:37 ` [PATCH v3 2/3] kernel/events/uprobes: pass VMA to set_swbp(), set_orig_insn() and uprobe_write_opcode() David Hildenbrand
2025-03-21 11:37 ` [PATCH v3 3/3] kernel/events/uprobes: uprobe_write_opcode() rewrite David Hildenbrand
2025-03-21 13:05 ` Jiri Olsa
2025-03-21 13:17 ` David Hildenbrand [this message]
2025-03-21 13:34 ` [PATCH v3 0/3] " Oleg Nesterov
2025-03-25 10:53 ` Peter Zijlstra
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=69256f08-1d1c-45ac-945a-495ef4ffc558@redhat.com \
--to=david@redhat.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrii.nakryiko@gmail.com \
--cc=irogers@google.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=olsajiri@gmail.com \
--cc=peterz@infradead.org \
--cc=tongtiangen@huawei.com \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).