Thanks for the clarification.
I found that static_cpu_has was replaced by static_cpu_has_safe:
https://lkml.org/lkml/2016/1/24/29 -- so is it fair to assume that
both are equally safe at this point?
I have sent a follow-up patch which uses static_cpu_has:
http://lkml.kernel.org/r/20190531150828.1
On May 31, 2019 2:57:36 AM PDT, Marco Elver wrote:
>On Wed, 29 May 2019 at 16:29, wrote:
>>
>> On May 29, 2019 7:15:00 AM PDT, Marco Elver wrote:
>> >This patch is a pre-requisite for enabling KASAN bitops
>> >instrumentation:
>> >moves boot_cpu_has feature test out of the uaccess region, as
>>
On Wed, 29 May 2019 at 16:29, wrote:
>
> On May 29, 2019 7:15:00 AM PDT, Marco Elver wrote:
> >This patch is a pre-requisite for enabling KASAN bitops
> >instrumentation:
> >moves boot_cpu_has feature test out of the uaccess region, as
> >boot_cpu_has uses test_bit. With instrumentation, the KASA
On May 29, 2019 7:15:00 AM PDT, Marco Elver wrote:
>This patch is a pre-requisite for enabling KASAN bitops
>instrumentation:
>moves boot_cpu_has feature test out of the uaccess region, as
>boot_cpu_has uses test_bit. With instrumentation, the KASAN check would
>otherwise be flagged by objtool.
>
This patch is a pre-requisite for enabling KASAN bitops instrumentation:
moves boot_cpu_has feature test out of the uaccess region, as
boot_cpu_has uses test_bit. With instrumentation, the KASAN check would
otherwise be flagged by objtool.
This approach is preferred over adding the explicit kasan_
