linux-kernel - Re: [PATCH] ubi: kill homegrown endian macros

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]

Date:	Fri, 18 May 2007 11:17:54 +0800
From:	David Woodhouse <dwmw2@...radead.org>
To:	"John Anthony Kazos Jr." <jakj@...-k-j.com>
Cc:	Matthieu CASTET <castet.matthieu@...e.fr>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ubi: kill homegrown endian macros

On Thu, 2007-05-17 at 22:57 -0400, John Anthony Kazos Jr. wrote:
> Wouldn't the appropriate test be to demonstrate that the same program text 
> opcodes are generated in both cases for all architectures? 

No, empirical testing with the compiler is never the _correct_ thing to
do. It's just expedient.

> If that's not the case, even if the generation isn't -worse-, it shows
> that the compiler is doing different things with each, which means
> different versions of the compiler could do different things with it,

Well yes, but even it _is_ generating precisely the same output today,
there's no reason why the compiler shouldn't behave differently under a
different phase of the moon.

The _correct_ thing to do is act upon my mutterings at the time I
removed the '__attribute__((packed))' from various JFFS2 structures to
improve the generated code on ARM -- actually implement an attribute for
GCC which has the same "don't insert any padding" meaning, but without
the unwanted "assume arbitrary alignment" implications.

It'd actually be nice if GCC knew about endianness too. I don't want to
have to do:

   *x = le32_to_cpu(cpu_to_le32(*x) + 5);

I just want 

  uint32_t __attribute__((littleendian)) *x;

  *x += 5;

I know we can hack around it for masks, with '*x |= cpu_to_le32(X_BAR);'
and such like, and we can load it into local native-endian variables and
then copy it back again later -- but it's better just to let the
compiler know what's going on and do its own optimisation. Especially on
architectures which have 'load-and-swap' or 'store-and-swap'
instructions.

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/