All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Will Deacon <will@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	dja@axtens.net,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	linux-arch <linux-arch@vger.kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))
Date: Thu, 12 Dec 2019 21:21:57 +0100	[thread overview]
Message-ID: <20191212202157.GD11457@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20191212193401.GB19020@willie-the-truck>

On Thu, Dec 12, 2019 at 07:34:01PM +0000, Will Deacon wrote:
> void ool_store_release(volatile unsigned long *ptr, unsigned long val)
> {
> 	smp_store_release(ptr, val);
> }
> 
> 0000000000000000 <ool_store_release>:
>    0:   a9be7bfd        stp     x29, x30, [sp, #-32]!
>    4:   90000002        adrp    x2, 0 <__stack_chk_guard>
>    8:   91000042        add     x2, x2, #0x0
>    c:   910003fd        mov     x29, sp
>   10:   f9400043        ldr     x3, [x2]
>   14:   f9000fa3        str     x3, [x29, #24]
>   18:   d2800003        mov     x3, #0x0                        // #0
>   1c:   c89ffc01        stlr    x1, [x0]
>   20:   f9400fa1        ldr     x1, [x29, #24]
>   24:   f9400040        ldr     x0, [x2]
>   28:   ca000020        eor     x0, x1, x0
>   2c:   b5000060        cbnz    x0, 38 <ool_store_release+0x38>
>   30:   a8c27bfd        ldp     x29, x30, [sp], #32
>   34:   d65f03c0        ret
>   38:   94000000        bl      0 <__stack_chk_fail>
> 
> It's a mess, and fixing READ_ONCE() doesn't help this case, which is why
> I was looking at getting rid of volatile where it's not strictly needed.
> I'm certainly open to other suggestions, I just haven't managed to think
> of anything else.

We could move the kernel to C++ and write:

	std::remove_volatile<typeof(p)>::type __p = (p);

/me runs like hell...

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Will Deacon <will@kernel.org>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linuxppc-dev@lists.ozlabs.org, dja@axtens.net
Subject: Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))
Date: Thu, 12 Dec 2019 21:21:57 +0100	[thread overview]
Message-ID: <20191212202157.GD11457@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20191212193401.GB19020@willie-the-truck>

On Thu, Dec 12, 2019 at 07:34:01PM +0000, Will Deacon wrote:
> void ool_store_release(volatile unsigned long *ptr, unsigned long val)
> {
> 	smp_store_release(ptr, val);
> }
> 
> 0000000000000000 <ool_store_release>:
>    0:   a9be7bfd        stp     x29, x30, [sp, #-32]!
>    4:   90000002        adrp    x2, 0 <__stack_chk_guard>
>    8:   91000042        add     x2, x2, #0x0
>    c:   910003fd        mov     x29, sp
>   10:   f9400043        ldr     x3, [x2]
>   14:   f9000fa3        str     x3, [x29, #24]
>   18:   d2800003        mov     x3, #0x0                        // #0
>   1c:   c89ffc01        stlr    x1, [x0]
>   20:   f9400fa1        ldr     x1, [x29, #24]
>   24:   f9400040        ldr     x0, [x2]
>   28:   ca000020        eor     x0, x1, x0
>   2c:   b5000060        cbnz    x0, 38 <ool_store_release+0x38>
>   30:   a8c27bfd        ldp     x29, x30, [sp], #32
>   34:   d65f03c0        ret
>   38:   94000000        bl      0 <__stack_chk_fail>
> 
> It's a mess, and fixing READ_ONCE() doesn't help this case, which is why
> I was looking at getting rid of volatile where it's not strictly needed.
> I'm certainly open to other suggestions, I just haven't managed to think
> of anything else.

We could move the kernel to C++ and write:

	std::remove_volatile<typeof(p)>::type __p = (p);

/me runs like hell...

  reply	other threads:[~2019-12-12 20:22 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06 12:46 [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops) Michael Ellerman
2019-12-06 12:46 ` Michael Ellerman
2019-12-06 13:16 ` Peter Zijlstra
2019-12-06 13:16   ` Peter Zijlstra
2019-12-10  5:38   ` Michael Ellerman
2019-12-10  5:38     ` Michael Ellerman
2019-12-10 10:15     ` Peter Zijlstra
2019-12-10 10:15       ` Peter Zijlstra
2019-12-11  0:29       ` Michael Ellerman
2019-12-11  0:29         ` Michael Ellerman
2019-12-12  5:42   ` READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops)) Michael Ellerman
2019-12-12  5:42     ` Michael Ellerman
2019-12-12  8:01     ` Peter Zijlstra
2019-12-12  8:01       ` Peter Zijlstra
2019-12-12 10:07       ` Will Deacon
2019-12-12 10:07         ` Will Deacon
2019-12-12 10:46         ` Peter Zijlstra
2019-12-12 10:46           ` Peter Zijlstra
2019-12-12 17:04           ` Will Deacon
2019-12-12 17:04             ` Will Deacon
2019-12-12 17:16             ` Will Deacon
2019-12-12 17:16               ` Will Deacon
2019-12-12 17:41           ` Linus Torvalds
2019-12-12 17:41             ` Linus Torvalds
2019-12-12 17:50             ` Segher Boessenkool
2019-12-12 17:50               ` Segher Boessenkool
2019-12-12 18:06             ` Will Deacon
2019-12-12 18:06               ` Will Deacon
2019-12-12 18:29               ` Christian Borntraeger
2019-12-12 18:29                 ` Christian Borntraeger
2019-12-12 18:43               ` Linus Torvalds
2019-12-12 18:43                 ` Linus Torvalds
2019-12-12 19:34                 ` Will Deacon
2019-12-12 19:34                   ` Will Deacon
2019-12-12 20:21                   ` Peter Zijlstra [this message]
2019-12-12 20:21                     ` Peter Zijlstra
2019-12-12 20:53                     ` Peter Zijlstra
2019-12-12 20:53                       ` Peter Zijlstra
2019-12-13 10:47                       ` Luc Van Oostenryck
2019-12-13 10:47                         ` Luc Van Oostenryck
2019-12-13 12:56                         ` Peter Zijlstra
2019-12-13 12:56                           ` Peter Zijlstra
2019-12-13 14:28                           ` Luc Van Oostenryck
2019-12-13 14:28                             ` Luc Van Oostenryck
2019-12-12 20:49                   ` Linus Torvalds
2019-12-12 20:49                     ` Linus Torvalds
2019-12-13 13:17                     ` Arnd Bergmann
2019-12-13 13:17                       ` Arnd Bergmann
2019-12-13 21:32                       ` Arnd Bergmann
2019-12-13 21:32                         ` Arnd Bergmann
2019-12-13 22:01                         ` Linus Torvalds
2019-12-13 22:01                           ` Linus Torvalds
2019-12-16 10:28                       ` Will Deacon
2019-12-16 10:28                         ` Will Deacon
2019-12-16 11:47                         ` Peter Zijlstra
2019-12-16 11:47                           ` Peter Zijlstra
2019-12-16 12:06                         ` Arnd Bergmann
2019-12-16 12:06                           ` Arnd Bergmann
2019-12-17 17:07                     ` Will Deacon
2019-12-17 17:07                       ` Will Deacon
2019-12-17 18:04                       ` Linus Torvalds
2019-12-17 18:04                         ` Linus Torvalds
2019-12-17 18:05                         ` Linus Torvalds
2019-12-17 18:05                           ` Linus Torvalds
2019-12-17 18:31                           ` Will Deacon
2019-12-17 18:31                             ` Will Deacon
2019-12-17 18:32                         ` Linus Torvalds
2019-12-17 18:32                           ` Linus Torvalds
2019-12-18 12:17                           ` Michael Ellerman
2019-12-18 12:17                             ` Michael Ellerman
2019-12-19 12:11                           ` Will Deacon
2019-12-19 12:11                             ` Will Deacon
2019-12-18 10:22                     ` Christian Borntraeger
2019-12-18 10:22                       ` Christian Borntraeger
2019-12-18 10:35                       ` Will Deacon
2019-12-18 10:35                         ` Will Deacon
2019-12-13 12:07           ` Michael Ellerman
2019-12-13 12:07             ` Michael Ellerman
2019-12-13 13:53             ` Segher Boessenkool
2019-12-13 13:53               ` Segher Boessenkool
2019-12-13 21:06               ` Michael Ellerman
2019-12-13 21:06                 ` Michael Ellerman
2019-12-12 15:10     ` Segher Boessenkool
2019-12-12 15:10       ` Segher Boessenkool
2019-12-06 22:15 ` [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops) pr-tracker-bot
2019-12-06 22:15   ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191212202157.GD11457@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=arnd@arndb.de \
    --cc=borntraeger@de.ibm.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=dja@axtens.net \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mark.rutland@arm.com \
    --cc=mpe@ellerman.id.au \
    --cc=segher@kernel.crashing.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.