search

google / kernel-sanitizers

Linux Kernel Sanitizers, fast bug-detectors for the Linux kernel
https://google.github.io/kernel-sanitizers/
437 stars 87 forks source link

[kfence] Avoid intermediate string buffers for dumping information #69

Closed melver closed 4 years ago

melver commented 4 years ago

Avoid intermediate string buffers for dumping information to console or debugfs.

ramosian-glider commented 4 years ago

More context here: https://github.com/google/kasan/pull/68, but it's still unclear to me which intermediate buffers you were talking about. Those we allocate with alloc_pages()?

melver commented 4 years ago

More context here: #68, but it's still unclear to me which intermediate buffers you were talking about. Those we allocate with alloc_pages()?

Yes, we should just be able to directly seqprintf or pr the contents. It may require passing a function pointer but because pr_ are macros and printk doesn't take the same args as seq_printf, it may require some other trickery to make the function more generic.

ramosian-glider commented 4 years ago

On a second thought, I think we'd better not call printk() in the reporting code, as it may allocate memory, which can lead to deadlocks. We can perhaps pre-allocate the needed buffers instead of calling aloc_pages() every time we need to print an object.

ramosian-glider commented 4 years ago

Guess we can close this for now. One global buffer protected by a lock is enough so far.

melver commented 4 years ago

We still have an intermediate buffer, but as you say, if we can't call printk() immediately then the global buffer is probably as good as we can make it.

ramosian-glider commented 4 years ago

Marco, guess you've fixed the remnants in 95de3b56f7e1cfc38e45094cb296d20320d8d8f7 ?

melver commented 4 years ago

Marco, guess you've fixed the remnants in 95de3b5 ?

Yes, this can be closed.