* Marco Elver wrote:
> > Yeah, so why cannot we allocate enough space from the signal
> > handler user-space stack and put the attr there, and point to it
> > from sig_info?
> >
> > The idea would be to create a stable, per-signal snapshot of
> > whatever the perf_attr state is at the
On Thu, 25 Mar 2021 at 15:18, Ingo Molnar wrote:
>
> * Dmitry Vyukov wrote:
>
> > On Wed, Mar 24, 2021 at 3:05 PM Marco Elver wrote:
> > >
> > > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> > > >
> > > > One last try, I'll leave it alone now, I promise :-)
> > >
> > > This looks like
* Dmitry Vyukov wrote:
> On Wed, Mar 24, 2021 at 3:05 PM Marco Elver wrote:
> >
> > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> > >
> > > One last try, I'll leave it alone now, I promise :-)
> >
> > This looks like it does what you suggested, thanks! :-)
> >
> > I'll still need to
On Wed, 24 Mar 2021 at 15:15, Dmitry Vyukov wrote:
> On Wed, Mar 24, 2021 at 3:12 PM Dmitry Vyukov wrote:
> > > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> > > >
> > > > One last try, I'll leave it alone now, I promise :-)
> > >
> > > This looks like it does what you suggested,
On Wed, Mar 24, 2021 at 3:12 PM Dmitry Vyukov wrote:
> > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> > >
> > > One last try, I'll leave it alone now, I promise :-)
> >
> > This looks like it does what you suggested, thanks! :-)
> >
> > I'll still need to think about it, because of the
On Wed, Mar 24, 2021 at 3:05 PM Marco Elver wrote:
>
> On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> >
> > One last try, I'll leave it alone now, I promise :-)
>
> This looks like it does what you suggested, thanks! :-)
>
> I'll still need to think about it, because of the potential
On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
>
> One last try, I'll leave it alone now, I promise :-)
This looks like it does what you suggested, thanks! :-)
I'll still need to think about it, because of the potential problem
with modify-signal-races and what the user's synchronization
One last try, I'll leave it alone now, I promise :-)
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -778,6 +778,9 @@ struct perf_event {
void *security;
#endif
struct list_headsb_list;
+
+ unsigned long si_uattr;
+
On Wed, 24 Mar 2021 at 14:21, Peter Zijlstra wrote:
>
> On Wed, Mar 24, 2021 at 02:01:56PM +0100, Peter Zijlstra wrote:
> > On Wed, Mar 24, 2021 at 01:53:48PM +0100, Peter Zijlstra wrote:
> > > On Wed, Mar 24, 2021 at 12:24:59PM +0100, Marco Elver wrote:
> > > > Encode information from breakpoint
On Wed, Mar 24, 2021 at 02:21:37PM +0100, Peter Zijlstra wrote:
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5652,13 +5652,17 @@ static long _perf_ioctl(struct perf_even
> return perf_event_query_prog_array(event, (void __user *)arg);
>
> case
On Wed, Mar 24, 2021 at 02:01:56PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 24, 2021 at 01:53:48PM +0100, Peter Zijlstra wrote:
> > On Wed, Mar 24, 2021 at 12:24:59PM +0100, Marco Elver wrote:
> > > Encode information from breakpoint attributes into siginfo_t, which
> > > helps disambiguate
On Wed, Mar 24, 2021 at 01:53:48PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 24, 2021 at 12:24:59PM +0100, Marco Elver wrote:
> > Encode information from breakpoint attributes into siginfo_t, which
> > helps disambiguate which breakpoint fired.
> >
> > Note, providing the event fd may be
On Wed, Mar 24, 2021 at 12:24:59PM +0100, Marco Elver wrote:
> Encode information from breakpoint attributes into siginfo_t, which
> helps disambiguate which breakpoint fired.
>
> Note, providing the event fd may be unreliable, since the event may have
> been modified (via
Encode information from breakpoint attributes into siginfo_t, which
helps disambiguate which breakpoint fired.
Note, providing the event fd may be unreliable, since the event may have
been modified (via PERF_EVENT_IOC_MODIFY_ATTRIBUTES) between the event
triggering and the signal being delivered
14 matches
Mail list logo
