arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

PATCH New Luc Van Oostenryck 3 participants 12 messages Jun 28, 2017 – Jun 29, 2017 arm64

Share & tools

Luc Van Oostenryck

author

2017-06-28 14:55 UTC #0 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

get_alt_insn() is used to read and create ARM instructions, which are always stored in memory in little-endian order. These values are thus correctly converted to/from native order when processed but the pointers used to hold the address of these instructions are declared as for native order values.

Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes.

Signed-off-by Luc Van Oostenryck <[email protected]>

---
 arch/arm64/kernel/alternative.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

arch/arm64/kernel/alternative.c +5 -5

index 8840c109c..56bfda8cb 100644
@@ -60,7 +60,7 @@ static bool branch_insn_requires_update(struct alt_instr *alt, unsigned long pc)
 
 #define align_down(x, a)	((unsigned long)(x) & ~(((unsigned long)(a)) - 1))
 
-static u32 get_alt_insn(struct alt_instr *alt, u32 *insnptr, u32 *altinsnptr)
+static u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnptr)
 {
 	u32 insn;

@@ -109,7 +109,7 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
 {
 	struct alt_instr *alt;
 	struct alt_region *region = alt_region;
-	u32 *origptr, *replptr, *updptr;
+	__le32 *origptr, *replptr, *updptr;
 
 	for (alt = region->begin; alt < region->end; alt++) {
 		u32 insn;

@@ -122,9 +122,9 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
 
 		pr_info_once("patching kernel code\n");
 
-		origptr = ALT_ORIG_PTR(alt);
-		replptr = ALT_REPL_PTR(alt);
-		updptr = use_linear_alias ? (u32 *)lm_alias(origptr) : origptr;
+		origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+		replptr = (__le32 __force *) ALT_REPL_PTR(alt);
+		updptr = use_linear_alias ? (__le32 *)lm_alias(origptr) : origptr;
 		nr_inst = alt->alt_len / sizeof(insn);
 
 		for (i = 0; i < nr_inst; i++) {

Signature · 1 line

2.13.0

Will Deacon

2017-06-29 10:28 UTC #1 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 37 lines · Luc Van Oostenryck

get_alt_insn() is used to read and create ARM instructions, which are always stored in memory in little-endian order. These values are thus correctly converted to/from native order when processed but the pointers used to hold the address of these instructions are declared as for native order values.
Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes.
Signed-off-by Luc Van Oostenryck <[email protected]>
---
 arch/arm64/kernel/alternative.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
arch/arm64/kernel/alternative.c +2 -2
index 8840c109c..56bfda8cb 100644
@@ -60,7 +60,7 @@ static bool branch_insn_requires_update(struct alt_instr *alt, unsigned long pc)
 
 #define align_down(x, a)	((unsigned long)(x) & ~(((unsigned long)(a)) - 1))
 
-static u32 get_alt_insn(struct alt_instr *alt, u32 *insnptr, u32 *altinsnptr)
+static u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnptr)
 {
 	u32 insn;
 
@@ -109,7 +109,7 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
 {
 	struct alt_instr *alt;
 	struct alt_region *region = alt_region;
-	u32 *origptr, *replptr, *updptr;
+	__le32 *origptr, *replptr, *updptr;
 
 	for (alt = region->begin; alt < region->end; alt++) {
 		u32 insn;

arch/arm64/kernel/alternative.c static void __apply_alternatives(void *alt_region, bool use_linear_alias) · line 126

Quoted 8 lines

arch/arm64/kernel/alternative.c +2 -3

@@ -122,9 +122,9 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
 
 		pr_info_once("patching kernel code\n");
 
-		origptr = ALT_ORIG_PTR(alt);
-		replptr = ALT_REPL_PTR(alt);
-		updptr = use_linear_alias ? (u32 *)lm_alias(origptr) : origptr;
+		origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+		replptr = (__le32 __force *) ALT_REPL_PTR(alt);

Why is the __force needed here?

Will

Luc Van Oostenryck

author

2017-06-29 13:26 UTC #2 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 7 lines · Will Deacon

Quoted 6 lines · Luc Van Oostenryck
get_alt_insn() is used to read and create ARM instructions, which are always stored in memory in little-endian order. These values are thus correctly converted to/from native order when processed but the pointers used to hold the address of these instructions are declared as for native order values.

Quoted 7 lines

arch/arm64/kernel/alternative.c static void __apply_alternatives(void *alt_region, bool use_linear_alias) · line 126
Quoted 5 lines
Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes.
arch/arm64/kernel/alternative.c +2 -0
+		origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+		replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?

Because of the cast to u32* in:

	#define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
	#define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
	#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)

Of course, if this (u32*) is not really needed, then the __force is also not needed.

And since, it seems indeed to be the case, I'll gladly sent a patch:

	-#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
	+#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)

if it suits you.

-- Luc

Will Deacon

2017-06-29 14:11 UTC #3 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 21 lines · Luc Van Oostenryck

Quoted 7 lines · Will Deacon
Quoted 6 lines · Luc Van Oostenryck
get_alt_insn() is used to read and create ARM instructions, which are always stored in memory in little-endian order. These values are thus correctly converted to/from native order when processed but the pointers used to hold the address of these instructions are declared as for native order values.
Quoted 7 lines
arch/arm64/kernel/alternative.c static void __apply_alternatives(void *alt_region, bool use_linear_alias) · line 126
Quoted 5 lines
Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes.
arch/arm64/kernel/alternative.c +2 -0
+		origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+		replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?
Because of the cast to u32* in:
	#define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
	#define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
	#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)

Quoted 7 lines

Of course, if this (u32*) is not really needed, then the __force is also not needed.
And since, it seems indeed to be the case, I'll gladly sent a patch:
	-#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
	+#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)
if it suits you.

Yes, please!

Will

Mark Rutland

reviewer

2017-06-29 14:13 UTC #4 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

In reply to Luc Van Oostenryck

Quoted 21 lines · Luc Van Oostenryck

Quoted 7 lines · Will Deacon
Quoted 6 lines · Luc Van Oostenryck
get_alt_insn() is used to read and create ARM instructions, which are always stored in memory in little-endian order. These values are thus correctly converted to/from native order when processed but the pointers used to hold the address of these instructions are declared as for native order values.
Quoted 7 lines
arch/arm64/kernel/alternative.c static void __apply_alternatives(void *alt_region, bool use_linear_alias) · line 126
Quoted 5 lines
Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes.
arch/arm64/kernel/alternative.c +2 -0
+		origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+		replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?
Because of the cast to u32* in:
	#define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
	#define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
	#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)

Quoted 7 lines

Of course, if this (u32*) is not really needed, then the __force is also not needed.
And since, it seems indeed to be the case, I'll gladly sent a patch:
	-#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
	+#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)
if it suits you.

Given __ALT_PTR is intended to give a pointer to A64 instructions, which are in le32 format, wouldn't it make more sense for __ALT_PTR to cast to __le32 * ?

Thanks,
Mark.

Will Deacon

2017-06-29 14:19 UTC #5 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 25 lines · Mark Rutland

Quoted 24 lines · Luc Van Oostenryck
Quoted 7 lines · Will Deacon
Quoted 6 lines · Luc Van Oostenryck
get_alt_insn() is used to read and create ARM instructions, which are always stored in memory in little-endian order. These values are thus correctly converted to/from native order when processed but the pointers used to hold the address of these instructions are declared as for native order values.
Quoted 7 lines
arch/arm64/kernel/alternative.c static void __apply_alternatives(void *alt_region, bool use_linear_alias) · line 126
Quoted 5 lines
Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes.
arch/arm64/kernel/alternative.c +2 -0
+		origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+		replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?
Because of the cast to u32* in:
	#define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
	#define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
	#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
Of course, if this (u32*) is not really needed, then the __force is also not needed.

Quoted 8 lines

Quoted 4 lines
And since, it seems indeed to be the case, I'll gladly sent a patch:
	-#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
	+#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)
if it suits you.
Given __ALT_PTR is intended to give a pointer to A64 instructions, which are in le32 format, wouldn't it make more sense for __ALT_PTR to cast to __le32 * ?

Might be a bit weird for ALT_REPL_PTR, which is cast to unsigned long.

Will

Mark Rutland

reviewer

2017-06-29 14:22 UTC #6 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 31 lines · Will Deacon

Quoted 30 lines · Mark Rutland
Quoted 28 lines · Luc Van Oostenryck
Quoted 7 lines · Will Deacon
Quoted 6 lines · Luc Van Oostenryck
get_alt_insn() is used to read and create ARM instructions, which are always stored in memory in little-endian order. These values are thus correctly converted to/from native order when processed but the pointers used to hold the address of these instructions are declared as for native order values.
Quoted 7 lines
arch/arm64/kernel/alternative.c static void __apply_alternatives(void *alt_region, bool use_linear_alias) · line 126
Quoted 5 lines
Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes.
arch/arm64/kernel/alternative.c +2 -0
+		origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+		replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?
Because of the cast to u32* in:
	#define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
	#define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
	#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
Of course, if this (u32*) is not really needed, then the __force is also not needed.
And since, it seems indeed to be the case, I'll gladly sent a patch:
	-#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
	+#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)
if it suits you.

Quoted 5 lines

Quoted 3 lines
Given __ALT_PTR is intended to give a pointer to A64 instructions, which are in le32 format, wouldn't it make more sense for __ALT_PTR to cast to __le32 * ?
Might be a bit weird for ALT_REPL_PTR, which is cast to unsigned long.

Maybe, but that's one cast, rather than two, and matches other similar casts from a pointer to unsigned long (e.g. the the addr cast in __range_ok()).

Thanks,
Mark.

Will Deacon

2017-06-29 14:26 UTC #7 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 36 lines · Mark Rutland

Quoted 35 lines · Will Deacon
Quoted 33 lines · Mark Rutland
Quoted 21 lines · Luc Van Oostenryck
Quoted 7 lines · Will Deacon
Quoted 6 lines · Luc Van Oostenryck
get_alt_insn() is used to read and create ARM instructions, which are always stored in memory in little-endian order. These values are thus correctly converted to/from native order when processed but the pointers used to hold the address of these instructions are declared as for native order values.
Quoted 7 lines
arch/arm64/kernel/alternative.c static void __apply_alternatives(void *alt_region, bool use_linear_alias) · line 126
Quoted 5 lines
Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes.
arch/arm64/kernel/alternative.c +2 -0
+		origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+		replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?
Because of the cast to u32* in:
	#define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
	#define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
	#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
Quoted 7 lines
Of course, if this (u32*) is not really needed, then the __force is also not needed.
And since, it seems indeed to be the case, I'll gladly sent a patch:
	-#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
	+#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)
if it suits you.
Given __ALT_PTR is intended to give a pointer to A64 instructions, which are in le32 format, wouldn't it make more sense for __ALT_PTR to cast to __le32 * ?

Quoted 5 lines

Quoted 1 line
Might be a bit weird for ALT_REPL_PTR, which is cast to unsigned long.
Maybe, but that's one cast, rather than two, and matches other similar casts from a pointer to unsigned long (e.g. the the addr cast in __range_ok()).

Sure, but isn't it a __force cast? I'd like to avoid that if we can.

Will

Luc Van Oostenryck

author

2017-06-29 15:15 UTC #8 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 18 lines · Will Deacon

Quoted 17 lines · Mark Rutland
Quoted 16 lines · Will Deacon
Quoted 15 lines · Mark Rutland
Quoted 14 lines · Luc Van Oostenryck
Quoted 4 lines · Will Deacon
Review
Quoted 2 lines
(quoted diff) +2 -0
+           origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+           replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?
Because of the cast to u32* in:
        #define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
        #define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
        #define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
Of course, if this (u32*) is not really needed, then the __force is also not needed.

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
And since, it seems indeed to be the case, I'll gladly sent a patch:
        -#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
        +#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)
if it suits you.
Given __ALT_PTR is intended to give a pointer to A64 instructions, which are in le32 format, wouldn't it make more sense for __ALT_PTR to cast to __le32 * ?

Yes, it could.

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
Might be a bit weird for ALT_REPL_PTR, which is cast to unsigned long.
Maybe, but that's one cast, rather than two, and matches other similar casts from a pointer to unsigned long (e.g. the the addr cast in __range_ok()).
Sure, but isn't it a __force cast? I'd like to avoid that if we can.

No, once you cast to an integer all the specificities of pointers are thrown away,
like for a const pointer and here the __bitwise underlying the __le32. It's exactly the same fro cast from/to void*, the reasoning behind it is something
like : "it's OK to drop all the qualifiers and such because you will anyway need to cast the result to another pointer before being able to dereference it".

I already sent a version leaving the type as void*, without having seen your replies here, but if you wish I can, of course, resend something for __le32*.

-- Luc

Will Deacon

2017-06-29 15:20 UTC #9 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 38 lines · Luc Van Oostenryck

Quoted 18 lines · Will Deacon
Quoted 17 lines · Mark Rutland
Quoted 16 lines · Will Deacon
Quoted 15 lines · Mark Rutland
Quoted 14 lines · Luc Van Oostenryck
Quoted 4 lines · Will Deacon
Review
Quoted 2 lines
(quoted diff) +2 -0
+           origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+           replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?
Because of the cast to u32* in:
        #define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
        #define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
        #define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
Of course, if this (u32*) is not really needed, then the __force is also not needed.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
And since, it seems indeed to be the case, I'll gladly sent a patch:
        -#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
        +#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)
if it suits you.
Given __ALT_PTR is intended to give a pointer to A64 instructions, which are in le32 format, wouldn't it make more sense for __ALT_PTR to cast to __le32 * ?
Yes, it could.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Might be a bit weird for ALT_REPL_PTR, which is cast to unsigned long.
Maybe, but that's one cast, rather than two, and matches other similar casts from a pointer to unsigned long (e.g. the the addr cast in __range_ok()).
Sure, but isn't it a __force cast? I'd like to avoid that if we can.

Quoted 7 lines

No, once you cast to an integer all the specificities of pointers are thrown away,
like for a const pointer and here the __bitwise underlying the __le32. It's exactly the same fro cast from/to void*, the reasoning behind it is something
like : "it's OK to drop all the qualifiers and such because you will anyway need to cast the result to another pointer before being able to dereference it".

Ok, so does that mean that the __force cast in __range_ok is not needed?

Quoted 2 lines

I already sent a version leaving the type as void*, without having seen your replies here, but if you wish I can, of course, resend something for __le32*.

I'm happy with the patch you sent, so no need to resend.

Will

Luc Van Oostenryck

author

2017-06-29 15:56 UTC #10 lore raw

PATCH 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

Quoted 47 lines · Will Deacon

Quoted 38 lines · Luc Van Oostenryck
Quoted 18 lines · Will Deacon
Quoted 17 lines · Mark Rutland
Quoted 16 lines · Will Deacon
Quoted 15 lines · Mark Rutland
Quoted 14 lines · Luc Van Oostenryck
Quoted 4 lines · Will Deacon
Review
Quoted 2 lines
(quoted diff) +2 -0
+           origptr = (__le32 __force *) ALT_ORIG_PTR(alt);
+           replptr = (__le32 __force *) ALT_REPL_PTR(alt);
Why is the __force needed here?
Because of the cast to u32* in:
        #define ALT_ORIG_PTR(a)         __ALT_PTR(a, orig_offset)
        #define ALT_REPL_PTR(a)         __ALT_PTR(a, alt_offset)
        #define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
Of course, if this (u32*) is not really needed, then the __force is also not needed.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
And since, it seems indeed to be the case, I'll gladly sent a patch:
        -#define __ALT_PTR(a,f)          (u32 *)((void *)&(a)->f + (a)->f)
        +#define __ALT_PTR(a,f)          ((void *)&(a)->f + (a)->f)
if it suits you.
Given __ALT_PTR is intended to give a pointer to A64 instructions, which are in le32 format, wouldn't it make more sense for __ALT_PTR to cast to __le32 * ?
Yes, it could.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Might be a bit weird for ALT_REPL_PTR, which is cast to unsigned long.
Maybe, but that's one cast, rather than two, and matches other similar casts from a pointer to unsigned long (e.g. the the addr cast in __range_ok()).
Sure, but isn't it a __force cast? I'd like to avoid that if we can.
Quoted 7 lines
No, once you cast to an integer all the specificities of pointers are thrown away,
like for a const pointer and here the __bitwise underlying the __le32. It's exactly the same fro cast from/to void*, the reasoning behind it is something
like : "it's OK to drop all the qualifiers and such because you will anyway need to cast the result to another pointer before being able to dereference it".

Quoted 1 line

Ok, so does that mean that the __force cast in __range_ok is not needed?

Indeed.

And I just verified this with a quick check with sparse only on arch/arm64/ with and without the __force.

Quoted 4 lines

Quoted 2 lines
I already sent a version leaving the type as void*, without having seen your replies here, but if you wish I can, of course, resend something for __le32*.
I'm happy with the patch you sent, so no need to resend.

OK.

-- Luc

Luc Van Oostenryck

author

2017-06-29 14:40 UTC #11 lore raw

PATCH v2 1/1 arm64: fix endianness annotation for __apply_alternatives()/get_alt_insn()

In reply to Luc Van Oostenryck

Fix this by declaring the pointers as __le32* instead of u32* and make the few appropriate needed changes like removing the unneeded cast '(u32*)' in front of __ALT_PTR()'s definition.

Signed-off-by Luc Van Oostenryck <[email protected]>

---
Change since v1:
- remove the unneeded cast '(u32*)' in front of __ALT_PTR()'s definition.
- remove the now unneeded forced cast to __le32* when using ALT_ORIG_PTR() or ALT_REPL_PTR().
- remove an unnneded cast in front of lm_alias().

 arch/arm64/kernel/alternative.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm64/kernel/alternative.c +4 -4

index 8840c109c..6dd0a3a3e 100644
@@ -28,7 +28,7 @@
 #include <asm/sections.h>
 #include <linux/stop_machine.h>
 
-#define __ALT_PTR(a,f)		(u32 *)((void *)&(a)->f + (a)->f)
+#define __ALT_PTR(a,f)		((void *)&(a)->f + (a)->f)
 #define ALT_ORIG_PTR(a)		__ALT_PTR(a, orig_offset)
 #define ALT_REPL_PTR(a)		__ALT_PTR(a, alt_offset)

@@ -60,7 +60,7 @@ static bool branch_insn_requires_update(struct alt_instr *alt, unsigned long pc)
 
 #define align_down(x, a)	((unsigned long)(x) & ~(((unsigned long)(a)) - 1))
 
-static u32 get_alt_insn(struct alt_instr *alt, u32 *insnptr, u32 *altinsnptr)
+static u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnptr)
 {
 	u32 insn;

@@ -109,7 +109,7 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
 {
 	struct alt_instr *alt;
 	struct alt_region *region = alt_region;
-	u32 *origptr, *replptr, *updptr;
+	__le32 *origptr, *replptr, *updptr;
 
 	for (alt = region->begin; alt < region->end; alt++) {
 		u32 insn;

@@ -124,7 +124,7 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
 
 		origptr = ALT_ORIG_PTR(alt);
 		replptr = ALT_REPL_PTR(alt);
-		updptr = use_linear_alias ? (u32 *)lm_alias(origptr) : origptr;
+		updptr = use_linear_alias ? lm_alias(origptr) : origptr;
 		nr_inst = alt->alt_len / sizeof(insn);
 
 		for (i = 0; i < nr_inst; i++) {

Signature · 1 line

2.13.0