* Re: [RFC PATCH 3/5] kasan: allow architectures to provide an outline readiness check
From: Daniel Axtens @ 2019-02-26 0:14 UTC (permalink / raw)
To: Christophe Leroy, aneesh.kumar, bsingharora
Cc: linuxppc-dev, Aneesh Kumar K . V, kasan-dev
In-Reply-To: <4ff60641-684a-8e86-0193-ef5380602096@c-s.fr>
>>> Unless somebody minds, I'll do the change and take this patch in my
>>> series in order to handle the case of book3s/32 hash.
>>
>> Please do; feel free to take as many of the patches as you would like
>> and I'll rebase whatever is left on the next version of your series.
>
> I have now done a big step with v7: works on both nohash and hash ppc32
> without any special feature in the core of kasan. Have to do more tests
> on the hash version, but it seems promissing.
>
> I have kept your patches on sync on top of it (allthough totally
> untested), you can find them in
> https://github.com/chleroy/linux/commits/kasan
Thanks - I've got sidetracked with other internal stuff but I hope to
get back to this later in the week.
Regards,
Daniel
>
>>
>> The idea with the macro magic was to take advantage of the speed of
>> static keys (I think, I borrowed it from Balbir's patch). Perhaps an
>> inline function will achieve this anyway, but given that KASAN with
>> outline instrumentation is inevitably slow, I guess it doesn't matter
>> much either way.
>
> You'll see in the modifications I've done to your patches, we can still
> use static keys while using static inline functions.
>
> Christophe
^ permalink raw reply
* Re: [PATCH] tools: testing: selftests: Remove duplicate headers
From: Michael Ellerman @ 2019-02-26 1:48 UTC (permalink / raw)
To: Souptick Joarder, bamv2005, shuah, davem, benh, paulus, adobriyan,
mathieu.desnoyers, peterz, paulmck, boqun.feng, john.stultz, tglx,
sboyd, akpm
Cc: sabyasachi.linux, netdev, linux-kernel, linux-gpio,
linux-kselftest, linux-fsdevel, linuxppc-dev
In-Reply-To: <20190223070901.GA10274@jordon-HP-15-Notebook-PC>
Souptick Joarder <jrdr.linux@gmail.com> writes:
> Remove duplicate headers which are included twice.
>
> Signed-off-by: Sabyasachi Gupta <sabyasachi.linux@gmail.com>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> ---
...
> tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c | 1 -
I took this hunk via the powerpc tree.
> diff --git a/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c b/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
> index 167135b..af1b802 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
> @@ -11,7 +11,6 @@
> #include <sys/wait.h>
> #include <unistd.h>
> #include <setjmp.h>
> -#include <signal.h>
>
> #include "ebb.h"
cheers
^ permalink raw reply
* RE: [PATCH V2] ASoC: fsl_esai: fix channel swap issue when stream starts
From: S.j. Wang @ 2019-02-26 2:01 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190225211440.GA20734@Asurada-Nvidia.nvidia.com>
>
> On Mon, Feb 25, 2019 at 02:48:18AM +0000, S.j. Wang wrote:
> > There is very low possibility ( < 0.1% ) that channel swap happened in
> > beginning when multi output/input pin is enabled. The issue is that
> > hardware can't send data to correct pin in the beginning with the
> > normal enable flow.
> >
> > This is hardware issue, but there is no errata, the workaround flow is
> > that: Each time playback/recording, firstly clear the xSMA/xSMB, then
> > enable TE/RE, then enable xSMB and xSMA (xSMB must be enabled
> before
> > xSMA). Which is to use the xSMA as the trigger start register,
> > previously the xCR_TE or xCR_RE is the bit for starting.
> >
> > Fixes 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
> > Cc: <stable@vger.kernel.org>
> > Reviewed-by: Fabio Estevam <festevam@gmail.com>
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > Changes in v2
> > - update commit comments.
> >
> > sound/soc/fsl/fsl_esai.c | 32 ++++++++++++++++++++++----------
> > 1 file changed, 22 insertions(+), 10 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index
> > afe67c865330..23bd0ad4ac31 100644
> > --- a/sound/soc/fsl/fsl_esai.c
> > +++ b/sound/soc/fsl/fsl_esai.c
> > @@ -54,6 +54,8 @@ struct fsl_esai {
> > u32 fifo_depth;
> > u32 slot_width;
> > u32 slots;
> > + u32 tx_mask;
> > + u32 rx_mask;
> > u32 hck_rate[2];
> > u32 sck_rate[2];
> > bool hck_dir[2];
> > @@ -361,21 +363,13 @@ static int fsl_esai_set_dai_tdm_slot(struct
> snd_soc_dai *dai, u32 tx_mask,
> > regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR,
> > ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
> >
> > - regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMA,
> > - ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(tx_mask));
> > - regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMB,
> > - ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(tx_mask));
> > -
> > regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR,
> > ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
> >
> > - regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMA,
> > - ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(rx_mask));
> > - regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMB,
> > - ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(rx_mask));
> > -
> > esai_priv->slot_width = slot_width;
> > esai_priv->slots = slots;
> > + esai_priv->tx_mask = tx_mask;
> > + esai_priv->rx_mask = rx_mask;
>
> The two masks only got values here. If a machine driver doesn't have a
> set_dai_tdm_slot() call, they will be remained as 0 and then will seemly
> clean those four registers.
>
> Thanks
> Nicolin
Then I think we need to add default value for tx_mask and rx_mask, that is
In the probe function to add:
esai_priv->tx_mask = 0xFFFFFFFF;
esai_priv->rx_mask = 0xFFFFFFFF;
best regards
wang shengjiu
>
> >
> > return 0;
> > }
> > @@ -596,6 +590,7 @@ static int fsl_esai_trigger(struct
> snd_pcm_substream *substream, int cmd,
> > bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> > u8 i, channels = substream->runtime->channels;
> > u32 pins = DIV_ROUND_UP(channels, esai_priv->slots);
> > + u32 mask;
> >
> > switch (cmd) {
> > case SNDRV_PCM_TRIGGER_START:
> > @@ -611,12 +606,23 @@ static int fsl_esai_trigger(struct
> snd_pcm_substream *substream, int cmd,
> > regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
> > tx ? ESAI_xCR_TE_MASK :
> ESAI_xCR_RE_MASK,
> > tx ? ESAI_xCR_TE(pins) :
> ESAI_xCR_RE(pins));
> > + mask = tx ? esai_priv->tx_mask : esai_priv->rx_mask;
> > +
> > + regmap_update_bits(esai_priv->regmap,
> REG_ESAI_xSMB(tx),
> > + ESAI_xSMB_xS_MASK,
> ESAI_xSMB_xS(mask));
> > + regmap_update_bits(esai_priv->regmap,
> REG_ESAI_xSMA(tx),
> > + ESAI_xSMA_xS_MASK,
> ESAI_xSMA_xS(mask));
> > +
> > break;
> > case SNDRV_PCM_TRIGGER_SUSPEND:
> > case SNDRV_PCM_TRIGGER_STOP:
> > case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> > regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
> > tx ? ESAI_xCR_TE_MASK :
> ESAI_xCR_RE_MASK, 0);
> > + regmap_update_bits(esai_priv->regmap,
> REG_ESAI_xSMA(tx),
> > + ESAI_xSMA_xS_MASK, 0);
> > + regmap_update_bits(esai_priv->regmap,
> REG_ESAI_xSMB(tx),
> > + ESAI_xSMB_xS_MASK, 0);
> >
> > /* Disable and reset FIFO */
> > regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx),
> @@ -906,6
> > +912,12 @@ static int fsl_esai_probe(struct platform_device *pdev)
> > return ret;
> > }
> >
> > + /* Clear the TSMA, TSMB, RSMA, RSMB */
> > + regmap_write(esai_priv->regmap, REG_ESAI_TSMA, 0);
> > + regmap_write(esai_priv->regmap, REG_ESAI_TSMB, 0);
> > + regmap_write(esai_priv->regmap, REG_ESAI_RSMA, 0);
> > + regmap_write(esai_priv->regmap, REG_ESAI_RSMB, 0);
> > +
> > ret = devm_snd_soc_register_component(&pdev->dev,
> &fsl_esai_component,
> > &fsl_esai_dai, 1);
> > if (ret) {
> > --
> > 1.9.1
> >
^ permalink raw reply
* Re: [PATCH V2] ASoC: fsl_esai: fix channel swap issue when stream starts
From: Nicolin Chen @ 2019-02-26 2:33 UTC (permalink / raw)
To: S.j. Wang
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VI1PR0402MB3392A0477A1C8CE66C47960EE37B0@VI1PR0402MB3392.eurprd04.prod.outlook.com>
On Tue, Feb 26, 2019 at 02:01:14AM +0000, S.j. Wang wrote:
> > > diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index
> > > afe67c865330..23bd0ad4ac31 100644
> > > --- a/sound/soc/fsl/fsl_esai.c
> > > +++ b/sound/soc/fsl/fsl_esai.c
> > > @@ -54,6 +54,8 @@ struct fsl_esai {
> > > u32 fifo_depth;
> > > u32 slot_width;
> > > u32 slots;
> > > + u32 tx_mask;
> > > + u32 rx_mask;
> > > esai_priv->slot_width = slot_width;
> > > esai_priv->slots = slots;
> > > + esai_priv->tx_mask = tx_mask;
> > > + esai_priv->rx_mask = rx_mask;
> >
> > The two masks only got values here. If a machine driver doesn't have a
> > set_dai_tdm_slot() call, they will be remained as 0 and then will seemly
> > clean those four registers.
> >
> Then I think we need to add default value for tx_mask and rx_mask, that is
> In the probe function to add:
> esai_priv->tx_mask = 0xFFFFFFFF;
> esai_priv->rx_mask = 0xFFFFFFFF;
Yea:) Please include them in v3.
^ permalink raw reply
* RE: [PATCH V2] ASoC: fsl_esai: fix channel swap issue when stream starts
From: S.j. Wang @ 2019-02-26 2:54 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190226023259.GA18857@Asurada-Nvidia.nvidia.com>
>
> On Tue, Feb 26, 2019 at 02:01:14AM +0000, S.j. Wang wrote:
> > > > diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> > > > index
> > > > afe67c865330..23bd0ad4ac31 100644
> > > > --- a/sound/soc/fsl/fsl_esai.c
> > > > +++ b/sound/soc/fsl/fsl_esai.c
> > > > @@ -54,6 +54,8 @@ struct fsl_esai {
> > > > u32 fifo_depth;
> > > > u32 slot_width;
> > > > u32 slots;
> > > > + u32 tx_mask;
> > > > + u32 rx_mask;
>
> > > > esai_priv->slot_width = slot_width;
> > > > esai_priv->slots = slots;
> > > > + esai_priv->tx_mask = tx_mask;
> > > > + esai_priv->rx_mask = rx_mask;
> > >
> > > The two masks only got values here. If a machine driver doesn't have
> > > a
> > > set_dai_tdm_slot() call, they will be remained as 0 and then will
> > > seemly clean those four registers.
> > >
> > Then I think we need to add default value for tx_mask and rx_mask,
> > that is In the probe function to add:
> > esai_priv->tx_mask = 0xFFFFFFFF;
> > esai_priv->rx_mask = 0xFFFFFFFF;
>
> Yea:) Please include them in v3.
Ok.
^ permalink raw reply
* [PATCH V3] ASoC: fsl_esai: fix channel swap issue when stream starts
From: S.j. Wang @ 2019-02-26 3:12 UTC (permalink / raw)
To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, broonie@kernel.org,
alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
There is very low possibility ( < 0.1% ) that channel swap happened
in beginning when multi output/input pin is enabled. The issue is
that hardware can't send data to correct pin in the beginning with
the normal enable flow.
This is hardware issue, but there is no errata, the workaround flow
is that: Each time playback/recording, firstly clear the xSMA/xSMB,
then enable TE/RE, then enable xSMB and xSMA (xSMB must be enabled
before xSMA). Which is to use the xSMA as the trigger start register,
previously the xCR_TE or xCR_RE is the bit for starting.
Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
changes in v3
- initialize tx_mask and rx_mask in probe
sound/soc/fsl/fsl_esai.c | 35 +++++++++++++++++++++++++----------
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index afe67c865330..7ee91c28b636 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -54,6 +54,8 @@ struct fsl_esai {
u32 fifo_depth;
u32 slot_width;
u32 slots;
+ u32 tx_mask;
+ u32 rx_mask;
u32 hck_rate[2];
u32 sck_rate[2];
bool hck_dir[2];
@@ -361,21 +363,13 @@ static int fsl_esai_set_dai_tdm_slot(struct snd_soc_dai *dai, u32 tx_mask,
regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR,
ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMA,
- ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(tx_mask));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMB,
- ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(tx_mask));
-
regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR,
ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMA,
- ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(rx_mask));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMB,
- ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(rx_mask));
-
esai_priv->slot_width = slot_width;
esai_priv->slots = slots;
+ esai_priv->tx_mask = tx_mask;
+ esai_priv->rx_mask = rx_mask;
return 0;
}
@@ -596,6 +590,7 @@ static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
u8 i, channels = substream->runtime->channels;
u32 pins = DIV_ROUND_UP(channels, esai_priv->slots);
+ u32 mask;
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -611,12 +606,23 @@ static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
tx ? ESAI_xCR_TE(pins) : ESAI_xCR_RE(pins));
+ mask = tx ? esai_priv->tx_mask : esai_priv->rx_mask;
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
+ ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
+ ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
+
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
+ ESAI_xSMA_xS_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
+ ESAI_xSMB_xS_MASK, 0);
/* Disable and reset FIFO */
regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx),
@@ -906,6 +912,15 @@ static int fsl_esai_probe(struct platform_device *pdev)
return ret;
}
+ esai_priv->tx_mask = 0xFFFFFFFF;
+ esai_priv->rx_mask = 0xFFFFFFFF;
+
+ /* Clear the TSMA, TSMB, RSMA, RSMB */
+ regmap_write(esai_priv->regmap, REG_ESAI_TSMA, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_TSMB, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_RSMA, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_RSMB, 0);
+
ret = devm_snd_soc_register_component(&pdev->dev, &fsl_esai_component,
&fsl_esai_dai, 1);
if (ret) {
--
1.9.1
^ permalink raw reply related
* Re: powerpc/64s: Remove MSR_RI optimisation in system_call_exit()
From: Michael Ellerman @ 2019-02-26 3:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: npiggin
In-Reply-To: <20190117113510.4265-1-mpe@ellerman.id.au>
On Thu, 2019-01-17 at 11:35:10 UTC, Michael Ellerman wrote:
> Currently in system_call_exit() we have an optimisation where we
> disable MSR_RI (recoverable interrupt) and MSR_EE (external interrupt
> enable) in a single mtmsrd instruction.
>
> Unfortunately this will no longer work with THREAD_INFO_IN_TASK,
> because then the load of TI_FLAGS might fault and faulting with MSR_RI
> clear is treated as an unrecoverable exception which leads to a
> panic().
>
> So change the code to only clear MSR_EE prior to loading TI_FLAGS,
> leaving the clear of MSR_RI until later. We have some latitude in
> where do the clear of MSR_RI. A bit of experimentation has shown that
> this location gives the least slow down.
>
> This still causes a noticeable slow down in our null_syscall
> performance. On a Power9 DD2.2:
>
> Before After Delta Delta %
> 955 cycles 999 cycles -44 -4.6%
>
> On the plus side this does simplify the code somewhat, because we
> don't have to reenable MSR_RI on the restore_math() or
> syscall_exit_work() paths which was necessitated previously by the
> optimisation.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/e7fda7e569e1776d4dccbcef52d34882
cheers
^ permalink raw reply
* Re: [v16, 01/21] powerpc/irq: use memblock functions returning virtual address
From: Michael Ellerman @ 2019-02-26 3:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: npiggin
In-Reply-To: <20190205113219.17903-2-mpe@ellerman.id.au>
On Tue, 2019-02-05 at 11:31:59 UTC, Michael Ellerman wrote:
> From: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Since only the virtual address of allocated blocks is used,
> lets use functions returning directly virtual address.
>
> Those functions have the advantage of also zeroing the block.
>
> Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c8e409a33cf8df5060064a70df3e1350
cheers
^ permalink raw reply
* Re: [v3, 1/2] powerpc/8xx: replace most #ifdef by IS_ENABLED() in 8xx_mmu.c
From: Michael Ellerman @ 2019-02-26 3:27 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <21f171c0cbd460905a134ce9b9afc2ecb5277269.1550073540.git.christophe.leroy@c-s.fr>
On Wed, 2019-02-13 at 16:06:19 UTC, Christophe Leroy wrote:
> This patch replaces most #ifdef mess by IS_ENABLED() in 8xx_mmu.c
> This has the advantage of allowing syntax verification at compile
> time regardless of selected options.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/665bed2386e5dc29844ad78c7ef14646
cheers
^ permalink raw reply
* Re: [1/3] powerpc: sstep: Add tests for compute type instructions
From: Michael Ellerman @ 2019-02-26 3:27 UTC (permalink / raw)
To: Sandipan Das; +Cc: naveen.n.rao, linuxppc-dev, dja, paulus, ravi.bangoria
In-Reply-To: <df7e1d69a6ac2ec3db8bb5481431d8ad8a28157a.1550645549.git.sandipan@linux.ibm.com>
On Wed, 2019-02-20 at 06:56:58 UTC, Sandipan Das wrote:
> This enhances the current selftest framework for validating
> the in-kernel instruction emulation infrastructure by adding
> support for compute type instructions i.e. integer ALU-based
> instructions. Originally, this framework was limited to only
> testing load and store instructions.
>
> While most of the GPRs can be validated, support for SPRs is
> limited to LR, CR and XER for now.
>
> When writing the test cases, one must ensure that the Stack
> Pointer (GPR1) or the Thread Pointer (GPR13) are not touched
> by any means as these are vital non-volatile registers.
>
> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/84022ac17327c5383917f46c162fd943
cheers
^ permalink raw reply
* Re: [v5, 01/16] powerpc/wii: properly disable use of BATs when requested.
From: Michael Ellerman @ 2019-02-26 3:27 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
j.neuschaefer
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e3ad0e890941de019189a616cbb40c3665264b37.1550775950.git.christophe.leroy@c-s.fr>
On Thu, 2019-02-21 at 19:08:37 UTC, Christophe Leroy wrote:
> 'nobats' kernel parameter or some options like CONFIG_DEBUG_PAGEALLOC
> deny the use of BATS for mapping memory.
>
> This patch makes sure that the specific wii RAM mapping function
> takes it into account as well.
>
> Fixes: de32400dd26e ("wii: use both mem1 and mem2 as ram")
> Cc: stable@vger.kernel.org
> Reviewed-by: Jonathan Neuschafer <j.neuschaefer@gmx.net>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6d183ca8baec983dc4208ca45ece3c36
cheers
^ permalink raw reply
* Re: [v3,2/2] powerpc: Enable kcov
From: Michael Ellerman @ 2019-02-26 3:27 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev; +Cc: syzkaller, dvyukov, npiggin, dja
In-Reply-To: <20190222004046.14914-2-andrew.donnellan@au1.ibm.com>
On Fri, 2019-02-22 at 00:40:46 UTC, Andrew Donnellan wrote:
> kcov provides kernel coverage data that's useful for fuzzing tools like
> syzkaller.
>
> Wire up kcov support on powerpc. Disable kcov instrumentation on the same
> files where we currently disable gcov and UBSan instrumentation, plus some
> additional exclusions which appear necessary to boot on book3e machines.
>
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Acked-by: Dmitry Vyukov <dvyukov@google.com>
> Tested-by: Daniel Axtens <dja@axtens.net> # e6500
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fb0b0a73b223fc113e961b1d92132284
cheers
^ permalink raw reply
* Re: powerpc/64: Simplify __secondary_start paca->kstack handling
From: Michael Ellerman @ 2019-02-26 3:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: paulus, matt
In-Reply-To: <20190223122439.24020-1-mpe@ellerman.id.au>
On Sat, 2019-02-23 at 12:24:39 UTC, Michael Ellerman wrote:
> In __secondary_start() we load the thread_info of the idle task of the
> secondary CPU from current_set[cpu], and then convert it into a stack
> pointer before storing that back to paca->kstack.
>
> As pointed out in commit f761622e5943 ("powerpc: Initialise
> paca->kstack before early_setup_secondary") it's important that we
> initialise paca->kstack before calling the MMU setup code, in
> particular slb_initialize(), because it will bolt the SLB entry for
> the kstack into the SLB.
>
> However we have already setup paca->kstack in cpu_idle_thread_init(),
> since commit 3b5750644b2f ("[POWERPC] Bolt in SLB entry for kernel
> stack on secondary cpus") (May 2008).
>
> It's also in cpu_idle_thread_init() that we initialise current_set[cpu]
> with the thread_info pointer, so there is no issue of the timing being
> different between the two.
>
> Therefore the initialisation of paca->kstack in __setup_secondary() is
> completely redundant, so remove it.
>
> This has the added benefit of removing code that runs in real mode,
> and is therefore restricted by the RMO, and so opens the way for us to
> enable THREAD_INFO_IN_TASK.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/eafd825ed7106ac1ca84d20d8b3b8682
cheers
^ permalink raw reply
* Re: [PATCH v7 06/11] powerpc/32: make KVIRT_TOP dependant on FIXMAP_START
From: kbuild test robot @ 2019-02-26 3:30 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-kernel, Nicholas Piggin, linux-mm, Paul Mackerras,
kbuild-all, Aneesh Kumar K.V, Andrey Ryabinin,
Alexander Potapenko, kasan-dev, linuxppc-dev, Dmitry Vyukov,
Daniel Axtens
In-Reply-To: <be8f68bbfc608d9edba17d74971e33c24294db39.1551098214.git.christophe.leroy@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.0-rc8]
[cannot apply to next-20190225]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Christophe-Leroy/KASAN-for-powerpc-32/20190226-052610
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-acadia_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
In file included from arch/powerpc/include/asm/nohash/pgtable.h:8,
from arch/powerpc/include/asm/pgtable.h:20,
from include/linux/mm.h:98,
from include/linux/highmem.h:8,
from arch/powerpc/mm/dma-noncoherent.c:31:
>> arch/powerpc/include/asm/nohash/32/pgtable.h:75:19: error: 'FIXADDR_START' undeclared here (not in a function); did you mean 'XAS_RESTART'?
#define KVIRT_TOP FIXADDR_START
^~~~~~~~~~~~~
arch/powerpc/include/asm/nohash/32/pgtable.h:84:23: note: in expansion of macro 'KVIRT_TOP'
#define IOREMAP_TOP ((KVIRT_TOP - CONFIG_CONSISTENT_SIZE) & PAGE_MASK)
^~~~~~~~~
arch/powerpc/mm/dma-noncoherent.c:47:27: note: in expansion of macro 'IOREMAP_TOP'
#define CONSISTENT_BASE (IOREMAP_TOP)
^~~~~~~~~~~
arch/powerpc/mm/dma-noncoherent.c:93:14: note: in expansion of macro 'CONSISTENT_BASE'
.vm_start = CONSISTENT_BASE,
^~~~~~~~~~~~~~~
vim +75 arch/powerpc/include/asm/nohash/32/pgtable.h
60
61 #define pte_ERROR(e) \
62 pr_err("%s:%d: bad pte %llx.\n", __FILE__, __LINE__, \
63 (unsigned long long)pte_val(e))
64 #define pgd_ERROR(e) \
65 pr_err("%s:%d: bad pgd %08lx.\n", __FILE__, __LINE__, pgd_val(e))
66
67 /*
68 * This is the bottom of the PKMAP area with HIGHMEM or an arbitrary
69 * value (for now) on others, from where we can start layout kernel
70 * virtual space that goes below PKMAP and FIXMAP
71 */
72 #ifdef CONFIG_HIGHMEM
73 #define KVIRT_TOP PKMAP_BASE
74 #else
> 75 #define KVIRT_TOP FIXADDR_START
76 #endif
77
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 11847 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/16] powerpc/xive: add OPAL extensions for the XIVE native exploitation support
From: David Gibson @ 2019-02-26 4:21 UTC (permalink / raw)
To: Cédric Le Goater
Cc: kvm, kvm-ppc, Paul Mackerras, Stewart Smith, linuxppc-dev
In-Reply-To: <543ff6a2-b892-6710-d218-6aed1414840f@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]
On Mon, Feb 25, 2019 at 11:11:58AM +0100, Cédric Le Goater wrote:
> On 2/25/19 4:50 AM, Michael Ellerman wrote:
> > Cédric Le Goater <clg@kaod.org> writes:
> >
> >> The support for XIVE native exploitation mode in Linux/KVM needs a
> >> couple more OPAL calls to configure the sPAPR guest and to get/set the
> >> state of the XIVE internal structures.
> >>
> >> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> >> ---
> >> arch/powerpc/include/asm/opal-api.h | 11 ++-
> >> arch/powerpc/include/asm/opal.h | 7 ++
> >> arch/powerpc/include/asm/xive.h | 14 +++
> >> arch/powerpc/sysdev/xive/native.c | 99 +++++++++++++++++++
> >> .../powerpc/platforms/powernv/opal-wrappers.S | 3 +
> >> 5 files changed, 130 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
> >> index 870fb7b239ea..cdfc54f78101 100644
> >> --- a/arch/powerpc/include/asm/opal-api.h
> >> +++ b/arch/powerpc/include/asm/opal-api.h
> >> @@ -186,8 +186,8 @@
> >> #define OPAL_XIVE_FREE_IRQ 140
> >> #define OPAL_XIVE_SYNC 141
> >> #define OPAL_XIVE_DUMP 142
> >> -#define OPAL_XIVE_RESERVED3 143
> >> -#define OPAL_XIVE_RESERVED4 144
> >> +#define OPAL_XIVE_GET_QUEUE_STATE 143
> >> +#define OPAL_XIVE_SET_QUEUE_STATE 144
> >> #define OPAL_SIGNAL_SYSTEM_RESET 145
> >> #define OPAL_NPU_INIT_CONTEXT 146
> >> #define OPAL_NPU_DESTROY_CONTEXT 147
> >> @@ -209,8 +209,11 @@
> >> #define OPAL_SENSOR_GROUP_ENABLE 163
> >> #define OPAL_PCI_GET_PBCQ_TUNNEL_BAR 164
> >> #define OPAL_PCI_SET_PBCQ_TUNNEL_BAR 165
> >> -#define OPAL_NX_COPROC_INIT 167
> >> -#define OPAL_LAST 167
> >> +#define OPAL_HANDLE_HMI2 166
> >> +#define OPAL_NX_COPROC_INIT 167
> >> +#define OPAL_NPU_SET_RELAXED_ORDER 168
> >> +#define OPAL_NPU_GET_RELAXED_ORDER 169
> >> +#define OPAL_XIVE_GET_VP_STATE 170
> >
> > You should only be defining the calls you need, leaving gaps for other
> > things, and you need to retain OPAL_LAST. So it should look more like:
> >
> > -#define OPAL_LAST 167
> > +#define OPAL_XIVE_GET_VP_STATE 170
> > +#define OPAL_LAST 170
> >
> >
> > Also I can't merge this until it's merged into skiboot.
>
> OK. Let's start with skiboot.
Yeah.. where are we at with skiboot in general. We can't test this
downstream until we have a released skiboot with the necessary
support.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2 1/2] powerpc/hugetlb: Handle mmap_min_addr correctly in get_unmapped_area callback
From: Aneesh Kumar K.V @ 2019-02-26 4:39 UTC (permalink / raw)
To: npiggin, benh, paulus, mpe; +Cc: Aneesh Kumar K.V, Laurent Dufour, linuxppc-dev
After we ALIGN up the address we need to make sure we didn't overflow
and resulted in zero address. In that case, we need to make sure that
the returned address is greater than mmap_min_addr.
This fixes selftest va_128TBswitch --run-hugetlb reporting failures when
run as non root user for
mmap(-1, MAP_HUGETLB)
The bug is that a non-root user requesting address -1 will be given address 0
which will then fail, whereas they should have been given something else that
would have succeeded.
We also avoid the first mmap(-1, MAP_HUGETLB) returning NULL address as mmap address
with this change. So we think this is not a security issue, because it only affects
whether we choose an address below mmap_min_addr, not whether we
actually allow that address to be mapped. ie. there are existing capability
checks to prevent a user mapping below mmap_min_addr and those will still be
honoured even without this fix.
Fixes: 484837601d4d ("powerpc/mm: Add radix support for hugetlb")
Reviewed-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/hugetlbpage-radix.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee0f93e..97c7a39ebc00 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/mm.h>
#include <linux/hugetlb.h>
+#include <linux/security.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
#include <asm/cacheflush.h>
@@ -73,7 +74,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
if (addr) {
addr = ALIGN(addr, huge_page_size(h));
vma = find_vma(mm, addr);
- if (high_limit - len >= addr &&
+ if (high_limit - len >= addr && addr >= mmap_min_addr &&
(!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
@@ -83,7 +84,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
*/
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
- info.low_limit = PAGE_SIZE;
+ info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 2/2] powerpc/mm/hash: Handle mmap_min_addr correctly in get_unmapped_area topdown search
From: Aneesh Kumar K.V @ 2019-02-26 4:39 UTC (permalink / raw)
To: npiggin, benh, paulus, mpe; +Cc: Aneesh Kumar K.V, Laurent Dufour, linuxppc-dev
In-Reply-To: <20190226043935.14053-1-aneesh.kumar@linux.ibm.com>
When doing top-down search the low_limit is not PAGE_SIZE but rather
max(PAGE_SIZE, mmap_min_addr). This handle cases in which mmap_min_addr >
PAGE_SIZE.
Fixes: fba2369e6ceb ("mm: use vm_unmapped_area() on powerpc architecture")
Reviewed-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/slice.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 06898c13901d..aec91dbcdc0b 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -32,6 +32,7 @@
#include <linux/export.h>
#include <linux/hugetlb.h>
#include <linux/sched/mm.h>
+#include <linux/security.h>
#include <asm/mman.h>
#include <asm/mmu.h>
#include <asm/copro.h>
@@ -377,6 +378,7 @@ static unsigned long slice_find_area_topdown(struct mm_struct *mm,
int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT);
unsigned long addr, found, prev;
struct vm_unmapped_area_info info;
+ unsigned long min_addr = max(PAGE_SIZE, mmap_min_addr);
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
@@ -393,7 +395,7 @@ static unsigned long slice_find_area_topdown(struct mm_struct *mm,
if (high_limit > DEFAULT_MAP_WINDOW)
addr += mm->context.slb_addr_limit - DEFAULT_MAP_WINDOW;
- while (addr > PAGE_SIZE) {
+ while (addr > min_addr) {
info.high_limit = addr;
if (!slice_scan_available(addr - 1, available, 0, &addr))
continue;
@@ -405,8 +407,8 @@ static unsigned long slice_find_area_topdown(struct mm_struct *mm,
* Check if we need to reduce the range, or if we can
* extend it to cover the previous available slice.
*/
- if (addr < PAGE_SIZE)
- addr = PAGE_SIZE;
+ if (addr < min_addr)
+ addr = min_addr;
else if (slice_scan_available(addr - 1, available, 0, &prev)) {
addr = prev;
goto prev_slice;
@@ -528,7 +530,7 @@ unsigned long slice_get_unmapped_area(unsigned long addr, unsigned long len,
addr = _ALIGN_UP(addr, page_size);
slice_dbg(" aligned addr=%lx\n", addr);
/* Ignore hint if it's too large or overlaps a VMA */
- if (addr > high_limit - len ||
+ if (addr > high_limit - len || addr < mmap_min_addr ||
!slice_area_is_free(mm, addr, len))
addr = 0;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v7 07/11] powerpc/32: prepare shadow area for KASAN
From: Daniel Axtens @ 2019-02-26 5:12 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Nicholas Piggin, Aneesh Kumar K.V,
Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov
Cc: linux-mm, linuxppc-dev, linux-kernel, kasan-dev
In-Reply-To: <bada5c0051f749565d27da9527ce933aa205bf86.1551098214.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> This patch prepares a shadow area for KASAN.
>
> The shadow area will be at the top of the kernel virtual
> memory space above the fixmap area and will occupy one
> eighth of the total kernel virtual memory space.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/Kconfig | 5 +++++
> arch/powerpc/include/asm/fixmap.h | 5 +++++
> arch/powerpc/include/asm/kasan.h | 17 +++++++++++++++++
> arch/powerpc/mm/mem.c | 4 ++++
> arch/powerpc/mm/ptdump/ptdump.c | 8 ++++++++
> 5 files changed, 39 insertions(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 652c25260838..f446e016f4a1 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -382,6 +382,11 @@ config PGTABLE_LEVELS
> default 3 if PPC_64K_PAGES && !PPC_BOOK3S_64
> default 4
>
> +config KASAN_SHADOW_OFFSET
> + hex
> + depends on KASAN
> + default 0xe0000000
> +
Should this live in Kconfig.debug?
Regards,
Daniel
> source "arch/powerpc/sysdev/Kconfig"
> source "arch/powerpc/platforms/Kconfig"
>
> diff --git a/arch/powerpc/include/asm/fixmap.h b/arch/powerpc/include/asm/fixmap.h
> index b9fbed84ddca..51a1a309c919 100644
> --- a/arch/powerpc/include/asm/fixmap.h
> +++ b/arch/powerpc/include/asm/fixmap.h
> @@ -22,7 +22,12 @@
> #include <asm/kmap_types.h>
> #endif
>
> +#ifdef CONFIG_KASAN
> +#include <asm/kasan.h>
> +#define FIXADDR_TOP KASAN_SHADOW_START
> +#else
> #define FIXADDR_TOP ((unsigned long)(-PAGE_SIZE))
> +#endif
>
> /*
> * Here we define all the compile-time 'special' virtual
> diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h
> index 2efd0e42cfc9..b554d3bd3e2c 100644
> --- a/arch/powerpc/include/asm/kasan.h
> +++ b/arch/powerpc/include/asm/kasan.h
> @@ -12,4 +12,21 @@
> #define EXPORT_SYMBOL_KASAN(fn) EXPORT_SYMBOL(fn)
> #endif
>
> +#ifndef __ASSEMBLY__
> +
> +#include <asm/page.h>
> +#include <asm/pgtable-types.h>
> +
> +#define KASAN_SHADOW_SCALE_SHIFT 3
> +
> +#define KASAN_SHADOW_OFFSET ASM_CONST(CONFIG_KASAN_SHADOW_OFFSET)
> +
> +#define KASAN_SHADOW_START (KASAN_SHADOW_OFFSET + \
> + (PAGE_OFFSET >> KASAN_SHADOW_SCALE_SHIFT))
> +
> +#define KASAN_SHADOW_END 0UL
> +
> +#define KASAN_SHADOW_SIZE (KASAN_SHADOW_END - KASAN_SHADOW_START)
> +
> +#endif /* __ASSEMBLY */
> #endif
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index f6787f90e158..4e7fa4eb2dd3 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -309,6 +309,10 @@ void __init mem_init(void)
> mem_init_print_info(NULL);
> #ifdef CONFIG_PPC32
> pr_info("Kernel virtual memory layout:\n");
> +#ifdef CONFIG_KASAN
> + pr_info(" * 0x%08lx..0x%08lx : kasan shadow mem\n",
> + KASAN_SHADOW_START, KASAN_SHADOW_END);
> +#endif
> pr_info(" * 0x%08lx..0x%08lx : fixmap\n", FIXADDR_START, FIXADDR_TOP);
> #ifdef CONFIG_HIGHMEM
> pr_info(" * 0x%08lx..0x%08lx : highmem PTEs\n",
> diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
> index 37138428ab55..812ed680024f 100644
> --- a/arch/powerpc/mm/ptdump/ptdump.c
> +++ b/arch/powerpc/mm/ptdump/ptdump.c
> @@ -101,6 +101,10 @@ static struct addr_marker address_markers[] = {
> { 0, "Fixmap start" },
> { 0, "Fixmap end" },
> #endif
> +#ifdef CONFIG_KASAN
> + { 0, "kasan shadow mem start" },
> + { 0, "kasan shadow mem end" },
> +#endif
> { -1, NULL },
> };
>
> @@ -322,6 +326,10 @@ static void populate_markers(void)
> #endif
> address_markers[i++].start_address = FIXADDR_START;
> address_markers[i++].start_address = FIXADDR_TOP;
> +#ifdef CONFIG_KASAN
> + address_markers[i++].start_address = KASAN_SHADOW_START;
> + address_markers[i++].start_address = KASAN_SHADOW_END;
> +#endif
> #endif /* CONFIG_PPC64 */
> }
>
> --
> 2.13.3
^ permalink raw reply
* Re: [PATCH v2 04/16] KVM: PPC: Book3S HV: XIVE: add a control to initialize a source
From: Paul Mackerras @ 2019-02-26 4:25 UTC (permalink / raw)
To: David Gibson; +Cc: kvm, kvm-ppc, Cédric Le Goater, linuxppc-dev
In-Reply-To: <20190225021012.GH7668@umbus.fritz.box>
On Mon, Feb 25, 2019 at 01:10:12PM +1100, David Gibson wrote:
> On Fri, Feb 22, 2019 at 12:28:28PM +0100, Cédric Le Goater wrote:
> > + /*
> > + * If the source doesn't already have an IPI, allocate
> > + * one and get the corresponding data
> > + */
> > + if (!state->ipi_number) {
> > + state->ipi_number = xive_native_alloc_irq();
> > + if (state->ipi_number == 0) {
> > + pr_err("Failed to allocate IRQ !\n");
> > + return -ENXIO;
> > + }
> > + xive_native_populate_irq_data(state->ipi_number,
> > + &state->ipi_data);
> > + pr_debug("%s allocated hw_irq=0x%x for irq=0x%lx\n", __func__,
> > + state->ipi_number, irq);
> > + }
> > +
> > + arch_spin_lock(&sb->lock);
>
> Why the direct call to arch_spin_lock() rather than just spin_lock()?
He's sharing data structures with the xics-on-xive code, and that code
has a real-mode variant, and in real mode we don't want to risk
invoking lockdep code. Hence sb->lock is an arch_spinlock_t, and he
has to use arch_spin_lock() on it.
Paul.
^ permalink raw reply
* Re: [PATCH v2 06/16] KVM: PPC: Book3S HV: XIVE: add controls for the EQ configuration
From: Paul Mackerras @ 2019-02-26 5:24 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, linuxppc-dev, David Gibson
In-Reply-To: <20190222112840.25000-7-clg@kaod.org>
On Fri, Feb 22, 2019 at 12:28:30PM +0100, Cédric Le Goater wrote:
> These controls will be used by the H_INT_SET_QUEUE_CONFIG and
> H_INT_GET_QUEUE_CONFIG hcalls from QEMU. They will also be used to
> restore the configuration of the XIVE EQs in the KVM device and to
> capture the internal runtime state of the EQs. Both 'get' and 'set'
> rely on an OPAL call to access from the XIVE interrupt controller the
> EQ toggle bit and EQ index which are updated by the HW when event
> notifications are enqueued in the EQ.
>
> The value of the guest physical address of the event queue is saved in
> the XIVE internal xive_q structure for later use. That is when
> migration needs to mark the EQ pages dirty to capture a consistent
> memory state of the VM.
>
> To be noted that H_INT_SET_QUEUE_CONFIG does not require the extra
> OPAL call setting the EQ toggle bit and EQ index to configure the EQ,
> but restoring the EQ state will.
[snip]
> +/* Layout of 64-bit eq attribute */
> +#define KVM_XIVE_EQ_PRIORITY_SHIFT 0
> +#define KVM_XIVE_EQ_PRIORITY_MASK 0x7
> +#define KVM_XIVE_EQ_SERVER_SHIFT 3
> +#define KVM_XIVE_EQ_SERVER_MASK 0xfffffff8ULL
> +
> +/* Layout of 64-bit eq attribute values */
> +struct kvm_ppc_xive_eq {
> + __u32 flags;
> + __u32 qsize;
> + __u64 qpage;
> + __u32 qtoggle;
> + __u32 qindex;
> + __u8 pad[40];
> +};
This is confusing. What's the difference between an "eq attribute"
and an "eq attribute value"? Is the first actually a queue index or
a queue identifier?
Also, the kvm_ppc_xive_eq is not 64 bits, so the comment above it is
wrong. Maybe you meant "64-byte"?
[snip]
> + page = gfn_to_page(kvm, gpa_to_gfn(kvm_eq.qpage));
> + if (is_error_page(page)) {
> + pr_warn("Couldn't get guest page for %llx!\n", kvm_eq.qpage);
> + return -ENOMEM;
> + }
> + qaddr = page_to_virt(page) + (kvm_eq.qpage & ~PAGE_MASK);
Isn't this assuming that we can map the whole queue with a single
gfn_to_page? That would only be true if kvm_eq.qsize <= PAGE_SHIFT.
What happens if kvm_eq.qsize > PAGE_SHIFT?
Paul.
^ permalink raw reply
* Re: [PATCH] tools: testing: selftests: Remove duplicate headers
From: Souptick Joarder @ 2019-02-26 5:29 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-fsdevel, John Stultz, Andrew Morton, linux-gpio,
Peter Zijlstra, boqun.feng, linuxppc-dev, linux-kernel,
David S. Miller, sboyd, Sabyasachi Gupta, Bamvor Zhang,
linux-kselftest, netdev, Mathieu Desnoyers, Paul Mackerras,
Thomas Gleixner, Paul McKenney, shuah, Alexey Dobriyan
In-Reply-To: <87tvgr1fr4.fsf@concordia.ellerman.id.au>
On Tue, Feb 26, 2019 at 7:18 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Souptick Joarder <jrdr.linux@gmail.com> writes:
> > Remove duplicate headers which are included twice.
> >
> > Signed-off-by: Sabyasachi Gupta <sabyasachi.linux@gmail.com>
> > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> > ---
> ...
> > tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c | 1 -
>
> I took this hunk via the powerpc tree.
How about taking this entirely through a single tree ?
or Shall I send these changes in different patches ?
>
> > diff --git a/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c b/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
> > index 167135b..af1b802 100644
> > --- a/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
> > +++ b/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
> > @@ -11,7 +11,6 @@
> > #include <sys/wait.h>
> > #include <unistd.h>
> > #include <setjmp.h>
> > -#include <signal.h>
> >
> > #include "ebb.h"
>
>
> cheers
^ permalink raw reply
* [PATCH] powerpc/xmon: Fix opcode being uninitialized in print_insn_powerpc
From: Nathan Chancellor @ 2019-02-26 5:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Nick Desaulniers, Nathan Chancellor, linuxppc-dev, linux-kernel,
Joel Stanley
When building with -Wsometimes-uninitialized, Clang warns:
arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
if (cpu_has_feature(CPU_FTRS_POWER9))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/xmon/ppc-dis.c:167:7: note: uninitialized use occurs here
if (opcode == NULL)
^~~~~~
arch/powerpc/xmon/ppc-dis.c:157:3: note: remove the 'if' if its
condition is always true
if (cpu_has_feature(CPU_FTRS_POWER9))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/xmon/ppc-dis.c:132:38: note: initialize the variable
'opcode' to silence this warning
const struct powerpc_opcode *opcode;
^
= NULL
1 warning generated.
This warning seems to make no sense on the surface because opcode is set
to NULL right below this statement. However, there is a comma instead of
semicolon to end the dialect assignment, meaning that the opcode
assignment only happens in the if statement. Properly terminate that
line so that Clang no longer warns.
Fixes: 5b102782c7f4 ("powerpc/xmon: Enable disassembly files (compilation changes)")
Link: https://github.com/ClangBuiltLinux/linux/issues/390
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/powerpc/xmon/ppc-dis.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/xmon/ppc-dis.c b/arch/powerpc/xmon/ppc-dis.c
index 9deea5ee13f6..27f1e6415036 100644
--- a/arch/powerpc/xmon/ppc-dis.c
+++ b/arch/powerpc/xmon/ppc-dis.c
@@ -158,7 +158,7 @@ int print_insn_powerpc (unsigned long insn, unsigned long memaddr)
dialect |= (PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7
| PPC_OPCODE_POWER8 | PPC_OPCODE_POWER9 | PPC_OPCODE_HTM
| PPC_OPCODE_ALTIVEC | PPC_OPCODE_ALTIVEC2
- | PPC_OPCODE_VSX | PPC_OPCODE_VSX3),
+ | PPC_OPCODE_VSX | PPC_OPCODE_VSX3);
/* Get the major opcode of the insn. */
opcode = NULL;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] powerpc/xmon: Fix opcode being uninitialized in print_insn_powerpc
From: Nick Desaulniers @ 2019-02-26 5:43 UTC (permalink / raw)
To: Nathan Chancellor; +Cc: LKML, Paul Mackerras, Joel Stanley, linuxppc-dev
In-Reply-To: <20190226053855.7020-1-natechancellor@gmail.com>
On Mon, Feb 25, 2019 at 9:39 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> When building with -Wsometimes-uninitialized, Clang warns:
>
> arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used
> uninitialized whenever 'if' condition is false
> [-Wsometimes-uninitialized]
> if (cpu_has_feature(CPU_FTRS_POWER9))
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/xmon/ppc-dis.c:167:7: note: uninitialized use occurs here
> if (opcode == NULL)
> ^~~~~~
> arch/powerpc/xmon/ppc-dis.c:157:3: note: remove the 'if' if its
> condition is always true
> if (cpu_has_feature(CPU_FTRS_POWER9))
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/xmon/ppc-dis.c:132:38: note: initialize the variable
> 'opcode' to silence this warning
> const struct powerpc_opcode *opcode;
> ^
> = NULL
> 1 warning generated.
>
> This warning seems to make no sense on the surface because opcode is set
> to NULL right below this statement. However, there is a comma instead of
> semicolon to end the dialect assignment, meaning that the opcode
> assignment only happens in the if statement. Properly terminate that
> line so that Clang no longer warns.
>
> Fixes: 5b102782c7f4 ("powerpc/xmon: Enable disassembly files (compilation changes)")
> Link: https://github.com/ClangBuiltLinux/linux/issues/390
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
haha! (shows office mates). Nice find, and fix!
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> arch/powerpc/xmon/ppc-dis.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/xmon/ppc-dis.c b/arch/powerpc/xmon/ppc-dis.c
> index 9deea5ee13f6..27f1e6415036 100644
> --- a/arch/powerpc/xmon/ppc-dis.c
> +++ b/arch/powerpc/xmon/ppc-dis.c
> @@ -158,7 +158,7 @@ int print_insn_powerpc (unsigned long insn, unsigned long memaddr)
> dialect |= (PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7
> | PPC_OPCODE_POWER8 | PPC_OPCODE_POWER9 | PPC_OPCODE_HTM
> | PPC_OPCODE_ALTIVEC | PPC_OPCODE_ALTIVEC2
> - | PPC_OPCODE_VSX | PPC_OPCODE_VSX3),
> + | PPC_OPCODE_VSX | PPC_OPCODE_VSX3);
>
> /* Get the major opcode of the insn. */
> opcode = NULL;
> --
> 2.21.0
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH v3 1/4] powerpc/64s: Fix HV NMI vs HV interrupt recoverability test
From: Nicholas Piggin @ 2019-02-26 6:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20190226060901.18715-1-npiggin@gmail.com>
HV interrupts that use HSRR registers do not enter with MSR[RI] clear,
but their entry code is not recoverable vs NMI, due to shared use of
HSPRG1 as a scratch register to save r13.
This means that a system reset or machine check that hits in HSRR
interrupt entry can cause r13 to be silently corrupted.
Fix this by marking NMIs non-recoverable if they land in HV interrupt
ranges.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/asm-prototypes.h | 8 +++
arch/powerpc/include/asm/nmi.h | 2 +
arch/powerpc/kernel/exceptions-64s.S | 8 +++
arch/powerpc/kernel/mce.c | 3 ++
arch/powerpc/kernel/traps.c | 66 +++++++++++++++++++++++
5 files changed, 87 insertions(+)
diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
index 1d911f68a23b..0f8326644fa4 100644
--- a/arch/powerpc/include/asm/asm-prototypes.h
+++ b/arch/powerpc/include/asm/asm-prototypes.h
@@ -51,6 +51,14 @@ int exit_vmx_usercopy(void);
int enter_vmx_ops(void);
void *exit_vmx_ops(void *dest);
+/* Exceptions */
+#ifdef CONFIG_PPC_POWERNV
+extern unsigned long real_trampolines_start;
+extern unsigned long real_trampolines_end;
+extern unsigned long virt_trampolines_start;
+extern unsigned long virt_trampolines_end;
+#endif
+
/* Traps */
long machine_check_early(struct pt_regs *regs);
long hmi_exception_realmode(struct pt_regs *regs);
diff --git a/arch/powerpc/include/asm/nmi.h b/arch/powerpc/include/asm/nmi.h
index bd9ba8defd72..84b4cfe73edd 100644
--- a/arch/powerpc/include/asm/nmi.h
+++ b/arch/powerpc/include/asm/nmi.h
@@ -14,4 +14,6 @@ extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask,
#define arch_trigger_cpumask_backtrace arch_trigger_cpumask_backtrace
#endif
+extern void hv_nmi_check_nonrecoverable(struct pt_regs *regs);
+
#endif /* _ASM_NMI_H */
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 9e253ce27e08..d2e9fc968655 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -68,6 +68,14 @@ OPEN_FIXED_SECTION(real_vectors, 0x0100, 0x1900)
OPEN_FIXED_SECTION(real_trampolines, 0x1900, 0x4000)
OPEN_FIXED_SECTION(virt_vectors, 0x4000, 0x5900)
OPEN_FIXED_SECTION(virt_trampolines, 0x5900, 0x7000)
+
+#ifdef CONFIG_PPC_POWERNV
+ .globl real_trampolines_start
+ .globl real_trampolines_end
+ .globl virt_trampolines_start
+ .globl virt_trampolines_end
+#endif
+
#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
/*
* Data area reserved for FWNMI option.
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index bd933a75f0bc..d653b5de4537 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -31,6 +31,7 @@
#include <asm/machdep.h>
#include <asm/mce.h>
+#include <asm/nmi.h>
static DEFINE_PER_CPU(int, mce_nest_count);
static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT], mce_event);
@@ -488,6 +489,8 @@ long machine_check_early(struct pt_regs *regs)
{
long handled = 0;
+ hv_nmi_check_nonrecoverable(regs);
+
/*
* See if platform is capable of handling machine check.
*/
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 64936b60d521..12b54908c15d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -376,6 +376,70 @@ void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr)
force_sig_fault(signr, code, (void __user *)addr, current);
}
+/*
+ * The interrupt architecture has a quirk in that the HV interrupts excluding
+ * the NMIs (0x100 and 0x200) do not clear MSR[RI] at entry. The first thing
+ * that an interrupt handler must do is save off a GPR into a scratch register,
+ * and all interrupts on POWERNV (HV=1) use the HSPRG1 register as scratch.
+ * Therefore an NMI can clobber an HV interrupt's live HSPRG1 without noticing
+ * that it is non-reentrant, which leads to random data corruption.
+ *
+ * The solution is for NMI interrupts in HV mode to check if they originated
+ * from these critical HV interrupt regions. If so, then mark them not
+ * recoverable.
+ *
+ * An alternative would be for HV NMIs to use SPRG for scratch to avoid the
+ * HSPRG1 clobber, however this would cause guest SPRG to be clobbered. Linux
+ * guests should always have MSR[RI]=0 when its scratch SPRG is in use, so
+ * that would work. However any other guest OS that may have the SPRG live
+ * and MSR[RI]=1 could encounter silent corruption.
+ *
+ * Builds that do not support KVM could take this second option to increase
+ * the recoverability of NMIs.
+ */
+void hv_nmi_check_nonrecoverable(struct pt_regs *regs)
+{
+#ifdef CONFIG_PPC_POWERNV
+ unsigned long kbase = (unsigned long)_stext;
+ unsigned long nip = regs->nip;
+
+ if (!(regs->msr & MSR_RI))
+ return;
+ if (!(regs->msr & MSR_HV))
+ return;
+ if (regs->msr & MSR_PR)
+ return;
+
+ /*
+ * Now test if the interrupt has hit a range that may be using
+ * HSPRG1 without having RI=0 (i.e., an HSRR interrupt). The
+ * problem ranges all run un-relocated. Test real and virt modes
+ * at the same time by droping the high bit of the nip (virt mode
+ * entry points still have the +0x4000 offset).
+ */
+ nip &= ~0xc000000000000000ULL;
+ if ((nip >= 0x500 && nip < 0x600) || (nip >= 0x4500 && nip < 0x4600))
+ goto nonrecoverable;
+ if ((nip >= 0x980 && nip < 0xa00) || (nip >= 0x4980 && nip < 0x4a00))
+ goto nonrecoverable;
+ if ((nip >= 0xe00 && nip < 0xec0) || (nip >= 0x4e00 && nip < 0x4ec0))
+ goto nonrecoverable;
+ if ((nip >= 0xf80 && nip < 0xfa0) || (nip >= 0x4f80 && nip < 0x4fa0))
+ goto nonrecoverable;
+ /* Trampoline code runs un-relocated so subtract kbase. */
+ if (nip >= real_trampolines_start - kbase &&
+ nip < real_trampolines_end - kbase)
+ goto nonrecoverable;
+ if (nip >= virt_trampolines_start - kbase &&
+ nip < virt_trampolines_end - kbase)
+ goto nonrecoverable;
+ return;
+
+nonrecoverable:
+ regs->msr &= ~MSR_RI;
+#endif
+}
+
void system_reset_exception(struct pt_regs *regs)
{
/*
@@ -386,6 +450,8 @@ void system_reset_exception(struct pt_regs *regs)
if (!nested)
nmi_enter();
+ hv_nmi_check_nonrecoverable(regs);
+
__this_cpu_inc(irq_stat.sreset_irqs);
/* See if any machine dependent calls */
--
2.18.0
^ permalink raw reply related
* [PATCH v3 0/4] Fixes for 3 separate NMI reentrancy bugs
From: Nicholas Piggin @ 2019-02-26 6:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
This series fixes several similar but unrelated bugs with NMIs
clobbering live registers without noticing it, because MSR[RI] is set.
Pretty rare bugs, but serious silent corruption consequences.
For the most part these can be observed and tested quite easily
with the mambo simulator, except that it does not seem to follow
the architecture wrt leaving MSR[RI] unchanged for HV interrupts.
Mambo clears MSR[RI], so you have to account for that manually.
Since v1:
- Fixed several build bugs.
Since v2:
- Improved changelog and comments.
- Fixed the NIA test for virt mode interrupts.
Nicholas Piggin (4):
powerpc/64s: Fix HV NMI vs HV interrupt recoverability test
powerpc/64s: system reset interrupt preserve HSRRs
powerpc/64s: Prepare to handle data interrupts vs d-side MCE
reentrancy
powerpc/64s: Fix data interrupts vs d-side MCE reentrancy
arch/powerpc/include/asm/asm-prototypes.h | 8 ++
arch/powerpc/include/asm/nmi.h | 2 +
arch/powerpc/kernel/exceptions-64s.S | 92 +++++++++++++++++++----
arch/powerpc/kernel/mce.c | 3 +
arch/powerpc/kernel/traps.c | 91 +++++++++++++++++++++-
5 files changed, 179 insertions(+), 17 deletions(-)
--
2.18.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox