* Dmitry Vyukov <[email protected]> wrote:
> On Mon, Jun 19, 2017 at 12:50 PM, Mark Rutland <[email protected]> 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 <[email protected]>
> >> Cc: Mark Rutland <[email protected]>
> >> Cc: Andrey Ryabinin <[email protected]>
> >> Cc: Thomas Gleixner <[email protected]>
> >> Cc: "H. Peter Anvin" <[email protected]>
> >> Cc: Peter Zijlstra <[email protected]>
> >> Cc: Andrew Morton <[email protected]>
> >> Cc: [email protected]
> >> Cc: [email protected]
> >> Cc: [email protected]
> >> Cc: [email protected]
> >
> > Looks sane to me, and I can confirm this doesn't advervsely affect
> > arm64. FWIW:
> >
> > Acked-by: Mark Rutland <[email protected]>
> >
> > 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.)
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
