Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote:
> On 24.06.2020 15:41, Julien Grall wrote:
> > On 24/06/2020 11:12, Jan Beulich wrote:
> >> On 23.06.2020 19:26, Roger Pau Monné wrote:
> >>> I'm confused. Couldn't we switch from uint64_aligned_t to plain
> >>> uint64_t (like it's currently on the Linux headers), and then use the
> >>> compat layer in Xen to handle the size difference when called from
> >>> 32bit environments?
> >>
> >> And which size would we use there? The old or the new one (breaking
> >> future or existing callers respectively)? Meanwhile I think that if
> >> this indeed needs to not be tools-only (which I still question),
> > 
> > I think we now agreed on a subthread that the kernel needs to know the 
> > layout of the hypercall.
> > 
> >> then our only possible route is to add explicit padding for the
> >> 32-bit case alongside the change you're already making.
> > 
> > AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make 
> > incompatible the two incompatible?
> 
> In principle yes. But they're putting the structure instance on the
> stack, so there's not risk from Xen reading 4 bytes too many. I'd
> prefer keeping the interface as is (i.e. with the previously
> implicit padding made explicit) to avoid risking to break other
> possible callers. But that's just my view on it, anyway ...

Adding the padding is cleaner because we don't need any compat stuff
in order to access the structure from the caller, and we also keep the
original layout currently present on Xen headers.

I can prepare a fix for the Linux kernel, if this approach is fine.

Roger.