* [PATCH v4 0/2] powerpc/mce: Fix mce handler and add selftest
From: Ganesh Goudar @ 2020-10-09 6:40 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: msuchanek, Ganesh Goudar, keescook, npiggin, mahesh
This patch series fixes mce handling for pseries, Adds LKDTM test
for SLB multihit recovery and enables selftest for the same,
basically to test MCE handling on pseries/powernv machines running
in hash mmu mode.
v4:
* Use radix_enabled() to check if its in Hash or Radix mode.
* Use FW_FEATURE_LPAR instead of machine_is_pseries().
v3:
* Merging selftest changes with patch 2/2, Instead of having separate
patch.
* Minor improvements like adding enough comments, Makefile changes,
including header file and adding some prints.
v2:
* Remove in_nmi check before calling nmi_enter/exit,
as nesting is supported.
* Fix build errors and remove unused variables.
* Integrate error injection code into LKDTM.
* Add support to inject multihit in paca.
Ganesh Goudar (2):
powerpc/mce: remove nmi_enter/exit from real mode handler
lkdtm/powerpc: Add SLB multihit test
arch/powerpc/kernel/mce.c | 7 +-
drivers/misc/lkdtm/Makefile | 1 +
drivers/misc/lkdtm/core.c | 3 +
drivers/misc/lkdtm/lkdtm.h | 3 +
drivers/misc/lkdtm/powerpc.c | 156 ++++++++++++++++++++++++
tools/testing/selftests/lkdtm/tests.txt | 1 +
6 files changed, 167 insertions(+), 4 deletions(-)
create mode 100644 drivers/misc/lkdtm/powerpc.c
--
2.26.2
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc/mce: remove nmi_enter/exit from real mode handler
From: Ganesh @ 2020-10-09 6:33 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: msuchanek, keescook, npiggin, mahesh
In-Reply-To: <20201001175144.286189-2-ganeshgr@linux.ibm.com>
On 10/1/20 11:21 PM, Ganesh Goudar wrote:
> Use of nmi_enter/exit in real mode handler causes the kernel to panic
> and reboot on injecting slb mutihit on pseries machine running in hash
> mmu mode, As these calls try to accesses memory outside RMO region in
> real mode handler where translation is disabled.
>
> Add check to not to use these calls on pseries machine running in hash
> mmu mode.
>
> Fixes: 116ac378bb3f ("powerpc/64s: machine check interrupt update NMI accounting")
> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
> ---
> arch/powerpc/kernel/mce.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> index ada59f6c4298..3bf39dd5dd43 100644
> --- a/arch/powerpc/kernel/mce.c
> +++ b/arch/powerpc/kernel/mce.c
> @@ -591,12 +591,14 @@ EXPORT_SYMBOL_GPL(machine_check_print_event_info);
> long notrace machine_check_early(struct pt_regs *regs)
> {
> long handled = 0;
> - bool nested = in_nmi();
> + bool is_pseries_hpt_guest;
> u8 ftrace_enabled = this_cpu_get_ftrace_enabled();
>
> this_cpu_set_ftrace_enabled(0);
> -
> - if (!nested)
> + is_pseries_hpt_guest = machine_is(pseries) &&
> + mmu_has_feature(MMU_FTR_HPTE_TABLE);
> + /* Do not use nmi_enter/exit for pseries hpte guest */
> + if (!is_pseries_hpt_guest)
In an offline discussion mpe suggested to use radix_enabled() to check if it is
radix or hash, as MMU_FTR_HPTE_TABLE may be true on radix machines also and use
of FW_FEATURE_LPAR better than machine_is(pseries), sending v4 with these changes.
> nmi_enter();
>
> hv_nmi_check_nonrecoverable(regs);
> @@ -607,7 +609,7 @@ long notrace machine_check_early(struct pt_regs *regs)
> if (ppc_md.machine_check_early)
> handled = ppc_md.machine_check_early(regs);
>
> - if (!nested)
> + if (!is_pseries_hpt_guest)
> nmi_exit();
>
> this_cpu_set_ftrace_enabled(ftrace_enabled);
^ permalink raw reply
* Re: [PATCH] powerpc/papr_scm: Add PAPR command family to pass-through command-set
From: Michael Ellerman @ 2020-10-09 6:04 UTC (permalink / raw)
To: linux-nvdimm, linuxppc-dev, Vaibhav Jain; +Cc: Aneesh Kumar K . V
In-Reply-To: <20200913211904.24472-1-vaibhav@linux.ibm.com>
On Mon, 14 Sep 2020 02:49:04 +0530, Vaibhav Jain wrote:
> Add NVDIMM_FAMILY_PAPR to the list of valid 'dimm_family_mask'
> acceptable by papr_scm. This is needed as since commit
> 92fe2aa859f5 ("libnvdimm: Validate command family indices") libnvdimm
> performs a validation of 'nd_cmd_pkg.nd_family' received as part of
> ND_CMD_CALL processing to ensure only known command families can use
> the general ND_CMD_CALL pass-through functionality.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/papr_scm: Add PAPR command family to pass-through command-set
https://git.kernel.org/powerpc/c/13135b461cf205941308984bd3271ec7d403dc40
cheers
^ permalink raw reply
* Re: [PATCH] cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_reboot_notifier
From: Michael Ellerman @ 2020-10-09 6:04 UTC (permalink / raw)
To: Michael Ellerman, Srikar Dronamraju
Cc: linuxppc-dev, Pratik Rajesh Sampat, Daniel Axtens
In-Reply-To: <20200922080254.41497-1-srikar@linux.vnet.ibm.com>
On Tue, 22 Sep 2020 13:32:54 +0530, Srikar Dronamraju wrote:
> The patch avoids allocating cpufreq_policy on stack hence fixing frame
> size overflow in 'powernv_cpufreq_reboot_notifier'
>
> ./drivers/cpufreq/powernv-cpufreq.c: In function _powernv_cpufreq_reboot_notifier_:
> ./drivers/cpufreq/powernv-cpufreq.c:906:1: error: the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> }
> ^
> cc1: all warnings being treated as errors
> make[3]: *** [./scripts/Makefile.build:316: drivers/cpufreq/powernv-cpufreq.o] Error 1
> make[2]: *** [./scripts/Makefile.build:556: drivers/cpufreq] Error 2
> make[1]: *** [./Makefile:1072: drivers] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [Makefile:157: sub-make] Error 2
Applied to powerpc/next.
[1/1] cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_reboot_notifier
https://git.kernel.org/powerpc/c/a2d0230b91f7e23ceb5d8fb6a9799f30517ec33a
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/eeh: Delete eeh_pe->config_addr
From: Michael Ellerman @ 2020-10-09 6:04 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20201007040903.819081-1-oohall@gmail.com>
On Wed, 7 Oct 2020 15:09:02 +1100, Oliver O'Halloran wrote:
> The eeh_pe->config_addr field was supposed to be removed in
> commit 35d64734b643 ("powerpc/eeh: Clean up PE addressing") which made it
> largely unused. Finish the job.
Applied to powerpc/next.
[1/2] powerpc/eeh: Delete eeh_pe->config_addr
https://git.kernel.org/powerpc/c/269e583357df32d77368903214f10f43fa5d7a5f
[2/2] powerpc/pseries/eeh: Fix use of uninitialised variable
https://git.kernel.org/powerpc/c/8175bd580e629dcf9cc507794da774a6b8d3a9bd
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/security: Fix link stack flush instruction
From: Michael Ellerman @ 2020-10-09 6:04 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20201007080605.64423-1-npiggin@gmail.com>
On Wed, 7 Oct 2020 18:06:05 +1000, Nicholas Piggin wrote:
> The inline execution path for the hardware assisted branch flush
> instruction failed to set CTR to the correct value before bcctr,
> causing a crash when the feature is enabled.
Applied to powerpc/next.
[1/1] powerpc/security: Fix link stack flush instruction
https://git.kernel.org/powerpc/c/792254a77201453d9a77479e63dc216ad90462d2
cheers
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/hv-gpci: Fix starting index value
From: Michael Ellerman @ 2020-10-09 6:04 UTC (permalink / raw)
To: linuxppc-dev, Kajol Jain, mpe; +Cc: suka, maddy
In-Reply-To: <20201003074943.338618-1-kjain@linux.ibm.com>
On Sat, 3 Oct 2020 13:19:39 +0530, Kajol Jain wrote:
> Commit 9e9f60108423f ("powerpc/perf/{hv-gpci, hv-common}: generate
> requests with counters annotated") adds a framework for defining
> gpci counters.
> In this patch, they adds starting_index value as '0xffffffffffffffff'.
> which is wrong as starting_index is of size 32 bits.
>
> Because of this, incase we try to run hv-gpci event we get error.
>
> [...]
Applied to powerpc/next.
[1/5] powerpc/perf/hv-gpci: Fix starting index value
https://git.kernel.org/powerpc/c/0f9866f7e85765bbda86666df56c92f377c3bc10
[2/5] Documentation/ABI: Add ABI documentation for hv-24x7 format
https://git.kernel.org/powerpc/c/264a034099b6e3c76fae85e75329373f3652a033
[3/5] Documentation/ABI: Add ABI documentation for hv-gpci format
https://git.kernel.org/powerpc/c/435387dd1f6fc03c64e3fdb4cc8737904c08a4db
[4/5] powerpc/perf/hv-gpci: Add cpu hotplug support
https://git.kernel.org/powerpc/c/dcb5cdf60a1fbbdb3b4dd2abc562206481f09ef1
[5/5] powerpc/hv-gpci: Add sysfs files inside hv-gpci device to show cpumask
https://git.kernel.org/powerpc/c/09b791d95559ef82542063333ecaa2ac9d57118e
cheers
^ permalink raw reply
* Re: [PATCH v3 1/8] powerpc: Remove SYNC on non 6xx
From: Michael Ellerman @ 2020-10-09 6:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <27951fa6c9a8f80724d1bc81a6117ac32343a55d.1601362098.git.christophe.leroy@csgroup.eu>
On Tue, 29 Sep 2020 06:48:31 +0000 (UTC), Christophe Leroy wrote:
> SYNC is usefull for Powerpc 601 only. On everything else,
> SYNC is empty.
>
> Remove it from code that is not made to run on 6xx.
Applied to powerpc/next.
[1/8] powerpc: Remove SYNC on non 6xx
https://git.kernel.org/powerpc/c/ca1d3443b4dd1e8f152bd6c881ddb3eb2996179a
[2/8] powerpc: Remove CONFIG_PPC601_SYNC_FIX
https://git.kernel.org/powerpc/c/e42a64002a507bf61e57106ed5323b1854371563
[3/8] powerpc: Drop SYNC_601() ISYNC_601() and SYNC()
https://git.kernel.org/powerpc/c/d2a5cd83ee984c0e9fc172d2df9591c264261a52
[4/8] powerpc: Remove PowerPC 601
https://git.kernel.org/powerpc/c/f0ed73f3fa2cdca65973659689ec9e46d99a5f60
[5/8] powerpc: Remove support for PowerPC 601
https://git.kernel.org/powerpc/c/8b14e1dff067195dca7a42321771437cb33a99e9
[6/8] powerpc: Tidy up a bit after removal of PowerPC 601.
https://git.kernel.org/powerpc/c/2e38ea486615bddbc7a42d002aee93a3a9e7a36f
[7/8] powerpc: Remove __USE_RTC()
https://git.kernel.org/powerpc/c/a4c5a355422920bcbfe3fd1f01aead2d3a2a820c
[8/8] powerpc: Remove get_tb_or_rtc()
https://git.kernel.org/powerpc/c/6601ec1c2ba929430f5585ce7f9d9960b0e0a01d
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/time: Remove ifdef in get_dec() and set_dec()
From: Michael Ellerman @ 2020-10-09 6:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <3c9a6eb0fc040868ac59be66f338d08fd017668d.1601549945.git.christophe.leroy@csgroup.eu>
On Thu, 1 Oct 2020 10:59:19 +0000 (UTC), Christophe Leroy wrote:
> Move SPRN_PIT definition in reg.h.
>
> This allows to remove ifdef in get_dec() and set_dec() and
> makes them more readable.
Applied to powerpc/next.
[1/1] powerpc/time: Remove ifdef in get_dec() and set_dec()
https://git.kernel.org/powerpc/c/63f9d9df5ed0d4f3a2c0cd08730e1cae1edd11bf
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
From: Michael Ellerman @ 2020-10-09 6:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <b8f8101c368b8a6451844a58d7bd7d83c14cf2aa.1601566529.git.christophe.leroy@csgroup.eu>
On Thu, 1 Oct 2020 15:35:38 +0000 (UTC), Christophe Leroy wrote:
> At the time being, an early hash table is set up when
> CONFIG_KASAN is selected.
>
> There is nothing wrong with setting such an early hash table
> all the time, even if it is not used. This is a statically
> allocated 256 kB table which lies in the init data section.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32s: Setup the early hash table at all time.
https://git.kernel.org/powerpc/c/69a1593abdbcf03a76367320d929a8ae7a5e3d71
cheers
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/time: Rename mftbl() to mftb()
From: Michael Ellerman @ 2020-10-09 6:03 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Michael Ellerman,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <94dc68d3d9ef9eb549796d4b938b6ba0305a049b.1601556145.git.christophe.leroy@csgroup.eu>
On Thu, 1 Oct 2020 12:42:39 +0000 (UTC), Christophe Leroy wrote:
> On PPC64, we have mftb().
> On PPC32, we have mftbl() and an #define mftb() mftbl().
>
> mftb() and mftbl() are equivalent, their purpose is to read the
> content of SPRN_TRBL, as returned by 'mftb' simplified instruction.
>
> binutils seems to define 'mftbl' instruction as an equivalent
> of 'mftb'.
>
> [...]
Applied to powerpc/next.
[1/6] powerpc/time: Rename mftbl() to mftb()
https://git.kernel.org/powerpc/c/15c102153e722cc6e0729764a7068c209a7469cd
[2/6] powerpc/time: Make mftb() common to PPC32 and PPC64
https://git.kernel.org/powerpc/c/ff125fbcd45d1706861579dbe66e31f5b3f1e779
[3/6] powerpc/time: Avoid using get_tbl() and get_tbu() internally
https://git.kernel.org/powerpc/c/942e89115b588b4b5df86930b5302a5c07b820ba
[4/6] powerpc/time: Remove get_tbu()
https://git.kernel.org/powerpc/c/e8d5bf30eafc37e31ce68bc7ccf1db970fe3cd04
[5/6] powerpc/time: Make get_tbl() common to PPC32 and PPC64
https://git.kernel.org/powerpc/c/1156a6285cd38e5a6987ddee3758e7954c56cb3d
[6/6] powerpc/time: Make get_tb() common to PPC32 and PPC64
https://git.kernel.org/powerpc/c/9686e431c683ee7b8aca0f3985c244aee3d9f30d
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/32s: Rename head_32.S to head_book3s_32.S
From: Michael Ellerman @ 2020-10-09 6:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <319d379f696412681c66a987cc75e6abf8f958d2.1601975100.git.christophe.leroy@csgroup.eu>
On Tue, 6 Oct 2020 09:05:26 +0000 (UTC), Christophe Leroy wrote:
> Unlike PPC64 which had a single head_64.S, PPC32 are multiple ones.
> There is the head_32.S, selected by default based on the value of BITS
> and overridden based on some CONFIG_ values. This leads to thinking
> that it may be selected by different types of PPC32 platform but
> indeed it ends up being selected by book3s/32 only.
>
> Make that explicit by:
> - Not doing any default selection based on BITS.
> - Renaming head_32.S to head_book3s_32.S.
> - Get head_book3s_32.S selected only by CONFIG_PPC_BOOK3S_32.
Applied to powerpc/next.
[1/2] powerpc/32s: Rename head_32.S to head_book3s_32.S
https://git.kernel.org/powerpc/c/533090e5a980ad80bbe0961b4ed45a9bcf55cc0c
[2/2] powerpc/32s: Remove #ifdef CONFIG_PPC_BOOK3S_32 in head_book3s_32.S
https://git.kernel.org/powerpc/c/865418795a1dea1c2b58a5fd7b6bdcb93e0c36b8
cheers
^ permalink raw reply
* Re: [PATCH v3 0/4] Enable usage of larger LMB ( > 4G)
From: Michael Ellerman @ 2020-10-09 6:03 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe; +Cc: nathanl
In-Reply-To: <20201007114836.282468-1-aneesh.kumar@linux.ibm.com>
On Wed, 7 Oct 2020 17:18:32 +0530, Aneesh Kumar K.V wrote:
> Changes from v2:
> * Don't use root addr and size cells during runtime. Walk up the
> device tree and use the first addr and size cells value (of_n_addr_cells()/
> of_n_size_cells())
>
> Aneesh Kumar K.V (4):
> powerpc/drmem: Make lmb_size 64 bit
> powerpc/memhotplug: Make lmb size 64bit
> powerpc/book3s64/radix: Make radix_mem_block_size 64bit
> powerpc/lmb-size: Use addr #size-cells value when fetching lmb-size
>
> [...]
Applied to powerpc/next.
[1/4] powerpc/drmem: Make lmb_size 64 bit
https://git.kernel.org/powerpc/c/ec72024e35dddb88a81e40071c87ceb18b5ee835
[2/4] powerpc/memhotplug: Make lmb size 64bit
https://git.kernel.org/powerpc/c/301d2ea6572386245c5d2d2dc85c3b5a737b85ac
[3/4] powerpc/book3s64/radix: Make radix_mem_block_size 64bit
https://git.kernel.org/powerpc/c/950805f4d90eda14325ceab56b0f00d034baa8bc
[4/4] powerpc/lmb-size: Use addr #size-cells value when fetching lmb-size
https://git.kernel.org/powerpc/c/fbf2f134c8c312d3166534a8bd6a1aaee6e9c7ef
cheers
^ permalink raw reply
* [PATCH] powerpc/8xx: Fix instruction TLB miss exception with perf enabled
From: Christophe Leroy @ 2020-10-09 5:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
When perf is enabled, r11 must also be restored when CONFIG_HUGETLBFS
is selected.
Fixes: a891c43b97d3 ("powerpc/8xx: Prepare handlers for _PAGE_HUGE for 512k pages.")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/head_8xx.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 9f359d3fba74..32d85387bdc5 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -268,7 +268,7 @@ InstructionTLBMiss:
addi r10, r10, 1
stw r10, (itlb_miss_counter - PAGE_OFFSET)@l(0)
mfspr r10, SPRN_SPRG_SCRATCH0
-#if defined(ITLB_MISS_KERNEL) || defined(CONFIG_SWAP)
+#if defined(ITLB_MISS_KERNEL) || defined(CONFIG_SWAP) || defined(CONFIG_HUGETLBFS)
mfspr r11, SPRN_SPRG_SCRATCH1
#endif
rfi
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv/dump: Fix race while processing OPAL dump
From: Michael Ellerman @ 2020-10-09 5:06 UTC (permalink / raw)
To: Vasant Hegde, linuxppc-dev; +Cc: Vasant Hegde, Mahesh Salgaonkar
In-Reply-To: <20201007101742.40757-1-hegdevasant@linux.vnet.ibm.com>
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
> diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
> index 543c816fa99e..7e6eeedec32b 100644
> --- a/arch/powerpc/platforms/powernv/opal-dump.c
> +++ b/arch/powerpc/platforms/powernv/opal-dump.c
> @@ -346,21 +345,39 @@ static struct dump_obj *create_dump_obj(uint32_t id, size_t size,
> rc = kobject_add(&dump->kobj, NULL, "0x%x-0x%x", type, id);
> if (rc) {
> kobject_put(&dump->kobj);
> - return NULL;
> + return;
> }
>
> + /*
> + * As soon as the sysfs file for this dump is created/activated there is
> + * a chance the opal_errd daemon (or any userspace) might read and
> + * acknowledge the dump before kobject_uevent() is called. If that
> + * happens then there is a potential race between
> + * dump_ack_store->kobject_put() and kobject_uevent() which leads to a
> + * use-after-free of a kernfs object resulting in a kernel crash.
> + *
> + * To avoid that, we need to take a reference on behalf of the bin file,
> + * so that our reference remains valid while we call kobject_uevent().
> + * We then drop our reference before exiting the function, leaving the
> + * bin file to drop the last reference (if it hasn't already).
> + */
> +
> + /* Take a reference for the bin file */
> + kobject_get(&dump->kobj);
> rc = sysfs_create_bin_file(&dump->kobj, &dump->dump_attr);
> if (rc) {
> kobject_put(&dump->kobj);
> - return NULL;
> + /* Drop reference count taken for bin file */
> + kobject_put(&dump->kobj);
> + return;
> }
>
> pr_info("%s: New platform dump. ID = 0x%x Size %u\n",
> __func__, dump->id, dump->size);
>
> kobject_uevent(&dump->kobj, KOBJ_ADD);
> -
> - return dump;
> + /* Drop reference count taken for bin file */
> + kobject_put(&dump->kobj);
> }
I think this would be better if it was reworked along the lines of:
aea948bb80b4 ("powerpc/powernv/elog: Fix race while processing OPAL error log event.")
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/powernv/elog: Reduce elog message severity
From: Michael Ellerman @ 2020-10-09 5:04 UTC (permalink / raw)
To: Vasant Hegde, linuxppc-dev; +Cc: Vasant Hegde, Mahesh Salgaonkar
In-Reply-To: <20201007101756.40811-1-hegdevasant@linux.vnet.ibm.com>
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
> OPAL interrupts kernel whenever it has new error log. Kernel calls
> interrupt handler (elog_event()) to retrieve event. elog_event makes
> OPAL API call (opal_get_elog_size()) to retrieve elog info.
>
> In some case before kernel makes opal_get_elog_size() call, it gets interrupt
> again. So second time when elog_event() calls opal_get_elog_size API OPAL
> returns error.
Can you give more detail there? Do you have a stack trace?
We use IRQF_ONESHOT for elog_event(), which (I thought) meant it
shouldn't be called again until it has completed.
So I'm unclear how you're seeing the behaviour you describe.
cheers
> Its safe to ignore this error. Hence reduce the severity
> of log message.
>
> CC: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/opal-elog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
> index 62ef7ad995da..67f435bb1ec4 100644
> --- a/arch/powerpc/platforms/powernv/opal-elog.c
> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
> @@ -247,7 +247,7 @@ static irqreturn_t elog_event(int irq, void *data)
>
> rc = opal_get_elog_size(&id, &size, &type);
> if (rc != OPAL_SUCCESS) {
> - pr_err("ELOG: OPAL log info read failed\n");
> + pr_debug("ELOG: OPAL log info read failed\n");
> return IRQ_HANDLED;
> }
>
> --
> 2.26.2
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the powerpc tree
From: Michael Ellerman @ 2020-10-09 4:27 UTC (permalink / raw)
To: Stephen Rothwell, PowerPC
Cc: Linux Next Mailing List, Srikar Dronamraju,
Linux Kernel Mailing List
In-Reply-To: <20201009075816.0cb5a86f@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> In commit
>
> a2d0230b91f7 ("cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_reboot_notifier")
>
> Fixes tag
>
> Fixes: cf30af76 ("cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec")
Gah.
I've changed my scripts to make this a hard error when I'm applying
patches.
cheers
^ permalink raw reply
* Re: [PATCH 2/2] dt: Remove booting-without-of.rst
From: Michael Ellerman @ 2020-10-09 3:51 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: Thomas Bogendoerfer, Yoshinori Sato, Geert Uytterhoeven,
Jonathan Corbet, linux-sh, linuxppc-dev, x86, linux-doc,
linux-kernel, linux-mips, Rich Felker, Paul Mackerras,
H. Peter Anvin, Borislav Petkov, Thomas Gleixner,
Mauro Carvalho Chehab, Frank Rowand, Ingo Molnar
In-Reply-To: <20201008142420.2083861-2-robh@kernel.org>
Rob Herring <robh@kernel.org> writes:
> booting-without-of.rstt is an ancient document that first outlined
^
nit
> Flattened DeviceTree on PowerPC initially. The DT world has evolved a
> lot in the 15 years since and booting-without-of.rst is pretty stale.
> The name of the document itself is confusing if you don't understand the
> evolution from real 'OpenFirmware'. Most of what booting-without-of.rst
> contains is now in the DT specification (which evolved out of the
> ePAPR). The few things that weren't documented in the DT specification
> are now.
>
> All that remains is the boot entry details, so let's move these to arch
> specific documents. The exception is arm which already has the same
> details documented.
>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-mips@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/booting-without-of.rst | 1585 -----------------
> Documentation/devicetree/index.rst | 1 -
> Documentation/mips/booting.rst | 28 +
> Documentation/mips/index.rst | 1 +
> Documentation/powerpc/booting.rst | 110 ++
LGTM.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS a2d0230b91f7e23ceb5d8fb6a9799f30517ec33a
From: kernel test robot @ 2020-10-09 1:32 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: a2d0230b91f7e23ceb5d8fb6a9799f30517ec33a cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_reboot_notifier
elapsed time: 870m
configs tested: 215
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm colibri_pxa300_defconfig
m68k m5475evb_defconfig
mips fuloong2e_defconfig
arm exynos_defconfig
mips bigsur_defconfig
powerpc eiger_defconfig
mips rbtx49xx_defconfig
arm tegra_defconfig
powerpc icon_defconfig
powerpc mpc885_ads_defconfig
mips bmips_stb_defconfig
arm footbridge_defconfig
sh ap325rxa_defconfig
powerpc xes_mpc85xx_defconfig
m68k m5307c3_defconfig
arm mxs_defconfig
h8300 defconfig
nios2 defconfig
xtensa generic_kc705_defconfig
sh secureedge5410_defconfig
sh apsh4ad0a_defconfig
arm multi_v4t_defconfig
m68k sun3_defconfig
sh rsk7203_defconfig
sh kfr2r09-romimage_defconfig
c6x evmc6678_defconfig
powerpc ppc64e_defconfig
powerpc warp_defconfig
sh polaris_defconfig
arm sama5_defconfig
powerpc bamboo_defconfig
sh ecovec24_defconfig
m68k allmodconfig
arm ezx_defconfig
powerpc tqm8540_defconfig
arm imx_v6_v7_defconfig
arm pxa255-idp_defconfig
powerpc stx_gp3_defconfig
powerpc maple_defconfig
sh urquell_defconfig
powerpc mpc834x_itxgp_defconfig
powerpc ps3_defconfig
arm h3600_defconfig
powerpc mpc512x_defconfig
parisc allyesconfig
arm omap2plus_defconfig
m68k apollo_defconfig
powerpc g5_defconfig
mips ath25_defconfig
sh landisk_defconfig
mips decstation_defconfig
sparc defconfig
powerpc pseries_defconfig
arm netwinder_defconfig
arm ep93xx_defconfig
i386 alldefconfig
powerpc mpc834x_itx_defconfig
powerpc powernv_defconfig
powerpc mgcoge_defconfig
m68k mvme16x_defconfig
arc vdk_hs38_smp_defconfig
arc axs103_defconfig
powerpc storcenter_defconfig
sh dreamcast_defconfig
m68k m5275evb_defconfig
powerpc ppa8548_defconfig
openrisc or1ksim_defconfig
sh rsk7201_defconfig
riscv allnoconfig
arm pxa_defconfig
mips mtx1_defconfig
mips malta_defconfig
c6x allyesconfig
powerpc pmac32_defconfig
mips malta_kvm_defconfig
sh se7721_defconfig
arc haps_hs_smp_defconfig
sh r7780mp_defconfig
sh r7785rp_defconfig
um i386_defconfig
powerpc tqm8548_defconfig
sh se7712_defconfig
mips mpc30x_defconfig
powerpc kilauea_defconfig
powerpc makalu_defconfig
arm qcom_defconfig
arm rpc_defconfig
c6x alldefconfig
arm integrator_defconfig
sh sh7757lcr_defconfig
arm assabet_defconfig
sparc sparc32_defconfig
h8300 alldefconfig
arm viper_defconfig
powerpc ppc44x_defconfig
h8300 h8s-sim_defconfig
m68k m5249evb_defconfig
xtensa smp_lx200_defconfig
arm keystone_defconfig
arm cm_x300_defconfig
mips db1xxx_defconfig
powerpc ppc6xx_defconfig
riscv defconfig
powerpc ge_imp3a_defconfig
arm axm55xx_defconfig
powerpc ep88xc_defconfig
powerpc gamecube_defconfig
powerpc mpc832x_rdb_defconfig
arm aspeed_g5_defconfig
mips cu1000-neo_defconfig
sh se7619_defconfig
arm nhk8815_defconfig
i386 allyesconfig
arm bcm2835_defconfig
sh espt_defconfig
mips loongson3_defconfig
mips ip28_defconfig
arm shmobile_defconfig
powerpc arches_defconfig
powerpc ksi8560_defconfig
arm davinci_all_defconfig
powerpc allyesconfig
mips decstation_64_defconfig
powerpc kmeter1_defconfig
powerpc obs600_defconfig
mips capcella_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allyesconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 defconfig
sparc allyesconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20201008
x86_64 randconfig-a003-20201008
x86_64 randconfig-a005-20201008
x86_64 randconfig-a001-20201008
x86_64 randconfig-a002-20201008
x86_64 randconfig-a006-20201008
i386 randconfig-a006-20201008
i386 randconfig-a005-20201008
i386 randconfig-a001-20201008
i386 randconfig-a004-20201008
i386 randconfig-a002-20201008
i386 randconfig-a003-20201008
i386 randconfig-a006-20201009
i386 randconfig-a005-20201009
i386 randconfig-a001-20201009
i386 randconfig-a004-20201009
i386 randconfig-a002-20201009
i386 randconfig-a003-20201009
x86_64 randconfig-a012-20201009
x86_64 randconfig-a015-20201009
x86_64 randconfig-a013-20201009
x86_64 randconfig-a014-20201009
x86_64 randconfig-a011-20201009
x86_64 randconfig-a016-20201009
i386 randconfig-a015-20201009
i386 randconfig-a013-20201009
i386 randconfig-a014-20201009
i386 randconfig-a016-20201009
i386 randconfig-a011-20201009
i386 randconfig-a012-20201009
i386 randconfig-a015-20201008
i386 randconfig-a013-20201008
i386 randconfig-a014-20201008
i386 randconfig-a016-20201008
i386 randconfig-a011-20201008
i386 randconfig-a012-20201008
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20201009
x86_64 randconfig-a003-20201009
x86_64 randconfig-a005-20201009
x86_64 randconfig-a001-20201009
x86_64 randconfig-a002-20201009
x86_64 randconfig-a006-20201009
x86_64 randconfig-a012-20201008
x86_64 randconfig-a015-20201008
x86_64 randconfig-a013-20201008
x86_64 randconfig-a014-20201008
x86_64 randconfig-a011-20201008
x86_64 randconfig-a016-20201008
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 118be7377c97e35c33819bcb3bbbae5a42a4ac43
From: kernel test robot @ 2020-10-09 1:32 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 118be7377c97e35c33819bcb3bbbae5a42a4ac43 Automatic merge of 'next' into merge (2020-10-08 21:55)
elapsed time: 871m
configs tested: 176
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm colibri_pxa300_defconfig
m68k m5475evb_defconfig
mips fuloong2e_defconfig
arm exynos_defconfig
mips bigsur_defconfig
powerpc eiger_defconfig
mips rbtx49xx_defconfig
arm tegra_defconfig
powerpc icon_defconfig
powerpc mpc885_ads_defconfig
mips bmips_stb_defconfig
arm footbridge_defconfig
sh ap325rxa_defconfig
powerpc xes_mpc85xx_defconfig
m68k m5307c3_defconfig
arm mxs_defconfig
h8300 defconfig
xtensa generic_kc705_defconfig
sh secureedge5410_defconfig
sh apsh4ad0a_defconfig
arm multi_v4t_defconfig
m68k sun3_defconfig
sh rsk7203_defconfig
sh kfr2r09-romimage_defconfig
c6x evmc6678_defconfig
powerpc ppc64e_defconfig
powerpc warp_defconfig
m68k allmodconfig
arm ezx_defconfig
powerpc tqm8540_defconfig
powerpc maple_defconfig
sh urquell_defconfig
powerpc mpc834x_itxgp_defconfig
powerpc ps3_defconfig
arm h3600_defconfig
powerpc mpc512x_defconfig
parisc allyesconfig
arm omap2plus_defconfig
m68k apollo_defconfig
powerpc g5_defconfig
mips ath25_defconfig
sh landisk_defconfig
mips decstation_defconfig
sparc defconfig
powerpc pseries_defconfig
arm netwinder_defconfig
arm ep93xx_defconfig
i386 alldefconfig
powerpc mpc834x_itx_defconfig
powerpc powernv_defconfig
powerpc mgcoge_defconfig
arm pxa_defconfig
mips mtx1_defconfig
mips malta_defconfig
powerpc pmac32_defconfig
arc haps_hs_smp_defconfig
sh r7780mp_defconfig
sh r7785rp_defconfig
um i386_defconfig
powerpc tqm8548_defconfig
sh se7712_defconfig
mips mpc30x_defconfig
powerpc kilauea_defconfig
powerpc makalu_defconfig
arm qcom_defconfig
arm rpc_defconfig
c6x alldefconfig
arm integrator_defconfig
sh sh7757lcr_defconfig
arm assabet_defconfig
sparc sparc32_defconfig
h8300 alldefconfig
arm viper_defconfig
powerpc ppc44x_defconfig
h8300 h8s-sim_defconfig
m68k m5249evb_defconfig
xtensa smp_lx200_defconfig
arm keystone_defconfig
powerpc ppc6xx_defconfig
riscv defconfig
powerpc ge_imp3a_defconfig
arm axm55xx_defconfig
powerpc ep88xc_defconfig
powerpc gamecube_defconfig
arm bcm2835_defconfig
sh espt_defconfig
mips loongson3_defconfig
powerpc cm5200_defconfig
sh sh7770_generic_defconfig
arm spitz_defconfig
arm iop32x_defconfig
mips ip28_defconfig
arm shmobile_defconfig
powerpc arches_defconfig
powerpc ksi8560_defconfig
powerpc ppa8548_defconfig
powerpc obs600_defconfig
mips capcella_defconfig
powerpc kmeter1_defconfig
openrisc or1ksim_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20201008
x86_64 randconfig-a003-20201008
x86_64 randconfig-a005-20201008
x86_64 randconfig-a001-20201008
x86_64 randconfig-a002-20201008
x86_64 randconfig-a006-20201008
i386 randconfig-a006-20201008
i386 randconfig-a005-20201008
i386 randconfig-a001-20201008
i386 randconfig-a004-20201008
i386 randconfig-a002-20201008
i386 randconfig-a003-20201008
x86_64 randconfig-a012-20201009
x86_64 randconfig-a015-20201009
x86_64 randconfig-a013-20201009
x86_64 randconfig-a014-20201009
x86_64 randconfig-a011-20201009
x86_64 randconfig-a016-20201009
i386 randconfig-a015-20201008
i386 randconfig-a013-20201008
i386 randconfig-a014-20201008
i386 randconfig-a016-20201008
i386 randconfig-a011-20201008
i386 randconfig-a012-20201008
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a012-20201008
x86_64 randconfig-a015-20201008
x86_64 randconfig-a013-20201008
x86_64 randconfig-a014-20201008
x86_64 randconfig-a011-20201008
x86_64 randconfig-a016-20201008
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Linux kernel: powerpc: RTAS calls can be used to compromise kernel integrity
From: Andrew Donnellan @ 2020-10-09 1:20 UTC (permalink / raw)
To: oss-security, linuxppc-dev
The Linux kernel for powerpc has an issue with the Run-Time Abstraction
Services (RTAS) interface, allowing root (or CAP_SYS_ADMIN users) in a
VM to overwrite some parts of memory, including kernel memory.
This issue impacts guests running on top of PowerVM or KVM hypervisors
(pseries platform), and does *not* impact bare-metal machines (powernv
platform).
Description
===========
The RTAS interface, defined in the Power Architecture Platform
Reference, provides various platform hardware services to operating
systems running on PAPR platforms (e.g. the "pseries" platform in Linux,
running in a LPAR/VM on PowerVM or KVM).
Some userspace daemons require access to certain RTAS calls for system
maintenance and monitoring purposes.
The kernel exposes a syscall, sys_rtas, that allows root (or any user
with CAP_SYS_ADMIN) to make arbitrary RTAS calls. For the RTAS calls
which require a work area, it allocates a buffer (the "RMO buffer") and
exposes the physical address in /proc so that the userspace tool can
pass addresses within that buffer as an argument to the RTAS call.
The syscall doesn't check that the work area arguments to RTAS calls are
within the RMO buffer, which makes it trivial to read and write to any
guest physical address within the LPAR's Real Memory Area, including
overwriting the guest kernel's text.
At the time the RTAS syscall interface was first developed, it was
generally assumed that root had unlimited ability to modify system
state, so this would not have been considered an integrity violation.
However, with the advent of Secure Boot, Lockdown etc, root should not
be able to arbitrarily modify the kernel text or read arbitrary kernel data.
Therefore, while this issue impacts all kernels since the RTAS interface
was first implemented, we are only considering it a vulnerability for
upstream kernels from 5.3 onwards, which is when the Lockdown LSM was
merged. Lockdown was widely included in pre-5.3 distribution kernels, so
distribution vendors should consider whether they need to backport the
patch to their pre-5.3 distro trees.
(A CVE for this issue is pending; we requested one some time ago but it
has not yet been assigned.)
Fixes
=====
A patch is currently in powerpc-next[0] and is expected to be included
in mainline kernel 5.10. The patch has not yet been backported to
upstream stable trees.
The approach taken by the patch is to maintain the existing RTAS
interface, but restrict requests to the list of RTAS calls actually used
by the librtas userspace library, and restrict work area pointer
arguments to the region within the RMO buffer.
All RTAS-using applications that we are aware of are system
management/monitoring tools, maintained by IBM, that use the librtas
library. We don't anticipate there being any real world legitimate
applications that require an RTAS call that isn't in the librtas list,
however if such an application exists, the filtering can be disabled by
a Kconfig option specified during kernel build.
Credit
======
Thanks to Daniel Axtens (IBM) for initial discovery of this issue.
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next&id=bd59380c5ba4147dcbaad3e582b55ccfd120b764
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* linux-next: Fixes tag needs some work in the powerpc tree
From: Stephen Rothwell @ 2020-10-08 20:58 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Srikar Dronamraju,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
Hi all,
In commit
a2d0230b91f7 ("cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_reboot_notifier")
Fixes tag
Fixes: cf30af76 ("cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] mm: Fetch the dirty bit before we reset the pte
From: Aneesh Kumar K.V @ 2020-10-08 17:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michal Hocko, Jan Kara, Linux-MM, Hugh Dickins,
Linux Kernel Mailing List, Peter Xu, Jason Gunthorpe, Nick Piggin,
John Hubbard, Kirill Shutemov, Andrew Morton, linuxppc-dev
In-Reply-To: <CAHk-=whwY0WT046fqM-zdHu9vamUjgkvmd36gCd4qSaeYy98nA@mail.gmail.com>
On 10/8/20 10:32 PM, Linus Torvalds wrote:
> On Thu, Oct 8, 2020 at 2:27 AM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> In copy_present_page, after we mark the pte non-writable, we should
>> check for previous dirty bit updates and make sure we don't lose the dirty
>> bit on reset.
>
> No, we'll just remove that entirely.
>
> Do you have a test-case that shows a problem? I have a patch that I
> was going to delay until 5.10 because I didn't think it mattered in
> practice..
>
Unfortunately, I don't have a test case. That was observed by code
inspection while I was fixing syzkaller report.
> The second part of this patch would be to add a sequence count
> protection to fast-GUP pinning, so that GUP and fork() couldn't race,
> but I haven't written that part.
>
> Here's the first patch anyway. If you actually have a test-case where
> this matters, I guess I need to apply it now..
>
> Linus
>
-aneesh
^ permalink raw reply
* Re: [RFC PATCH] mm: Fetch the dirty bit before we reset the pte
From: Linus Torvalds @ 2020-10-08 17:30 UTC (permalink / raw)
To: Aneesh Kumar K.V, Leon Romanovsky
Cc: Michal Hocko, Jan Kara, Linux-MM, Hugh Dickins,
Linux Kernel Mailing List, Peter Xu, Jason Gunthorpe, Nick Piggin,
John Hubbard, Kirill Shutemov, Andrew Morton, linuxppc-dev
In-Reply-To: <CAHk-=whwY0WT046fqM-zdHu9vamUjgkvmd36gCd4qSaeYy98nA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
On Thu, Oct 8, 2020 at 10:02 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Here's the first patch anyway. If you actually have a test-case where
> this matters, I guess I need to apply it now..
Actually, I removed the "__page_mapcount()" part of that patch, to
keep it minimal and _only_ do remove the wrprotect trick.
We can do the __page_mapcount() optimization and the mm sequence count
for 5.10 (although so far nobody has actually written the seqcount
patch - I think it would be a trivial few-liner, but I guess it won't
make 5.10 at this point).
So here's what I ended up with.
Linus
[-- Attachment #2: 0001-mm-avoid-early-COW-write-protect-games-during-fork.patch --]
[-- Type: text/x-patch, Size: 5138 bytes --]
From f3c64eda3e5097ec3198cb271f5f504d65d67131 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 28 Sep 2020 12:50:03 -0700
Subject: [PATCH] mm: avoid early COW write protect games during fork()
In commit 70e806e4e645 ("mm: Do early cow for pinned pages during fork()
for ptes") we write-protected the PTE before doing the page pinning
check, in order to avoid a race with concurrent fast-GUP pinning (which
doesn't take the mm semaphore or the page table lock).
That trick doesn't actually work - it doesn't handle memory ordering
properly, and doing so would be prohibitively expensive.
It also isn't really needed. While we're moving in the direction of
allowing and supporting page pinning without marking the pinned area
with MADV_DONTFORK, the fact is that we've never really supported this
kind of odd "concurrent fork() and page pinning", and doing the
serialization on a pte level is just wrong.
We can add serialization with a per-mm sequence counter, so we know how
to solve that race properly, but we'll do that at a more appropriate
time. Right now this just removes the write protect games.
It also turns out that the write protect games actually break on Power,
as reported by Aneesh Kumar:
"Architecture like ppc64 expects set_pte_at to be not used for updating
a valid pte. This is further explained in commit 56eecdb912b5 ("mm:
Use ptep/pmdp_set_numa() for updating _PAGE_NUMA bit")"
and the code triggered a warning there:
WARNING: CPU: 0 PID: 30613 at arch/powerpc/mm/pgtable.c:185 set_pte_at+0x2a8/0x3a0 arch/powerpc/mm/pgtable.c:185
Call Trace:
copy_present_page mm/memory.c:857 [inline]
copy_present_pte mm/memory.c:899 [inline]
copy_pte_range mm/memory.c:1014 [inline]
copy_pmd_range mm/memory.c:1092 [inline]
copy_pud_range mm/memory.c:1127 [inline]
copy_p4d_range mm/memory.c:1150 [inline]
copy_page_range+0x1f6c/0x2cc0 mm/memory.c:1212
dup_mmap kernel/fork.c:592 [inline]
dup_mm+0x77c/0xab0 kernel/fork.c:1355
copy_mm kernel/fork.c:1411 [inline]
copy_process+0x1f00/0x2740 kernel/fork.c:2070
_do_fork+0xc4/0x10b0 kernel/fork.c:2429
Link: https://lore.kernel.org/lkml/CAHk-=wiWr+gO0Ro4LvnJBMs90OiePNyrE3E+pJvc9PzdBShdmw@mail.gmail.com/
Link: https://lore.kernel.org/linuxppc-dev/20201008092541.398079-1-aneesh.kumar@linux.ibm.com/
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Tested-by: Leon Romanovsky <leonro@nvidia.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill Shutemov <kirill@shutemov.name>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
mm/memory.c | 41 ++++-------------------------------------
1 file changed, 4 insertions(+), 37 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index fcfc4ca36eba..eeae590e526a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -806,8 +806,6 @@ copy_present_page(struct mm_struct *dst_mm, struct mm_struct *src_mm,
return 1;
/*
- * The trick starts.
- *
* What we want to do is to check whether this page may
* have been pinned by the parent process. If so,
* instead of wrprotect the pte on both sides, we copy
@@ -815,47 +813,16 @@ copy_present_page(struct mm_struct *dst_mm, struct mm_struct *src_mm,
* the pinned page won't be randomly replaced in the
* future.
*
- * To achieve this, we do the following:
- *
- * 1. Write-protect the pte if it's writable. This is
- * to protect concurrent write fast-gup with
- * FOLL_PIN, so that we'll fail the fast-gup with
- * the write bit removed.
- *
- * 2. Check page_maybe_dma_pinned() to see whether this
- * page may have been pinned.
- *
- * The order of these steps is important to serialize
- * against the fast-gup code (gup_pte_range()) on the
- * pte check and try_grab_compound_head(), so that
- * we'll make sure either we'll capture that fast-gup
- * so we'll copy the pinned page here, or we'll fail
- * that fast-gup.
- *
- * NOTE! Even if we don't end up copying the page,
- * we won't undo this wrprotect(), because the normal
- * reference copy will need it anyway.
- */
- if (pte_write(pte))
- ptep_set_wrprotect(src_mm, addr, src_pte);
-
- /*
- * These are the "normally we can just copy by reference"
- * checks.
+ * The page pinning checks are just "has this mm ever
+ * seen pinning", along with the (inexact) check of
+ * the page count. That might give false positives for
+ * for pinning, but it will work correctly.
*/
if (likely(!atomic_read(&src_mm->has_pinned)))
return 1;
if (likely(!page_maybe_dma_pinned(page)))
return 1;
- /*
- * Uhhuh. It looks like the page might be a pinned page,
- * and we actually need to copy it. Now we can set the
- * source pte back to being writable.
- */
- if (pte_write(pte))
- set_pte_at(src_mm, addr, src_pte, pte);
-
new_page = *prealloc;
if (!new_page)
return -EAGAIN;
--
2.28.0.218.gc12ef3d349
^ permalink raw reply related
* Re: [PATCH] mm: Avoid using set_pte_at when updating a present pte
From: Linus Torvalds @ 2020-10-08 17:09 UTC (permalink / raw)
To: Aneesh Kumar K.V, Leon Romanovsky
Cc: Michal Hocko, Jan Kara, Linux-MM, Hugh Dickins,
Linux Kernel Mailing List, Peter Xu, Jason Gunthorpe, Nick Piggin,
John Hubbard, Kirill Shutemov, Andrew Morton, linuxppc-dev
In-Reply-To: <20201008092541.398079-1-aneesh.kumar@linux.ibm.com>
Ahh, and I should learn to read all my emails before replying to some of them..
On Thu, Oct 8, 2020 at 2:26 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> This avoids the below warning
> [..]
> WARNING: CPU: 0 PID: 30613 at arch/powerpc/mm/pgtable.c:185
set_pte_at+0x2a8/0x3a0 arch/powerpc/mm/pgtable.c:185
.. and I assume this is what triggered the other patch too.
Yes, with the ppc warning, we need to do _something_ about this, and
at that point I think the "something" is to just avoid the pte
wrpritect trick.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox