[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
https://bugzilla.kernel.org/show_bug.cgi?id=215389 --- Comment #8 from Christophe Leroy (christophe.le...@csgroup.eu) --- Looking closer, in fact that might be a false positive. The huge difference with that bad commit is that: - Before the commit, the kernel is built _without_ CONFIG_VMAP_STACK - After the commit, the kernel is built _with_ CONFIG_VMAP_STACK Would you be able to perform following tests: - Disable VMAP_STACK and see if the problem still occurs. - Disable ADB_PMU and see it the problem still occurs. With the version which preceeds the bad commit, can you disable ADB_PMU and enable VMAP_STACK and see what happens ? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] PCI/DPC: Disable DPC when link is in L2/L3 ready, L2 and L3 state
Since TLP and DLLP transmission is disabled for a Link in L2/L3 Ready,
L2 and L3, and DPC depends on AER, so also disable DPC here.
Signed-off-by: Kai-Heng Feng
---
drivers/pci/pcie/dpc.c | 61 +++---
1 file changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 3e9afee02e8d1..9585c10b7c577 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -343,13 +343,34 @@ void pci_dpc_init(struct pci_dev *pdev)
}
}
+static void dpc_enable(struct pcie_device *dev)
+{
+ struct pci_dev *pdev = dev->port;
+ u16 ctl;
+
+ pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, );
+
+ ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL |
PCI_EXP_DPC_CTL_INT_EN;
+ pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl);
+}
+
+static void dpc_disable(struct pcie_device *dev)
+{
+ struct pci_dev *pdev = dev->port;
+ u16 ctl;
+
+ pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, );
+ ctl &= ~(PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN);
+ pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl);
+}
+
#define FLAG(x, y) (((x) & (y)) ? '+' : '-')
static int dpc_probe(struct pcie_device *dev)
{
struct pci_dev *pdev = dev->port;
struct device *device = >device;
int status;
- u16 ctl, cap;
+ u16 cap;
if (!pcie_aer_is_native(pdev) && !pcie_ports_dpc_native)
return -ENOTSUPP;
@@ -364,10 +385,7 @@ static int dpc_probe(struct pcie_device *dev)
}
pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CAP, );
- pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, );
-
- ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL |
PCI_EXP_DPC_CTL_INT_EN;
- pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl);
+ dpc_enable(dev);
pci_info(pdev, "enabled with IRQ %d\n", dev->irq);
pci_info(pdev, "error containment capabilities: Int Msg #%d, RPExt%c
PoisonedTLP%c SwTrigger%c RP PIO Log %d, DL_ActiveErr%c\n",
@@ -380,22 +398,33 @@ static int dpc_probe(struct pcie_device *dev)
return status;
}
-static void dpc_remove(struct pcie_device *dev)
+static int dpc_suspend(struct pcie_device *dev)
{
- struct pci_dev *pdev = dev->port;
- u16 ctl;
+ dpc_disable(dev);
+ return 0;
+}
- pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, );
- ctl &= ~(PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN);
- pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl);
+static int dpc_resume(struct pcie_device *dev)
+{
+ dpc_enable(dev);
+ return 0;
+}
+
+static void dpc_remove(struct pcie_device *dev)
+{
+ dpc_disable(dev);
}
static struct pcie_port_service_driver dpcdriver = {
- .name = "dpc",
- .port_type = PCIE_ANY_PORT,
- .service= PCIE_PORT_SERVICE_DPC,
- .probe = dpc_probe,
- .remove = dpc_remove,
+ .name = "dpc",
+ .port_type = PCIE_ANY_PORT,
+ .service= PCIE_PORT_SERVICE_DPC,
+ .probe = dpc_probe,
+ .suspend= dpc_suspend,
+ .resume = dpc_resume,
+ .runtime_suspend= dpc_suspend,
+ .runtime_resume = dpc_resume,
+ .remove = dpc_remove,
};
int __init pcie_dpc_init(void)
--
2.33.1
[PATCH 1/2] PCI/AER: Disable AER when link is in L2/L3 ready, L2 and L3 state
Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
hint") enables ACS, and some platforms lose its NVMe after resume from
S3:
[ 50.947816] pcieport :00:1b.0: DPC: containment event, status:0x1f01
source:0x
[ 50.947817] pcieport :00:1b.0: DPC: unmasked uncorrectable error detected
[ 50.947829] pcieport :00:1b.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal), type=Transaction Layer, (Receiver ID)
[ 50.947830] pcieport :00:1b.0: device [8086:06ac] error
status/mask=0020/0001
[ 50.947831] pcieport :00:1b.0:[21] ACSViol(First)
[ 50.947841] pcieport :00:1b.0: AER: broadcast error_detected message
[ 50.947843] nvme nvme0: frozen state error detected, reset controller
It happens right after ACS gets enabled during resume.
There's another case, when Thunderbolt reaches D3cold:
[ 30.100211] pcieport :00:1d.0: AER: Uncorrected (Non-Fatal) error
received: :00:1d.0
[ 30.100251] pcieport :00:1d.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal), type=Transaction Layer, (Requester ID)
[ 30.100256] pcieport :00:1d.0: device [8086:7ab0] error
status/mask=0010/4000
[ 30.100262] pcieport :00:1d.0:[20] UnsupReq (First)
[ 30.100267] pcieport :00:1d.0: AER: TLP Header: 3400 0852
[ 30.100372] thunderbolt :0a:00.0: AER: can't recover (no error_detected
callback)
[ 30.100401] xhci_hcd :3e:00.0: AER: can't recover (no error_detected
callback)
[ 30.100427] pcieport :00:1d.0: AER: device recovery failed
Since PCIe spec "5.2 Link State Power Management" states that TLP and DLLP
transmission is disabled for a Link in L2/L3 Ready (D3hot), L2 (D3cold with aux
power) and L3 (D3cold), so disable AER to avoid the noises from turning power
rails on/off.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209149
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215453
Fixes: 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in hint")
Signed-off-by: Kai-Heng Feng
---
drivers/pci/pcie/aer.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 9fa1f97e5b270..e4e9d4a3098d7 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1367,6 +1367,22 @@ static int aer_probe(struct pcie_device *dev)
return 0;
}
+static int aer_suspend(struct pcie_device *dev)
+{
+ struct aer_rpc *rpc = get_service_data(dev);
+
+ aer_disable_rootport(rpc);
+ return 0;
+}
+
+static int aer_resume(struct pcie_device *dev)
+{
+ struct aer_rpc *rpc = get_service_data(dev);
+
+ aer_enable_rootport(rpc);
+ return 0;
+}
+
/**
* aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP
* @dev: pointer to Root Port, RCEC, or RCiEP
@@ -1433,12 +1449,15 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
*dev)
}
static struct pcie_port_service_driver aerdriver = {
- .name = "aer",
- .port_type = PCIE_ANY_PORT,
- .service= PCIE_PORT_SERVICE_AER,
-
- .probe = aer_probe,
- .remove = aer_remove,
+ .name = "aer",
+ .port_type = PCIE_ANY_PORT,
+ .service= PCIE_PORT_SERVICE_AER,
+ .probe = aer_probe,
+ .suspend= aer_suspend,
+ .resume = aer_resume,
+ .runtime_suspend= aer_suspend,
+ .runtime_resume = aer_resume,
+ .remove = aer_remove,
};
/**
--
2.33.1
[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
https://bugzilla.kernel.org/show_bug.cgi?id=215389 --- Comment #7 from Christophe Leroy (christophe.le...@csgroup.eu) --- Interesting ... Though confusing. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 6/7] modules: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
Le 25/01/2022 à 22:10, Luis Chamberlain a écrit : > On Mon, Jan 24, 2022 at 09:22:34AM +, Christophe Leroy wrote: >> This can also be useful on other powerpc/32 in order to maximize the >> chance of code being close enough to kernel core to avoid branch >> trampolines. > > Curious about all this branch trampoline talk. Do you have data to show > negative impact with things as-is? See https://github.com/linuxppc/linux/commit/2ec13df167040cd153c25c4d96d0ffc573ac4c40 Or https://github.com/linuxppc/linux/commit/7d485f647c1f4a6976264c90447fb0dbf07b111d > > Also, was powerpc/32 broken then without this? The commit log seems to > suggest so, but I don't think that's the case. How was this issue noticed? Your question is related to the trampoline topic or the exec/noexec flagging ? Regarding trampoline, everything is working OK. That's just cherry on the cake, when putting data away you can have more code closer to the kernel. But that would not have been a reason in itself for this series. Regarding the exec/noexec discussion, it's a real issue. powerpc/32 doesn't honor page exec flag, so when you select STRICT_MODULES_RWX and flag module data as no-exec, it remains executable. That's because powerpc/32 MMU doesn't have a per page exec flag but only a per 256Mbytes segment exec flag. Typical PPC32 layount: 0xf000-0x : VMALLOC AREA ==> NO EXEC 0xc000-0xefff : Linear kernel memory mapping 0xb000-0xbfff : MODULES AREA ==> EXEC 0x-0xafff : User space ==> EXEC So STRICT_MODULES_RWX is broken on some powerpc/32 > > Are there other future CPU families being planned where this is all true for > as well? Are they goin to be 32-bit as well? Future I don't know. Regarding the trampoline stuff, I see at least the following existing architectures with a similar constraint: ARM: https://elixir.bootlin.com/linux/v5.16/source/arch/arm/include/asm/memory.h#L55 ARM even has a config item to allow trampolines or not. I might add the same to powerpc to reduce number of pages used by modules. https://elixir.bootlin.com/linux/v5.16/source/arch/arm/Kconfig#L1514 NDS32 has the constraint https://elixir.bootlin.com/linux/v5.16/source/arch/nds32/include/asm/memory.h#L41 NIOS2 has the constraint, allthough they handled it in a different way: https://elixir.bootlin.com/linux/v5.16/source/arch/nios2/kernel/module.c#L30 Even ARM64 benefits from modules closer to kernel: https://elixir.bootlin.com/linux/v5.16/source/arch/arm64/Kconfig#L1848 Another future opportunity with the ability to allocate module parts separately is the possibility to then use huge vmalloc mappings. Today huge vmalloc mappings cannot be used for modules, see recent discussion at https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20211227145903.187152-4-wangkefeng.w...@huawei.com/ Christophe
Re: [PATCH 0/7] Allocate module text and data separately
Le 25/01/2022 à 21:52, Luis Chamberlain a écrit : > On Mon, Jan 24, 2022 at 09:22:11AM +, Christophe Leroy wrote: >> This series allow architectures to request having modules data in >> vmalloc area instead of module area. >> >> This is required on powerpc book3s/32 in order to set data non >> executable, because it is not possible to set executability on page >> basis, this is done per 256 Mbytes segments. The module area has exec >> right, vmalloc area has noexec. >> >> This can also be useful on other powerpc/32 in order to maximize the >> chance of code being close enough to kernel core to avoid branch >> trampolines. > > Am I understanding that this entire effort is for 32-bit powerpc? > If so, why such an interest in 32-bit these days? > 32 bit powerpc processors are still manufactured and are widely used in embedded products like internet boxes, small routers, etc ... One of the reason is that there power consumption hence their heat dissipation is way lower than 64 bits variants. I found the effort quite small compared to the benefit it provides. Christophe
Re: [PATCH v3] powerpc: Add missing SPDX license identifiers
> On Fri, Jan 21, 2022 at 03:13:50PM +, Christophe Leroy wrote: > > Isn't it what GPL-2.0+ means ? Greg Kroah-Hartman wrote: > Yes, but look further down, as I point out below... > > > >> include/asm/epapr_hcalls.h:/* SPDX-License-Identifier: GPL-2.0+ OR BSD > > >> */ > > >> include/asm/fsl_hcalls.h:/* SPDX-License-Identifier: GPL-2.0+ OR BSD */ > > >> include/asm/ibmebus.h:/* SPDX-License-Identifier: GPL-2.0 OR OpenIB BSD > > >> */ > > >> include/asm/sfp-machine.h:/* SPDX-License-Identifier: LGPL-2.0+ */ > > >> kvm/mpic.c:// SPDX-License-Identifier: GPL-2.0 > > >> lib/crtsavres.S:/* SPDX-License-Identifier: GPL-2.0+ */ > > >> mm/book3s64/hash_4k.c:// SPDX-License-Identifier: LGPL-2.0 > > >> mm/book3s64/hash_64k.c:// SPDX-License-Identifier: LGPL-2.0 > > >> mm/book3s64/hash_hugepage.c:// SPDX-License-Identifier: LGPL-2.1 > > >> platforms/pseries/ibmebus.c:// SPDX-License-Identifier: GPL-2.0 OR > > >> OpenIB BSD > > >> tools/head_check.sh:# SPDX-License-Identifier: GPL-2.0+ > > >> xmon/ppc.h:/* SPDX-License-Identifier: GPL-1.0+ */ If you're combining GPLv2-or-later works with LGPLv2.0/2.1 works, you'll have to normalize to some GPLv2-based license (such as GPLv2-or-later), since LGPLv2.1 requires that for combinations. You won't be able to carry along the "OR 3-Clause-BSD" part once the combination is made. Similarly true with GPLv2-or-later, but LGPL is the interesting one because it's explicit about the need to change license notices to GPL notices when you combine. -- bkuhn
RE: Build regressions/improvements in v5.17-rc1
> -Original Message-
> From: Geert Uytterhoeven
> Sent: Monday, January 24, 2022 1:26 PM
> To: linux-ker...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; sparcli...@vger.kernel.org; linux-
> u...@lists.infradead.org; D, Lakshmi Sowjanya
> ; k...@vger.kernel.org; linux-
> m...@vger.kernel.org; Tobin C. Harding ; alsa-devel@alsa-
> project.org; amd-...@lists.freedesktop.org; net...@vger.kernel.org
> Subject: Re: Build regressions/improvements in v5.17-rc1
>
> On Sun, 23 Jan 2022, Geert Uytterhoeven wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v5.17-rc1[1] compared to v5.16[2].
> >
> > Summarized:
> > - build errors: +17/-2
> > - build warnings: +23/-25
> >
> > Note that there may be false regressions, as some logs are incomplete.
> > Still, they're build errors/warnings.
> >
> > Happy fixing! ;-)
> >
> > Thanks to the linux-next team for providing the build service.
> >
> > [1]
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e783362eb54cd99b
> > 2cac8b3a9aeac942e6f6ac07/ (all 99 configs) [2]
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/df0cc57e057f18e4
> > 4dac8e6c18aba47ab53202f9/ (98 out of 99 configs)
> >
> >
> > *** ERRORS ***
> >
> > 17 error regressions:
> > + /kisskb/src/arch/powerpc/kernel/stacktrace.c: error: implicit
> > declaration of function 'nmi_cpu_backtrace'
> > [-Werror=implicit-function-declaration]: => 171:2 +
> > /kisskb/src/arch/powerpc/kernel/stacktrace.c: error: implicit
> > declaration of function 'nmi_trigger_cpumask_backtrace'
> > [-Werror=implicit-function-declaration]: => 226:2
>
> powerpc-gcc5/skiroot_defconfig
>
> > + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible
> > function types from 'void (*)(long unsigned int)' to 'void (*)(long
> > unsigned int, long unsigned int, long unsigned int, long unsigned
> > int, long unsigned int)' [-Werror=cast-function-type]: => 1756:13,
> > 1639:13 + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between
> > incompatible function types from 'void (*)(struct mm_struct *)' to
> > 'void (*)(long unsigned int, long unsigned int, long unsigned int,
> > long unsigned int, long unsigned int)' [-Werror=cast-function-type]:
> > => 1674:29, 1662:29 + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast
> > between incompatible function types from 'void (*)(struct mm_struct *,
> > long unsigned int)' to 'void (*)(long unsigned int, long unsigned
> > int, long unsigned int, long unsigned int, long unsigned int)'
> > [-Werror=cast-function-type]: => 1767:21 +
> > /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible
> > function types from 'void (*)(struct vm_area_struct *, long unsigned
> > int)' to 'void (*)(long unsigned int, long unsigned int, long
> > unsigned int, long unsigned int, long unsigned int)'
> > [-Werror=cast-function-type]: => 1741:29, 1726:29 +
> > /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible
> > function types from 'void (*)(struct vm_area_struct *, long unsigned
> > int, long unsigned int)' to 'void (*)(long unsigned int, long
> > unsigned int, long unsigned int, long unsigned int, long unsigned
> > int)' [-Werror=cast-function-type]: => 1694:29, 1711:29
>
> sparc64-gcc11/sparc-allmodconfig
>
> > + /kisskb/src/arch/um/include/asm/processor-generic.h: error: called
> > object is not a function or function pointer: => 103:18 +
> > /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: assignment makes
> > pointer from integer without a cast [-Werror=int-conversion]: =>
> > 324:9, 317:9 + /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error:
> > implicit declaration of function 'ioport_map'
> > [-Werror=implicit-function-declaration]: => 317:11 +
> > /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit
> > declaration of function 'ioport_unmap'
> > [-Werror=implicit-function-declaration]: => 338:15
>
> um-x86_64/um-allyesconfig
>
> > + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:
> > error: control reaches end of non-void function [-Werror=return-type]:
> > => 1560:1
>
> um-x86_64/um-all{mod,yes}config
>
> > + /kisskb/src/drivers/net/ethernet/freescale/fec_mpc52xx.c: error:
> > passing argument 2 of 'mpc52xx_fec_set_paddr' discards 'const'
> > qualifier from pointer target type [-Werror=discarded-qualifiers]: =>
> > 659:29
>
> powerpc-gcc5/ppc32_allmodconfig
>
> > + /kisskb/src/drivers/pinctrl/pinctrl-thunderbay.c: error: assignment
> > discards 'const' qualifier from pointer target type
> > [-Werror=discarded-qualifiers]: => 815:8, 815:29
>
> arm64-gcc5.4/arm64-allmodconfig
> arm64-gcc8/arm64-allmodconfig
>
These errors are fixed with the patch set by Rafał Miłecki:
https://lore.kernel.org/all/cacrpkdybr-hpltcvn1_luxeh_mghlqdmopdqo1ddui9o8zv...@mail.gmail.com/t/
Regards,
Lakshmi Sowjanya
> > + /kisskb/src/lib/test_printf.c: error: "PTR" redefined [-Werror]:
> > => 247:0, 247 +
[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300318
--> https://bugzilla.kernel.org/attachment.cgi?id=300318=edit
bisect.log
Ok, finally got it. Interesting find:
# git bisect bad
db972a3787d12b1ce9ba7a31ec376d8a79e04c47 is the first bad commit
commit db972a3787d12b1ce9ba7a31ec376d8a79e04c47
Author: Christophe Leroy
Date: Tue Dec 8 05:24:19 2020 +
powerpc/powermac: Fix low_sleep_handler with CONFIG_VMAP_STACK
low_sleep_handler() can't restore the context from standard
stack because the stack can hardly be accessed with MMU OFF.
Store everything in a global storage area instead of storing
a pointer to the stack in that global storage area.
To avoid a complete churn of the function, still use r1 as
the pointer to the storage area during restore.
Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
Reported-by: Giuseppe Sacco
Signed-off-by: Christophe Leroy
Tested-by: Giuseppe Sacco
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/e3e0d8042a3ba75cb4a9546c19c408b5b5b28994.1607404931.git.christophe.le...@csgroup.eu
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/platforms/powermac/sleep.S | 132 ++--
2 files changed, 60 insertions(+), 74 deletions(-)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[PATCH v5 5/5] KVM: PPC: Book3s: mmio: Deliver DSI after emulation failure
MMIO emulation can fail if the guest uses an instruction that we are
not prepared to emulate. Since these instructions can be and most
likely are valid ones, this is (slightly) closer to an access fault
than to an illegal instruction, so deliver a Data Storage interrupt
instead of a Program interrupt.
BookE ignores bad faults, so it will keep using a Program interrupt
because a DSI would cause a fault loop in the guest.
Suggested-by: Nicholas Piggin
Signed-off-by: Fabiano Rosas
---
arch/powerpc/kvm/emulate_loadstore.c | 10 +++---
arch/powerpc/kvm/powerpc.c | 22 ++
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kvm/emulate_loadstore.c
b/arch/powerpc/kvm/emulate_loadstore.c
index 48272a9b9c30..cfc9114b87d0 100644
--- a/arch/powerpc/kvm/emulate_loadstore.c
+++ b/arch/powerpc/kvm/emulate_loadstore.c
@@ -73,7 +73,6 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
{
u32 inst;
enum emulation_result emulated = EMULATE_FAIL;
- int advance = 1;
struct instruction_op op;
/* this default type might be overwritten by subcategories */
@@ -98,6 +97,8 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
int type = op.type & INSTR_TYPE_MASK;
int size = GETSIZE(op.type);
+ vcpu->mmio_is_write = OP_IS_STORE(type);
+
switch (type) {
case LOAD: {
int instr_byte_swap = op.type & BYTEREV;
@@ -355,15 +356,10 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
}
}
- if (emulated == EMULATE_FAIL) {
- advance = 0;
- kvmppc_core_queue_program(vcpu, 0);
- }
-
trace_kvm_ppc_instr(inst, kvmppc_get_pc(vcpu), emulated);
/* Advance past emulated instruction. */
- if (advance)
+ if (emulated != EMULATE_FAIL)
kvmppc_set_pc(vcpu, kvmppc_get_pc(vcpu) + 4);
return emulated;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index acb0d2a4bdb9..82d889db2b6b 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -309,6 +309,28 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
kvmppc_get_last_inst(vcpu, INST_GENERIC, _inst);
kvm_debug_ratelimited("Guest access to device memory using
unsupported instruction (opcode: %#08x)\n",
last_inst);
+
+ /*
+* Injecting a Data Storage here is a bit more
+* accurate since the instruction that caused the
+* access could still be a valid one.
+*/
+ if (!IS_ENABLED(CONFIG_BOOKE)) {
+ ulong dsisr = DSISR_BADACCESS;
+
+ if (vcpu->mmio_is_write)
+ dsisr |= DSISR_ISSTORE;
+
+ kvmppc_core_queue_data_storage(vcpu,
vcpu->arch.vaddr_accessed, dsisr);
+ } else {
+ /*
+* BookE does not send a SIGBUS on a bad
+* fault, so use a Program interrupt instead
+* to avoid a fault loop.
+*/
+ kvmppc_core_queue_program(vcpu, 0);
+ }
+
r = RESUME_GUEST;
break;
}
--
2.34.1
[PATCH v5 4/5] KVM: PPC: mmio: Return to guest after emulation failure
If MMIO emulation fails we don't want to crash the whole guest by
returning to userspace.
The original commit bbf45ba57eae ("KVM: ppc: PowerPC 440 KVM
implementation") added a todo:
/* XXX Deliver Program interrupt to guest. */
and later the commit d69614a295ae ("KVM: PPC: Separate loadstore
emulation from priv emulation") added the Program interrupt injection
but in another file, so I'm assuming it was missed that this block
needed to be altered.
Also change the message to a ratelimited one since we're letting the
guest run and it could flood the host logs.
Signed-off-by: Fabiano Rosas
Reviewed-by: Nicholas Piggin
---
arch/powerpc/kvm/powerpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 27fb2b70f631..acb0d2a4bdb9 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -307,9 +307,9 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
u32 last_inst;
kvmppc_get_last_inst(vcpu, INST_GENERIC, _inst);
- /* XXX Deliver Program interrupt to guest. */
- pr_emerg("%s: emulation failed (%08x)\n", __func__, last_inst);
- r = RESUME_HOST;
+ kvm_debug_ratelimited("Guest access to device memory using
unsupported instruction (opcode: %#08x)\n",
+ last_inst);
+ r = RESUME_GUEST;
break;
}
default:
--
2.34.1
[PATCH v5 3/5] KVM: PPC: mmio: Reject instructions that access more than mmio.data size
The MMIO interface between the kernel and userspace uses a structure
that supports a maximum of 8-bytes of data. Instructions that access
more than that need to be emulated in parts.
We currently don't have generic support for splitting the emulation in
parts and each set of instructions needs to be explicitly included.
There's already an error message being printed when a load or store
exceeds the mmio.data buffer but we don't fail the emulation until
later at kvmppc_complete_mmio_load and even then we allow userspace to
make a partial copy of the data, which ends up overwriting some fields
of the mmio structure.
This patch makes the emulation fail earlier at kvmppc_handle_load|store,
which will send a Program interrupt to the guest. This is better than
allowing the guest to proceed with partial data.
Note that this was caught in a somewhat artificial scenario using
quadword instructions (lq/stq), there's no account of an actual guest
in the wild running instructions that are not properly emulated.
(While here, remove the "bad MMIO" messages. The caller already has an
error message.)
Signed-off-by: Fabiano Rosas
Reviewed-by: Alexey Kardashevskiy
Reviewed-by: Nicholas Piggin
---
arch/powerpc/kvm/powerpc.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index c2bd29e90314..27fb2b70f631 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1114,10 +1114,8 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu
*vcpu)
struct kvm_run *run = vcpu->run;
u64 gpr;
- if (run->mmio.len > sizeof(gpr)) {
- printk(KERN_ERR "bad MMIO length: %d\n", run->mmio.len);
+ if (run->mmio.len > sizeof(gpr))
return;
- }
if (!vcpu->arch.mmio_host_swabbed) {
switch (run->mmio.len) {
@@ -1236,10 +1234,8 @@ static int __kvmppc_handle_load(struct kvm_vcpu *vcpu,
host_swabbed = !is_default_endian;
}
- if (bytes > sizeof(run->mmio.data)) {
- printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
- run->mmio.len);
- }
+ if (bytes > sizeof(run->mmio.data))
+ return EMULATE_FAIL;
run->mmio.phys_addr = vcpu->arch.paddr_accessed;
run->mmio.len = bytes;
@@ -1325,10 +1321,8 @@ int kvmppc_handle_store(struct kvm_vcpu *vcpu,
host_swabbed = !is_default_endian;
}
- if (bytes > sizeof(run->mmio.data)) {
- printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
- run->mmio.len);
- }
+ if (bytes > sizeof(run->mmio.data))
+ return EMULATE_FAIL;
run->mmio.phys_addr = vcpu->arch.paddr_accessed;
run->mmio.len = bytes;
--
2.34.1
[PATCH v5 2/5] KVM: PPC: Fix vmx/vsx mixup in mmio emulation
The MMIO emulation code for vector instructions is duplicated between
VSX and VMX. When emulating VMX we should check the VMX copy size
instead of the VSX one.
Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction ...")
Signed-off-by: Fabiano Rosas
Reviewed-by: Nicholas Piggin
---
arch/powerpc/kvm/powerpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 50414fb2a5ea..c2bd29e90314 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1499,7 +1499,7 @@ int kvmppc_handle_vmx_load(struct kvm_vcpu *vcpu,
{
enum emulation_result emulated = EMULATE_DONE;
- if (vcpu->arch.mmio_vsx_copy_nums > 2)
+ if (vcpu->arch.mmio_vmx_copy_nums > 2)
return EMULATE_FAIL;
while (vcpu->arch.mmio_vmx_copy_nums) {
@@ -1596,7 +1596,7 @@ int kvmppc_handle_vmx_store(struct kvm_vcpu *vcpu,
unsigned int index = rs & KVM_MMIO_REG_MASK;
enum emulation_result emulated = EMULATE_DONE;
- if (vcpu->arch.mmio_vsx_copy_nums > 2)
+ if (vcpu->arch.mmio_vmx_copy_nums > 2)
return EMULATE_FAIL;
vcpu->arch.io_gpr = rs;
--
2.34.1
[PATCH v5 0/5] KVM: PPC: MMIO fixes
Changes from v4: -patch 4: switched to kvm_debug_ratelimited. -patch 5: kept the Program interrupt for BookE. v4: https://lore.kernel.org/r/20220121222626.972495-1-faro...@linux.ibm.com v3: https://lore.kernel.org/r/20220107210012.4091153-1-faro...@linux.ibm.com v2: https://lore.kernel.org/r/20220106200304.4070825-1-faro...@linux.ibm.com v1: https://lore.kernel.org/r/20211223211528.3560711-1-faro...@linux.ibm.com Fabiano Rosas (5): KVM: PPC: Book3S HV: Stop returning internal values to userspace KVM: PPC: Fix vmx/vsx mixup in mmio emulation KVM: PPC: mmio: Reject instructions that access more than mmio.data size KVM: PPC: mmio: Return to guest after emulation failure KVM: PPC: Book3s: mmio: Deliver DSI after emulation failure arch/powerpc/kvm/emulate_loadstore.c | 10 ++--- arch/powerpc/kvm/powerpc.c | 56 2 files changed, 43 insertions(+), 23 deletions(-) -- 2.34.1
[PATCH v5 1/5] KVM: PPC: Book3S HV: Stop returning internal values to userspace
Our kvm_arch_vcpu_ioctl_run currently returns the RESUME_HOST values to userspace, against the API of the KVM_RUN ioctl which returns 0 on success. Signed-off-by: Fabiano Rosas Reviewed-by: Nicholas Piggin --- This was noticed while enabling the kvm selftests for powerpc. There's an assert at the _vcpu_run function when we return a value different from the expected. --- arch/powerpc/kvm/powerpc.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index 2ad0ccd202d5..50414fb2a5ea 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -1841,6 +1841,14 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) #ifdef CONFIG_ALTIVEC out: #endif + + /* +* We're already returning to userspace, don't pass the +* RESUME_HOST flags along. +*/ + if (r > 0) + r = 0; + vcpu_put(vcpu); return r; } -- 2.34.1
Re: [PATCH 6/7] modules: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
On Mon, Jan 24, 2022 at 09:22:34AM +, Christophe Leroy wrote: > This can also be useful on other powerpc/32 in order to maximize the > chance of code being close enough to kernel core to avoid branch > trampolines. Curious about all this branch trampoline talk. Do you have data to show negative impact with things as-is? Also, was powerpc/32 broken then without this? The commit log seems to suggest so, but I don't think that's the case. How was this issue noticed? Are there other future CPU families being planned where this is all true for as well? Are they goin to be 32-bit as well? Luis
Re: [PATCH 0/7] Allocate module text and data separately
On Mon, Jan 24, 2022 at 09:22:11AM +, Christophe Leroy wrote: > This series allow architectures to request having modules data in > vmalloc area instead of module area. > > This is required on powerpc book3s/32 in order to set data non > executable, because it is not possible to set executability on page > basis, this is done per 256 Mbytes segments. The module area has exec > right, vmalloc area has noexec. > > This can also be useful on other powerpc/32 in order to maximize the > chance of code being close enough to kernel core to avoid branch > trampolines. Am I understanding that this entire effort is for 32-bit powerpc? If so, why such an interest in 32-bit these days? Luis
Re: ppc64le: BUG: Kernel NULL pointer dereference on write at 0x00000000
Dear Paul, Am 25.01.22 um 21:33 schrieb Paul E. McKenney: On Mon, Jan 24, 2022 at 07:48:59PM +0100, Paul Menzel wrote: Building Linux 5.17-rc1+ (dd81e1c7d5fb) under Ubuntu 21.04 with CONFIG_TORTURE_TEST=y CONFIG_RCU_TORTURE_TEST=y and $ clang --version Ubuntu clang version 12.0.0-3ubuntu1~21.04.2 Target: powerpc64le-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin $ make -j100 LLVM=1 LLVM_IAS=0 bindeb-pkg and booting it on an IBM S822LC, it runs into a null pointer dereference. (Please note, the log below is captured using the Serial over LAN (SOL) interface, and I hope it’s all correct and there is no garbage due to overridden lines or characters.): ``` [0.037960][T1] rcu: rcu_spawn_gp_kthread(): Limited prio to 2 from 1 [0.399013][T1] BUG: using smp_processor_id() in preemptible [] code: swapper/0/1 [0.399527][T1] BUG: using smp_processor_id() in preemptible [] code: swapper/0/1 [0.400063][T1] BUG: using smp_processor_id() in preemptible [] code: swapper/0/1 [0.702349][T1] BUG: using smp_processor_id() in preemptible [] code: swapper/0/1 [0.702928][T1] rcu-torture:--- Start of test: nreaders=15 nfakewriters=4 stat_interval=60 verbose=1 test_n_idle_hz=1 sohuffl_eintrvale= 3stut 0.705260][T1] rcu-torture: Creating rcu_torture_fakewriter task [0.705265][ T145] rcu-torture: rcu_torture_fakewriter task started [0.705447][T1] rcu-torture: Creating rcu_torture_reader task [0.705449][ T146] rcu-torture: rcu_torture_fakewriter task started [0.705653][T1] rcu-torture: Creating rcu_torture_reader task [0.705656][ T149] rcu-torture: rcu_torture_reader task started [0.705691][T1] rcu-torture: Creating rcu_torture_reader task [0.705694][ T150] rcu-torture: rcu_torture_reader task started [0.705741][T1] rcu-torture: Creating rcu_torture_reader task [0.705745][ T151] rcu-torture: rcu_torture_reader task started [0.705927][T1] rcu-torture: Creating rcu_torture_reader task [0.705930][ T152] rcu-torture: rcu_torture_reader task started [0.705981][T1] rcu-torture: Creating rcu_torture_reader task [0.705986][ T153] rcu-torture: rcu_torture_reader task started [0.706110][T1] rcu-torture: Creating rcu_torture_reader task [0.706114][ T154] rcu-torture: rcu_torture_reader task started [0.706248][T1] rcu-torture: Creating rcu_torture_reader task [0.706251][ T155] rcu-torture: rcu_torture_reader task started [0.706320][T1] rcu-torture: Creating rcu_torture_reader task [0.706327][ T156] rcu-torture: rcu_torture_reader task started [0.706385][T1] rcu-torture: Creating rcu_torture_reader task [0.706389][ T157] rcu-torture: rcu_torture_reader task started [0.706485][T1] rcu-torture: Creating rcu_torture_reader task [0.706492][ T158] rcu-torture: rcu_torture_reader task started [0.706560][T1] rcu-torture: Creating rcu_torture_reader task [0.706567][ T159] rcu-torture: rcu_torture_reader task started [0.706628][T1] rcu-torture: Creating rcu_torture_reader task [0.706633][ T160] rcu-torture: rcu_torture_reader task started [0.706705][T1] rcu-torture: Creating rcu_torture_reader task [0.706713][ T161] rcu-torture: rcu_torture_reader task started [0.706797][T1] rcu-torture: Creating rcu_torture_reader task [0.706862][ T162] rcu-torture: rcu_torture_reader task started [0.710471][T1] rcu-torture: Creating rcu_torture_stats task [0.710475][ T163] rcu-torture: rcu_torture_reader task started [0.710516][T1] rcu-torture: Creating torture_shuffle task [0.710525][ T166] rcu-torture: rcu_torture_stats task started [0.710607][T1] rcu-torture: Creating torture_stutter task [0.710609][ T167] rcu-torture: torture_shuffle task started [0.710657][ T168] rcu-torture: torture_stutter task started [0.710662][ T18] rcu-torture: Creating rcu_torture_boost task [0.710722][ T169] rcu-torture: rcu_torture_boost started [0.710726][ T19] rcu-torture: Creating rcu_torture_boost task [0.710782][ T170] rcu-torture: rcu_torture_boost started [0.710787][ T25] rcu-torture: Creating rcu_torture_boost task [0.710840][ T171] rcu-torture: rcu_torture_boost started [0.710846][ T32] rcu-torture: Creating rcu_torture_boost task [0.710900][ T172] rcu-torture: rcu_torture_boost started [0.710906][ T38] rcu-torture: Creating rcu_torture_boost task [0.710992][ T173] rcu-torture: rcu_torture_boost started [0.710997][ T45] rcu-torture: Creating rcu_torture_boost task [0.711059][ T174] rcu-torture: rcu_torture_boost started [0.711065][ T51] rcu-torture: Creating rcu_torture_boost task [0.711126][ T175] rcu-torture: rcu_torture_boost started [0.711132][ T58] rcu-torture: Creating rcu_torture_boost task [
Re: [PATCH v5 0/6] KEXEC_SIG with appended signature
On Tue, Jan 11, 2022 at 12:37:42PM +0100, Michal Suchanek wrote: > Hello, > > This is a refresh of the KEXEC_SIG series. > > This adds KEXEC_SIG support on powerpc and deduplicates the code dealing > with appended signatures in the kernel. > > powerpc supports IMA_KEXEC but that's an exception rather than the norm. > On the other hand, KEXEC_SIG is portable across platforms. > > For distributions to have uniform security features across platforms one > option should be used on all platforms. > > Thanks > > Michal > > Previous revision: > https://lore.kernel.org/linuxppc-dev/cover.1637862358.git.msucha...@suse.de/ > Patched kernel tree: https://github.com/hramrach/kernel/tree/kexec_sig > > Michal Suchanek (6): > s390/kexec_file: Don't opencode appended signature check. > powerpc/kexec_file: Add KEXEC_SIG support. > kexec_file: Don't opencode appended signature verification. > module: strip the signature marker in the verification function. > module: Use key_being_used_for for log messages in > verify_appended_signature > module: Move duplicate mod_check_sig users code to mod_parse_sig What tree should this go through? I'd prefer if over through modules tree as it can give a chance for Aaron Tomlin to work with this for his code refactoring of kernel/module*.c to kernel/module/ Luis
Re: [PATCH v5 6/6] module: Move duplicate mod_check_sig users code to mod_parse_sig
On Tue, Jan 11, 2022 at 12:37:48PM +0100, Michal Suchanek wrote: > Multiple users of mod_check_sig check for the marker, then call > mod_check_sig, extract signature length, and remove the signature. > > Put this code in one place together with mod_check_sig. > > This changes the error from ENOENT to ENODATA for ima_read_modsig in the > case the signature marker is missing. > > This also changes the buffer length in ima_read_modsig from size_t to > unsigned long. This reduces the possible value range on 32bit but the > length refers to kernel in-memory buffer which cannot be longer than > ULONG_MAX. > > Also change mod_check_sig to unsigned long while at it. > > Signed-off-by: Michal Suchanek Reviewed-by: Luis Chamberlain Luis
Re: [PATCH v5 5/6] module: Use key_being_used_for for log messages in verify_appended_signature
On Tue, Jan 11, 2022 at 12:37:47PM +0100, Michal Suchanek wrote: > Add value for kexec appended signature and pass in key_being_used_for > enum rather than a string to verify_appended_signature to produce log > messages about the signature. > > Signed-off-by: Michal Suchanek Acked-by: Luis Chamberlain Luis
Re: [PATCH v5 4/6] module: strip the signature marker in the verification function.
On Tue, Jan 11, 2022 at 12:37:46PM +0100, Michal Suchanek wrote: > It is stripped by each caller separately. > > Note: this changes the error for kexec_file from EKEYREJECTED to ENODATA > when the signature marker is missing. > > Signed-off-by: Michal Suchanek > --- > v3: - Philipp Rudo : Update the commit with note about > change of raturn value > - the module_signature.h is now no longer needed for kexec_file Reviewed-by: Luis Chamberlain Luis
Re: [PATCH v5 3/6] kexec_file: Don't opencode appended signature verification.
On Tue, Jan 11, 2022 at 12:37:45PM +0100, Michal Suchanek wrote:
> diff --git a/include/linux/verification.h b/include/linux/verification.h
> index a655923335ae..32db9287a7b0 100644
> --- a/include/linux/verification.h
> +++ b/include/linux/verification.h
> @@ -60,5 +60,8 @@ extern int verify_pefile_signature(const void *pebuf,
> unsigned pelen,
> enum key_being_used_for usage);
> #endif
>
> +int verify_appended_signature(const void *data, unsigned long *len,
> + struct key *trusted_keys, const char *what);
> +
Looks very non-module specific.
> diff --git a/kernel/module_signing.c b/kernel/module_signing.c
> index 8723ae70ea1f..30149969f21f 100644
> --- a/kernel/module_signing.c
> +++ b/kernel/module_signing.c
> @@ -14,32 +14,38 @@
> #include
> #include "module-internal.h"
>
> -/*
> - * Verify the signature on a module.
> +/**
> + * verify_appended_signature - Verify the signature on a module with the
> + * signature marker stripped.
> + * @data: The data to be verified
> + * @len: Size of @data.
> + * @trusted_keys: Keyring to use for verification
> + * @what: Informational string for log messages
> */
> -int mod_verify_sig(const void *mod, struct load_info *info)
> +int verify_appended_signature(const void *data, unsigned long *len,
> + struct key *trusted_keys, const char *what)
> {
> - struct module_signature ms;
> - size_t sig_len, modlen = info->len;
> + struct module_signature *ms;
There goes the abstraction, so why not make this clear where we re-use
the struct module_signature for various things and call it as it is,
verify_mod_appended_signature() or some such?
David? Any preference?
Other than that:
Reviewed-by: Luis Chamberlain
Luis
Re: [PATCH v4 1/6] s390/kexec_file: Don't opencode appended signature check.
On Mon, Jan 10, 2022 at 02:49:53PM +0100, Michal Suchanek wrote: > Module verification already implements appeded signature check. > > Reuse it for kexec_file. > > The kexec_file implementation uses EKEYREJECTED error in some cases when > there is no key and the common implementation uses ENOPKG or EBADMSG > instead. > > Signed-off-by: Michal Suchanek > Acked-by: Heiko Carstens > --- > v3: Philipp Rudo : Update the commit with note about > change of return value > --- > arch/s390/kernel/machine_kexec_file.c | 22 +- > 1 file changed, 5 insertions(+), 17 deletions(-) > > diff --git a/arch/s390/kernel/machine_kexec_file.c > b/arch/s390/kernel/machine_kexec_file.c > index 8f43575a4dd3..c944d71316c7 100644 > --- a/arch/s390/kernel/machine_kexec_file.c > +++ b/arch/s390/kernel/machine_kexec_file.c > @@ -31,6 +31,7 @@ int s390_verify_sig(const char *kernel, unsigned long > kernel_len) > const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1; > struct module_signature *ms; > unsigned long sig_len; > + int ret; > > /* Skip signature verification when not secure IPLed. */ > if (!ipl_secure_flag) > @@ -45,25 +46,12 @@ int s390_verify_sig(const char *kernel, unsigned long > kernel_len) > kernel_len -= marker_len; > > ms = (void *)kernel + kernel_len - sizeof(*ms); > - kernel_len -= sizeof(*ms); > + ret = mod_check_sig(ms, kernel_len, "kexec"); > + if (ret) > + return ret; > > sig_len = be32_to_cpu(ms->sig_len); > - if (sig_len >= kernel_len) > - return -EKEYREJECTED; There is a small minor fix here, where by using mod_check_sig() now decreased the kernel_len by the sizeof(*ms). It is minor though. > - kernel_len -= sig_len; > - > - if (ms->id_type != PKEY_ID_PKCS7) > - return -EKEYREJECTED; More importantly is the return value used here changes but given the Ack by Heiko I suspect this if fine and does not break old userspace, the only change here is the possible error value returned by the kexec_file_load() system call. Reviewed-by: Luis Chamberlain Luis
Re: [PATCH 00/16] Remove usage of the deprecated "pci-dma-compat.h" API
On Thu, Jan 06, 2022 at 10:45:13PM +0100, Christophe JAILLET wrote: > This serie axes all the remaining usages of the deprecated "pci-dma-compat.h" > API. > > All these patches have already been posted. > > They have been generated with a coccinelle script. > The tricky parts are patches that use dma_alloc_coherent() because the correct > GFP flag has to be used in place of the previous embedded GFP_ATOMIC. > > Patches 1-3 are already Reviewed. References to the corresponding mail is > given below the --- > > Patch 1-2,4-10 are just generated from the coccinelle script. Only too long > lines have been hand modified. dma_alloc_coherent() modification are NOT part > of these patches. > > Patch 3 also includes some 'dma_set_mask_and_coherent()' instead of > 'pci_set_dma_mask()/pci_set_consistent_dma_mask()'. > I've left this additional modification because it was reviewed with it. > > Patch 10-15 are the tricky parts. Explanation of which GFP flag is the right > one > is given in each patch. It has been divided in several patches to ease review. > > Patch 15 is the only one I'm slighly unsure with. The old code was using a > GFP_USER flag in the function. I'm not familiar with it. > I *guess* that GFP_KERNEL is fine, but maybe it should also be GFP_USER or > left > as GFP_ATOMIC so that nothing is changed. > > Patch 16 is the last step that remove "pci-dma-compat.h" and its only usage. > > > All patches, exept 1-2,6 that are architecture specific, have been compile > tested. > > > After all that, a few rst files, 1 or 2 strings in error messages and some > error branching labels should still need some attention. > This is some minor issues. > > > Only the cover letter is sent to every one. Each patch is sent to the > corresponding maintainer(s) + Andrew Morton, Christoph Hellwig and Arnd > Bergmann. > > > Best regards. > > > Christophe JAILLET (16): > alpha: Remove usage of the deprecated "pci-dma-compat.h" API > floppy: Remove usage of the deprecated "pci-dma-compat.h" API > fpga: dfl: pci: Remove usage of the deprecated "pci-dma-compat.h" API > media: Remove usage of the deprecated "pci-dma-compat.h" API > agp/intel: Remove usage of the deprecated "pci-dma-compat.h" API > sparc: Remove usage of the deprecated "pci-dma-compat.h" API > dmaengine: pch_dma: Remove usage of the deprecated "pci-dma-compat.h" > API > rapidio/tsi721: Remove usage of the deprecated "pci-dma-compat.h" API > media: v4l2-pci-skeleton: Remove usage of the deprecated > "pci-dma-compat.h" API > scsi: message: fusion: Remove usage of the deprecated > "pci-dma-compat.h" API > scsi: mptbase: Use dma_alloc_coherent() in 'mpt_alloc_fw_memory()' > scsi: mptbase: Use dma_alloc_coherent() > scsi: mptsas: Use dma_alloc_coherent() in > mptsas_exp_repmanufacture_info() > scsi: mptsas: Use dma_alloc_coherent() > scsi: mptctl: Use dma_alloc_coherent() > PCI: Remove usage of the deprecated "pci-dma-compat.h" API > > arch/alpha/include/asm/floppy.h | 7 +- > arch/alpha/kernel/pci_iommu.c | 12 +-- > arch/powerpc/include/asm/floppy.h | 8 +- > arch/sparc/kernel/ioport.c | 2 +- > drivers/char/agp/intel-gtt.c| 26 ++--- > drivers/dma/pch_dma.c | 2 +- > drivers/fpga/dfl-pci.c | 14 +-- > drivers/media/pci/cx18/cx18-queue.h | 6 +- > drivers/media/pci/ivtv/ivtv-queue.h | 25 +++-- > drivers/media/pci/ivtv/ivtv-udma.h | 8 +- > drivers/message/fusion/mptbase.c| 149 > drivers/message/fusion/mptctl.c | 82 +-- > drivers/message/fusion/mptlan.c | 90 + > drivers/message/fusion/mptsas.c | 94 +- > drivers/rapidio/devices/tsi721.c| 8 +- > include/linux/pci-dma-compat.h | 129 > include/linux/pci.h | 3 - > samples/v4l/v4l2-pci-skeleton.c | 2 +- > 18 files changed, 289 insertions(+), 378 deletions(-) > delete mode 100644 include/linux/pci-dma-compat.h > > -- > 2.32.0 > Applied [03/16] to linux-fpga for-next. Thanks, Moritz
Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
On 25 Jan 2022, at 8:21, Oscar Salvador wrote: > On Tue, Jan 25, 2022 at 02:19:46PM +0100, Oscar Salvador wrote: >> I know that this has been discussed previously, and the cover-letter already >> mentions it, but I think it would be great to have some sort of information >> about >> the problem in the commit message as well, so people do not have to go and >> find >> it somewhere else. > > Sorry, the commit already points it out, but I meant to elaborate some more. You got it right about the issue. And I will add more text in the commit message and function comments to clarify the situation. Thanks for your suggestions. -- Best Regards, Yan, Zi signature.asc Description: OpenPGP digital signature
[PATCH v3 4/4] KVM: PPC: Decrement module refcount if init_vm fails
We increment the reference count for KVM-HV/PR before the call to
kvmppc_core_init_vm. If that function fails we need to decrement the
refcount.
Also remove the check on kvm_ops->owner because try_module_get can
handle a NULL module.
Signed-off-by: Fabiano Rosas
Reviewed-by: Nicholas Piggin
---
arch/powerpc/kvm/powerpc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2ad0ccd202d5..a6d6d452243f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -431,6 +431,8 @@ int kvm_arch_check_processor_compat(void *opaque)
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
{
struct kvmppc_ops *kvm_ops = NULL;
+ int r;
+
/*
* if we have both HV and PR enabled, default is HV
*/
@@ -452,11 +454,14 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
} else
goto err_out;
- if (kvm_ops->owner && !try_module_get(kvm_ops->owner))
+ if (!try_module_get(kvm_ops->owner))
return -ENOENT;
kvm->arch.kvm_ops = kvm_ops;
- return kvmppc_core_init_vm(kvm);
+ r = kvmppc_core_init_vm(kvm);
+ if (r)
+ module_put(kvm_ops->owner);
+ return r;
err_out:
return -EINVAL;
}
--
2.34.1
[PATCH v3 3/4] KVM: PPC: Book3S HV: Free allocated memory if module init fails
The module's exit function is not called when the init fails, we need
to do cleanup before returning.
Signed-off-by: Fabiano Rosas
Reviewed-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_hv.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index b9aace212599..87a49651a402 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -6104,7 +6104,7 @@ static int kvmppc_book3s_init_hv(void)
if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
r = kvm_init_subcore_bitmap();
if (r)
- return r;
+ goto err;
}
/*
@@ -6120,7 +6120,8 @@ static int kvmppc_book3s_init_hv(void)
np = of_find_compatible_node(NULL, NULL, "ibm,opal-intc");
if (!np) {
pr_err("KVM-HV: Cannot determine method for accessing
XICS\n");
- return -ENODEV;
+ r = -ENODEV;
+ goto err;
}
/* presence of intc confirmed - node can be dropped again */
of_node_put(np);
@@ -6133,12 +6134,12 @@ static int kvmppc_book3s_init_hv(void)
r = kvmppc_mmu_hv_init();
if (r)
- return r;
+ goto err;
if (kvmppc_radix_possible()) {
r = kvmppc_radix_init();
if (r)
- return r;
+ goto err;
}
r = kvmppc_uvmem_init();
@@ -6151,6 +6152,12 @@ static int kvmppc_book3s_init_hv(void)
kvmppc_hv_ops = _ops_hv;
return 0;
+
+err:
+ kvmhv_nested_exit();
+ kvmppc_radix_exit();
+
+ return r;
}
static void kvmppc_book3s_exit_hv(void)
--
2.34.1
[PATCH v3 2/4] KVM: PPC: Book3S HV: Delay setting of kvm ops
Delay the setting of kvm_hv_ops until after all init code has
completed. This avoids leaving the ops still accessible if the init
fails.
Signed-off-by: Fabiano Rosas
---
arch/powerpc/kvm/book3s_hv.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 3a3845f366d4..b9aace212599 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -6127,9 +6127,6 @@ static int kvmppc_book3s_init_hv(void)
}
#endif
- kvm_ops_hv.owner = THIS_MODULE;
- kvmppc_hv_ops = _ops_hv;
-
init_default_hcalls();
init_vcore_lists();
@@ -6145,10 +6142,15 @@ static int kvmppc_book3s_init_hv(void)
}
r = kvmppc_uvmem_init();
- if (r < 0)
+ if (r < 0) {
pr_err("KVM-HV: kvmppc_uvmem_init failed %d\n", r);
+ return r;
+ }
- return r;
+ kvm_ops_hv.owner = THIS_MODULE;
+ kvmppc_hv_ops = _ops_hv;
+
+ return 0;
}
static void kvmppc_book3s_exit_hv(void)
--
2.34.1
[PATCH v3 1/4] KVM: PPC: Book3S HV: Check return value of kvmppc_radix_init
The return of the function is being shadowed by the call to
kvmppc_uvmem_init.
Fixes: ca9f4942670c ("KVM: PPC: Book3S HV: Support for running secure guests")
Signed-off-by: Fabiano Rosas
Reviewed-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_hv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index d1817cd9a691..3a3845f366d4 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -6138,8 +6138,11 @@ static int kvmppc_book3s_init_hv(void)
if (r)
return r;
- if (kvmppc_radix_possible())
+ if (kvmppc_radix_possible()) {
r = kvmppc_radix_init();
+ if (r)
+ return r;
+ }
r = kvmppc_uvmem_init();
if (r < 0)
--
2.34.1
[PATCH v3 0/4] KVM: PPC: KVM module exit fixes
changes from v2: - patch 4: Matched module_put() to try_module_get() v2: https://lore.kernel.org/r/20220124220803.1011673-1-faro...@linux.ibm.com v1: https://lore.kernel.org/r/20211223211931.3560887-1-faro...@linux.ibm.com Fabiano Rosas (4): KVM: PPC: Book3S HV: Check return value of kvmppc_radix_init KVM: PPC: Book3S HV: Delay setting of kvm ops KVM: PPC: Book3S HV: Free allocated memory if module init fails KVM: PPC: Decrement module refcount if init_vm fails arch/powerpc/kvm/book3s_hv.c | 28 arch/powerpc/kvm/powerpc.c | 9 +++-- 2 files changed, 27 insertions(+), 10 deletions(-) -- 2.34.1
Re: [PATCH v2 4/4] KVM: PPC: Decrement module refcount if init_vm fails
Nicholas Piggin writes: > Excerpts from Fabiano Rosas's message of January 25, 2022 8:08 am: >> We increment the reference count for KVM-HV/PR before the call to >> kvmppc_core_init_vm. If that function fails we need to decrement the >> refcount. >> >> Signed-off-by: Fabiano Rosas >> --- >> Caught this while testing Nick's LPID patches by looking at >> /sys/module/kvm_hv/refcnt > > Nice catch. Is this the only change in the series? Yes. > You can just use kvm_ops->owner like try_module_get() does I think? Also > try_module_get works on a NULL module same as module_put by the looks, > so you could adjust that in this patch to remove the NULL check so it > is consistent with the put. Sure, I'll send a v3.
[linux-next] 5.17.0-rc1-next-20220124 kernel fails to boot on my powerpc box
Greeting's Today's next kernel 5.17.0-rc1-next-20220124(first bad) fails to boot on my powerpc box. I see it booted fine last Friday for kernel 5.16.0-next-20220121 Boot logs: Removing IBM Power 842 compression device device-mapper: multipath: 253:0: Failing path 8:0. scsi 0:0:0:0: alua: Detached scsi 0:0:1:0: alua: Detached kexec_core: Starting new kernel kexec: waiting for cpu 16 (physical 16) to enter 1 state kexec: waiting for cpu 17 (physical 17) to enter 1 state kexec: waiting for cpu 1 (physical 1) to enter 2 state kexec: waiting for cpu 3 (physical 3) to enter 2 state kexec: waiting for cpu 8 (physical 8) to enter 2 state kexec: waiting for cpu 9 (physical 9) to enter 2 state kexec: waiting for cpu 10 (physical 10) to enter 2 state kexec: waiting for cpu 11 (physical 11) to enter 2 state kexec: waiting for cpu 13 (physical 13) to enter 2 state kexec: waiting for cpu 16 (physical 16) to enter 2 state kexec: waiting for cpu 17 (physical 17) to enter 2 state kexec: Starting switchover sequence. y Reserving 1024MB of memory at 128MB for crashkernel (System RAM: 30720MB) hash-mmu: Page sizes from device-tree: hash-mmu: base_shift=12: shift=12, sllp=0x, avpnm=0x, tlbiel=1, penc=0 hash-mmu: base_shift=12: shift=16, sllp=0x, avpnm=0x, tlbiel=1, penc=7 hash-mmu: base_shift=12: shift=24, sllp=0x, avpnm=0x, tlbiel=1, penc=56 hash-mmu: base_shift=16: shift=16, sllp=0x0110, avpnm=0x, tlbiel=1, penc=1 hash-mmu: base_shift=16: shift=24, sllp=0x0110, avpnm=0x, tlbiel=1, penc=8 hash-mmu: base_shift=24: shift=24, sllp=0x0100, avpnm=0x0001, tlbiel=0, penc=0 hash-mmu: base_shift=34: shift=34, sllp=0x0120, avpnm=0x07ff, tlbiel=0, penc=3 Enabling pkeys with max key count 31 Activating Kernel Userspace Access Prevention Activating Kernel Userspace Execution Prevention Using 1TB segments hash-mmu: Initializing hash mmu with SLB Linux version 5.17.0-rc1-next-20220124-autotest (r...@ltc-zz3-lp1.aus.stglabs.ibm.com) (gcc (GCC) 8.3.1 20190507 (Red Hat 8.3.1-4), GNU ld version 2.30-58.el8) #1 SMP Tue Jan 25 04:47:57 CST 2022 Found initrd at 0xc580:0xc7d2892c Using pSeries machine description printk: bootconsole [udbg0] enabled Partition configured for 24 cpus. CPU maps initialized for 8 threads per core numa: Partition configured for 32 NUMA nodes. - phys_mem_size = 0x78000 dcache_bsize = 0x80 icache_bsize = 0x80 cpu_features = 0x0001c07b8f5f9187 possible = 0x000ffbfbcf5fb187 always = 0x000380008181 cpu_user_features = 0xdc0065c2 0xeff0 mmu_features = 0x7c006e01 firmware_features = 0x009fc45bfc57 vmalloc start = 0xc008 IO start = 0xc00a vmemmap start = 0xc00c hash-mmu: ppc64_pft_size = 0x1c hash-mmu: htab_hash_mask = 0x1f - numa: NODE_DATA [mem 0x77ff1ef00-0x77ff23fff] rfi-flush: fallback displacement flush available rfi-flush: mttrig type flush available count-cache-flush: flush disabled. link-stack-flush: software flush enabled. stf-barrier: eieio barrier available lpar: H_BLOCK_REMOVE supports base psize:0 psize:0 block size:8 lpar: H_BLOCK_REMOVE supports base psize:0 psize:2 block size:8 lpar: H_BLOCK_REMOVE supports base psize:0 psize:10 block size:8 lpar: H_BLOCK_REMOVE supports base psize:2 psize:2 block size:8 lpar: H_BLOCK_REMOVE supports base psize:2 psize:10 block size:8 PPC64 nvram contains 15360 bytes PV qspinlock hash table entries: 4096 (order: 0, 65536 bytes, linear) barrier-nospec: using ORI speculation barrier Zone ranges: Normal [mem 0x-0x00077fff] Movable zone start for each node Early memory node ranges node 0: [mem 0x-0x00077fff] Initmem setup node 0 [mem 0x-0x00077fff] percpu: Embedded 10 pages/cpu s590744 r0 d64616 u1048576 Fallback order for Node 0: 0 Built 1 zonelists, mobility grouping on. Total pages: 491040 Policy zone: Normal Kernel command line: BOOT_IMAGE=/vmlinuz-5.16.0-rc5-next-20211220-autotest root=UUID=8b32580a-0de0-4694-882d-7db2567ad115 ro crashkernel=1024M biosdevname=0 ibmvfc.mq=0 Unknown kernel command line parameters "BOOT_IMAGE=/vmlinuz-5.16.0-rc5-next-20211220-autotest biosdevname=0", will be passed to user space. Dentry cache hash table entries: 4194304 (order: 9, 33554432 bytes, linear) Inode-cache hash table entries: 2097152 (order: 8, 16777216 bytes, linear) mem auto-init: stack:off, heap alloc:off, heap free:off Memory: 30158976K/31457280K available (12992K kernel code, 5696K rwdata, 4160K rodata, 3904K init, 2588K bss, 1298304K reserved, 0K cma-reserved) SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=24, Nodes=32 trace event string verifier disabled rcu: Hierarchical RCU implementation. rcu: RCU event tracing is enabled. rcu: RCU restricting CPUs from
Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests
On Tue, 25 Jan 2022 09:30:51 +0530 Sachin Sant wrote: > Tested-by: Sachin Sant Thanks, I'll start running it through my tests and send it to Linus later today or tomorrow. -- Steve
Re: Build regressions/improvements in v5.17-rc1
On Mon, Jan 24, 2022 at 08:55:40AM +0100, Geert Uytterhoeven wrote: > > + /kisskb/src/lib/test_printf.c: error: "PTR" redefined [-Werror]: => > > 247:0, 247 > > + /kisskb/src/sound/pci/ca0106/ca0106.h: error: "PTR" redefined [-Werror]: > > => 62, 62:0 > > mips-gcc8/mips-allmodconfig > mipsel/mips-allmodconfig fixing patch sent. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
[PATCH] macintosh: macio_asic: remove useless cast for driver.name
pci_driver name is const char pointer, so the cast it not necessary.
Signed-off-by: Corentin Labbe
---
drivers/macintosh/macio_asic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index c1fdf2896021..1943a007e2d5 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -756,7 +756,7 @@ MODULE_DEVICE_TABLE (pci, pci_ids);
/* pci driver glue; this is a "new style" PCI driver module */
static struct pci_driver macio_pci_driver = {
- .name = (char *) "macio",
+ .name = "macio",
.id_table = pci_ids,
.probe = macio_pci_probe,
--
2.34.1
Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
On Tue, Jan 25, 2022 at 02:19:46PM +0100, Oscar Salvador wrote: > I know that this has been discussed previously, and the cover-letter already > mentions it, but I think it would be great to have some sort of information > about > the problem in the commit message as well, so people do not have to go and > find > it somewhere else. Sorry, the commit already points it out, but I meant to elaborate some more. -- Oscar Salvador SUSE Labs
Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
On Mon, Jan 24, 2022 at 12:17:23PM -0500, Zi Yan wrote: > You are right. Sorry for the confusion. I think it should be > “Page isolation is done at least on max(MAX_ORDER_NR_PAEGS, > pageblock_nr_pages) granularity.” > > memory_hotplug uses PAGES_PER_SECTION. It is greater than that. Or just specify that the max(MAX_ORDER_NR_PAGES, pageblock_nr_pages) granurality only comes from alloc_contig_range at the moment. Other callers might want to work in other granularity (e.g: memory-hotplug) although ultimately the range has to be aligned to something. > > True is that start_isolate_page_range() expects the range to be pageblock > > aligned and works in pageblock_nr_pages chunks, but I do not think that is > > what you meant to say here. > > Actually, start_isolate_page_range() should expect max(MAX_ORDER_NR_PAEGS, > pageblock_nr_pages) alignment instead of pageblock alignment. It seems to > be an uncovered bug in the current code, since all callers uses at least > max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) alignment. > > The reason is that if start_isolate_page_range() is only pageblock aligned > and a caller wants to isolate one pageblock from a MAX_ORDER-1 > (2 pageblocks on x84_64 systems) free page, this will lead to MIGRATE_ISOLATE > accounting error. To avoid it, start_isolate_page_range() needs to isolate > the max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) aligned range. So, let me see if I get this straight: You are saying that, currently, alloc_contig_ranges() works on the biggest alignment otherwise we might have this scenario: [ MAX_ORDER-1 ] [pageblock#0][pageblock#1] We only want to isolate pageblock#1, so we pass a pageblock-aligned range to start_isolate_page_range(), but the page belonging to pageblock#1 spans pageblock#0 and pageblock#1 because it is a MAX_ORDER-1 page. So when we call set_migratetype_isolate()->set_pageblock_migratetype(), this will mark either pageblock#0 or pageblock#1 as isolated, but the whole page will be put in the MIGRATE_ISOLATE freelist by move_freepages_block()->move_freepages(). Meaning, we wil effectively have two pageblocks isolated, but only one marked as such? Did I get it right or did I miss something? I know that this has been discussed previously, and the cover-letter already mentions it, but I think it would be great to have some sort of information about the problem in the commit message as well, so people do not have to go and find it somewhere else. -- Oscar Salvador SUSE Labs
Re: [PATCH 2/2] powerpc/uprobes: Reject uprobe on a system call instruction
Nicholas Piggin writes:
> Per the ISA, a Trace interrupt is not generated for a system call
> [vectored] instruction. Reject uprobes on such instructions as we are
> not emulating a system call [vectored] instruction anymore.
This should really be patch 1, otherwise there's a single commit window
where we allow uprobes on sc but don't honour them.
> Signed-off-by: Naveen N. Rao
> [np: Switch to pr_info_ratelimited]
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 1 +
> arch/powerpc/kernel/uprobes.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h
> b/arch/powerpc/include/asm/ppc-opcode.h
> index 9675303b724e..8bbe16ce5173 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -411,6 +411,7 @@
> #define PPC_RAW_DCBFPS(a, b) (0x7cac | ___PPC_RA(a) |
> ___PPC_RB(b) | (4 << 21))
> #define PPC_RAW_DCBSTPS(a, b)(0x7cac | ___PPC_RA(a) |
> ___PPC_RB(b) | (6 << 21))
> #define PPC_RAW_SC() (0x4402)
> +#define PPC_RAW_SCV()(0x4401)
> #define PPC_RAW_SYNC() (0x7c0004ac)
> #define PPC_RAW_ISYNC() (0x4c00012c)
>
> diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
> index c6975467d9ff..3779fde804bd 100644
> --- a/arch/powerpc/kernel/uprobes.c
> +++ b/arch/powerpc/kernel/uprobes.c
> @@ -41,6 +41,12 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
> if (addr & 0x03)
> return -EINVAL;
>
> + if (ppc_inst_val(ppc_inst_read(auprobe->insn)) == PPC_RAW_SC() ||
> + ppc_inst_val(ppc_inst_read(auprobe->insn)) == PPC_RAW_SCV()) {
We should probably reject hypercall too?
There's also a lot of reserved fields in `sc`, so doing an exact match
like this risks missing instructions that are badly formed but the CPU
will happily execute as `sc`.
We'd obviously never expect to see those in compiler generated code, but
it'd still be safer to mask. We could probably just reject opcode 17
entirely.
And I guess for a subsequent patch, but we should be rejecting some
others here as well shouldn't we? Like rfid etc.
cheers
> + pr_info_ratelimited("Rejecting uprobe on system call
> instruction\n");
> + return -EINVAL;
> + }
> +
> if (cpu_has_feature(CPU_FTR_ARCH_31) &&
> ppc_inst_prefixed(ppc_inst_read(auprobe->insn)) &&
> (addr & 0x3f) == 60) {
> --
> 2.23.0
Re: [PATCH v2 0/5] fsl-asoc-card: Add optional dt property for setting mclk-id
On Mon, 17 Jan 2022 10:21:04 -0300, Ariel D'Alessandro wrote: > This is a follow up of patchset: > > [RFC patch 0/5] Support BCLK input clock in tlv320aic31xx > > Sound cards may allow using different main clock inputs. In the generic > fsl-asoc-card driver, these values are hardcoded for each specific card > configuration. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/5] dt-bindings: sound: Rename tlv320aic31xx-micbias as tlv320aic31xx commit: 85f856f790b5fd427cb31b3f62755713174da0aa [2/5] dt-bindings: tlv320aic31xx: Define PLL clock inputs commit: 6045ffd366283236f0de79c8a0e98ae766e9a8f9 [3/5] ASoC: bindings: fsl-asoc-card: Add mclk-id optional property commit: 55915f20ad9ae92015bf7b2c4ac854e5b720d63f [4/5] ASoC: fsl-asoc-card: Add optional dt property for setting mclk-id commit: e6ec5a3936ee0c01f46e1d09dc758bb762e06dd9 [5/5] ASoC: fsl-asoc-card: Remove BCLK default value for tlv320aic31xx card commit: d4c4e2861560ab1cbf540bbda5bcdf4c92b17110 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
