[Devel] [PATCH VZ9 17/20] fuse: pcs: split trace_printk

[Vasily Averin]

On 10/6/23 13:44, Alexey Kuznetsov wrote:
> trace_printk() is a function which is not desired in release kernels,
> if is referenced from a module, even if it is not actually used, it allocates
> lots of memory and scares people with some messages.
> 
> What can we do?

Why not switch to ftrace events?
Do you mean it is not better than trace_printk?

> 1. Surround it with ifdef turned off in release kernels
>    No. We need this at customer's environments to investigate actual problems,
>    modules cannot be replaced with debugging when they are in use.
> 2. Just delete it.
>    Instead we could use systemtap to attach to running module to get desired traces.
>    This facility is used frequently in any case. Contra: systemtap puts
>    heavy overhead, it is not easy to install, frequently customers are heavily
>    firewalled and do not allow debugging software to pollute their systems.
>    One day, when bpftrace becomes mature it could be an option. Right now
>    it is still useless.
> 3. Convert them to userspace logging FUSE_KTRACE at higher loglevel.
>    Too expensive. We do not need this garbage in user space logs and it is not easy,
>    userpace logging requires context pointer which is diffficult or impossible to fetch.
> 
> So, the third variant is suggested. It is some compromise, we preserve
> debugging in code, but split actual uses of trace_printk to separate module,
> which can be loaded when we need tracing. It is more expensive, includes
> an indirect call and does not allow inline calls, but yet it still looks better
> than any other way. Also, a few TRACE which have analogs in userspace were
> missed, convert them to FUSE_KTRACE now.