On Tue, Mar 06, 2007 at 08:54:55AM -0800, Nishanth Aravamudan wrote:
> On 06.03.2007 [16:55:14 +1100], David Gibson wrote:
> > On Mon, Mar 05, 2007 at 09:44:01PM -0800, Nishanth Aravamudan wrote:
> > > On 06.03.2007 [16:33:22 +1100], David Gibson wrote:
> > > > On Mon, Mar 05, 2007 at 07:10:16PM -0800, Nishanth Aravamudan wrote:
> > > > > On 06.03.2007 [11:54:04 +1100], David Gibson wrote:
> > > > > > On Mon, Mar 05, 2007 at 11:58:00AM -0800, Nishanth Aravamudan wrote:
> > > > > > > On 05.03.2007 [15:35:05 +1100], David Gibson wrote:
> > > > > > > > On Sat, Mar 03, 2007 at 09:44:31PM -0800, Nishanth Aravamudan
> > > > > > > > wrote:
> > > > > > > > > On 04.03.2007 [10:23:00 +1100], David Gibson wrote:
> > > > > > > > > > On Sat, Mar 03, 2007 at 01:38:52PM -0800, Nishanth
> > > > > > > > > > Aravamudan wrote:
> > > > > > > > > > > On 03.03.2007 [17:44:48 +1100], David Gibson wrote:
> > > > > > > > > > > > On Fri, Mar 02, 2007 at 05:14:14PM -0800, Nishanth
> > > > > > > > > > > > Aravamudan wrote:
> > > > > > [snip]
> > > > > > > > But... I've just thought some more. And I think we can work
> > > > > > > > around
> > > > > > > > this problem with similar linker tricks to the ones I was using
> > > > > > > > when I
> > > > > > > > had the syscall()-statically-linked-from-libc almost working.
> > > > > > > > But now
> > > > > > > > that we'll be compiling the arch specific code in question with
> > > > > > > > -fPIC
> > > > > > > > ourselves, the problems that arose there should be gone.
> > > > > > >
> > > > > > > Ok, are you going to spin up some patches then?
> > > > > >
> > > > > > Yeah, started working on it yesterday, will keep going today.
> > > > >
> > > > > Great, thanks.
> > > >
> > > > Ok, here's a first draft. This gets unmapped_abort() working
> > > > correctly on ppc32, ppc64 and i386. x86_64 is untested (don't have a
> > > > machine handy). sparc64 and ia64 will not build with this version,
> > > > because there isn't a stub for them yet.
> > >
> > > I should be able to test x86_64 in the morning here.
> >
> > Note that to actually test the unmapped_abort() code, you'll need to
> > insert some code into the elflink path so that it thinks the remapping
> > has failed.
>
> Yep, I gathered as much. I might head into the office after class, so I
> may not be able to test until later today. But it will be done before
> EOD.
Actually, I've been working from home today, and have now tested this
on my home amd64 machine. There was a typo in that patch (%rcd
instead of %rcx), but once that's fixed it seems to work.
I also have a couple more patches fixing testcase problems on i386 and
x86_64. First, I've fixed a problem with task-size-overrun - on
recent kernels the stack is not necssarily the highest mapping, which
broke that testcase's determination of TASK_SIZE.
Second, I've fixed icache-hygeine for i386 (and made it more robust
for x86_64). The problem is that there are two possible ways we can
blow up in the PASS() case, but I was only checking for one of them.
Which case happens in practice depends on the details of gcc's code
generation (a specific register value at the point where we jump into
the cleared hugepage) which explains why it worked when I first wrote
this test, but is broken now.
Patches coming shortly.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
