public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Walker (danielwa)" <danielwa@cisco.com>
To: Jann Horn <jannh@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
	"David Hildenbrand (Arm)" <david@kernel.org>,
	"Darko Tominac -X (dtominac - GLOBALLOGIC INC at Cisco)"
	<dtominac@cisco.com>, Masami Hiramatsu <mhiramat@kernel.org>,
	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>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	"xe-linux-external(mailer list)" <xe-linux-external@cisco.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-trace-kernel@vger.kernel.org"
	<linux-trace-kernel@vger.kernel.org>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] mm/madvise: preserve uprobe breakpoints across MADV_DONTNEED
Date: Thu, 30 Apr 2026 19:25:58 +0000	[thread overview]
Message-ID: <afOsxsC6MKhkuqKD@goliath> (raw)
In-Reply-To: <CAG48ez0mwkHz=4+PoLv_VmYrQiPqkSQqCSo=3R-ztrQ2zAHUwQ@mail.gmail.com>

On Thu, Apr 30, 2026 at 05:22:18PM +0200, Jann Horn wrote:
> On Wed, Apr 29, 2026 at 11:11 PM Daniel Walker (danielwa)
> <danielwa@cisco.com> wrote:
> > On Wed, Apr 29, 2026 at 05:24:25PM +0200, Oleg Nesterov wrote:
> > > On 04/29, David Hildenbrand (Arm) wrote:
> > > >
> > > > On 4/29/26 15:15, Darko Tominac wrote:
> > > >
> > > > > uprobe infrastructure does not re-instrument pages on individual page
> > > > > faults (uprobe_mmap() is only called during VMA creation, not on
> > > > > page-in), the breakpoints are silently lost once the discarded pages are
> > > > > re-read from the backing file.  The probes stop firing with no error
> > > > > indication, and the only recovery is to unregister and re-register the
> > > > > affected uprobes.
> > > >
> > > > Right. Don't MADV_DONTNEED uprobes, just like you are not supposed to
> > > > MADV_DONTNEED debugger breakpoints/set data etc. :)
> > >
> > > Agreed, thanks.
> >
> >
> > Shouldn't there be some sort of compensation or notification for this, or is each person that
> > hits this suppose to just scratch their head and send a patch that's rejected?
> 
> I guess we could add a pr_warn_once() that warns when
> madvise(MADV_DONTNEED) is called on a read+execute file mapping,
> and/or (as David said) add an explicit note in the madvise() manpage
> about how that can interfere with software breakpoints and uprobes?

It does feel like it's the debuggers problem. The application doesn't know it's
getting debugged. So the application does whatever it does. If GDB is debugging
an application it should assume there's a problematic madvise() call which will
hurt/stop the debugging from happening. It should endeavor to prevent that
from happening. There are options in userspace to prevent it from happening. I'm
sure madvise() is not the only thing GDB has to worry about w.r.t. screwing up
the debugging.

Noting it in the man page seems reasonable.

Daniel

      reply	other threads:[~2026-04-30 19:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29 13:15 [PATCH] mm/madvise: preserve uprobe breakpoints across MADV_DONTNEED Darko Tominac
2026-04-29 13:31 ` David Hildenbrand (Arm)
2026-04-29 15:24   ` Oleg Nesterov
2026-04-29 21:11     ` Daniel Walker (danielwa)
2026-04-30  9:16       ` Oleg Nesterov
2026-04-30  9:54         ` David Hildenbrand (Arm)
2026-04-30 18:46           ` Oleg Nesterov
2026-04-30 19:11             ` Jann Horn
2026-04-30 15:22       ` Jann Horn
2026-04-30 19:25         ` Daniel Walker (danielwa) [this message]

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=afOsxsC6MKhkuqKD@goliath \
    --to=danielwa@cisco.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=david@kernel.org \
    --cc=dtominac@cisco.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jannh@google.com \
    --cc=jolsa@kernel.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=ljs@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=vbabka@kernel.org \
    --cc=xe-linux-external@cisco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox