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: <1227814545.5511.143.camel@brick>
Date:	Thu, 27 Nov 2008 11:35:44 -0800
From:	Harvey Harrison <harvey.harrison@...il.com>
To:	Anton Altaparmakov <aia21@....ac.uk>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH-mm 1/8] ntfs: remove private wrapper around endian
 helpers

On Thu, 2008-11-27 at 08:22 +0000, Anton Altaparmakov wrote:
> Hi,
> 
> On 26 Nov 2008, at 21:12, Harvey Harrison wrote:
> > The base versions handle constant folding just fine.
> > Done with sed other than the mft.c and inode.c one-liners.
> 
> Have you checked the compiler output?  And on all architectures?  And  
> on all gcc versions?

Yes I've checked the compiler output for the new byteorder helpers
for gcc 3.4, 4, 4.2 on x86.

Notice this depends on the byteorder bits in -mm.  The failure of
the old bits to properly compile-time swap I've only seen at -O0,
which the new bits do properly.  If you can cite a particular
version/arch that you know of where the bug arose, please let me
know.

> 
> The reason I introduced the constant version are precisely that at  
> least some versions of gcc at least on some architectures do NOT  
> handle the constant folding and actually put in endianness conversion  
> code for the constants instead of converting them at compile time.

Which ones....-O0 builds perhaps?

> 
> Also you are breaking sparse checking with this patch as you remove  
> some of the necessary endianness conversions (e.g. your one liner in  
> mft.c which causes us to apply a binary 'not' operator on a little  
> endian which sparse complains about - in fact that is the reason the  
> endianness conversions are in there in the first place - I added them  
> because sparse was complaining about them).

No, sparse does not complain about it.  Bitwise operations are just
fine on types such as le16 etc.  Try running sparse again with
my changes, there are no new warnings.

> 
> Andrew, please do not apply this patch.
> 

I hope you change you mind.

Harvey

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ