Re: [PATCH 1/2] LoongArch: Add pad structure members for explicit alignment

[Xi Ruoyao]

On Thu, 2023-04-20 at 10:14 +0800, Qing Zhang wrote:
> > > Ah right. This is UAPI so without *very* concrete and convicing reason 
> > > why the change is not going to impact any potential users, it's gonna 
> > > be a presumed NAK. In other words you must demonstrate (1) why it's 
> > > absolutely necessary to make the change and (2) that it's impossible 
> > > to impact anyone, before any such changes can even be considered.
> > Please ignore all of this. The memory layout is actually the same after 
> > the change due to the padding, I was somehow thinking in big-endian a 
> > few hours ago.

No.  The problem is not related to big endian or little endian. 
Changing the type of this field *can* turn valid user code into
undefined behavior.  `printf(PRIu16 "\n", ptr->dbg_info);` is an
undefined behavior if ptr->dbg_info is a int16_t, because the standard
says so, not because the machine may be big endian.

It is a rare case where the ABI is backward-compatible but the API is
incompatible.

Why not just insert "int16_t pad1[3];" after dbg_info?

> > (The commit message didn't help either, I think both 
> > Ruoyao and me got into the habitual thinking that changes like this are 
> > most likely just churn without real benefits, after *not* seeing the
> > rationale in the commit message which was kinda expected.)
> > > 
> 
> This patch does not change the size of the structure. The structure
> itself is implicitly aligned. We changed it to explicit alignment for
> the convenience of hw_break_get/set (using membuf.left) to calculate the
> offset and prevent breaks. Count overflow.
> 
> With pad explicit alignment, after membuf_write(&to, &info, 
> sizeof(info)); to.left=200-8 bytes,
> Thus,
> membuf_store(&to, addr);
> membuf_store(&to, mask);
> membuf_store(&to, ctrl);
> membuf_zero(&to, sizeof(u32));
> After that, to.left is decremented by 24 bytes each time,
> so the number of breakpoints will not overflow.
> 
> The user support code has not been submitted to the upstream, so
> the current uapi change has no effect.

The problem is once we put a header into the UAPI directory and make a
Linux kernel release, people may start to use it (maybe in a way we
don't expected).

-- 
Xi Ruoyao <xry111@xxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University