linux-kernel - RE: [PATCH v1] asm-generic: introduce be56 unaligned accessors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a55a7abb5fc745c8bb4bc081356ed7eb@AcuMS.aculab.com>
Date: Mon, 7 Oct 2024 15:05:13 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Arnd Bergmann' <arnd@...db.de>, "Marius.Cristea@...rochip.com"
	<Marius.Cristea@...rochip.com>
CC: Linux-Arch <linux-arch@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v1] asm-generic: introduce be56 unaligned accessors

From: Arnd Bergmann
> Sent: 07 October 2024 15:45
> On Mon, Oct 7, 2024, at 14:40, Marius.Cristea@...rochip.com wrote:
> > On Sun, 2024-09-29 at 21:16 +0000, David Laight wrote:
> >> [You don't often get email from david.laight@...lab.com. Learn why
> >> this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> EXTERNAL EMAIL: Do not click links or open attachments unless you
> >> know the content is safe
> >>
> >> From: marius.cristea@...rochip.com
> >> > Sent: 27 September 2024 09:36
> >> >
> >> > The PAC194X, IIO driver, is using some unaligned 56 bit registers.
> >> > Provide some helper accessors in preparation for the new driver.
> >>
> >> Someone please shoot the hardware engineer ;-)
> >>
> >> Do separate unaligned access of the first 4 bytes and last four
> >> bytes.
> >> It can't matter if the middle byte is accessed twice.
> >>
> >> Or, for reads read 8 bytes from 'p & ~1ul' and then fixup
> >> the value.
> >>
> >
> > Do you recommend me to drop this patch?
> >
> > I know that there are some "workarounds", but those didn't "looks"
> > nice. I was using that function locally and I got a suggestion from the
> > IIO subsystem maintainer to move it into the kernel in order for others
> > to used it.
> 
> My feeling is that this is too specific to one driver, I don't
> expect it to be shared much. I also suspect that most 56-bit
> integers in data structures are actually always part of a naturally
> aligned 64-bit word. If that is the case here, the driver can
> probably better access it as a normal 64-bit number and mask
> out the upper 56 bits using the include/linux/bitfield.h helpers.

Or get the compiler to do it for you.
This DTRT https://www.godbolt.org/z/GMdePjYMY:

struct foo {
    unsigned long a;
    unsigned char b;
    unsigned long c:56 __attribute__((packed));
    unsigned long d;
};

Although you'll need #define htobe56(x) (htobe64(x) >> 8) on LE.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)