* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Arnd Bergmann @ 2020-09-22 9:01 UTC (permalink / raw)
To: Pavel Begunkov
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390,
Linux SCSI List, X86 ML, linux-block, Al Viro, Andy Lutomirski,
io-uring, linux-arm-kernel, Jens Axboe, Parisc List,
Network Development, LKML, LSM List, Linux FS Devel,
Andrew Morton, linuxppc-dev
In-Reply-To: <f25b4708-eba6-78d6-03f9-5bfb04e07627@gmail.com>
On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
> On 22/09/2020 10:23, Arnd Bergmann wrote:
> > On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
> >> On 22/09/2020 03:58, Andy Lutomirski wrote:
> >>> On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
> >>> I may be looking at a different kernel than you, but aren't you
> >>> preventing creating an io_uring regardless of whether SQPOLL is
> >>> requested?
> >>
> >> I diffed a not-saved file on a sleepy head, thanks for noticing.
> >> As you said, there should be an SQPOLL check.
> >>
> >> ...
> >> if (ctx->compat && (p->flags & IORING_SETUP_SQPOLL))
> >> goto err;
> >
> > Wouldn't that mean that now 32-bit containers behave differently
> > between compat and native execution?
> >
> > I think if you want to prevent 32-bit applications from using SQPOLL,
> > it needs to be done the same way on both to be consistent:
>
> The intention was to disable only compat not native 32-bit.
I'm not following why that would be considered a valid option,
as that clearly breaks existing users that update from a 32-bit
kernel to a 64-bit one.
Taking away the features from users that are still on 32-bit kernels
already seems questionable to me, but being inconsistent
about it seems much worse, in particular when the regression
is on the upgrade path.
> > Can we expect all existing and future user space to have a sane
> > fallback when IORING_SETUP_SQPOLL fails?
>
> SQPOLL has a few differences with non-SQPOLL modes, but it's easy
> to convert between them. Anyway, SQPOLL is a privileged special
> case that's here for performance/latency reasons, I don't think
> there will be any non-accidental users of it.
Ok, so the behavior of 32-bit tasks would be the same as running
the same application as unprivileged 64-bit tasks, with applications
already having to implement that fallback, right?
Arnd
^ permalink raw reply
* [PATCH] i2c: cpm: Fix i2c_ram structure
From: nico.vince @ 2020-09-22 9:04 UTC (permalink / raw)
To: jochen; +Cc: Nicolas VINCENT, linuxppc-dev, linux-i2c
From: Nicolas VINCENT <nicolas.vincent@vossloh.com>
the i2c_ram structure is missing the sdmatmp field mentionned in
datasheet for MPC8272 at paragraph 36.5. With this field missing, the
hardware would write past the allocated memory done through
cpm_muram_alloc for the i2c_ram structure and land in memory allocated
for the buffers descriptors corrupting the cbd_bufaddr field. Since this
field is only set during setup(), the first i2c transaction would work
and the following would send data read from an arbitrary memory
location.
Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
---
drivers/i2c/busses/i2c-cpm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 1213e1932ccb..c5700addbf65 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -64,7 +64,8 @@ struct i2c_ram {
uint txtmp; /* Internal */
char res1[4]; /* Reserved */
ushort rpbase; /* Relocation pointer */
- char res2[2]; /* Reserved */
+ char res2[6]; /* Reserved */
+ uint sdmatmp; /* Internal */
};
#define I2COM_START 0x80
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V2] powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints
From: Paul A. Clarke @ 2020-09-22 10:46 UTC (permalink / raw)
To: Athira Rajeev; +Cc: maddy, linuxppc-dev
In-Reply-To: <1600672204-1610-1-git-send-email-atrajeev@linux.vnet.ibm.com>
Just one nit in a comment below...
(and this is not worthy of tags like "reviewed-by" ;-)
On Mon, Sep 21, 2020 at 03:10:04AM -0400, Athira Rajeev wrote:
> PMU counter support functions enforces event constraints for group of
> events to check if all events in a group can be monitored. Incase of
> event codes using PMC5 and PMC6 ( 500fa and 600f4 respectively ),
> not all constraints are applicable, say the threshold or sample bits.
> But current code includes pmc5 and pmc6 in some group constraints (like
> IC_DC Qualifier bits) which is actually not applicable and hence results
> in those events not getting counted when scheduled along with group of
> other events. Patch fixes this by excluding PMC5/6 from constraints
> which are not relevant for it.
>
> Fixes: 7ffd948 ("powerpc/perf: factor out power8 pmu functions")
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
> diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
> index 964437a..12153da 100644
> --- a/arch/powerpc/perf/isa207-common.c
> +++ b/arch/powerpc/perf/isa207-common.c
> @@ -288,6 +288,15 @@ int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)
>
> mask |= CNST_PMC_MASK(pmc);
> value |= CNST_PMC_VAL(pmc);
> +
> + /*
> + * PMC5 and PMC6 are used to count cycles and instructions
> + * and these doesnot support most of the constraint bits.
s/doesnot/do not/
> + * Add a check to exclude PMC5/6 from most of the constraints
> + * except for ebb/bhrb.
> + */
> + if (pmc >= 5)
> + goto ebb_bhrb;
PC
^ permalink raw reply
* Re: [PATCH] i2c: cpm: Fix i2c_ram structure
From: Joakim Tjernlund @ 2020-09-22 11:50 UTC (permalink / raw)
To: nicolas.vincent@vossloh.com, jochen@scram.de,
christophe.leroy@c-s.fr
Cc: linuxppc-dev@lists.ozlabs.org, linux-i2c@vger.kernel.org
In-Reply-To: <20200922090400.6282-1-nicolas.vincent@vossloh.com>
On Tue, 2020-09-22 at 11:04 +0200, nico.vince@gmail.com wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> From: Nicolas VINCENT <nicolas.vincent@vossloh.com>
>
> the i2c_ram structure is missing the sdmatmp field mentionned in
> datasheet for MPC8272 at paragraph 36.5. With this field missing, the
> hardware would write past the allocated memory done through
> cpm_muram_alloc for the i2c_ram structure and land in memory allocated
> for the buffers descriptors corrupting the cbd_bufaddr field. Since this
> field is only set during setup(), the first i2c transaction would work
> and the following would send data read from an arbitrary memory
> location.
>
> Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
> ---
> drivers/i2c/busses/i2c-cpm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
> index 1213e1932ccb..c5700addbf65 100644
> --- a/drivers/i2c/busses/i2c-cpm.c
> +++ b/drivers/i2c/busses/i2c-cpm.c
> @@ -64,7 +64,8 @@ struct i2c_ram {
> uint txtmp; /* Internal */
> char res1[4]; /* Reserved */
> ushort rpbase; /* Relocation pointer */
> - char res2[2]; /* Reserved */
> + char res2[6]; /* Reserved */
> + uint sdmatmp; /* Internal */
> };
Not sure if this will fit on 8xx CPUs, Leroy ?
Jocke
^ permalink raw reply
* Re: [PATCH] i2c: cpm: Fix i2c_ram structure
From: Christophe Leroy @ 2020-09-22 12:38 UTC (permalink / raw)
To: nicolas.vincent, jochen; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <20200922090400.6282-1-nicolas.vincent@vossloh.com>
Le 22/09/2020 à 11:04, nico.vince@gmail.com a écrit :
> From: Nicolas VINCENT <nicolas.vincent@vossloh.com>
>
> the i2c_ram structure is missing the sdmatmp field mentionned in
> datasheet for MPC8272 at paragraph 36.5. With this field missing, the
> hardware would write past the allocated memory done through
> cpm_muram_alloc for the i2c_ram structure and land in memory allocated
> for the buffers descriptors corrupting the cbd_bufaddr field. Since this
> field is only set during setup(), the first i2c transaction would work
> and the following would send data read from an arbitrary memory
> location.
>
> Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
> ---
> drivers/i2c/busses/i2c-cpm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
> index 1213e1932ccb..c5700addbf65 100644
> --- a/drivers/i2c/busses/i2c-cpm.c
> +++ b/drivers/i2c/busses/i2c-cpm.c
> @@ -64,7 +64,8 @@ struct i2c_ram {
> uint txtmp; /* Internal */
> char res1[4]; /* Reserved */
> ushort rpbase; /* Relocation pointer */
> - char res2[2]; /* Reserved */
> + char res2[6]; /* Reserved */
> + uint sdmatmp; /* Internal */
On CPM1, I2C param RAM has size 0x30 (offset 0x1c80-0x1caf)
Your change overlaps the miscellaneous area that contains CP Microcode
Revision Number, ref MPC885 Reference Manual §18.7.3
> };
>
> #define I2COM_START 0x80
>
Christophe
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
From: Philipp Zabel @ 2020-09-22 12:08 UTC (permalink / raw)
To: Viorel Suman (OSS)
Cc: devicetree, alsa-devel, Matthias Schiffer, Timur Tabi, Xiubo Li,
Shengjiu Wang, linuxppc-dev, Takashi Iwai, Rob Herring,
Liam Girdwood, Nicolin Chen, Mark Brown, NXP Linux Team,
Viorel Suman, Viorel Suman, Cosmin-Gabriel Samoila,
Jaroslav Kysela, Fabio Estevam, linux-kernel
In-Reply-To: <1600715292-28529-2-git-send-email-viorel.suman@oss.nxp.com>
On Mon, Sep 21, 2020 at 10:08:11PM +0300, Viorel Suman (OSS) wrote:
> From: Viorel Suman <viorel.suman@nxp.com>
>
> XCVR (Audio Transceiver) is a on-chip functional module found
> on i.MX8MP. It support HDMI2.1 eARC, HDMI1.4 ARC and SPDIF.
>
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> ---
> sound/soc/fsl/Kconfig | 10 +
> sound/soc/fsl/Makefile | 2 +
> sound/soc/fsl/fsl_xcvr.c | 1343 ++++++++++++++++++++++++++++++++++++++++++++++
> sound/soc/fsl/fsl_xcvr.h | 266 +++++++++
> 4 files changed, 1621 insertions(+)
> create mode 100644 sound/soc/fsl/fsl_xcvr.c
> create mode 100644 sound/soc/fsl/fsl_xcvr.h
>
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 3f76ff7..d04b64d 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -95,6 +95,16 @@ config SND_SOC_FSL_EASRC
> destination sample rate. It is a new design module compare with the
> old ASRC.
>
> +config SND_SOC_FSL_XCVR
> + tristate "NXP Audio Transceiver (XCVR) module support"
> + select REGMAP_MMIO
> + select SND_SOC_IMX_PCM_DMA if SND_IMX_SOC != n
> + select SND_SOC_GENERIC_DMAENGINE_PCM
> + help
> + Say Y if you want to add Audio Transceiver (XCVR) support for NXP
> + iMX CPUs. XCVR is a digital module that supports HDMI2.1 eARC,
> + HDMI1.4 ARC and SPDIF.
> +
> config SND_SOC_FSL_UTILS
> tristate
>
> diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
> index b835eeb..1d2231f 100644
> --- a/sound/soc/fsl/Makefile
> +++ b/sound/soc/fsl/Makefile
> @@ -25,6 +25,7 @@ snd-soc-fsl-utils-objs := fsl_utils.o
> snd-soc-fsl-dma-objs := fsl_dma.o
> snd-soc-fsl-mqs-objs := fsl_mqs.o
> snd-soc-fsl-easrc-objs := fsl_easrc.o
> +snd-soc-fsl-xcvr-objs := fsl_xcvr.o
>
> obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o
> obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o
> @@ -38,6 +39,7 @@ obj-$(CONFIG_SND_SOC_FSL_UTILS) += snd-soc-fsl-utils.o
> obj-$(CONFIG_SND_SOC_FSL_MQS) += snd-soc-fsl-mqs.o
> obj-$(CONFIG_SND_SOC_FSL_EASRC) += snd-soc-fsl-easrc.o
> obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
> +obj-$(CONFIG_SND_SOC_FSL_XCVR) += snd-soc-fsl-xcvr.o
>
> # MPC5200 Platform Support
> obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
> diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c
> new file mode 100644
> index 00000000..7391bca
> --- /dev/null
> +++ b/sound/soc/fsl/fsl_xcvr.c
> @@ -0,0 +1,1343 @@
[...]
> +static int fsl_xcvr_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + const struct of_device_id *of_id;
> + struct fsl_xcvr *xcvr;
> + struct resource *ram_res, *regs_res, *rx_res, *tx_res;
> + void __iomem *regs;
> + int ret, irq;
> +
> + of_id = of_match_device(fsl_xcvr_dt_ids, dev);
> + if (!of_id)
> + return -EINVAL;
> +
> + xcvr = devm_kzalloc(dev, sizeof(*xcvr), GFP_KERNEL);
> + if (!xcvr)
> + return -ENOMEM;
> +
> + xcvr->pdev = pdev;
> + xcvr->ipg_clk = devm_clk_get(dev, "ipg");
> + if (IS_ERR(xcvr->ipg_clk)) {
> + dev_err(dev, "failed to get ipg clock\n");
> + return PTR_ERR(xcvr->ipg_clk);
> + }
> +
> + xcvr->phy_clk = devm_clk_get(dev, "phy");
> + if (IS_ERR(xcvr->phy_clk)) {
> + dev_err(dev, "failed to get phy clock\n");
> + return PTR_ERR(xcvr->phy_clk);
> + }
> +
> + xcvr->spba_clk = devm_clk_get(dev, "spba");
> + if (IS_ERR(xcvr->spba_clk)) {
> + dev_err(dev, "failed to get spba clock\n");
> + return PTR_ERR(xcvr->spba_clk);
> + }
> +
> + xcvr->pll_ipg_clk = devm_clk_get(dev, "pll_ipg");
> + if (IS_ERR(xcvr->pll_ipg_clk)) {
> + dev_err(dev, "failed to get pll_ipg clock\n");
> + return PTR_ERR(xcvr->pll_ipg_clk);
> + }
> +
> + ram_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ram");
> + xcvr->ram_addr = devm_ioremap_resource(dev, ram_res);
> + if (IS_ERR(xcvr->ram_addr))
> + return PTR_ERR(xcvr->ram_addr);
> +
> + regs_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + regs = devm_ioremap_resource(dev, regs_res);
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
> +
> + xcvr->regmap = devm_regmap_init_mmio_clk(dev, NULL, regs,
> + &fsl_xcvr_regmap_cfg);
> + if (IS_ERR(xcvr->regmap)) {
> + dev_err(dev, "failed to init XCVR regmap: %ld\n",
> + PTR_ERR(xcvr->regmap));
> + return PTR_ERR(xcvr->regmap);
> + }
> +
> + xcvr->reset = of_reset_control_get(np, NULL);
Please use devm_reset_control_get_exclusive().
[...]
> +static __maybe_unused int fsl_xcvr_runtime_resume(struct device *dev)
> +{
> + struct fsl_xcvr *xcvr = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_prepare_enable(xcvr->ipg_clk);
> + if (ret) {
> + dev_err(dev, "failed to start IPG clock.\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(xcvr->pll_ipg_clk);
> + if (ret) {
> + dev_err(dev, "failed to start PLL IPG clock.\n");
> + goto stop_ipg_clk;
> + }
> +
> + ret = clk_prepare_enable(xcvr->phy_clk);
> + if (ret) {
> + dev_err(dev, "failed to start PHY clock: %d\n", ret);
> + goto stop_pll_ipg_clk;
> + }
> +
> + ret = clk_prepare_enable(xcvr->spba_clk);
> + if (ret) {
> + dev_err(dev, "failed to start SPBA clock.\n");
> + goto stop_phy_clk;
> + }
> +
> + regcache_cache_only(xcvr->regmap, false);
> + regcache_mark_dirty(xcvr->regmap);
> + ret = regcache_sync(xcvr->regmap);
> +
> + if (ret) {
> + dev_err(dev, "failed to sync regcache.\n");
> + goto stop_spba_clk;
> + }
> +
> + reset_control_assert(xcvr->reset);
> + reset_control_deassert(xcvr->reset);
No delay required between the two?
regards
Philipp
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Andy Lutomirski @ 2020-09-22 16:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390,
Linux SCSI List, X86 ML, linux-block, Al Viro, Andy Lutomirski,
io-uring, linux-arm-kernel, Jens Axboe, Parisc List,
Network Development, LKML, LSM List, Linux FS Devel,
Andrew Morton, linuxppc-dev, Pavel Begunkov
In-Reply-To: <CAK8P3a39jN+t2hhLg0oKZnbYATQXmYE2-Z1JkmFyc1EPdg1HXw@mail.gmail.com>
> On Sep 22, 2020, at 2:01 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>> On 22/09/2020 10:23, Arnd Bergmann wrote:
>>> On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>>> On 22/09/2020 03:58, Andy Lutomirski wrote:
>>>>> On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>>>> I may be looking at a different kernel than you, but aren't you
>>>>> preventing creating an io_uring regardless of whether SQPOLL is
>>>>> requested?
>>>>
>>>> I diffed a not-saved file on a sleepy head, thanks for noticing.
>>>> As you said, there should be an SQPOLL check.
>>>>
>>>> ...
>>>> if (ctx->compat && (p->flags & IORING_SETUP_SQPOLL))
>>>> goto err;
>>>
>>> Wouldn't that mean that now 32-bit containers behave differently
>>> between compat and native execution?
>>>
>>> I think if you want to prevent 32-bit applications from using SQPOLL,
>>> it needs to be done the same way on both to be consistent:
>>
>> The intention was to disable only compat not native 32-bit.
>
> I'm not following why that would be considered a valid option,
> as that clearly breaks existing users that update from a 32-bit
> kernel to a 64-bit one.
>
> Taking away the features from users that are still on 32-bit kernels
> already seems questionable to me, but being inconsistent
> about it seems much worse, in particular when the regression
> is on the upgrade path.
>
>>> Can we expect all existing and future user space to have a sane
>>> fallback when IORING_SETUP_SQPOLL fails?
>>
>> SQPOLL has a few differences with non-SQPOLL modes, but it's easy
>> to convert between them. Anyway, SQPOLL is a privileged special
>> case that's here for performance/latency reasons, I don't think
>> there will be any non-accidental users of it.
>
> Ok, so the behavior of 32-bit tasks would be the same as running
> the same application as unprivileged 64-bit tasks, with applications
> already having to implement that fallback, right?
>
>
I don’t have any real preference wrt SQPOLL, and it may be that we have a problem even without SQPOLL when IO gets punted without one of the fixes discussed.
But banning the mismatched io_uring and io_uring_enter seems like it may be worthwhile regardless.
^ permalink raw reply
* Re: [PATCH v3 2/5] powerpc: apm82181: create shared dtsi for APM bluestone
From: Rob Herring @ 2020-09-22 19:14 UTC (permalink / raw)
To: Christian Lamparter
Cc: devicetree, Arnd Bergmann, Chris Blake, Paul Mackerras,
Andy Shevchenko, linuxppc-dev
In-Reply-To: <7bf866fd-6499-68e4-9825-5c3e2042ef65@gmail.com>
On Sat, Sep 19, 2020 at 2:23 PM Christian Lamparter <chunkeey@gmail.com> wrote:
>
> On 2020-09-15 03:05, Rob Herring wrote:
> > On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote:
> >> This patch adds an DTSI-File that can be used by various device-tree
> >> files for APM82181-based devices.
> >>
> >> Some of the nodes (like UART, PCIE, SATA) are used by the uboot and
> >> need to stick with the naming-conventions of the old times'.
> >> I've added comments whenever this was the case.
> >>
> >> Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
> >> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> >> ---
> >> rfc v1 -> v2:
> >> - removed PKA (this CryptoPU will need driver)
> >> - stick with compatibles, nodes, ... from either
> >> Bluestone (APM82181) or Canyonlands (PPC460EX).
> >> - add labels for NAND and NOR to help with access.
> >> v2 -> v3:
> >> - nodename of pciex@d.... was changed to pcie@d..
> >> due to upstream patch.
> >> - use simple-bus on the ebc, opb and plb nodes
> >> ---
> >> arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++
> >> 1 file changed, 466 insertions(+)
> >> create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi
> >>
> >> diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi
> >> new file mode 100644
> >> index 000000000000..60283430978d
> >> --- /dev/null
> >> +++ b/arch/powerpc/boot/dts/apm82181.dtsi
> >> @@ -0,0 +1,466 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later
> >> +/*
> >> + * Device Tree template include for various APM82181 boards.
> >> + *
> >> + * The SoC is an evolution of the PPC460EX predecessor.
> >> + * This is why dt-nodes from the canyonlands EBC, OPB, USB,
> >> + * DMA, SATA, EMAC, ... ended up in here.
> >> + *
> >> + * Copyright (c) 2010, Applied Micro Circuits Corporation
> >> + * Author: Tirumala R Marri <tmarri@apm.com>,
> >> + * Christian Lamparter <chunkeey@gmail.com>,
> >> + * Chris Blake <chrisrblake93@gmail.com>
> >> + */
> >> +
> >> +#include <dt-bindings/dma/dw-dmac.h>
> >> +#include <dt-bindings/input/input.h>
> >> +#include <dt-bindings/interrupt-controller/irq.h>
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +
> >> +/ {
> >> + #address-cells = <2>;
> >> + #size-cells = <1>;
> >> + dcr-parent = <&{/cpus/cpu@0}>;
> >> +
> >> + aliases {
> >> + ethernet0 = &EMAC0; /* needed for BSP u-boot */
> >> + };
> >> +
> >> + cpus {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + CPU0: cpu@0 {
> >> + device_type = "cpu";
> >> + model = "PowerPC,apm82181";
> >
> > This doesn't match the existing bluestone dts file.
> >
> > Please separate any restructuring from changes.
>
>
> "I see" (I'm including your comment of the dt-binding as well).
>
> I'm getting the vibe that I better should not touch that bluestone.dts.
I don't know about that.
> An honestly, looking at the series and patches that the APM-engineers
> posted back in the day, I can see why this well is so poisoned... and
> stuff like SATA/AHBDMA/USB/GPIO/CPM/... was missing.
>
> As for the devices. In the spirit of Arnd Bergmann's post of
> <https://lkml.org/lkml/2020/3/30/195>
>
> |It would be nice to move over the the bluestone .dts to the apm82181.dtsi file
> |when that gets added, if only to ensure they use the same description for each
> |node, but that shouldn't stop the addition of the new file if that is needed for
> |distros to make use of a popular device.
> |I see a couple of additional files in openwrt.
>
> I mean I don't have the bluestone dev board, just the consumer devices.
This stuff is old enough, I'd guess no one cares about a dev board.
But we should figure that out and document that with any changes.
> Would it be possible to support those? I can start from a "skeleton" apm82181.dtsi
> This would just include CPU, Memory (SD-RAM+L2C+OCM), UIC (Interrupt-Controller),
> the PLB+OBP+EBC Busses and UART. Just enough to make a board "boot from ram".
This skeleton would be chunks moved over or duplicated? I don't think
we want 2 of the same thing.
The order I would go is split into an apm82181.dtsi with 0 changes to
the built dtb(s). Then make changes/additions you need. As far as
changes to existing bindings, it's only an ABI if someone notices.
Rob
^ permalink raw reply
* Re: [PATCH] ibmvfc: Protect vhost->task_set increment by the host lock
From: Martin K. Petersen @ 2020-09-22 21:39 UTC (permalink / raw)
To: Brian King; +Cc: tyreld, linuxppc-dev, martin.petersen, linux-scsi
In-Reply-To: <1600286999-22059-1-git-send-email-brking@linux.vnet.ibm.com>
Brian,
> In the discovery thread, ibmvfc does a vhost->task_set++ without any
> lock held. This could result in two targets getting the same cancel
> key, which could have strange effects in error recovery. The actual
> probability of this occurring should be extremely small, since this
> should all be done in a single threaded loop from the discovery
> thread, but let's fix it up anyway to be safe.
Applied to 5.10/scsi-staging, thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH] soc: fsl: qbman: Fix return value on success
From: Li Yang @ 2020-09-22 22:42 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Roy Pledge, linuxppc-dev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200920202625.11377-1-krzk@kernel.org>
On Sun, Sep 20, 2020 at 3:27 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On error the function was meant to return -ERRNO. This also fixes
> compile warning:
>
> drivers/soc/fsl/qbman/bman.c:640:6: warning: variable 'err' set but not used [-Wunused-but-set-variable]
>
> Fixes: 0505d00c8dba ("soc/fsl/qbman: Cleanup buffer pools if BMan was initialized prior to bootup")
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Applied for next. Thanks.
> ---
> drivers/soc/fsl/qbman/bman.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
> index f4fb527d8301..c5dd026fe889 100644
> --- a/drivers/soc/fsl/qbman/bman.c
> +++ b/drivers/soc/fsl/qbman/bman.c
> @@ -660,7 +660,7 @@ int bm_shutdown_pool(u32 bpid)
> }
> done:
> put_affine_portal();
> - return 0;
> + return err;
> }
>
> struct gen_pool *bm_bpalloc;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] soc: fsl: dpio: remove set but not used 'addr_cena'
From: Li Yang @ 2020-09-22 22:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jason Yan, Roy Pledge, linux-kernel@vger.kernel.org, Youri Querry,
Hulk Robot, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAJKOXPcsrL2T9EmiSnOhrC5Lh+ZM=nY4Go52cVDv1S6wxn5DHQ@mail.gmail.com>
On Sun, Sep 20, 2020 at 3:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Thu, 10 Sep 2020 at 16:57, Jason Yan <yanaijie@huawei.com> wrote:
> >
> > This addresses the following gcc warning with "make W=1":
> >
> > drivers/soc/fsl/dpio/qbman-portal.c: In function
> > ‘qbman_swp_enqueue_multiple_direct’:
> > drivers/soc/fsl/dpio/qbman-portal.c:650:11: warning: variable
> > ‘addr_cena’ set but not used [-Wunused-but-set-variable]
> > 650 | uint64_t addr_cena;
> > | ^~~~~~~~~
> >
> > Reported-by: Hulk Robot <hulkci@huawei.com>
> > Signed-off-by: Jason Yan <yanaijie@huawei.com>
>
> This was already reported:
> Reported-by: kernel test robot <lkp@intel.com>
> https://lkml.org/lkml/2020/6/12/290
>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Applied for next. Thanks.
>
> Best regards,
> Krzysztof
>
> > ---
> > drivers/soc/fsl/dpio/qbman-portal.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/soc/fsl/dpio/qbman-portal.c b/drivers/soc/fsl/dpio/qbman-portal.c
> > index 0ab85bfb116f..659b4a570d5b 100644
> > --- a/drivers/soc/fsl/dpio/qbman-portal.c
> > +++ b/drivers/soc/fsl/dpio/qbman-portal.c
> > @@ -647,7 +647,6 @@ int qbman_swp_enqueue_multiple_direct(struct qbman_swp *s,
> > const uint32_t *cl = (uint32_t *)d;
> > uint32_t eqcr_ci, eqcr_pi, half_mask, full_mask;
> > int i, num_enqueued = 0;
> > - uint64_t addr_cena;
> >
> > spin_lock(&s->access_spinlock);
> > half_mask = (s->eqcr.pi_ci_mask>>1);
> > @@ -701,7 +700,6 @@ int qbman_swp_enqueue_multiple_direct(struct qbman_swp *s,
> >
> > /* Flush all the cacheline without load/store in between */
> > eqcr_pi = s->eqcr.pi;
> > - addr_cena = (size_t)s->addr_cena;
> > for (i = 0; i < num_enqueued; i++)
> > eqcr_pi++;
> > s->eqcr.pi = eqcr_pi & full_mask;
> > --
> > 2.25.4
> >
^ permalink raw reply
* Re: [PATCH v1] soc: fsl: rcpm: Add ACPI support
From: Li Yang @ 2020-09-22 23:13 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Biwen Li, kuldip dwivedi, Arokia Samy, Paul Yang,
linux-kernel@vger.kernel.org, Samer El-Haj-Mahmoud, Varun Sethi,
tanveer, Ran Wang, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <caf01871-1c3d-bdf8-867d-daf7138966a8@arm.com>
On Wed, Sep 16, 2020 at 1:12 AM Ard Biesheuvel <ard.biesheuvel@arm.com> wrote:
>
> On 9/16/20 3:32 AM, Ran Wang wrote:
> > Hi Ard,
> >
> > On Tuesday, September 15, 2020 7:10 PM, Ard Biesheuvel wrote:
> >> Subject: Re: [PATCH v1] soc: fsl: rcpm: Add ACPI support
> >>
> >> On 9/15/20 1:06 PM, kuldip dwivedi wrote:
> >>> Add ACPI support in fsl RCPM driver. This is required to support ACPI
> >>> S3 state. S3 is the ACPI sleep state that is known as "sleep" or
> >>> "suspend to RAM".
> >>> It essentially turns off most power of the system but keeps memory
> >>> powered.
> >>>
> >>> Signed-off-by: tanveer <tanveer.alam@puresoftware.com>
> >>> Signed-off-by: kuldip dwivedi <kuldip.dwivedi@puresoftware.com>
> >>
> >> Why does the OS need to program this device? Can't this be done by
> >> firmware?
> >
> > This device is use to tell HW which IP (such as USB, SDHC, SATA, etc) should not be
> > clock gated during system enter low power state (to allow that IP work as a
> > wakeup source). And user does this configuration in device tree.
>
> The point of ACPI is *not* to describe a DT topology using a table
> format that is not suited for it. The point of ACPI is to describe a
> machine that is more abstracted from the hardware than is typically
> possible with DT, where the abstractions are implemented by AML code
> that is provided by the firmware, but executed in the context of the OS.
>
> So the idea is *not* finding the shortest possible path to get your
> existing DT driver code running on a system that boots via ACPI.
> Instead, you should carefully think about the abstract ACPI machine that
> you will expose to the OS, and hide everything else in firmware.
>
> In this particular case, it seems like your USB, SDHC and SATA device
> objects may need power state dependent AML methods that program this
> block directly.
The platform PM driver was created to support PM on systems without a
runtime PM firmware. Even with PSCI firmware on later systems, there
is no standard interface to communicate the wakeup source information
directly from peripheral drivers to the PSCI firmware. So we still
need this platform power management driver in kernel to deal with this
setup for non-ACPI scenarios. From the code re-use perspective, I
think it is probably better to keep this generic implementation in
kernel instead of moving it to ACPI byte-code for each platform.
>
>
>
> > So implement
> > this RCPM driver to do it in kernel rather than firmware.
> >
> > Regards,
> > Ran
> >
> >>> ---
> >>>
> >>> Notes:
> >>> 1. Add ACPI match table
> >>> 2. NXP team members are added for confirming HID changes
> >>> 3. There is only one node in ACPI so no need to check for
> >>> current device explicitly
> >>> 4. These changes are tested on LX2160A and LS1046A platforms
> >>>
> >>> drivers/soc/fsl/rcpm.c | 22 +++++++++++++++++++---
> >>> 1 file changed, 19 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c index
> >>> a093dbe6d2cb..e75a436fb159 100644
> >>> --- a/drivers/soc/fsl/rcpm.c
> >>> +++ b/drivers/soc/fsl/rcpm.c
> >>> @@ -2,10 +2,12 @@
> >>> //
> >>> // rcpm.c - Freescale QorIQ RCPM driver
> >>> //
> >>> -// Copyright 2019 NXP
> >>> +// Copyright 2019-2020 NXP
> >>> +// Copyright 2020 Puresoftware Ltd.
> >>> //
> >>> // Author: Ran Wang <ran.wang_1@nxp.com>
> >>>
> >>> +#include <linux/acpi.h>
> >>> #include <linux/init.h>
> >>> #include <linux/module.h>
> >>> #include <linux/platform_device.h>
> >>> @@ -57,8 +59,13 @@ static int rcpm_pm_prepare(struct device *dev)
> >>> rcpm->wakeup_cells + 1);
> >>>
> >>> /* Wakeup source should refer to current rcpm device */
> >>> - if (ret || (np->phandle != value[0]))
> >>> - continue;
> >>> + if (is_acpi_node(dev->fwnode)) {
> >>> + if (ret)
> >>> + continue;
> >>> + } else {
> >>> + if (ret || (np->phandle != value[0]))
> >>> + continue;
> >>> + }
> >>>
> >>> /* Property "#fsl,rcpm-wakeup-cells" of rcpm node defines the
> >>> * number of IPPDEXPCR register cells, and "fsl,rcpm-wakeup"
> >>> @@ -139,10 +146,19 @@ static const struct of_device_id rcpm_of_match[]
> >> = {
> >>> };
> >>> MODULE_DEVICE_TABLE(of, rcpm_of_match);
> >>>
> >>> +#ifdef CONFIG_ACPI
> >>> +static const struct acpi_device_id rcpm_acpi_match[] = {
> >>> + { "NXP0015", },
> >>> + { }
> >>> +};
> >>> +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_match); #endif
> >>> +
> >>> static struct platform_driver rcpm_driver = {
> >>> .driver = {
> >>> .name = "rcpm",
> >>> .of_match_table = rcpm_of_match,
> >>> + .acpi_match_table = ACPI_PTR(rcpm_acpi_match),
> >>> .pm = &rcpm_pm_ops,
> >>> },
> >>> .probe = rcpm_probe,
> >>>
> >
>
^ permalink raw reply
* Re: [PATCH -next] soc/qman: convert to use be32_add_cpu()
From: Li Yang @ 2020-09-22 23:19 UTC (permalink / raw)
To: Liu Shixin
Cc: linuxppc-dev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200914041752.3702104-1-liushixin2@huawei.com>
On Sun, Sep 13, 2020 at 10:56 PM Liu Shixin <liushixin2@huawei.com> wrote:
>
> Signed-off-by: Liu Shixin <liushixin2@huawei.com>
> drivers/soc/fsl/qbman/qman_test_api.c---
The patch seems to be messed up here.
I have fixed that, and applied for next. Thanks.
> drivers/soc/fsl/qbman/qman_test_api.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/qbman/qman_test_api.c b/drivers/soc/fsl/qbman/qman_test_api.c
> index 2895d062cf51..7066b2f1467c 100644
> --- a/drivers/soc/fsl/qbman/qman_test_api.c
> +++ b/drivers/soc/fsl/qbman/qman_test_api.c
> @@ -86,7 +86,7 @@ static void fd_inc(struct qm_fd *fd)
> len--;
> qm_fd_set_param(fd, fmt, off, len);
>
> - fd->cmd = cpu_to_be32(be32_to_cpu(fd->cmd) + 1);
> + be32_add_cpu(&fd->cmd, 1);
> }
>
> /* The only part of the 'fd' we can't memcmp() is the ppid */
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH -next] soc: fsl: qe: Remove unnessesary check in ucc_set_tdm_rxtx_clk
From: Li Yang @ 2020-09-22 23:25 UTC (permalink / raw)
To: Wang Hai
Cc: linuxppc-dev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Zhao Qiang
In-Reply-To: <20200804135644.58878-1-wanghai38@huawei.com>
On Tue, Aug 4, 2020 at 9:04 AM Wang Hai <wanghai38@huawei.com> wrote:
>
> Fix smatch warning:
>
> drivers/soc/fsl/qe/ucc.c:526
> ucc_set_tdm_rxtx_clk() warn: unsigned 'tdm_num' is never less than zero.
>
> 'tdm_num' is u32 type, never less than zero.
>
> Signed-off-by: Wang Hai <wanghai38@huawei.com>
Applied for next. Thanks.
> ---
> drivers/soc/fsl/qe/ucc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/qe/ucc.c b/drivers/soc/fsl/qe/ucc.c
> index cac0fb7693a0..21dbcd787cd5 100644
> --- a/drivers/soc/fsl/qe/ucc.c
> +++ b/drivers/soc/fsl/qe/ucc.c
> @@ -523,7 +523,7 @@ int ucc_set_tdm_rxtx_clk(u32 tdm_num, enum qe_clock clock,
>
> qe_mux_reg = &qe_immr->qmx;
>
> - if (tdm_num > 7 || tdm_num < 0)
> + if (tdm_num > 7)
> return -EINVAL;
>
> /* The communications direction must be RX or TX */
> --
> 2.17.1
>
^ permalink raw reply
* Re: [patch RFC 06/15] csky/mm/highmem: Switch to generic kmap atomic
From: Guo Ren @ 2020-09-23 0:05 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Juri Lelli, Peter Zijlstra, Sebastian Andrzej Siewior,
Joonas Lahtinen, dri-devel, linux-mips, Ben Segall, Max Filippov,
Paul Mackerras, sparclinux, Vincent Chen, Will Deacon,
Ard Biesheuvel, linux-arch, Vincent Guittot, Herbert Xu, x86,
Russell King, linux-csky, David Airlie, Mel Gorman,
linux-snps-arc, linux-xtensa, Paul McKenney, intel-gfx,
linuxppc-dev, Steven Rostedt, Linus Torvalds, Jani Nikula,
Rodrigo Vivi, Dietmar Eggemann, Linux ARM, Chris Zankel,
Michal Simek, Thomas Bogendoerfer, Nick Hu, Linux-MM,
Vineet Gupta, LKML, Arnd Bergmann, Daniel Vetter, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller, Greentime Hu
In-Reply-To: <20200919092616.432209211@linutronix.de>
Acked-by: Guo Ren <guoren@kernel.org>
On Sat, Sep 19, 2020 at 5:50 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Guo Ren <guoren@kernel.org>
> Cc: linux-csky@vger.kernel.org
> ---
> Note: Completely untested
> ---
> arch/csky/Kconfig | 1
> arch/csky/include/asm/highmem.h | 4 +-
> arch/csky/mm/highmem.c | 75 ----------------------------------------
> 3 files changed, 5 insertions(+), 75 deletions(-)
>
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -285,6 +285,7 @@ config NR_CPUS
> config HIGHMEM
> bool "High Memory Support"
> depends on !CPU_CK610
> + select KMAP_ATOMIC_GENERIC
> default y
>
> config FORCE_MAX_ZONEORDER
> --- a/arch/csky/include/asm/highmem.h
> +++ b/arch/csky/include/asm/highmem.h
> @@ -32,10 +32,12 @@ extern pte_t *pkmap_page_table;
>
> #define ARCH_HAS_KMAP_FLUSH_TLB
> extern void kmap_flush_tlb(unsigned long addr);
> -extern void *kmap_atomic_pfn(unsigned long pfn);
>
> #define flush_cache_kmaps() do {} while (0)
>
> +#define arch_kmap_temp_post_map(vaddr, pteval) kmap_flush_tlb(vaddr)
> +#define arch_kmap_temp_post_unmap(vaddr) kmap_flush_tlb(vaddr)
> +
> extern void kmap_init(void);
>
> #endif /* __KERNEL__ */
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -9,8 +9,6 @@
> #include <asm/tlbflush.h>
> #include <asm/cacheflush.h>
>
> -static pte_t *kmap_pte;
> -
> unsigned long highstart_pfn, highend_pfn;
>
> void kmap_flush_tlb(unsigned long addr)
> @@ -19,67 +17,7 @@ void kmap_flush_tlb(unsigned long addr)
> }
> EXPORT_SYMBOL(kmap_flush_tlb);
>
> -void *kmap_atomic_high_prot(struct page *page, pgprot_t prot)
> -{
> - unsigned long vaddr;
> - int idx, type;
> -
> - type = kmap_atomic_idx_push();
> - idx = type + KM_TYPE_NR*smp_processor_id();
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> -#ifdef CONFIG_DEBUG_HIGHMEM
> - BUG_ON(!pte_none(*(kmap_pte - idx)));
> -#endif
> - set_pte(kmap_pte-idx, mk_pte(page, prot));
> - flush_tlb_one((unsigned long)vaddr);
> -
> - return (void *)vaddr;
> -}
> -EXPORT_SYMBOL(kmap_atomic_high_prot);
> -
> -void kunmap_atomic_high(void *kvaddr)
> -{
> - unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
> - int idx;
> -
> - if (vaddr < FIXADDR_START)
> - return;
> -
> -#ifdef CONFIG_DEBUG_HIGHMEM
> - idx = KM_TYPE_NR*smp_processor_id() + kmap_atomic_idx();
> -
> - BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
> -
> - pte_clear(&init_mm, vaddr, kmap_pte - idx);
> - flush_tlb_one(vaddr);
> -#else
> - (void) idx; /* to kill a warning */
> -#endif
> - kmap_atomic_idx_pop();
> -}
> -EXPORT_SYMBOL(kunmap_atomic_high);
> -
> -/*
> - * This is the same as kmap_atomic() but can map memory that doesn't
> - * have a struct page associated with it.
> - */
> -void *kmap_atomic_pfn(unsigned long pfn)
> -{
> - unsigned long vaddr;
> - int idx, type;
> -
> - pagefault_disable();
> -
> - type = kmap_atomic_idx_push();
> - idx = type + KM_TYPE_NR*smp_processor_id();
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> - set_pte(kmap_pte-idx, pfn_pte(pfn, PAGE_KERNEL));
> - flush_tlb_one(vaddr);
> -
> - return (void *) vaddr;
> -}
> -
> -static void __init kmap_pages_init(void)
> +void __init kmap_init(void)
> {
> unsigned long vaddr;
> pgd_t *pgd;
> @@ -96,14 +34,3 @@ static void __init kmap_pages_init(void)
> pte = pte_offset_kernel(pmd, vaddr);
> pkmap_page_table = pte;
> }
> -
> -void __init kmap_init(void)
> -{
> - unsigned long vaddr;
> -
> - kmap_pages_init();
> -
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN);
> -
> - kmap_pte = pte_offset_kernel((pmd_t *)pgd_offset_k(vaddr), vaddr);
> -}
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply
* Re: [PATCH -next] powerpc/kvm/books: Fix symbol undeclared warnings
From: Paul Mackerras @ 2020-09-23 0:08 UTC (permalink / raw)
To: Wang Wensheng; +Cc: linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <20200921112211.82830-1-wangwensheng4@huawei.com>
On Mon, Sep 21, 2020 at 11:22:11AM +0000, Wang Wensheng wrote:
> Build the kernel with `C=2`:
> arch/powerpc/kvm/book3s_hv_nested.c:572:25: warning: symbol
> 'kvmhv_alloc_nested' was not declared. Should it be static?
> arch/powerpc/kvm/book3s_64_mmu_radix.c:350:6: warning: symbol
> 'kvmppc_radix_set_pte_at' was not declared. Should it be static?
> arch/powerpc/kvm/book3s_hv.c:3568:5: warning: symbol
> 'kvmhv_p9_guest_entry' was not declared. Should it be static?
> arch/powerpc/kvm/book3s_hv_rm_xics.c:767:15: warning: symbol 'eoi_rc'
> was not declared. Should it be static?
> arch/powerpc/kvm/book3s_64_vio_hv.c:240:13: warning: symbol
> 'iommu_tce_kill_rm' was not declared. Should it be static?
> arch/powerpc/kvm/book3s_64_vio.c:492:6: warning: symbol
> 'kvmppc_tce_iommu_do_map' was not declared. Should it be static?
> arch/powerpc/kvm/book3s_pr.c:572:6: warning: symbol 'kvmppc_set_pvr_pr'
> was not declared. Should it be static?
>
> Those symbols are used only in the files that define them so make them
> static to fix the warnings.
>
> Signed-off-by: Wang Wensheng <wangwensheng4@huawei.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Remove redundant initialization of variable ret
From: Paul Mackerras @ 2020-09-23 0:08 UTC (permalink / raw)
To: Jing Xiangfeng; +Cc: linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <20200919071230.125798-1-jingxiangfeng@huawei.com>
On Sat, Sep 19, 2020 at 03:12:30PM +0800, Jing Xiangfeng wrote:
> The variable ret is being initialized with '-ENOMEM' that is meaningless.
> So remove it.
>
> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Do not allocate HPT for a nested guest
From: Paul Mackerras @ 2020-09-23 0:09 UTC (permalink / raw)
To: Fabiano Rosas; +Cc: linuxppc-dev, kvm, kvm-ppc, david
In-Reply-To: <20200911041607.198092-1-farosas@linux.ibm.com>
On Fri, Sep 11, 2020 at 01:16:07AM -0300, Fabiano Rosas wrote:
> The current nested KVM code does not support HPT guests. This is
> informed/enforced in some ways:
>
> - Hosts < P9 will not be able to enable the nested HV feature;
>
> - The nested hypervisor MMU capabilities will not contain
> KVM_CAP_PPC_MMU_HASH_V3;
>
> - QEMU reflects the MMU capabilities in the
> 'ibm,arch-vec-5-platform-support' device-tree property;
>
> - The nested guest, at 'prom_parse_mmu_model' ignores the
> 'disable_radix' kernel command line option if HPT is not supported;
>
> - The KVM_PPC_CONFIGURE_V3_MMU ioctl will fail if trying to use HPT.
>
> There is, however, still a way to start a HPT guest by using
> max-compat-cpu=power8 at the QEMU machine options. This leads to the
> guest being set to use hash after QEMU calls the KVM_PPC_ALLOCATE_HTAB
> ioctl.
>
> With the guest set to hash, the nested hypervisor goes through the
> entry path that has no knowledge of nesting (kvmppc_run_vcpu) and
> crashes when it tries to execute an hypervisor-privileged (mtspr
> HDEC) instruction at __kvmppc_vcore_entry:
>
> root@L1:~ $ qemu-system-ppc64 -machine pseries,max-cpu-compat=power8 ...
>
> <snip>
> [ 538.543303] CPU: 83 PID: 25185 Comm: CPU 0/KVM Not tainted 5.9.0-rc4 #1
> [ 538.543355] NIP: c00800000753f388 LR: c00800000753f368 CTR: c0000000001e5ec0
> [ 538.543417] REGS: c0000013e91e33b0 TRAP: 0700 Not tainted (5.9.0-rc4)
> [ 538.543470] MSR: 8000000002843033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE> CR: 22422882 XER: 20040000
> [ 538.543546] CFAR: c00800000753f4b0 IRQMASK: 3
> GPR00: c0080000075397a0 c0000013e91e3640 c00800000755e600 0000000080000000
> GPR04: 0000000000000000 c0000013eab19800 c000001394de0000 00000043a054db72
> GPR08: 00000000003b1652 0000000000000000 0000000000000000 c0080000075502e0
> GPR12: c0000000001e5ec0 c0000007ffa74200 c0000013eab19800 0000000000000008
> GPR16: 0000000000000000 c00000139676c6c0 c000000001d23948 c0000013e91e38b8
> GPR20: 0000000000000053 0000000000000000 0000000000000001 0000000000000000
> GPR24: 0000000000000001 0000000000000001 0000000000000000 0000000000000001
> GPR28: 0000000000000001 0000000000000053 c0000013eab19800 0000000000000001
> [ 538.544067] NIP [c00800000753f388] __kvmppc_vcore_entry+0x90/0x104 [kvm_hv]
> [ 538.544121] LR [c00800000753f368] __kvmppc_vcore_entry+0x70/0x104 [kvm_hv]
> [ 538.544173] Call Trace:
> [ 538.544196] [c0000013e91e3640] [c0000013e91e3680] 0xc0000013e91e3680 (unreliable)
> [ 538.544260] [c0000013e91e3820] [c0080000075397a0] kvmppc_run_core+0xbc8/0x19d0 [kvm_hv]
> [ 538.544325] [c0000013e91e39e0] [c00800000753d99c] kvmppc_vcpu_run_hv+0x404/0xc00 [kvm_hv]
> [ 538.544394] [c0000013e91e3ad0] [c0080000072da4fc] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [ 538.544472] [c0000013e91e3af0] [c0080000072d61b8] kvm_arch_vcpu_ioctl_run+0x310/0x420 [kvm]
> [ 538.544539] [c0000013e91e3b80] [c0080000072c7450] kvm_vcpu_ioctl+0x298/0x778 [kvm]
> [ 538.544605] [c0000013e91e3ce0] [c0000000004b8c2c] sys_ioctl+0x1dc/0xc90
> [ 538.544662] [c0000013e91e3dc0] [c00000000002f9a4] system_call_exception+0xe4/0x1c0
> [ 538.544726] [c0000013e91e3e20] [c00000000000d140] system_call_common+0xf0/0x27c
> [ 538.544787] Instruction dump:
> [ 538.544821] f86d1098 60000000 60000000 48000099 e8ad0fe8 e8c500a0 e9264140 75290002
> [ 538.544886] 7d1602a6 7cec42a6 40820008 7d0807b4 <7d164ba6> 7d083a14 f90d10a0 480104fd
> [ 538.544953] ---[ end trace 74423e2b948c2e0c ]---
>
> This patch makes the KVM_PPC_ALLOCATE_HTAB ioctl fail when running in
> the nested hypervisor, causing QEMU to abort.
>
> Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Don't return -ENOTSUPP to userspace in ioctls
From: Paul Mackerras @ 2020-09-23 0:10 UTC (permalink / raw)
To: Greg Kurz; +Cc: trivial, linuxppc-dev, kvm-ppc
In-Reply-To: <159982162511.459323.13495475646618845164.stgit@bahia.lan>
On Fri, Sep 11, 2020 at 12:53:45PM +0200, Greg Kurz wrote:
> ENOTSUPP is a linux only thingy, the value of which is unknown to
> userspace, not to be confused with ENOTSUP which linux maps to
> EOPNOTSUPP, as permitted by POSIX [1]:
>
> [EOPNOTSUPP]
> Operation not supported on socket. The type of socket (address family
> or protocol) does not support the requested operation. A conforming
> implementation may assign the same values for [EOPNOTSUPP] and [ENOTSUP].
>
> Return -EOPNOTSUPP instead of -ENOTSUPP for the following ioctls:
> - KVM_GET_FPU for Book3s and BookE
> - KVM_SET_FPU for Book3s and BookE
> - KVM_GET_DIRTY_LOG for BookE
>
> This doesn't affect QEMU which doesn't call the KVM_GET_FPU and
> KVM_SET_FPU ioctls on POWER anyway since they are not supported,
> and _buggily_ ignores anything but -EPERM for KVM_GET_DIRTY_LOG.
>
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
>
> Signed-off-by: Greg Kurz <groug@kaod.org>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH -next v2] KVM: PPC: Book3S HV: XIVE: Convert to DEFINE_SHOW_ATTRIBUTE
From: Paul Mackerras @ 2020-09-23 0:09 UTC (permalink / raw)
To: Qinglang Miao; +Cc: linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <20200919012925.174377-1-miaoqinglang@huawei.com>
On Sat, Sep 19, 2020 at 09:29:25AM +0800, Qinglang Miao wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
From: Qian Cai @ 2020-09-23 0:33 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman
Cc: Stephen Rothwell, Alexey Kardashevskiy, linux-kernel, linux-next,
Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20200807101854.844619-1-clg@kaod.org>
On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
> When a passthrough IO adapter is removed from a pseries machine using
> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
> guest OS to clear all page table entries related to the adapter. If
> some are still present, the RTAS call which isolates the PCI slot
> returns error 9001 "valid outstanding translations" and the removal of
> the IO adapter fails. This is because when the PHBs are scanned, Linux
> maps automatically the INTx interrupts in the Linux interrupt number
> space but these are never removed.
>
> To solve this problem, we introduce a PPC platform specific
> pcibios_remove_bus() routine which clears all interrupt mappings when
> the bus is removed. This also clears the associated page table entries
> of the ESB pages when using XIVE.
>
> For this purpose, we record the logical interrupt numbers of the
> mapped interrupt under the PHB structure and let pcibios_remove_bus()
> do the clean up.
>
> Since some PCI adapters, like GPUs, use the "interrupt-map" property
> to describe interrupt mappings other than the legacy INTx interrupts,
> we can not restrict the size of the mapping array to PCI_NUM_INTX. The
> number of interrupt mappings is computed from the "interrupt-map"
> property and the mapping array is allocated accordingly.
>
> Cc: "Oliver O'Halloran" <oohall@gmail.com>
> Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Some syscall fuzzing will trigger this on POWER9 NV where the traces pointed to
this patch.
.config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config
[ 3574.564109][ T965] ata1.00: disabled
[ 3574.580373][T151472] sd 0:0:0:0: [sdb] Synchronizing SCSI cache
[ 3574.581180][T151472] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00
[ 3574.581226][T151472] sd 0:0:0:0: [sdb] Stopping disk
[ 3574.581289][T151472] sd 0:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00
[ 3574.611424][ T3019] Read-error on swap-device (254:1:849792)
[ 3574.611685][ T3019] Read-error on swap-device (254:1:914944)
[ 3574.611769][ T3019] Read-error on swap-device (254:1:915072)
[ 3574.611838][ T3019] Read-error on swap-device (254:1:915200)
[ 3574.611926][ T3019] Read-error on swap-device (254:1:915328)
[ 3574.612268][ T3084] Read-error on swap-device (254:1:792576)
[ 3574.612342][ T3084] Read-error on swap-device (254:1:792704)
[ 3574.612757][ T2362] Read-error on swap-device (254:1:957440)
[ 3574.612773][ T2905] Read-error on swap-device (254:1:784128)
[ 3574.613015][ T2362] Read-error on swap-device (254:1:957568)
[ 3574.613160][ T2905] Read-error on swap-device (254:1:784256)
[ 3574.613241][ T2362] Read-error on swap-device (254:1:957696)
[ 3574.613342][ T2362] Read-error on swap-device (254:1:957824)
[ 3574.614448][ T3019] Core dump to |/usr/lib/systemd/systemd-coredump pipe failed
[ 3574.614663][ T3019] Read-error on swap-device (254:1:961536)
[ 3574.675330][T151844] Read-error on swap-device (254:1:128)
[ 3574.675515][T151844] Read-error on swap-device (254:1:256)
[ 3574.675700][T151844] Read-error on swap-device (254:1:384)
[ 3574.703570][ T971] ata2.00: disabled
[ 3574.710393][T151472] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[ 3574.710864][T151472] sd 1:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00
[ 3574.710922][T151472] sd 1:0:0:0: [sda] Stopping disk
[ 3574.711010][T151472] sd 1:0:0:0: [sda] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00
[ 3574.826569][ T674] dm-0: writeback error on inode 68507862, offset 65536, sector 54281504
[ 3575.117547][ T3366] dm-0: writeback error on inode 68507851, offset 0, sector 54378880
[ 3575.140104][T151472] pci 0004:03:00.0: Removing from iommu group 3
[ 3575.141778][T151472] pci 0004:03 : [PE# fb] Releasing PE
[ 3575.141965][T151472] pci 0004:03 : [PE# fb] Removing DMA window #0
[ 3575.142452][T151472] pci 0004:03 : [PE# fb] Disabling 64-bit DMA bypass
[ 3575.149369][T151472] pci_bus 0004:03: busn_res: [bus 03] is released
[ 3575.150574][T152037] Read-error on swap-device (254:1:35584)
[ 3575.150713][T152037] Read-error on swap-device (254:1:35712)
[ 3575.152632][T152037] Read-error on swap-device (254:1:915584)
[ 3575.152706][T151472] pci_bus 0004:04: busn_res: [bus 04-08] is released
[ 3575.152983][T151472] =============================================================================
[ 3575.153937][T151472] BUG kmalloc-16 (Not tainted): Object already free
[ 3575.153962][T151472] -----------------------------------------------------------------------------
[ 3575.153962][T151472]
[ 3575.154020][T151472] Disabling lock debugging due to kernel taint
[ 3575.154047][T151472] INFO: Allocated in pcibios_scan_phb+0x104/0x3e0 age=356904 cpu=4 pid=1
[ 3575.154084][T151472] __slab_alloc+0xa4/0xf0
[ 3575.154105][T151472] __kmalloc+0x294/0x330
[ 3575.154127][T151472] pcibios_scan_phb+0x104/0x3e0
[ 3575.154165][T151472] pcibios_init+0x84/0x124
[ 3575.154209][T151472] do_one_initcall+0xac/0x528
[ 3575.154241][T151472] kernel_init_freeable+0x35c/0x3fc
[ 3575.154272][T151472] kernel_init+0x24/0x148
[ 3575.154306][T151472] ret_from_kernel_thread+0x5c/0x80
[ 3575.154352][T151472] INFO: Freed in pcibios_remove_bus+0x70/0x90 age=0 cpu=7 pid=151472
[ 3575.154387][T151472] kfree+0x49c/0x510
[ 3575.154406][T151472] pcibios_remove_bus+0x70/0x90
[ 3575.154443][T151472] pci_remove_bus+0xe4/0x110
[ 3575.154467][T151472] pci_remove_bus_device+0x74/0x170
[ 3575.154503][T151472] pci_remove_bus_device+0x4c/0x170
[ 3575.154524][T151472] pci_stop_and_remove_bus_device_locked+0x34/0x50
[ 3575.154539][T151472] remove_store+0xc0/0xe0
[ 3575.154551][T151472] dev_attr_store+0x30/0x50
[ 3575.154573][T151472] sysfs_kf_write+0x68/0xb0
[ 3575.154595][T151472] kernfs_fop_write+0x114/0x260
[ 3575.154643][T151472] vfs_write+0xe4/0x260
[ 3575.154667][T151472] ksys_write+0x74/0x130
[ 3575.154692][T151472] system_call_exception+0xf8/0x1d0
[ 3575.154728][T151472] system_call_common+0xe8/0x218
[ 3575.154788][T151472] INFO: Slab 0x00000000cafdf25c objects=178 used=174 fp=0x0000000020a64b99 flags=0x7fff8000000201
[ 3575.154848][T151472] INFO: Object 0x00000000af116201 @offset=5168 fp=0x0000000000000000
[ 3575.154848][T151472]
[ 3575.154901][T151472] Redzone 00000000781d3b96: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
[ 3575.154968][T151472] Object 00000000af116201: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
[ 3575.155012][T151472] Redzone 000000007b8ec00f: bb bb bb bb bb bb bb bb ........
[ 3575.155052][T151472] Padding 00000000df7d5e89: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
[ 3575.155107][T151472] CPU: 7 PID: 151472 Comm: trinity-c61 Tainted: G B 5.9.0-rc6-next-20200922+ #2
[ 3575.155147][T151472] Call Trace:
[ 3575.155171][T151472] [c000001fefdef800] [c000000000644278] dump_stack+0xec/0x144 (unreliable)
[ 3575.155204][T151472] [c000001fefdef840] [c00000000035e9a8] print_trailer+0x278/0x2a0
[ 3575.155220][T151472] [c000001fefdef8d0] [c000000000355d9c] free_debug_processing+0x57c/0x600
[ 3575.155236][T151472] [c000001fefdef9b0] [c000000000356234] __slab_free+0x414/0x5b0
[ 3575.155251][T151472] [c000001fefdefa80] [c00000000035686c] kfree+0x49c/0x510
[ 3575.155267][T151472] [c000001fefdefb10] [c000000000043260] pcibios_remove_bus+0x70/0x90
pci_irq_map_dispose at arch/powerpc/kernel/pci-common.c:456
(inlined by) pcibios_remove_bus at arch/powerpc/kernel/pci-common.c:461
[ 3575.155282][T151472] [c000001fefdefb40] [c00000000066fee4] pci_remove_bus+0xe4/0x110
[ 3575.155309][T151472] [c000001fefdefb70] [c000000000670084] pci_remove_bus_device+0x74/0x170
[ 3575.155348][T151472] [c000001fefdefbb0] [c000000000670070] pci_remove_bus_device+0x60/0x170
[ 3575.155377][T151472] [c000001fefdefbf0] [c0000000006701f4] pci_stop_and_remove_bus_device_locked+0x34/0x50
[ 3575.155395][T151472] [c000001fefdefc20] [c00000000067f5e0] remove_store+0xc0/0xe0
[ 3575.155431][T151472] [c000001fefdefc70] [c0000000006dccd0] dev_attr_store+0x30/0x50
[ 3575.155457][T151472] [c000001fefdefc90] [c00000000049fae8] sysfs_kf_write+0x68/0xb0
[ 3575.155507][T151472] [c000001fefdefcd0] [c00000000049ed14] kernfs_fop_write+0x114/0x260
[ 3575.155553][T151472] [c000001fefdefd20] [c0000000003ab2d4] vfs_write+0xe4/0x260
[ 3575.155592][T151472] [c000001fefdefd70] [c0000000003ab604] ksys_write+0x74/0x130
[ 3575.155630][T151472] [c000001fefdefdc0] [c00000000002a458] system_call_exception+0xf8/0x1d0
[ 3575.155671][T151472] [c000001fefdefe20] [c00000000000d0a8] system_call_common+0xe8/0x218
[ 3575.155715][T151472] FIX kmalloc-16: Object at 0x00000000af116201 not freed
[ 3575.156125][T151472] =============================================================================
[ 3575.156170][T151472] BUG kmalloc-16 (Tainted: G B ): Wrong object count. Counter is 174 but counted were 176
[ 3575.156204][T151472] -----------------------------------------------------------------------------
[ 3575.156204][T151472]
[ 3575.156240][T151472] INFO: Slab 0x00000000cafdf25c objects=178 used=174 fp=0x0000000020a64b99 flags=0x7fff8000000201
[ 3575.156296][T151472] CPU: 7 PID: 151472 Comm: trinity-c61 Tainted: G B 5.9.0-rc6-next-20200922+ #2
[ 3575.156348][T151472] Call Trace:
[ 3575.156376][T151472] [c000001fefdef6f0] [c000000000644278] dump_stack+0xec/0x144 (unreliable)
[ 3575.156439][T151472] [c000001fefdef730] [c00000000035e688] slab_err+0x78/0xb0
[ 3575.156502][T151472] [c000001fefdef810] [c0000000003552a4] on_freelist+0x364/0x390
[ 3575.156541][T151472] [c000001fefdef8b0] [c000000000355aa8] free_debug_processing+0x288/0x600
[ 3575.156598][T151472] [c000001fefdef990] [c000000000356234] __slab_free+0x414/0x5b0
[ 3575.156644][T151472] [c000001fefdefa60] [c00000000035686c] kfree+0x49c/0x510
[ 3575.156701][T151472] [c000001fefdefaf0] [c0000000002b8a10] kfree_const+0x60/0x80
[ 3575.156738][T151472] [c000001fefdefb10] [c00000000064d3bc] kobject_release+0x7c/0xd0
[ 3575.156784][T151472] [c000001fefdefb50] [c0000000006de0c0] put_device+0x20/0x40
[ 3575.156831][T151472] [c000001fefdefb70] [c00000000067015c] pci_remove_bus_device+0x14c/0x170
[ 3575.156867][T151472] [c000001fefdefbb0] [c000000000670070] pci_remove_bus_device+0x60/0x170
[ 3575.156923][T151472] [c000001fefdefbf0] [c0000000006701f4] pci_stop_and_remove_bus_device_locked+0x34/0x50
[ 3575.156998][T151472] [c000001fefdefc20] [c00000000067f5e0] remove_store+0xc0/0xe0
[ 3575.157058][T151472] [c000001fefdefc70] [c0000000006dccd0] dev_attr_store+0x30/0x50
[ 3575.157114][T151472] [c000001fefdefc90] [c00000000049fae8] sysfs_kf_write+0x68/0xb0
[ 3575.157169][T151472] [c000001fefdefcd0] [c00000000049ed14] kernfs_fop_write+0x114/0x260
[ 3575.157215][T151472] [c000001fefdefd20] [c0000000003ab2d4] vfs_write+0xe4/0x260
[ 3575.157256][T151472] [c000001fefdefd70] [c0000000003ab604] ksys_write+0x74/0x130
[ 3575.157301][T151472] [c000001fefdefdc0] [c00000000002a458] system_call_exception+0xf8/0x1d0
[ 3575.157352][T151472] [c000001fefdefe20] [c00000000000d0a8] system_call_common+0xe8/0x218
[ 3575.157396][T151472] FIX kmalloc-16: Object count adjusted.
[ 3575.157457][T151472] pci_bus 0004:09: busn_res: [bus 09-0d] is released
> ---
>
> Changes since v2:
>
> - merged 2 patches.
>
> arch/powerpc/include/asm/pci-bridge.h | 6 ++
> arch/powerpc/kernel/pci-common.c | 114 ++++++++++++++++++++++++++
> 2 files changed, 120 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/pci-bridge.h
> b/arch/powerpc/include/asm/pci-bridge.h
> index b92e81b256e5..ca75cf264ddf 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -48,6 +48,9 @@ struct pci_controller_ops {
>
> /*
> * Structure of a PCI controller (host bridge)
> + *
> + * @irq_count: number of interrupt mappings
> + * @irq_map: interrupt mappings
> */
> struct pci_controller {
> struct pci_bus *bus;
> @@ -127,6 +130,9 @@ struct pci_controller {
>
> void *private_data;
> struct npu *npu;
> +
> + unsigned int irq_count;
> + unsigned int *irq_map;
> };
>
> /* These are used for config access before all the PCI probing
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-
> common.c
> index be108616a721..deb831f0ae13 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -353,6 +353,115 @@ struct pci_controller
> *pci_find_controller_for_domain(int domain_nr)
> return NULL;
> }
>
> +/*
> + * Assumption is made on the interrupt parent. All interrupt-map
> + * entries are considered to have the same parent.
> + */
> +static int pcibios_irq_map_count(struct pci_controller *phb)
> +{
> + const __be32 *imap;
> + int imaplen;
> + struct device_node *parent;
> + u32 intsize, addrsize, parintsize, paraddrsize;
> +
> + if (of_property_read_u32(phb->dn, "#interrupt-cells", &intsize))
> + return 0;
> + if (of_property_read_u32(phb->dn, "#address-cells", &addrsize))
> + return 0;
> +
> + imap = of_get_property(phb->dn, "interrupt-map", &imaplen);
> + if (!imap) {
> + pr_debug("%pOF : no interrupt-map\n", phb->dn);
> + return 0;
> + }
> + imaplen /= sizeof(u32);
> + pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
> +
> + if (imaplen < (addrsize + intsize + 1))
> + return 0;
> +
> + imap += intsize + addrsize;
> + parent = of_find_node_by_phandle(be32_to_cpup(imap));
> + if (!parent) {
> + pr_debug("%pOF : no imap parent found !\n", phb->dn);
> + return 0;
> + }
> +
> + if (of_property_read_u32(parent, "#interrupt-cells", &parintsize)) {
> + pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
> + return 0;
> + }
> +
> + if (of_property_read_u32(parent, "#address-cells", ¶ddrsize))
> + paraddrsize = 0;
> +
> + return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
> +}
> +
> +static void pcibios_irq_map_init(struct pci_controller *phb)
> +{
> + phb->irq_count = pcibios_irq_map_count(phb);
> + if (phb->irq_count < PCI_NUM_INTX)
> + phb->irq_count = PCI_NUM_INTX;
> +
> + pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
> +
> + phb->irq_map = kcalloc(phb->irq_count, sizeof(unsigned int),
> + GFP_KERNEL);
> +}
> +
> +static void pci_irq_map_register(struct pci_dev *pdev, unsigned int virq)
> +{
> + struct pci_controller *phb = pci_bus_to_host(pdev->bus);
> + int i;
> +
> + if (!phb->irq_map)
> + return;
> +
> + for (i = 0; i < phb->irq_count; i++) {
> + /*
> + * Look for an empty or an equivalent slot, as INTx
> + * interrupts can be shared between adapters.
> + */
> + if (phb->irq_map[i] == virq || !phb->irq_map[i]) {
> + phb->irq_map[i] = virq;
> + break;
> + }
> + }
> +
> + if (i == phb->irq_count)
> + pr_err("PCI:%s all platform interrupts mapped\n",
> + pci_name(pdev));
> +}
> +
> +/*
> + * Clearing the mapped interrupts will also clear the underlying
> + * mappings of the ESB pages of the interrupts when under XIVE. It is
> + * a requirement of PowerVM to clear all memory mappings before
> + * removing a PHB.
> + */
> +static void pci_irq_map_dispose(struct pci_bus *bus)
> +{
> + struct pci_controller *phb = pci_bus_to_host(bus);
> + int i;
> +
> + if (!phb->irq_map)
> + return;
> +
> + pr_debug("PCI: Clearing interrupt mappings for PHB %04x:%02x...\n",
> + pci_domain_nr(bus), bus->number);
> + for (i = 0; i < phb->irq_count; i++)
> + irq_dispose_mapping(phb->irq_map[i]);
> +
> + kfree(phb->irq_map);
> +}
> +
> +void pcibios_remove_bus(struct pci_bus *bus)
> +{
> + pci_irq_map_dispose(bus);
> +}
> +EXPORT_SYMBOL_GPL(pcibios_remove_bus);
> +
> /*
> * Reads the interrupt pin to determine if interrupt is use by card.
> * If the interrupt is used, then gets the interrupt line from the
> @@ -401,6 +510,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
>
> pci_dev->irq = virq;
>
> + /* Record all interrut mappings for later removal of a PHB */
> + pci_irq_map_register(pci_dev, virq);
> return 0;
> }
>
> @@ -1554,6 +1665,9 @@ void pcibios_scan_phb(struct pci_controller *hose)
>
> pr_debug("PCI: Scanning PHB %pOF\n", node);
>
> + /* Allocate interrupt mappings array */
> + pcibios_irq_map_init(hose);
> +
> /* Get some IO space for the new PHB */
> pcibios_setup_phb_io_space(hose);
>
^ permalink raw reply
* Re: [PATCH -next] powerpc/perf: Fix symbol undeclared warning
From: Athira Rajeev @ 2020-09-23 2:18 UTC (permalink / raw)
To: Wang Wensheng
Cc: Madhavan Srinivasan, linux-kernel, anju@linux.vnet.ibm.com,
paulus, kajoljain, linuxppc-dev
In-Reply-To: <20200921112557.85471-1-wangwensheng4@huawei.com>
> On 21-Sep-2020, at 4:55 PM, Wang Wensheng <wangwensheng4@huawei.com> wrote:
>
> Build kernel with `C=2`:
> arch/powerpc/perf/isa207-common.c:24:18: warning: symbol
> 'isa207_pmu_format_attr' was not declared. Should it be static?
> arch/powerpc/perf/power9-pmu.c:101:5: warning: symbol 'p9_dd21_bl_ev'
> was not declared. Should it be static?
> arch/powerpc/perf/power9-pmu.c:115:5: warning: symbol 'p9_dd22_bl_ev'
> was not declared. Should it be static?
Hi,
It will be good to include a comment in the commit message saying what is the fix here.
ex, declare p9_dd21_bl_ev/p9_dd22_bl_ev as static variable.
Thanks
Athira
>
> Signed-off-by: Wang Wensheng <wangwensheng4@huawei.com>
> ---
> arch/powerpc/perf/isa207-common.c | 2 +-
> arch/powerpc/perf/power9-pmu.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
> index 964437adec18..85dc860b265b 100644
> --- a/arch/powerpc/perf/isa207-common.c
> +++ b/arch/powerpc/perf/isa207-common.c
> @@ -21,7 +21,7 @@ PMU_FORMAT_ATTR(thresh_stop, "config:32-35");
> PMU_FORMAT_ATTR(thresh_start, "config:36-39");
> PMU_FORMAT_ATTR(thresh_cmp, "config:40-49");
>
> -struct attribute *isa207_pmu_format_attr[] = {
> +static struct attribute *isa207_pmu_format_attr[] = {
> &format_attr_event.attr,
> &format_attr_pmcxsel.attr,
> &format_attr_mark.attr,
> diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
> index 2a57e93a79dc..4a315fad1f99 100644
> --- a/arch/powerpc/perf/power9-pmu.c
> +++ b/arch/powerpc/perf/power9-pmu.c
> @@ -98,7 +98,7 @@ extern u64 PERF_REG_EXTENDED_MASK;
> /* PowerISA v2.07 format attribute structure*/
> extern struct attribute_group isa207_pmu_format_group;
>
> -int p9_dd21_bl_ev[] = {
> +static int p9_dd21_bl_ev[] = {
> PM_MRK_ST_DONE_L2,
> PM_RADIX_PWC_L1_HIT,
> PM_FLOP_CMPL,
> @@ -112,7 +112,7 @@ int p9_dd21_bl_ev[] = {
> PM_DISP_HELD_SYNC_HOLD,
> };
>
> -int p9_dd22_bl_ev[] = {
> +static int p9_dd22_bl_ev[] = {
> PM_DTLB_MISS_16G,
> PM_DERAT_MISS_2M,
> PM_DTLB_MISS_2M,
> --
> 2.25.0
>
^ permalink raw reply
* Re: [PATCH 1/5] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr1-alt-addr' property
From: Rob Herring @ 2020-09-23 2:32 UTC (permalink / raw)
To: Ran Wang
Cc: devicetree, Biwen Li, Shawn Guo, linux-kernel, Li Yang,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200916081831.24747-1-ran.wang_1@nxp.com>
On Wed, Sep 16, 2020 at 04:18:27PM +0800, Ran Wang wrote:
> From: Biwen Li <biwen.li@nxp.com>
>
> The 'fsl,ippdexpcr1-alt-addr' property is used to handle an errata A-008646
> on LS1021A
>
> Signed-off-by: Biwen Li <biwen.li@nxp.com>
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> ---
> Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> index 5a33619..1be58a3 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> @@ -34,6 +34,11 @@ Chassis Version Example Chips
> Optional properties:
> - little-endian : RCPM register block is Little Endian. Without it RCPM
> will be Big Endian (default case).
> + - fsl,ippdexpcr1-alt-addr : The property is related to a hardware issue
> + on SoC LS1021A and only needed on SoC LS1021A.
> + Must include 2 entries:
> + The first entry must be a link to the SCFG device node.
> + The 2nd entry must be offset of register IPPDEXPCR1 in SCFG.
You don't need a DT change for this. You can find SCFG node by its
compatible string and then the offset should be known given this issue
is only on 1 SoC.
Rob
^ permalink raw reply
* Re: [PATCH v4 13/13] mm/debug_vm_pgtable: Avoid none pte in pte_clear_test
From: Anshuman Khandual @ 2020-09-23 3:14 UTC (permalink / raw)
To: Aneesh Kumar K.V, Nathan Chancellor
Cc: linux-mm, akpm, linuxppc-dev, linux-riscv
In-Reply-To: <87zh5wx51b.fsf@linux.ibm.com>
On 09/11/2020 10:51 AM, Aneesh Kumar K.V wrote:
> Nathan Chancellor <natechancellor@gmail.com> writes:
>
>> On Wed, Sep 02, 2020 at 05:12:22PM +0530, Aneesh Kumar K.V wrote:
>>> pte_clear_tests operate on an existing pte entry. Make sure that
>>> is not a none pte entry.
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>> ---
>>> mm/debug_vm_pgtable.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>>> index 9afa1354326b..c36530c69e33 100644
>>> --- a/mm/debug_vm_pgtable.c
>>> +++ b/mm/debug_vm_pgtable.c
>>> @@ -542,9 +542,10 @@ static void __init pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp,
>>> #endif /* PAGETABLE_P4D_FOLDED */
>>>
>>> static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
>>> - unsigned long vaddr)
>>> + unsigned long pfn, unsigned long vaddr,
>>> + pgprot_t prot)
>>> {
>>> - pte_t pte = ptep_get(ptep);
>>> + pte_t pte = pfn_pte(pfn, prot);
>>>
>>> pr_debug("Validating PTE clear\n");
>>> pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
>>> @@ -1049,7 +1050,7 @@ static int __init debug_vm_pgtable(void)
>>>
>>> ptl = pte_lockptr(mm, pmdp);
>>> spin_lock(ptl);
>>> - pte_clear_tests(mm, ptep, vaddr);
>>> + pte_clear_tests(mm, ptep, pte_aligned, vaddr, prot);
>>> pte_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>>> pte_unmap_unlock(ptep, ptl);
>>>
>>> --
>> This patch causes a panic at boot for RISC-V defconfig. The rootfs is here if it is needed:
>> https://github.com/ClangBuiltLinux/boot-utils/blob/3b21a5b71451742866349ba4f18638c5a754e660/images/riscv/rootfs.cpio.zst
>>
>> $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig Image
>>
>> $ qemu-system-riscv64 -bios default -M virt -display none -initrd rootfs.cpio -kernel Image -m 512m -nodefaults -serial mon:stdio
>> ...
>>
>> OpenSBI v0.6
>> ____ _____ ____ _____
>> / __ \ / ____| _ \_ _|
>> | | | |_ __ ___ _ __ | (___ | |_) || |
>> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
>> | |__| | |_) | __/ | | |____) | |_) || |_
>> \____/| .__/ \___|_| |_|_____/|____/_____|
>> | |
>> |_|
>>
>> Platform Name : QEMU Virt Machine
>> Platform HART Features : RV64ACDFIMSU
>> Platform Max HARTs : 8
>> Current Hart : 0
>> Firmware Base : 0x80000000
>> Firmware Size : 120 KB
>> Runtime SBI Version : 0.2
>>
>> MIDELEG : 0x0000000000000222
>> MEDELEG : 0x000000000000b109
>> PMP0 : 0x0000000080000000-0x000000008001ffff (A)
>> PMP1 : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
>> [ 0.000000] Linux version 5.9.0-rc4-next-20200910 (nathan@ubuntu-n2-xlarge-x86) (riscv64-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP Thu Sep 10 19:10:43 MST 2020
>> ...
>> [ 0.294593] NET: Registered protocol family 17
>> [ 0.295781] 9pnet: Installing 9P2000 support
>> [ 0.296153] Key type dns_resolver registered
>> [ 0.296694] debug_vm_pgtable: [debug_vm_pgtable ]: Validating architecture page table helpers
>> [ 0.297635] Unable to handle kernel paging request at virtual address 0a7fffe01dafefc8
>> [ 0.298029] Oops [#1]
>> [ 0.298153] Modules linked in:
>> [ 0.298433] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4-next-20200910 #1
>> [ 0.298792] epc: ffffffe000205afc ra : ffffffe0008be0aa sp : ffffffe01ae73d40
>> [ 0.299078] gp : ffffffe0010b9b48 tp : ffffffe01ae68000 t0 : ffffffe008152000
>> [ 0.299362] t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffe01ae73d60
>> [ 0.299648] s1 : bffffffffffffffb a0 : 0a7fffe01dafefc8 a1 : bffffffffffffffb
>> [ 0.299948] a2 : ffffffe0010a2698 a3 : 0000000000000001 a4 : 0000000000000003
>> [ 0.300231] a5 : 0000000000000800 a6 : fffffffff0000080 a7 : 000000001b642000
>> [ 0.300521] s2 : ffffffe0081517b8 s3 : ffffffe008150a80 s4 : ffffffe01af30000
>> [ 0.300806] s5 : ffffffe01f8ca9b8 s6 : ffffffe008150000 s7 : ffffffe0010bb100
>> [ 0.301161] s8 : ffffffe0010bb108 s9 : 0000000000080202 s10: ffffffe0010bb928
>> [ 0.301481] s11: 000000002008085b t3 : 0000000000000000 t4 : 0000000000000000
>> [ 0.301722] t5 : 0000000000000000 t6 : ffffffe008150000
>> [ 0.301947] status: 0000000000000120 badaddr: 0a7fffe01dafefc8 cause: 000000000000000f
>> [ 0.302569] ---[ end trace 7ffb153d816164cf ]---
>> [ 0.302797] note: swapper/0[1] exited with preempt_count 1
>> [ 0.303101] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> [ 0.303614] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>
>
> I guess it is the combination of a valid pte and usage of
> RANDOM_ORVALUE. The below change get the kernel to boot. Can somebody
> faimilar with riscv pte format take a look at the RANDOM_ORVALUE?
>
> modified mm/debug_vm_pgtable.c
> @@ -548,7 +548,7 @@ static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
> pte_t pte = pfn_pte(pfn, prot);
>
> pr_debug("Validating PTE clear\n");
> - pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
> +// pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
> set_pte_at(mm, vaddr, ptep, pte);
> barrier();
> pte_clear(mm, vaddr, ptep);
Do we have a fix for this problem ? Otherwise we just risk going into
the next release with this regression on riscv platforms.
^ permalink raw reply
* [PATCH 3/9] iov_iter: refactor rw_copy_check_uvector and import_iovec
From: Christoph Hellwig @ 2020-09-23 6:05 UTC (permalink / raw)
To: Alexander Viro
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, linux-arch, linux-s390, linux-scsi, Arnd Bergmann,
linux-block, io-uring, linux-arm-kernel, Jens Axboe, linux-parisc,
netdev, linux-kernel, linux-security-module, David Laight,
linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200923060547.16903-1-hch@lst.de>
Split rw_copy_check_uvector into two new helpers with more sensible
calling conventions:
- iovec_from_user copies a iovec from userspace either into the provided
stack buffer if it fits, or allocates a new buffer for it. Returns
the actually used iovec. It also verifies that iov_len does fit a
signed type, and handles compat iovecs if the compat flag is set.
- __import_iovec consolidates the native and compat versions of
import_iovec. It calls iovec_from_user, then validates each iovec
actually points to user addresses, and ensures the total length
doesn't overflow.
This has two major implications:
- the access_process_vm case loses the total lenght checking, which
wasn't required anyway, given that each call receives two iovecs
for the local and remote side of the operation, and it verifies
the total length on the local side already.
- instead of a single loop there now are two loops over the iovecs.
Given that the iovecs are cache hot this doesn't make a major
difference
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/linux/compat.h | 6 -
include/linux/fs.h | 13 --
include/linux/uio.h | 12 +-
lib/iov_iter.c | 300 ++++++++++++++++-------------------------
mm/process_vm_access.c | 34 +++--
5 files changed, 138 insertions(+), 227 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 654c1ec36671a4..b930de791ff16b 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -451,12 +451,6 @@ extern long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
struct epoll_event; /* fortunately, this one is fixed-layout */
-extern ssize_t compat_rw_copy_check_uvector(int type,
- const struct compat_iovec __user *uvector,
- unsigned long nr_segs,
- unsigned long fast_segs, struct iovec *fast_pointer,
- struct iovec **ret_pointer);
-
extern void __user *compat_alloc_user_space(unsigned long len);
int compat_restore_altstack(const compat_stack_t __user *uss);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 7519ae003a082c..e69b45b6cc7b5f 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -178,14 +178,6 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
/* File supports async buffered reads */
#define FMODE_BUF_RASYNC ((__force fmode_t)0x40000000)
-/*
- * Flag for rw_copy_check_uvector and compat_rw_copy_check_uvector
- * that indicates that they should check the contents of the iovec are
- * valid, but not check the memory that the iovec elements
- * points too.
- */
-#define CHECK_IOVEC_ONLY -1
-
/*
* Attribute flags. These should be or-ed together to figure out what
* has been changed!
@@ -1887,11 +1879,6 @@ static inline int call_mmap(struct file *file, struct vm_area_struct *vma)
return file->f_op->mmap(file, vma);
}
-ssize_t rw_copy_check_uvector(int type, const struct iovec __user * uvector,
- unsigned long nr_segs, unsigned long fast_segs,
- struct iovec *fast_pointer,
- struct iovec **ret_pointer);
-
extern ssize_t vfs_read(struct file *, char __user *, size_t, loff_t *);
extern ssize_t vfs_write(struct file *, const char __user *, size_t, loff_t *);
extern ssize_t vfs_readv(struct file *, const struct iovec __user *,
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 3835a8a8e9eae0..92c11fe41c6228 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -266,9 +266,15 @@ bool csum_and_copy_from_iter_full(void *addr, size_t bytes, __wsum *csum, struct
size_t hash_and_copy_to_iter(const void *addr, size_t bytes, void *hashp,
struct iov_iter *i);
-ssize_t import_iovec(int type, const struct iovec __user * uvector,
- unsigned nr_segs, unsigned fast_segs,
- struct iovec **iov, struct iov_iter *i);
+struct iovec *iovec_from_user(const struct iovec __user *uvector,
+ unsigned long nr_segs, unsigned long fast_segs,
+ struct iovec *fast_iov, bool compat);
+ssize_t import_iovec(int type, const struct iovec __user *uvec,
+ unsigned nr_segs, unsigned fast_segs, struct iovec **iovp,
+ struct iov_iter *i);
+ssize_t __import_iovec(int type, const struct iovec __user *uvec,
+ unsigned nr_segs, unsigned fast_segs, struct iovec **iovp,
+ struct iov_iter *i, bool compat);
#ifdef CONFIG_COMPAT
struct compat_iovec;
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index ccea9db3f72be8..d5d8afe31fca16 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -7,6 +7,7 @@
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/splice.h>
+#include <linux/compat.h>
#include <net/checksum.h>
#include <linux/scatterlist.h>
#include <linux/instrumented.h>
@@ -1650,107 +1651,133 @@ const void *dup_iter(struct iov_iter *new, struct iov_iter *old, gfp_t flags)
}
EXPORT_SYMBOL(dup_iter);
-/**
- * rw_copy_check_uvector() - Copy an array of &struct iovec from userspace
- * into the kernel and check that it is valid.
- *
- * @type: One of %CHECK_IOVEC_ONLY, %READ, or %WRITE.
- * @uvector: Pointer to the userspace array.
- * @nr_segs: Number of elements in userspace array.
- * @fast_segs: Number of elements in @fast_pointer.
- * @fast_pointer: Pointer to (usually small on-stack) kernel array.
- * @ret_pointer: (output parameter) Pointer to a variable that will point to
- * either @fast_pointer, a newly allocated kernel array, or NULL,
- * depending on which array was used.
- *
- * This function copies an array of &struct iovec of @nr_segs from
- * userspace into the kernel and checks that each element is valid (e.g.
- * it does not point to a kernel address or cause overflow by being too
- * large, etc.).
- *
- * As an optimization, the caller may provide a pointer to a small
- * on-stack array in @fast_pointer, typically %UIO_FASTIOV elements long
- * (the size of this array, or 0 if unused, should be given in @fast_segs).
- *
- * @ret_pointer will always point to the array that was used, so the
- * caller must take care not to call kfree() on it e.g. in case the
- * @fast_pointer array was used and it was allocated on the stack.
- *
- * Return: The total number of bytes covered by the iovec array on success
- * or a negative error code on error.
- */
-ssize_t rw_copy_check_uvector(int type, const struct iovec __user *uvector,
- unsigned long nr_segs, unsigned long fast_segs,
- struct iovec *fast_pointer, struct iovec **ret_pointer)
+static int copy_compat_iovec_from_user(struct iovec *iov,
+ const struct iovec __user *uvec, unsigned long nr_segs)
+{
+ const struct compat_iovec __user *uiov =
+ (const struct compat_iovec __user *)uvec;
+ int ret = -EFAULT, i;
+
+ if (!user_access_begin(uvec, nr_segs * sizeof(*uvec)))
+ return -EFAULT;
+
+ for (i = 0; i < nr_segs; i++) {
+ compat_uptr_t buf;
+ compat_ssize_t len;
+
+ unsafe_get_user(len, &uiov[i].iov_len, uaccess_end);
+ unsafe_get_user(buf, &uiov[i].iov_base, uaccess_end);
+
+ /* check for compat_size_t not fitting in compat_ssize_t .. */
+ if (len < 0) {
+ ret = -EINVAL;
+ goto uaccess_end;
+ }
+ iov[i].iov_base = compat_ptr(buf);
+ iov[i].iov_len = len;
+ }
+
+ ret = 0;
+uaccess_end:
+ user_access_end();
+ return ret;
+}
+
+static int copy_iovec_from_user(struct iovec *iov,
+ const struct iovec __user *uvec, unsigned long nr_segs)
{
unsigned long seg;
- ssize_t ret;
- struct iovec *iov = fast_pointer;
- /*
- * SuS says "The readv() function *may* fail if the iovcnt argument
- * was less than or equal to 0, or greater than {IOV_MAX}. Linux has
- * traditionally returned zero for zero segments, so...
- */
- if (nr_segs == 0) {
- ret = 0;
- goto out;
+ if (copy_from_user(iov, uvec, nr_segs * sizeof(*uvec)))
+ return -EFAULT;
+ for (seg = 0; seg < nr_segs; seg++) {
+ if ((ssize_t)iov[seg].iov_len < 0)
+ return -EINVAL;
}
+ return 0;
+}
+
+struct iovec *iovec_from_user(const struct iovec __user *uvec,
+ unsigned long nr_segs, unsigned long fast_segs,
+ struct iovec *fast_iov, bool compat)
+{
+ struct iovec *iov = fast_iov;
+ int ret;
+
/*
- * First get the "struct iovec" from user memory and
- * verify all the pointers
+ * SuS says "The readv() function *may* fail if the iovcnt argument was
+ * less than or equal to 0, or greater than {IOV_MAX}. Linux has
+ * traditionally returned zero for zero segments, so...
*/
- if (nr_segs > UIO_MAXIOV) {
- ret = -EINVAL;
- goto out;
- }
+ if (nr_segs == 0)
+ return iov;
+ if (nr_segs > UIO_MAXIOV)
+ return ERR_PTR(-EINVAL);
if (nr_segs > fast_segs) {
iov = kmalloc_array(nr_segs, sizeof(struct iovec), GFP_KERNEL);
- if (iov == NULL) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!iov)
+ return ERR_PTR(-ENOMEM);
}
- if (copy_from_user(iov, uvector, nr_segs*sizeof(*uvector))) {
- ret = -EFAULT;
- goto out;
+
+ if (compat)
+ ret = copy_compat_iovec_from_user(iov, uvec, nr_segs);
+ else
+ ret = copy_iovec_from_user(iov, uvec, nr_segs);
+ if (ret) {
+ if (iov != fast_iov)
+ kfree(iov);
+ return ERR_PTR(ret);
+ }
+
+ return iov;
+}
+
+ssize_t __import_iovec(int type, const struct iovec __user *uvec,
+ unsigned nr_segs, unsigned fast_segs, struct iovec **iovp,
+ struct iov_iter *i, bool compat)
+{
+ ssize_t total_len = 0;
+ unsigned long seg;
+ struct iovec *iov;
+
+ iov = iovec_from_user(uvec, nr_segs, fast_segs, *iovp, compat);
+ if (IS_ERR(iov)) {
+ *iovp = NULL;
+ return PTR_ERR(iov);
}
/*
- * According to the Single Unix Specification we should return EINVAL
- * if an element length is < 0 when cast to ssize_t or if the
- * total length would overflow the ssize_t return value of the
- * system call.
+ * According to the Single Unix Specification we should return EINVAL if
+ * an element length is < 0 when cast to ssize_t or if the total length
+ * would overflow the ssize_t return value of the system call.
*
* Linux caps all read/write calls to MAX_RW_COUNT, and avoids the
* overflow case.
*/
- ret = 0;
for (seg = 0; seg < nr_segs; seg++) {
- void __user *buf = iov[seg].iov_base;
ssize_t len = (ssize_t)iov[seg].iov_len;
- /* see if we we're about to use an invalid len or if
- * it's about to overflow ssize_t */
- if (len < 0) {
- ret = -EINVAL;
- goto out;
+ if (!access_ok(iov[seg].iov_base, len)) {
+ if (iov != *iovp)
+ kfree(iov);
+ *iovp = NULL;
+ return -EFAULT;
}
- if (type >= 0
- && unlikely(!access_ok(buf, len))) {
- ret = -EFAULT;
- goto out;
- }
- if (len > MAX_RW_COUNT - ret) {
- len = MAX_RW_COUNT - ret;
+
+ if (len > MAX_RW_COUNT - total_len) {
+ len = MAX_RW_COUNT - total_len;
iov[seg].iov_len = len;
}
- ret += len;
+ total_len += len;
}
-out:
- *ret_pointer = iov;
- return ret;
+
+ iov_iter_init(i, type, iov, nr_segs, total_len);
+ if (iov == *iovp)
+ *iovp = NULL;
+ else
+ *iovp = iov;
+ return total_len;
}
/**
@@ -1759,10 +1786,10 @@ ssize_t rw_copy_check_uvector(int type, const struct iovec __user *uvector,
* &struct iov_iter iterator to access it.
*
* @type: One of %READ or %WRITE.
- * @uvector: Pointer to the userspace array.
+ * @uvec: Pointer to the userspace array.
* @nr_segs: Number of elements in userspace array.
* @fast_segs: Number of elements in @iov.
- * @iov: (input and output parameter) Pointer to pointer to (usually small
+ * @iovp: (input and output parameter) Pointer to pointer to (usually small
* on-stack) kernel array.
* @i: Pointer to iterator that will be initialized on success.
*
@@ -1775,120 +1802,21 @@ ssize_t rw_copy_check_uvector(int type, const struct iovec __user *uvector,
*
* Return: Negative error code on error, bytes imported on success
*/
-ssize_t import_iovec(int type, const struct iovec __user * uvector,
+ssize_t import_iovec(int type, const struct iovec __user *uvec,
unsigned nr_segs, unsigned fast_segs,
- struct iovec **iov, struct iov_iter *i)
+ struct iovec **iovp, struct iov_iter *i)
{
- ssize_t n;
- struct iovec *p;
- n = rw_copy_check_uvector(type, uvector, nr_segs, fast_segs,
- *iov, &p);
- if (n < 0) {
- if (p != *iov)
- kfree(p);
- *iov = NULL;
- return n;
- }
- iov_iter_init(i, type, p, nr_segs, n);
- *iov = p == *iov ? NULL : p;
- return n;
+ return __import_iovec(type, uvec, nr_segs, fast_segs, iovp, i, false);
}
EXPORT_SYMBOL(import_iovec);
#ifdef CONFIG_COMPAT
-#include <linux/compat.h>
-
-ssize_t compat_rw_copy_check_uvector(int type,
- const struct compat_iovec __user *uvector,
- unsigned long nr_segs, unsigned long fast_segs,
- struct iovec *fast_pointer, struct iovec **ret_pointer)
-{
- compat_ssize_t tot_len;
- struct iovec *iov = *ret_pointer = fast_pointer;
- ssize_t ret = 0;
- int seg;
-
- /*
- * SuS says "The readv() function *may* fail if the iovcnt argument
- * was less than or equal to 0, or greater than {IOV_MAX}. Linux has
- * traditionally returned zero for zero segments, so...
- */
- if (nr_segs == 0)
- goto out;
-
- ret = -EINVAL;
- if (nr_segs > UIO_MAXIOV)
- goto out;
- if (nr_segs > fast_segs) {
- ret = -ENOMEM;
- iov = kmalloc_array(nr_segs, sizeof(struct iovec), GFP_KERNEL);
- if (iov == NULL)
- goto out;
- }
- *ret_pointer = iov;
-
- ret = -EFAULT;
- if (!access_ok(uvector, nr_segs*sizeof(*uvector)))
- goto out;
-
- /*
- * Single unix specification:
- * We should -EINVAL if an element length is not >= 0 and fitting an
- * ssize_t.
- *
- * In Linux, the total length is limited to MAX_RW_COUNT, there is
- * no overflow possibility.
- */
- tot_len = 0;
- ret = -EINVAL;
- for (seg = 0; seg < nr_segs; seg++) {
- compat_uptr_t buf;
- compat_ssize_t len;
-
- if (__get_user(len, &uvector->iov_len) ||
- __get_user(buf, &uvector->iov_base)) {
- ret = -EFAULT;
- goto out;
- }
- if (len < 0) /* size_t not fitting in compat_ssize_t .. */
- goto out;
- if (type >= 0 &&
- !access_ok(compat_ptr(buf), len)) {
- ret = -EFAULT;
- goto out;
- }
- if (len > MAX_RW_COUNT - tot_len)
- len = MAX_RW_COUNT - tot_len;
- tot_len += len;
- iov->iov_base = compat_ptr(buf);
- iov->iov_len = (compat_size_t) len;
- uvector++;
- iov++;
- }
- ret = tot_len;
-
-out:
- return ret;
-}
-
-ssize_t compat_import_iovec(int type,
- const struct compat_iovec __user * uvector,
- unsigned nr_segs, unsigned fast_segs,
- struct iovec **iov, struct iov_iter *i)
+ssize_t compat_import_iovec(int type, const struct compat_iovec __user *uvec,
+ unsigned nr_segs, unsigned fast_segs, struct iovec **iovp,
+ struct iov_iter *i)
{
- ssize_t n;
- struct iovec *p;
- n = compat_rw_copy_check_uvector(type, uvector, nr_segs, fast_segs,
- *iov, &p);
- if (n < 0) {
- if (p != *iov)
- kfree(p);
- *iov = NULL;
- return n;
- }
- iov_iter_init(i, type, p, nr_segs, n);
- *iov = p == *iov ? NULL : p;
- return n;
+ return __import_iovec(type, (const struct iovec __user *)uvec, nr_segs,
+ fast_segs, iovp, i, true);
}
EXPORT_SYMBOL(compat_import_iovec);
#endif
diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
index 29c052099affdc..5e728c20c2bead 100644
--- a/mm/process_vm_access.c
+++ b/mm/process_vm_access.c
@@ -276,20 +276,17 @@ static ssize_t process_vm_rw(pid_t pid,
if (rc < 0)
return rc;
if (!iov_iter_count(&iter))
- goto free_iovecs;
-
- rc = rw_copy_check_uvector(CHECK_IOVEC_ONLY, rvec, riovcnt, UIO_FASTIOV,
- iovstack_r, &iov_r);
- if (rc <= 0)
- goto free_iovecs;
-
+ goto free_iov_l;
+ iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r, false);
+ if (IS_ERR(iov_r)) {
+ rc = PTR_ERR(iov_r);
+ goto free_iov_l;
+ }
rc = process_vm_rw_core(pid, &iter, iov_r, riovcnt, flags, vm_write);
-
-free_iovecs:
if (iov_r != iovstack_r)
kfree(iov_r);
+free_iov_l:
kfree(iov_l);
-
return rc;
}
@@ -333,18 +330,17 @@ compat_process_vm_rw(compat_pid_t pid,
if (rc < 0)
return rc;
if (!iov_iter_count(&iter))
- goto free_iovecs;
- rc = compat_rw_copy_check_uvector(CHECK_IOVEC_ONLY, rvec, riovcnt,
- UIO_FASTIOV, iovstack_r,
- &iov_r);
- if (rc <= 0)
- goto free_iovecs;
-
+ goto free_iov_l;
+ iov_r = iovec_from_user((const struct iovec __user *)rvec, riovcnt,
+ UIO_FASTIOV, iovstack_r, true);
+ if (IS_ERR(iov_r)) {
+ rc = PTR_ERR(iov_r);
+ goto free_iov_l;
+ }
rc = process_vm_rw_core(pid, &iter, iov_r, riovcnt, flags, vm_write);
-
-free_iovecs:
if (iov_r != iovstack_r)
kfree(iov_r);
+free_iov_l:
kfree(iov_l);
return rc;
}
--
2.28.0
^ permalink raw reply related
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