Re: [PATCH v4 5/7] kasan: allow kasan_check_read/write() to accept pointers to volatiles

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 22, 2017 at 10:25 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>
>> On Mon, Jun 19, 2017 at 12:50 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
>> > On Sat, Jun 17, 2017 at 11:15:31AM +0200, Dmitry Vyukov wrote:
>> >> Currently kasan_check_read/write() accept 'const void*', make them
>> >> accept 'const volatile void*'. This is required for instrumentation
>> >> of atomic operations and there is just no reason to not allow that.
>> >>
>> >> Signed-off-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
>> >> Cc: Mark Rutland <mark.rutland@xxxxxxx>
>> >> Cc: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
>> >> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>> >> Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>
>> >> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
>> >> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> >> Cc: linux-kernel@xxxxxxxxxxxxxxx
>> >> Cc: x86@xxxxxxxxxx
>> >> Cc: linux-mm@xxxxxxxxx
>> >> Cc: kasan-dev@xxxxxxxxxxxxxxxx
>> >
>> > Looks sane to me, and I can confirm this doesn't advervsely affect
>> > arm64. FWIW:
>> >
>> > Acked-by: Mark Rutland <mark.rutland@xxxxxxx>
>> >
>> > Mark.
>>
>>
>> Great! Thanks for testing.
>>
>> Ingo, what are your thoughts? Are you taking this to locking tree? When?
>
> Yeah, it all looks pretty clean to me too. I've applied the first three patches to
> the locking tree, but did some minor stylistic cleanups to the first patch to
> harmonize the style of the code - which made the later patches not apply cleanly.
>
> Mind sending the remaining patches against the locking tree, tip:locking/core?
> (Please also add in all the acks you got.)

Mailed v5 rebased on tip:locking/core (now only 4 patches).
Added Acked/Reviewed-By that I got.

> This should also give people (Peter, Linus?) a last minute chance to object to my
> suggestion of increasing the linecount in patch #1:
>
>  0f2376eb0ff8: locking/atomic/x86: Un-macro-ify atomic ops implementation
>
>  arch/x86/include/asm/atomic.h      | 69 ++++++++++++++++++++++++++++++++++++++++++++++-----------------------
>  arch/x86/include/asm/atomic64_32.h | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------
>  arch/x86/include/asm/atomic64_64.h | 67 ++++++++++++++++++++++++++++++++++++++++++++-----------------------
>  3 files changed, 147 insertions(+), 70 deletions(-)
>
> ... to me the end result looks much more readable despite the +70 lines of code,
> but if anyone feels strongly about this please holler!
>
> Thanks,
>
>         Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux