On Thu, Feb 04, 2021 at 02:35:36PM +0100, Dmitry Vyukov wrote:
> I meant that we could restrict synchronous SIGTRAP for (1)
> perf_event_open(pid != 0) and (2) disable it after exec.
Hmm, I think I finally get what you're after. And yes, multi-process or
fork() based thingies are common and might
On Thu, Feb 04, 2021 at 02:35:36PM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 4, 2021 at 2:10 PM Peter Zijlstra wrote:
> >
> > On Thu, Feb 04, 2021 at 01:53:59PM +0100, Dmitry Vyukov wrote:
> > > Humm... I was thinking of perf_event_open(pid == 0).
> > > It does not make sense to send SIGTRAP in a
On Thu, Feb 4, 2021 at 2:33 PM Peter Zijlstra wrote:
>
> On Thu, Feb 04, 2021 at 01:53:59PM +0100, Dmitry Vyukov wrote:
> > On Thu, Feb 4, 2021 at 1:09 PM Peter Zijlstra wrote:
>
> > > What do we do then? The advantage of IOC_REFRESH is that it disables the
> > > event until it gets explicitly re
On Thu, Feb 4, 2021 at 2:10 PM Peter Zijlstra wrote:
>
> On Thu, Feb 04, 2021 at 01:53:59PM +0100, Dmitry Vyukov wrote:
> > Humm... I was thinking of perf_event_open(pid == 0).
> > It does not make sense to send SIGTRAP in a remote process, because it
> > does not necessarily cooperate with us.
>
On Thu, Feb 04, 2021 at 01:53:59PM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 4, 2021 at 1:09 PM Peter Zijlstra wrote:
> > What do we do then? The advantage of IOC_REFRESH is that it disables the
> > event until it gets explicitly re-armed, avoiding recursion issues etc.
> > Do you want those sema
On Thu, Feb 04, 2021 at 01:53:59PM +0100, Dmitry Vyukov wrote:
> Humm... I was thinking of perf_event_open(pid == 0).
> It does not make sense to send SIGTRAP in a remote process, because it
> does not necessarily cooperate with us.
>
> But is there any problem with clone w/o CLONE_THREAD? Assumin
On Thu, Feb 04, 2021 at 01:09:13PM +0100, Peter Zijlstra wrote:
> And I need to dig into that fcntl() crud again, see if that's capable of
> doing a SIGTRAP and if it's possible to target that to the task raising
> it, instead of doing a process wide signal delivery.
Hmm, so it might be possible
On Thu, Feb 4, 2021 at 1:09 PM Peter Zijlstra wrote:
>
> On Thu, Feb 04, 2021 at 10:54:42AM +0100, Dmitry Vyukov wrote:
> > On Thu, Feb 4, 2021 at 10:39 AM Peter Zijlstra wrote:
>
> > > OTOH, we're using ptrace permission checks, and ptrace() can inject
> > > signals just fine. But it's a fairly
On Thu, Feb 04, 2021 at 10:54:42AM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 4, 2021 at 10:39 AM Peter Zijlstra wrote:
> > OTOH, we're using ptrace permission checks, and ptrace() can inject
> > signals just fine. But it's a fairly big departure from what perf set
> > out to be.
>
> Oh, I see, I
On Thu, Feb 4, 2021 at 10:39 AM Peter Zijlstra wrote:
>
> On Thu, Feb 04, 2021 at 09:10:11AM +0100, Dmitry Vyukov wrote:
> > On Wed, Feb 3, 2021 at 2:37 PM Peter Zijlstra wrote:
>
> > > Letting perf send a signal to the monitored task is intrusive.. let me
> > > think on that.
> >
> > I was think
On Thu, Feb 04, 2021 at 09:10:11AM +0100, Dmitry Vyukov wrote:
> On Wed, Feb 3, 2021 at 2:37 PM Peter Zijlstra wrote:
> > Letting perf send a signal to the monitored task is intrusive.. let me
> > think on that.
>
> I was thinking of something very similar to that bpf_send_signal that
> delays s
On Wed, Feb 3, 2021 at 6:38 AM Namhyung Kim wrote:
>
> Hello,
>
> On Sun, Jan 31, 2021 at 7:28 PM Dmitry Vyukov wrote:
> > Not directly related to the above question, but related to my use case.
> > Could we extend bpf_perf_event_data with some more data re breakpoint
> > events?
> >
> > struct
On Wed, Feb 3, 2021 at 2:37 PM Peter Zijlstra wrote:
>
> On Wed, Feb 03, 2021 at 01:49:56PM +0100, Dmitry Vyukov wrote:
> > On Wed, Feb 3, 2021 at 1:29 PM Peter Zijlstra wrote:
> > >
> > > On Mon, Feb 01, 2021 at 09:50:20AM +0100, Dmitry Vyukov wrote:
> > > > Or, alternatively would it be reasona
On Wed, Feb 03, 2021 at 01:49:56PM +0100, Dmitry Vyukov wrote:
> On Wed, Feb 3, 2021 at 1:29 PM Peter Zijlstra wrote:
> >
> > On Mon, Feb 01, 2021 at 09:50:20AM +0100, Dmitry Vyukov wrote:
> > > Or, alternatively would it be reasonable for perf to generate SIGTRAP
> > > directly on watchpoint hit
On Wed, Feb 3, 2021 at 1:49 PM Dmitry Vyukov wrote:
>
> On Wed, Feb 3, 2021 at 1:29 PM Peter Zijlstra wrote:
> >
> > On Mon, Feb 01, 2021 at 09:50:20AM +0100, Dmitry Vyukov wrote:
> > > Or, alternatively would it be reasonable for perf to generate SIGTRAP
> > > directly on watchpoint hit (like pt
On Wed, Feb 3, 2021 at 1:29 PM Peter Zijlstra wrote:
>
> On Mon, Feb 01, 2021 at 09:50:20AM +0100, Dmitry Vyukov wrote:
> > Or, alternatively would it be reasonable for perf to generate SIGTRAP
> > directly on watchpoint hit (like ptrace does)? That's what I am
> > ultimately trying to do by attac
On Mon, Feb 01, 2021 at 09:50:20AM +0100, Dmitry Vyukov wrote:
> Or, alternatively would it be reasonable for perf to generate SIGTRAP
> directly on watchpoint hit (like ptrace does)? That's what I am
> ultimately trying to do by attaching a bpf program.
Perf should be able to generate signals, Th
On Sun, Jan 31, 2021 at 11:04:43AM +0100, Dmitry Vyukov wrote:
> PERF_EVENT_IOC_{ENABLE,DISABLE} work as advertised.
> However, PERF_EVENT_IOC_MODIFY_ATTRIBUTES does not work for inherited
> child events.
> Does something like this make any sense to you? Are you willing to
> accept such change?
>
Hello,
On Sun, Jan 31, 2021 at 7:28 PM Dmitry Vyukov wrote:
> Not directly related to the above question, but related to my use case.
> Could we extend bpf_perf_event_data with some more data re breakpoint events?
>
> struct bpf_perf_event_data {
> bpf_user_pt_regs_t regs;
> __u64 sample_
On Sun, Jan 31, 2021 at 11:28 AM Dmitry Vyukov wrote:
>
> On Sun, Jan 31, 2021 at 11:04 AM Dmitry Vyukov wrote:
> >
> > On Thu, Nov 12, 2020 at 11:43 AM Dmitry Vyukov wrote:
> > > > > for sampling race detection),
> > > > > number of threads in the process can be up to, say, ~~10K and the
> > >
On Sun, Jan 31, 2021 at 11:04 AM Dmitry Vyukov wrote:
>
> On Thu, Nov 12, 2020 at 11:43 AM Dmitry Vyukov wrote:
> > > > for sampling race detection),
> > > > number of threads in the process can be up to, say, ~~10K and the
> > > > watchpoint is intended to be set for a very brief period of time
On Thu, Nov 12, 2020 at 11:43 AM Dmitry Vyukov wrote:
> > > for sampling race detection),
> > > number of threads in the process can be up to, say, ~~10K and the
> > > watchpoint is intended to be set for a very brief period of time
> > > (~~few ms).
> >
> > Performance is a consideration here, do
On Thu, Nov 12, 2020 at 11:31 AM Peter Zijlstra wrote:
>
> On Thu, Nov 12, 2020 at 08:46:23AM +0100, Dmitry Vyukov wrote:
>
> > for sampling race detection),
> > number of threads in the process can be up to, say, ~~10K and the
> > watchpoint is intended to be set for a very brief period of time
>
On Thu, Nov 12, 2020 at 08:46:23AM +0100, Dmitry Vyukov wrote:
> for sampling race detection),
> number of threads in the process can be up to, say, ~~10K and the
> watchpoint is intended to be set for a very brief period of time
> (~~few ms).
Performance is a consideration here, doing lots of IP
Hello perf maintainers,
I have a wish for a particular kernel functionality related to
watchpoints, and I would appreciate it if you can say how
feasible/complex to add it is (mostly glueing existing infra pieces,
or redesigning and adding lots of new code), or maybe it exists
already and I am mis
25 matches
Mail list logo
