[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150311.132052.205877953171712952.davem@davemloft.net>
Date: Wed, 11 Mar 2015 13:20:52 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: sasha.levin@...cle.com
Cc: rostedt@...dmis.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, netdev@...r.kernel.org,
linux-arch@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-crypto@...r.kernel.org
Subject: Re: [PATCH] mm: kill kmemcheck
From: Sasha Levin <sasha.levin@...cle.com>
Date: Wed, 11 Mar 2015 09:39:33 -0400
> On 03/11/2015 08:40 AM, Steven Rostedt wrote:
>> On Wed, 11 Mar 2015 08:34:46 -0400
>> Sasha Levin <sasha.levin@...cle.com> wrote:
>>
>>> > Fair enough. We knew there are existing kmemcheck users, but KASan should be
>>> > superior both in performance and the scope of bugs it finds. It also shouldn't
>>> > impose new limitations beyond requiring gcc 4.9.2+.
>>> >
>> Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3.
>>
>> It will be a while before I upgrade my build farm to something newer.
>
> Are you actually compiling new kernels with 4.6.3, or are you using older
> kernels as well?
>
> There's no real hurry to kill kmemcheck right now, but we do want to stop
> supporting that in favour of KASan.
Is the spectrum of CPU's supported by this GCC feature equal to all of the
CPU's supported by the kernel right now?
If not, removing kmemcheck will always be a regression for someone.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists