[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5274ba1922d5eaf9568886191e0a05bdfc55506.camel@sipsolutions.net>
Date: Thu, 25 Nov 2021 16:45:07 +0100
From: Johannes Berg <johannes@...solutions.net>
To: "Sang, Oliver" <oliver.sang@...el.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Peter Oberparleiter <oberpar@...ux.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"lkp@...ts.01.org" <lkp@...ts.01.org>, lkp <lkp@...el.com>
Subject: Re: [gcov] 1391efa952:
BUG:KASAN:slab-out-of-bounds_in_gcov_info_add
On Thu, 2021-11-25 at 14:26 +0000, Sang, Oliver wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with clang-14):
>
> commit: 1391efa952e8b22088f8626fc63ade26767b92d6 ("gcov: use kvmalloc()")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
I don't think it actually *caused* the issue, but who knows? To me it
rather looks like it exposed an issue, which wasn't noticed before
because vmalloc() always allocates a page anyway? Assuming KASAN doesn't
track vmalloc() allocations more granular than their actual page-aligned
memory size (though perhaps it should?)
In any case, reviewing my commit again I see nothing wrong there, and I
don't understand the code/clang well enough to see what might be the
issue.
johannes
Powered by blists - more mailing lists