[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a3a227b8cb643e99fd79ce15610c4b2@AcuMS.aculab.com>
Date: Tue, 24 Nov 2020 22:12:52 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Arnd Bergmann' <arnd@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>
Subject: RE: [PATCH v4 2/4] net: socket: rework SIOC?IFMAP ioctls
From: Arnd Bergmann
> Sent: 24 November 2020 19:06
>
> On Tue, Nov 24, 2020 at 5:13 PM David Laight <David.Laight@...lab.com> wrote:
> >
> > From: Arnd Bergmann
> > > Sent: 24 November 2020 15:18
> > >
> > > SIOCGIFMAP and SIOCSIFMAP currently require compat_alloc_user_space()
> > > and copy_in_user() for compat mode.
> > >
> > > Move the compat handling into the location where the structures are
> > > actually used, to avoid using those interfaces and get a clearer
> > > implementation.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@...db.de>
> > > ---
> > > changes in v3:
> > > - complete rewrite
> > ...
> > > include/linux/compat.h | 18 ++++++------
> > > net/core/dev_ioctl.c | 64 +++++++++++++++++++++++++++++++++---------
> > > net/socket.c | 39 ++-----------------------
> > > 3 files changed, 62 insertions(+), 59 deletions(-)
> > >
> > > diff --git a/include/linux/compat.h b/include/linux/compat.h
> > > index 08dbd34bb7a5..47496c5eb5eb 100644
> > > --- a/include/linux/compat.h
> > > +++ b/include/linux/compat.h
> > > @@ -96,6 +96,15 @@ struct compat_iovec {
> > > compat_size_t iov_len;
> > > };
> > >
> > > +struct compat_ifmap {
> > > + compat_ulong_t mem_start;
> > > + compat_ulong_t mem_end;
> > > + unsigned short base_addr;
> > > + unsigned char irq;
> > > + unsigned char dma;
> > > + unsigned char port;
> > > +};
> >
> > Isn't the only difference the number of pad bytes at the end?
>
> No, the main difference is in the first two fields, which are
> 'unsigned long' and therefore different. The three-byte padding
> is in fact the same on all architectures (including x86) that
> have a compat mode, though it might be different on
> m68k and arm-oabi, which have slightly special struct
> alignment rules.
>
> It could be done with two assignments and a memcpy, but
> I like the individual assignments better here.
Gah my brain hurts today.
I was just thinking of the alignment and padding, not the sizes.
You could read the compat structure to 'mem_end' and
then move the first two fields forward.
But, I guess, this structure doesn't have many fields.
What you really need for these copies is COBOL's 'move corresponding'.
(Which wasn't implemented by the only COBOL compiler I've used.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists