Re: [cfs_trace_lock_tcd] BUG: KASAN: null-ptr-deref in cfs_trace_lock_tcd+0x25/0xeb

From: Andrey Ryabinin
Date: Thu Apr 19 2018 - 09:54:41 EST

On 04/19/2018 04:35 PM, Andrey Ryabinin wrote:
> On 04/18/2018 09:37 PM, Linus Torvalds wrote:
>> Ugh, that lustre code is disgusting.
>> I thought we were getting rid of it.
>> Anyway, I started looking at why the stack trace is such an incredible
>> mess, with lots of stale entries.
>> The reason (well, _one_ reason) seems to be "ksocknal_startup". It has
>> a 500-byte stack frame for some incomprehensible reason. I assume due
>> to excessive inlining, because the function itself doesn't seem to be
>> that bad.
>> Similarly, LNetNIInit has a 300-byte stack frame. So it gets pretty deep.
>> I'm getting the feeling that KASAN is making things worse because
>> probably it's disabling all the sane stack frame stuff (ie no merging
>> of stack slot entries, perhaps?).
> AFAIR no merging of stack slots policy enabled only if -fsanitize-address-use-after-scope
> is on (which is CONFIG_KASAN_EXTRA). This feature does cause sometimes significant stack bloat,
> but hasn't been proven to be very useful, so I wouldn't mind disabling it completely.
> So far I know only about a single BUG -<151238865557.4852.10258661301122491354@xxxxxxxxxxxxxxxxxxxx>
> it has found.

Actually, there is one more -
so two bugs.

> There are also a lot of other

I didn't finish this sentence:

There are also a lot of other reports about use-after-scope, but seem all of them are false positives
caused by STRUCTLEAK plugin.