[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877ctyzv08.fsf@mail.concordia>
Date: Wed, 26 Apr 2023 22:29:59 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Joel Fernandes <joel@...lfernandes.org>,
Zhouyi Zhou <zhouzhouyi@...il.com>,
Christophe Leroy <christophe.leroy@....fr>
Cc: Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>,
Segher Boessenkool <segher@...nel.crashing.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
rcu <rcu@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>, lance@...osl.org,
"Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail
Joel Fernandes <joel@...lfernandes.org> writes:
> On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou <zhouzhouyi@...il.com> wrote:
...
>
> Out of curiosity for PPC folks, why cannot 64-bit PPC use per-task
> canary? Michael, is this an optimization? Adding Christophe as well
> since it came in a few years ago via the following commit:
I think Christophe also answered these in his reply.
We do use a per-task canary, but because we don't have "current" in a
register, we can't use the value in current for GCC.
In one of my replies I said a possible solution would be to keep current
in a register on 64-bit, but we'd need to do that in addition to the
paca, so that would consume another GPR which we'd need to think hard
about.
There's another reason to have it in the paca, which is that the paca is
always accessible, even when the MMU is off, whereas current isn't (in
some situations).
In general we don't want to use stack protector in code that runs with
the MMU off, but if the canary wasn't in the paca then we'd have a hard
requirement to not use stack protector in that code.
cheers
Powered by blists - more mailing lists