Re: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb

[James Bottomley <James.Bottomley@steeleye.com>]

On Tue, 2004-04-06 at 08:21, Carlos O'Donell wrote:
> What was the fix? Can you explain the change please? :)

copy_to_user_page() does the copy via a non-equivalently aliased kernel
page.  Unless that page is flushed at the kernel address, the writeback
cache may not make the data visible (which is why gdb wasn't able to set
breakpoints anymore).

For some reason every arch implements copy_to_user_page as a memcpy
followed by flush_icache_user_range().  The usually map
flush_icache_user_range() to a kernel dcache page flush, which is
contradictory.

> The glibc test-suite almost completed without issue on the newest
> kernel, though I saw a transient failure in one of the resolv tests, it
> wasn't a failure in the test, but rather the test ran longer than 2
> seconds and was killed. The test uses mtrace() and I've not been able to
> duplicate the failure, the test should *not* have run over the
> milisecond mark.  I wasn't running anything on the box at that point so
> it worries me quite a bit. With the box up and running I'm no longer
> able to trigger the slow behaviour that caused the timeout. Previous to
> this I had run the entire compile + testsuite from a clean boot, I'll
> see if doing that again triggers the failure. It might not be related to
> anything you've done, I don't think I've ever run a glibc build and
> testsuite from a cold boot... who knows what VM issues lurk?

It's possible.  As global flushes get removed any lurking holes in the
rest of the API will emerge when they stop being covered by the global
flush.

James