[v3,0/3] Add error_report_end tracepoint to KFENCE and KASAN

Message

Alexander Potapenko Jan. 21, 2021, 1:19 p.m. UTC

This patchset adds a tracepoint, error_repor_end, that is to be used by
KFENCE, KASAN, and potentially other bug detection tools, when they
print an error report.
One of the possible use cases is userspace collection of kernel error
reports: interested parties can subscribe to the tracing event via
tracefs, and get notified when an error report occurs.

v3:
 - dropped the sysfs interface for log collection
 - dropped error_report_start tracepoint

v2:
 - added ABI documentation for /sys/kernel/error_report/
 - changed error_report_start and error_report end tracepoints to take
   a fixed set of values for the error detector


Alexander Potapenko (3):
  tracing: add error_report_end trace point
  kfence: use error_report_end tracepoint
  kasan: use error_report_end tracepoint

 include/trace/events/error_report.h | 74 +++++++++++++++++++++++++++++
 kernel/trace/Makefile               |  1 +
 kernel/trace/error_report-traces.c  | 12 +++++
 mm/kasan/report.c                   |  8 ++--
 mm/kfence/report.c                  |  2 +
 5 files changed, 94 insertions(+), 3 deletions(-)
 create mode 100644 include/trace/events/error_report.h
 create mode 100644 kernel/trace/error_report-traces.c

Comments

Petr Mladek Jan. 22, 2021, 8:32 a.m. UTC | #1

On Thu 2021-01-21 14:19:12, Alexander Potapenko wrote:
> This patchset adds a tracepoint, error_repor_end, that is to be used by
> KFENCE, KASAN, and potentially other bug detection tools, when they
> print an error report.
> One of the possible use cases is userspace collection of kernel error
> reports: interested parties can subscribe to the tracing event via
> tracefs, and get notified when an error report occurs.
> 
> v3:
>  - dropped the sysfs interface for log collection
>  - dropped error_report_start tracepoint

Just for record. This approach looks reasonable to me.
Thanks for removing the sysfs interface. It would have been
a potential can of worms.

I do not feel eligible to add any tag. I am neither familiar
with the tracepoint nor the KFENCE or KASAN code.

Best Regards,
Petr

Alexander Potapenko Jan. 22, 2021, 8:41 a.m. UTC | #2

On Fri, Jan 22, 2021 at 9:32 AM Petr Mladek <[e-mail]> wrote:
>
> On Thu 2021-01-21 14:19:12, Alexander Potapenko wrote:
> > This patchset adds a tracepoint, error_repor_end, that is to be used by
> > KFENCE, KASAN, and potentially other bug detection tools, when they
> > print an error report.
> > One of the possible use cases is userspace collection of kernel error
> > reports: interested parties can subscribe to the tracing event via
> > tracefs, and get notified when an error report occurs.
> >
> > v3:
> >  - dropped the sysfs interface for log collection
> >  - dropped error_report_start tracepoint
>
> Just for record. This approach looks reasonable to me.
> Thanks for removing the sysfs interface. It would have been
> a potential can of worms.

Thanks for the input!
At least it was premature to touch prink just for the sake of
collecting some particular crashes.
Perhaps we can revisit this topic when stronger arguments arise :)

> I do not feel eligible to add any tag. I am neither familiar
> with the tracepoint nor the KFENCE or KASAN code.
>
> Best Regards,
> Petr

Petr Mladek Jan. 22, 2021, 8:49 a.m. UTC | #3

On Fri 2021-01-22 09:41:54, Alexander Potapenko wrote:
> On Fri, Jan 22, 2021 at 9:32 AM Petr Mladek <[e-mail]> wrote:
> >
> > On Thu 2021-01-21 14:19:12, Alexander Potapenko wrote:
> > > This patchset adds a tracepoint, error_repor_end, that is to be used by
> > > KFENCE, KASAN, and potentially other bug detection tools, when they
> > > print an error report.
> > > One of the possible use cases is userspace collection of kernel error
> > > reports: interested parties can subscribe to the tracing event via
> > > tracefs, and get notified when an error report occurs.
> > >
> > > v3:
> > >  - dropped the sysfs interface for log collection
> > >  - dropped error_report_start tracepoint
> >
> > Just for record. This approach looks reasonable to me.
> > Thanks for removing the sysfs interface. It would have been
> > a potential can of worms.
> 
> Thanks for the input!
> At least it was premature to touch prink just for the sake of
> collecting some particular crashes.
> Perhaps we can revisit this topic when stronger arguments arise :)

Sure :-)

Best Regards,
Petr