linux-kernel - Re: [PATCH 22/37] move round

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] [day] [month] [year] [list]

Message-Id: <20100125172616.85c9eff2.akpm@linux-foundation.org>
Date:	Mon, 25 Jan 2010 17:26:16 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH 22/37] move round_up/down to kernel.h

On Mon, 25 Jan 2010 16:58:10 -0800
"H. Peter Anvin" <hpa@...or.com> wrote:

> On 01/25/2010 04:40 PM, Andrew Morton wrote:
> > 
> > The problem is that arch/x86/include/asm/proto.h implements private
> > rounding macros.  The right way to fix that is to convert each x86
> > "call site" over to using the standard macros from kernel.h, then
> > finally remove the private definitions from
> > arch/x86/include/asm/proto.h.  Don't just copy them over to kernel.h
> > and make things muddier than they already are!
> > 
> > If during that conversion it is found that the standard macros for some
> > reason don't suit the x86 usage sites then please propose
> > enhancements/fixes to the existing kernel.h facilities.
> > 
> 
> They don't.
> 
> The kernel-global alignment macros assume that either the alignment
> datum (divisor) is a constant, or that it is acceptable to take the hit
> of a division.  Unfortunately, we have real use cases where the
> alignment (guaranteed to be a power of two) is variable, but we don't
> want to take the hit of a full-blown division.
> 
> I suspect the global kernel tree has those, too, but it would seem to be
> a dramatic change to change to change the existing facilities to assume
> power of two alignment...
> 

OK.  And yes, rounding up or down to a power-of-two alignment is surely
a common case.  The rounding-up case is already handled by ALIGN(), is it
not?

round_up() is a quite poor name for a facility which will quietly
fail if passed a non-power-of-2 argument!

So I'd suggest that we see a standalone patch which adds the
suitably-named and suitably-documented features to kernel.h.  I'd be OK
with merging such a patch into 2.6.33-rc, btw.

As there is probably a lot of code which would benefit from being
janitorially converted to these factilities, the patch should be
well-reviewed and not hidden in an x86 patchbomb!

There might be merit in adding a debug-only runtime check to ensure
that the alignment mask really is a power-of-two, to assist such
janitorial conversions, dunno.

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