Recent tightening of the opcode table in binutils so as to consistently
disallow the assembly or disassembly of CP0 instructions not supported
by the processor architecture chosen has caused a regression like below:
arch/mips/dec/prom/locore.S: Assembler messages:
arch/mips/dec/prom/locore.S:29: Error: opcode not supported on this processor: r4600 (mips3) `rfe'
in a piece of code used to probe for memory with PMAX DECstation models,
which have non-REX firmware. Those computers always have an R2000 CPU
and consequently the exception handler used in memory probing uses the
RFE instruction, which those processors use.
While adding 64-bit support this code was correctly excluded for 64-bit
configurations, however it should have also been excluded for irrelevant
32-bit configurations. Do this now then, and only enable PMAX memory
probing for R3k systems.
Reported-by: Jan-Benedict Glaw <jbglaw(a)lug-owl.de>
Reported-by: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable(a)vger.kernel.org # v2.6.12+
---
Hi,
I'm assuming this won't go back beyond commit 2a11c8ea20bf ("kconfig:
Introduce IS_ENABLED(), IS_BUILTIN() and IS_MODULE()") or any backport
will have to be rewritten to avoid IS_ENABLED.
The original actual change named to fix ought to be commit dd82ef87e4c9
("PROM interface rework to support a 64-bit kernel.") from the LMO repo:
<https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=d…>,
which introduced the `prom_is_rex' macro, which guards this code. Said
commit predates the history of our main repository though.
This change has actually been verified at runtime with a PMIN system
(effectively a PMAX, but with a slower R2000 CPU) and a 4MAX+ system (an
R4400SC-based machine), and naturally throughout the three possible build
configurations: R3k, R4k/32-bit, R4k/64-bit.
It took longer than expected, but oh well... Sorry for the inconvenience
caused.
Please apply,
Maciej
---
arch/mips/dec/prom/Makefile | 2 +-
arch/mips/include/asm/dec/prom.h | 15 +++++----------
2 files changed, 6 insertions(+), 11 deletions(-)
linux-dec-locore-r3000.diff
Index: linux-macro/arch/mips/dec/prom/Makefile
===================================================================
--- linux-macro.orig/arch/mips/dec/prom/Makefile
+++ linux-macro/arch/mips/dec/prom/Makefile
@@ -6,4 +6,4 @@
lib-y += init.o memory.o cmdline.o identify.o console.o
-lib-$(CONFIG_32BIT) += locore.o
+lib-$(CONFIG_CPU_R3000) += locore.o
Index: linux-macro/arch/mips/include/asm/dec/prom.h
===================================================================
--- linux-macro.orig/arch/mips/include/asm/dec/prom.h
+++ linux-macro/arch/mips/include/asm/dec/prom.h
@@ -43,16 +43,11 @@
*/
#define REX_PROM_MAGIC 0x30464354
-#ifdef CONFIG_64BIT
-
-#define prom_is_rex(magic) 1 /* KN04 and KN05 are REX PROMs. */
-
-#else /* !CONFIG_64BIT */
-
-#define prom_is_rex(magic) ((magic) == REX_PROM_MAGIC)
-
-#endif /* !CONFIG_64BIT */
-
+/* KN04 and KN05 are REX PROMs, so only do the check for R3k systems. */
+static inline bool prom_is_rex(u32 magic)
+{
+ return !IS_ENABLED(CONFIG_CPU_R3000) || magic == REX_PROM_MAGIC;
+}
/*
* 3MIN/MAXINE PROM entry points for DS5000/1xx's, DS5000/xx's and
With KCFLAGS="-O3", I was able to trigger a fortify-source
memcpy() overflow panic on set_vi_srs_handler().
Although O3 level is not supported in the mainline, under some
conditions that may've happened with any optimization settings,
it's just a matter of inlining luck. The panic itself is correct,
more precisely, 50/50 false-positive and not at the same time.
From the one side, no real overflow happens. Exception handler
defined in asm just gets copied to some reserved places in the
memory.
But the reason behind is that C code refers to that exception
handler declares it as `char`, i.e. something of 1 byte length.
It's obvious that the asm function itself is way more than 1 byte,
so fortify logics thought we are going to past the symbol declared.
The standard way to refer to asm symbols from C code which is not
supposed to be called from C is to declare them as
`extern const u8[]`. This is fully correct from any point of view,
as any code itself is just a bunch of bytes (including 0 as it is
for syms like _stext/_etext/etc.), and the exact size is not known
at the moment of compilation.
Adjust the type of the except_vec_vi_*() and related variables.
Make set_handler() take `const` as a second argument to avoid
cast-away warnings and give a little more room for optimization.
Fixes: e01402b115cc ("More AP / SP bits for the 34K, the Malta bits and things. Still wants")
Fixes: c65a5480ff29 ("[MIPS] Fix potential latency problem due to non-atomic cpu_wait.")
Cc: stable(a)vger.kernel.org # 3.10+
Signed-off-by: Alexander Lobakin <alobakin(a)pm.me>
---
arch/mips/include/asm/setup.h | 2 +-
arch/mips/kernel/traps.c | 22 +++++++++++-----------
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/mips/include/asm/setup.h b/arch/mips/include/asm/setup.h
index bb36a400203d..8c56b862fd9c 100644
--- a/arch/mips/include/asm/setup.h
+++ b/arch/mips/include/asm/setup.h
@@ -16,7 +16,7 @@ static inline void setup_8250_early_printk_port(unsigned long base,
unsigned int reg_shift, unsigned int timeout) {}
#endif
-extern void set_handler(unsigned long offset, void *addr, unsigned long len);
+void set_handler(unsigned long offset, const void *addr, unsigned long len);
extern void set_uncached_handler(unsigned long offset, void *addr, unsigned long len);
typedef void (*vi_handler_t)(void);
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index a486486b2355..246c6a6b0261 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -2091,19 +2091,19 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs)
* If no shadow set is selected then use the default handler
* that does normal register saving and standard interrupt exit
*/
- extern char except_vec_vi, except_vec_vi_lui;
- extern char except_vec_vi_ori, except_vec_vi_end;
- extern char rollback_except_vec_vi;
- char *vec_start = using_rollback_handler() ?
- &rollback_except_vec_vi : &except_vec_vi;
+ extern const u8 except_vec_vi[], except_vec_vi_lui[];
+ extern const u8 except_vec_vi_ori[], except_vec_vi_end[];
+ extern const u8 rollback_except_vec_vi[];
+ const u8 *vec_start = using_rollback_handler() ?
+ rollback_except_vec_vi : except_vec_vi;
#if defined(CONFIG_CPU_MICROMIPS) || defined(CONFIG_CPU_BIG_ENDIAN)
- const int lui_offset = &except_vec_vi_lui - vec_start + 2;
- const int ori_offset = &except_vec_vi_ori - vec_start + 2;
+ const int lui_offset = except_vec_vi_lui - vec_start + 2;
+ const int ori_offset = except_vec_vi_ori - vec_start + 2;
#else
- const int lui_offset = &except_vec_vi_lui - vec_start;
- const int ori_offset = &except_vec_vi_ori - vec_start;
+ const int lui_offset = except_vec_vi_lui - vec_start;
+ const int ori_offset = except_vec_vi_ori - vec_start;
#endif
- const int handler_len = &except_vec_vi_end - vec_start;
+ const int handler_len = except_vec_vi_end - vec_start;
if (handler_len > VECTORSPACING) {
/*
@@ -2311,7 +2311,7 @@ void per_cpu_trap_init(bool is_boot_cpu)
}
/* Install CPU exception handler */
-void set_handler(unsigned long offset, void *addr, unsigned long size)
+void set_handler(unsigned long offset, const void *addr, unsigned long size)
{
#ifdef CONFIG_CPU_MICROMIPS
memcpy((void *)(ebase + offset), ((unsigned char *)addr - 1), size);
--
2.35.1
On 2022-03-06 22:47, Matthew Wilcox wrote:
> On Sat, Mar 05, 2022 at 03:56:38PM -0500, Sasha Levin wrote:
>> This is a note to let you know that I've just added the patch titled
>>
>> iommu/amd: Use put_pages_list
>>
>> to the 5.16-stable tree which can be found at:
>> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>>
>> The filename of the patch is:
>> iommu-amd-use-put_pages_list.patch
>> and it can be found in the queue-5.16 subdirectory.
>>
>> If you, or anyone else, feels it should not be added to the stable tree,
>> please let <stable(a)vger.kernel.org> know about it.
>
> I would defer to Robin, but I don't think this is a good candidate for
> a stable backport. It has some dependencies, IIRC. And it's not really
> fixing a bug.
Indeed, I'd feel a bit uncomfortable about backporting this
unnecessarily. It doesn't make much sense in isolation without the other
patch(es) converting the rest of the IOMMU subsystem as well, but either
way unless the whole SLAB rework needs backporting for some reason then
it just represents risk without benefit.
Thanks,
Robin.
--
Hi,
I am a banker working with one of the leading banks here in the United
States. I write to contact you over a very important business
transaction which will be in our interest and of huge benefit to both
parties. Kindly get back to me for more details.
Thanks.
Mr. William Brook
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: venus: hfi_cmds: List HDR10 property as unsupported for v1 and v3
Author: Stanimir Varbanov <stanimir.varbanov(a)linaro.org>
Date: Tue Feb 1 16:51:29 2022 +0100
The HFI_PROPERTY_PARAM_VENC_HDR10_PQ_SEI HFI property is not supported
on Venus v1 and v3.
cc: stable(a)vger.kernel.org # 5.13+
Fixes: 9172652d72f8 ("media: venus: venc: Add support for CLL and Mastering display controls")
Signed-off-by: Stanimir Varbanov <stanimir.varbanov(a)linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org>
drivers/media/platform/qcom/venus/hfi_cmds.c | 2 ++
1 file changed, 2 insertions(+)
---
diff --git a/drivers/media/platform/qcom/venus/hfi_cmds.c b/drivers/media/platform/qcom/venus/hfi_cmds.c
index 5aea07307e02..4ecd444050bb 100644
--- a/drivers/media/platform/qcom/venus/hfi_cmds.c
+++ b/drivers/media/platform/qcom/venus/hfi_cmds.c
@@ -1054,6 +1054,8 @@ static int pkt_session_set_property_1x(struct hfi_session_set_property_pkt *pkt,
pkt->shdr.hdr.size += sizeof(u32) + sizeof(*info);
break;
}
+ case HFI_PROPERTY_PARAM_VENC_HDR10_PQ_SEI:
+ return -ENOTSUPP;
/* FOLLOWING PROPERTIES ARE NOT IMPLEMENTED IN CORE YET */
case HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS: