Hi Alex, >We've recently attempted to build a universal library capturing every >error report, but then were pointed to tracefs, which was just enough >for our purpose (https://protect2.fireeye.com/v1/url?k=36bfb191-6924888b-36be3ade-0cc47a6cba04-0e7fd520f09636ee&q=1&e=a6b7f23a-98d4-4084-af0a-a88af0b4c9d0&u=https%3A%2F%2Flkml.org%2Flkml%2F2021%2F1%2F15%2F609). >Greg also stated that procfs is a bad place for storing reports: >https://protect2.fireeye.com/v1/url?k=924a3ffc-cdd106e6-924bb4b3-0cc47a6cba04-882467cbf9e8b46f&q=1&e=a6b7f23a-98d4-4084-af0a-a88af0b4c9d0&u=https%3A%2F%2Flkml.org%2Flkml%2F2021%2F1%2F15%2F929. > >Maninder, which exactly problem are you trying to solve? We focussed on 2 problems, 1 is to remove duplicate error reporting from KASAN when multishot is ON and second was to save KASAN metadata (minimal) to regenerate same KASAN warnings when user reads new proc interface. >Note that KASAN already triggers a trace_error_report_end tracepoint >on every error report: >https://protect2.fireeye.com/v1/url?k=2d128c9c-7289b586-2d1307d3-0cc47a6cba04-3e939a06aa0346db&q=1&e=a6b7f23a-98d4-4084-af0a-a88af0b4c9d0&u=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.12-rc8%2Fsource%2Fmm%2Fkasan%2Freport.c%23L90 >Would it help if you used that one? It could probably be extended with >more parameters. > >Another option if you want verbatim reports is to use the console >tracepoints, as this is done in >https://protect2.fireeye.com/v1/url?k=5f368dc2-00adb4d8-5f37068d-0cc47a6cba04-fe4efc4f73dbea2f&q=1&e=a6b7f23a-98d4-4084-af0a-a88af0b4c9d0&u=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.12-rc8%2Fsource%2Fmm%2Fkfence%2Fkfence_test.c >Note that there are many caveats with error report collection (see the >links above), but for testing purpose it might be enough. > Ok We will check these tracing methods also. Thanks Maninder Singh
