On 7/30/20 9:29 PM, Steven Rostedt wrote: > On Thu, 30 Jul 2020 21:12:39 +0200 > peter enderborg <peter.enderborg@xxxxxxxx> wrote: > >>>> avc: denied { find } for interface=vendor.qti.hardware.perf::IPerf sid=u:r:permissioncontroller_app:s0:c230,c256,c512,c768 pid=9164 scontext=u:r:permissioncontroller_app:s0:c230,c256,c512,c768 tcontext=u:object_r:vendor_hal_perf_hwservice:s0 tclass=hwservice_manager permissive=0 >>>> avc: denied { execute } for pid=13914 comm="ScionFrontendAp" path="/data/user_de/0/com.google.android.gms/app_chimera/m/00000002/oat/arm64/DynamiteLoader.odex" dev="sda77" ino=204967 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:privapp_data_file:s0:c512,c768 tclass=file permissive=0 ppid=788 pcomm="main" pgid=13914 pgcomm="on.updatecenter" >>>> >>>> It omit the fields that are not used. Some parts are common some are not. So a correct format specification for trace will be problematic if there is no "optional" field indicator. >>> That's all quite noisy. What is the object of these changes? What >>> exactly are you trying to trace and why? >> It is noisy, and it have to be. it covers a lot of different areas. One common problem is >> to debug userspace applications regarding violations. You get the violation from the logs >> and try to figure out what you did to cause it. With a trace point you can do much better >> when combine with other traces. Having a the userspace stack is a very good way, >> unfortunately it does not work on that many architectures within trace. >> >> What exactly are you doing with any trace? You collect data to analyse what's >> going on. This is not different. Selinux do a specific thing, but is has lots of parameters. > Have you thought of adding multiple trace events with if statements > around them to decode each specific type of event? Yes. And I think class is good split point. But I think it will require a few layers, but a is mostly data driven so I think it might be hard to do it compile time. I think a hybrid might be possible, but it then we need some ugly part with a other separator than =, or some escape seq to separate. sort of "generc1=X generic2=Y variable1^x variable2^y" or "generc1=X generic2=Y leftover=[variable1=x variable2=y]" If there was a formal parameter tree we could maybe do some generated printer. I don't think there are one, maybe Paul Moore or Stephen Smalley can verify that. > Note, you can have a generic event that gets enabled by all the other > events via the "reg" and "unreg" part of TRACE_EVENT_FN(). Say its > called trace_avc, make a dummy trace_avc() call hat doesn't even need > to be called anywhere, it just needs to exist to get to the other trace > events. > > Then have: > > if (trace_avc_enabled()) { > if (event1) > trace_avc_req_event1(); > if (event2) > trace_avc_req_event2(); > [..] > } > > The reason for the trace_avc_enabled() is because that's a static > branch, which is a nop when not enabled. When enabled, it is a jump to > the out of band if condition block that has all the other trace events. > > -- Steve