On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > Hi Dima, > > > On 7 Feb 2024, at 18:27, Dima Kogan <dko...@debian.org> wrote: > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > bit, and it looks like it might have portability bug, at least on > > big-endian architectures. For instance: > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > these? > > The kernel expects a 4 byte write here, since unsigned long is defined as at > least 32 bit this shall work on all architectures. > > If your concern is about endianess this is not in the current scope of libuio > and needs to be addressed by a higher layer. > > I am very familiar with library and in close contact with upstream.
In the case of uio_disable_irq() the bug is nicely hidden by the fact that tmp is guaranteed to be all-zeroes. However, consider the previous function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, then the "tmp" variable's value of 1 will be encoded in memory as 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. When uio_enable_irq() calls write(..., &tmp, 4), it will only send the first four bytes to the kernel - and they are 0, 0, 0, and... 0. So it turns out that uio_disable_irq() and uio_enable_irq() do exactly the same - send a 32-bit zero value to the kernel. Is this the expected behavior indeed? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
