Hi, I have realized that I did not comment the two ideas. On Wed 2021-02-10 11:27:45, Timur Tabi wrote: > > > On 2/10/21 7:41 AM, Petr Mladek wrote: > > > > The option causes that vsprintf() will not hash pointers. Yes, it is > > primary used by printk(). But it is used also in some other > > interfaces, especially trace_printk(), seq_buf() API. The naked > > pointers might appear more or less anywhere, including procfs, > > sysfs, debugfs. > > Fair point. Shouldn't calls to seq_buf_printf() (and any printk usage that > always exists in the context of a user-space process) use %pK anyway? seq_buf is a handy API that might be used for different purpose. For example, it seems to be used ftrace where people might want to see real pointers when debugging. > Hmmm.... maybe vsprintf() should automatically replace %p with %pK if it > detects a user-space context? I am not sure if there is an easy and reliable way how to detect the user-space context. On some architectures, it might be possible to guess it by the address of the buffer. But it will not work when the message is temporary printed into a local buffer and copied later. Let's keep it simple. Heuristics often become very complex over time. Best Regards, Petr
