On Tue, Nov 17, 2020 at 08:09:22PM -0500, Steven Rostedt wrote:
> On Tue, 17 Nov 2020 16:42:44 -0800
> Matt Mullins wrote:
>
>
> > > Indeed with a stub function, I don't see any need for
> > > READ_ONCE/WRITE_ONCE.
> >
> > I'm not sure if this is a practical issue, but without WRITE_ONCE, ca
On Tue, 17 Nov 2020 16:42:44 -0800
Matt Mullins wrote:
> > Indeed with a stub function, I don't see any need for READ_ONCE/WRITE_ONCE.
> >
>
> I'm not sure if this is a practical issue, but without WRITE_ONCE, can't
> the write be torn? A racing __traceiter_ could potentially see a
> half-m
On Tue, Nov 17, 2020 at 06:05:51PM -0500, Mathieu Desnoyers wrote:
> - On Nov 16, 2020, at 5:10 PM, rostedt rost...@goodmis.org wrote:
>
> > On Mon, 16 Nov 2020 16:34:41 -0500 (EST)
> > Mathieu Desnoyers wrote:
>
> [...]
>
> >> I think you'll want a WRITE_ONCE(old[i].func, tp_stub_func) her
- On Nov 16, 2020, at 5:10 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 16 Nov 2020 16:34:41 -0500 (EST)
> Mathieu Desnoyers wrote:
[...]
>> I think you'll want a WRITE_ONCE(old[i].func, tp_stub_func) here, matched
>> with a READ_ONCE() in __DO_TRACE. This introduces a new situation whe
On Mon, 16 Nov 2020 16:34:41 -0500 (EST)
Mathieu Desnoyers wrote:
> - On Nov 16, 2020, at 4:02 PM, rostedt rost...@goodmis.org wrote:
>
> > On Mon, 16 Nov 2020 15:44:37 -0500
> > Steven Rostedt wrote:
> >
> >> If you use a stub function, it shouldn't affect anything. And the worse
> >> t
- On Nov 16, 2020, at 4:02 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 16 Nov 2020 15:44:37 -0500
> Steven Rostedt wrote:
>
>> If you use a stub function, it shouldn't affect anything. And the worse
>> that would happen is that you have a slight overhead of calling the stub
>> until you
- On Nov 16, 2020, at 3:44 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 16 Nov 2020 15:37:27 -0500 (EST)
> Mathieu Desnoyers wrote:
>> >
>> > Mathieu,
>> >
>> > Can't we do something that would still allow to unregister a probe even if
>> > a new probe array fails to allocate? We could
On Mon, 16 Nov 2020 16:02:18 -0500
Steven Rostedt wrote:
> + if (new) {
> + for (i = 0; old[i].func; i++)
> + if (old[i].func != tp_func->func
> + || old[i].data != tp_func->data)
> +
On Mon, 16 Nov 2020 15:44:37 -0500
Steven Rostedt wrote:
> If you use a stub function, it shouldn't affect anything. And the worse
> that would happen is that you have a slight overhead of calling the stub
> until you can properly remove the callback.
Something like this:
(haven't compiled it y
On Mon, 16 Nov 2020 15:37:27 -0500 (EST)
Mathieu Desnoyers wrote:
> >
> > Mathieu,
> >
> > Can't we do something that would still allow to unregister a probe even if
> > a new probe array fails to allocate? We could kick off a irq work to try to
> > clean up the probe at a later time, but still,
- On Nov 16, 2020, at 12:19 PM, rostedt rost...@goodmis.org wrote:
> On Sat, 14 Nov 2020 21:52:55 -0800
> Matt Mullins wrote:
>
>> bpf_link_free is always called in process context, including from a
>> workqueue and from __fput. Neither of these have the ability to
>> propagate an -ENOMEM t
On Sat, 14 Nov 2020 21:52:55 -0800
Matt Mullins wrote:
> bpf_link_free is always called in process context, including from a
> workqueue and from __fput. Neither of these have the ability to
> propagate an -ENOMEM to the caller.
>
Hmm, I think the real fix is to not have unregistering a tracep
bpf_link_free is always called in process context, including from a
workqueue and from __fput. Neither of these have the ability to
propagate an -ENOMEM to the caller.
Reported-by: syzbot+83aa762ef23b6f0d1...@syzkaller.appspotmail.com
Reported-by: syzbot+d29e58bb557324e55...@syzkaller.appspotmail
13 matches
Mail list logo
