Skip to contentSkip to conversation

MIPS: Remove unnecessary zero-length struct member

PATCH Superseded Thorsten Blum 2 participants 5 messages Apr 11, 2025 – Apr 17, 2025

Subsystems (2)
MIPS ptrace support

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Thorsten Blum

author
#0 lore raw

PATCH 1/1 MIPS: Remove unnecessary zero-length struct member

Remove the zero-length struct member '__last' and use sizeof() to calculate the value for MAX_REG_OFFSET.

No functional changes intended.

Signed-off-by Thorsten Blum <[email protected]>
---
 arch/mips/include/asm/ptrace.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
arch/mips/include/asm/ptrace.h +1 -2
index 85fa9962266a..1bb10ee8c2ce 100644
@@ -48,7 +48,6 @@ struct pt_regs {
 	unsigned long long mpl[6];        /* MTM{0-5} */
 	unsigned long long mtp[6];        /* MTP{0-5} */
 #endif
-	unsigned long __last[0];
 } __aligned(8);
 
 static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)

@@ -65,7 +64,7 @@ static inline void instruction_pointer_set(struct pt_regs *regs,
 
 /* Query offset/name of register from its name/offset */
 extern int regs_query_register_offset(const char *name);
-#define MAX_REG_OFFSET (offsetof(struct pt_regs, __last))
+#define MAX_REG_OFFSET (sizeof(struct pt_regs))
 
 /**
  * regs_get_register() - get register value from its offset
Signature · 1 line
2.49.0
#1 lore raw
Quoted 4 lines · Thorsten Blum

Remove the zero-length struct member '__last' and use sizeof() to calculate the value for MAX_REG_OFFSET.

No functional changes intended.

Have you verified that there's no change except for timestamp data in
(non-debug) `vmlinux' produced with and w/o the patch applied?

Also this is broken anyway: if you use MAX_REG_OFFSET for `offset' passed
to regs_get_register', then data past the end of regs' will be accessed.

Maciej

author
#2 lore raw
Quoted 9 lines · Maciej W. Rozycki
Quoted 4 lines · Thorsten Blum

Remove the zero-length struct member '__last' and use sizeof() to calculate the value for MAX_REG_OFFSET.

No functional changes intended.

Have you verified that there's no change except for timestamp data in (non-debug) `vmlinux' produced with and w/o the patch applied?

Just did - and yes, the binaries are identical.

Thanks,
Thorsten

author
#3 lore raw
In reply to Maciej W. Rozycki
Quoted 5 lines · Maciej W. Rozycki
Quoted 3 lines · Thorsten Blum

Remove the zero-length struct member '__last' and use sizeof() to calculate the value for MAX_REG_OFFSET.

Quoted 7 lines
Quoted 1 line

No functional changes intended.

Have you verified that there's no change except for timestamp data in (non-debug) `vmlinux' produced with and w/o the patch applied?

Also this is broken anyway: if you use MAX_REG_OFFSET for offset' passed to regs_get_register', then data past the end of `regs' will be accessed.

Yes, true. It seems like

	if (unlikely(offset >= MAX_REG_OFFSET))
		return 0;

should do the trick.

The comment also says "If @offset is bigger than MAX_REG_OFFSET", rather than "is bigger than or equal to".

Happy to add it to v2 or a separate patch, if this is actually correct?!

Thanks,
Thorsten

#4 lore raw
Quoted 9 lines · Thorsten Blum
Quoted 2 lines

Also this is broken anyway: if you use MAX_REG_OFFSET for offset' passed to regs_get_register', then data past the end of `regs' will be accessed.

Yes, true. It seems like

	if (unlikely(offset >= MAX_REG_OFFSET))
		return 0;

should do the trick.

No, other platforms use the same (offset > MAX_REG_OFFSET) check that we
do and just set MAX_REG_OFFSET correctly to point at the last register in `struct pt_regs'.

Quoted 2 lines

The comment also says "If @offset is bigger than MAX_REG_OFFSET", rather than "is bigger than or equal to".

And quite correctly so.

Quoted 1 line

Happy to add it to v2 or a separate patch, if this is actually correct?!

Yes, please send v2. There's no point in changing MAX_REG_OFFSET twice.

Maciej