RFC: Page size on PPC/PPC64 builders

Lubomir Kundrak lkundrak at redhat.com
Sun Mar 2 19:18:48 UTC 2008


On Sun, 2008-03-02 at 13:59 +0000, David Woodhouse wrote:
> The PPC64 build hosts (which also build ppc32 packages) recently
> switched to RHEL5, and hence have 64KiB page size.
> 
> This is permitted by the PPC ABI, just as it is by the x86_64 ABI, and
> works perfectly well for almost everything.
> 
> Occasionally, however, it shows up some bugs in packages. This week, it
> found bug #435337, which is a generic bug and not really ppc-specific --
> although I won't enter the debate on whether it's a glibc bug or a bug
> with the programs which 'naively' expect pthread_attr_setstacksize() to
> actually set the stack size to the number they provide.
> 
> However, despite the fact that the majority of build failures on PPC
> actually demonstrate _generic_ bugs and not arch-specific bugs at all,
> some packagers don't bother to look -- they prefer to just exclude the
> 'offending' architecture and move on without checking to see what the
> problem is. And mutter to themselves that PPC is 'painful', despite the
> fact that it's helping to improve the quality of Fedora overall by
> finding their generic bugs. Primarily for that reason, I'm tempted to
> switch the PPC builders back to 4KiB pages.

If we going the way of not doing things that do expose bugs, we would
not ever randomize library load addresses, or use canaries on stack, or
check lengths of str*() arguments, etc... I would not be happy with
this :)

> I'm concerned that switching back to 4KiB pages is just papering over
> real bugs to make life easier for PPC folks. I suspect that what I
> should _actually_ do is keep it 64KiB, brazen it out and LART people who
> just exclude ppc builds without actually looking at the problem for
> themselves. But I'm lazy too... maybe we should switch the x86_64
> builders to 64KiB instead? :)

I never knew this is possible in x86_64 :)
Is there a strong reason against 64k pages there? :)

-- 
Lubomir Kundrak (Red Hat Security Response Team)




More information about the fedora-devel-list mailing list