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: <alpine.LFD.2.00.0811261727200.3325@localhost.localdomain>
Date:	Wed, 26 Nov 2008 17:38:47 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	eranian@...il.com
cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, mingo@...e.hu, x86@...nel.org
Subject: Re: [patch 05/24] perfmon: X86 generic code (x86)

Stephane,

On Wed, 26 Nov 2008, stephane eranian wrote:
> > I have not yet found a good reason why it needs to use u64 instead of
> > using what's there already.
> >
> There is a good reason why we cannot use unsigned long. We must make sure
> all data structures exchanged between user mode and the kernel have fixed size.
> This way, we can have a 32-bit tool run unmodified on top of a 64-bit kernel AND
> we do not need trampoline code to marshall/unmarshall the parameters.

That's not a good reason at all. We have in kernel interfaces and
kernel-userspace interfaces. Making them the same is nice if it works,
but horrible if it imposes crappy hackery like the bitops wrappers.

> And yes, the abstraction for bitmask ops was introduced because of issues
> casting u64 -> unsigned long on Big-Endian32-bit machines such as PPC32.

Sorry, I think it is simply stupid.

You can keep the userspace interface u64 and use unsigned long for the
bitmasks in the kernel and take care of it in the user space interface
code and do the BE32 conversion when you copy stuff from and to user.

That's a single well defined place and does not add extra crappola
over the kernel especially not into hot pathes like the interrupt. 

Why do you want to do u64 -> u32 BE32 magic on every interrupt,
context switch etc., if you can do it once in the userspace interface ?

Thanks,

	tglx


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