[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJHvVciAMt_PJ=V-q8_7X02cQmor3wVCTMKbpSQ9UhpnwFAa1A@mail.gmail.com>
Date: Tue, 11 May 2021 15:24:03 -0700
From: Axel Rasmussen <axelrasmussen@...gle.com>
To: "Robert O'Callahan" <roc@...nos.co>
Cc: Andrea Arcangeli <aarcange@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Hugh Dickins <hughd@...gle.com>, Peter Xu <peterx@...hat.com>,
Ingo Molnar <mingo@...hat.com>, Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>, Kyle Huey <khuey@...nos.co>
Subject: Re: Userspace notifications for observing userfaultfd faults
On Tue, May 11, 2021 at 3:15 PM Robert O'Callahan <roc@...nos.co> wrote:
>
> On Wed, May 12, 2021 at 6:12 AM Axel Rasmussen <axelrasmussen@...gle.com> wrote:
> > Is some combination of bpf and kprobes a possible solution? There are
> > some seemingly relevant examples here:
> > https://github.com/iovisor/bpftrace/blob/master/docs/tutorial_one_liners.md
> >
> > I haven't tried it, but it seems like attaching to handle_userfault()
> > would give similar information to perf_count_sw_page_faults, but for
> > userfaults.
>
> That would probably work in some cases, but as Kyle said that requires
> privileges and currently rr can run unprivileged (if you set
> perf_event_paranoid to 1 or less) and usually does. Also, AFAIK,
> kprobing handle_userfault would not be a stable ABI.
True, it would not be a stable ABI. That could be solved by adding a
real tracepoint, instead of just relying on a kprobe on a particular
function. But, I don't think that solves the concern around
permissions.
I am no expert on perf_count_sw_page_faults and similar, so I'll leave
it up to others to give an opinion on extending that.
>
> Rob
Powered by blists - more mailing lists