[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d0a1d479db3477e9bf6937b5a9b71af@AcuMS.aculab.com>
Date: Wed, 30 Aug 2023 08:32:00 +0000
From: David Laight <David.Laight@...LAB.COM>
To: David Laight <David.Laight@...LAB.COM>,
'Stefan Hajnoczi' <stefanha@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Tian, Kevin" <kevin.tian@...el.com>,
Alex Williamson <alex.williamson@...hat.com>,
Jason Gunthorpe <jgg@...pe.ca>
Subject: RE: [PATCH v2 0/3] vfio: use __aligned_u64 for ioctl structs
> -----Original Message-----
> From: David Laight <David.Laight@...LAB.COM>
> Sent: 29 August 2023 22:10
> To: 'Stefan Hajnoczi' <stefanha@...hat.com>; kvm@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org; Tian, Kevin <kevin.tian@...el.com>; Alex Williamson
> <alex.williamson@...hat.com>; Jason Gunthorpe <jgg@...pe.ca>
> Subject: RE: [PATCH v2 0/3] vfio: use __aligned_u64 for ioctl structs
>
> From: Stefan Hajnoczi
> > Sent: 29 August 2023 19:27
> >
> > v2:
> > - Rebased onto https://github.com/awilliam/linux-vfio.git next to get the
> > vfio_iommu_type1_info pad field [Kevin]
> > - Fixed min(minsz, sizeof(dmabuf)) -> min(dmabuf.argsz, sizeof(dmabuf)) [Jason, Kevin]
>
> You managed to use min_t() instead of fixing the types to match.
>
> > - Squashed Patch 3 (vfio_iommu_type1_info) into Patch 1 since it is trivial now
> > that the padding field is already there.
> >
> > Jason Gunthorpe <jgg@...dia.com> pointed out that u64 VFIO ioctl struct fields
> > have architecture-dependent alignment. iommufd already uses __aligned_u64 to
> > avoid this problem.
> >
> > See the __aligned_u64 typedef in <uapi/linux/types.h> for details on why it is
> > a good idea for kernel<->user interfaces.
> >
> > This series modifies the VFIO ioctl structs to use __aligned_u64. Some of the
> > changes preserve the existing memory layout on all architectures, so I put them
> > together into the first patch. The remaining patches are for structs where
> > explanation is necessary about why changing the memory layout does not break
> > the uapi.
>
> But you are extending a field in the middle of the uapi structure.
> This completely breaks any applications.
I've had a closer look this morning.
Your explanations aren't very good.
The structures all have the 64bit fields on their natural boundary
so the memory layout isn't really changed - just extra padding
at the end.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists