> The problem was that pagecache data on the NFS client was showing
> incorrect chunks of several k's of zeroes. No particuar alignment,
> either. And it only happened when the machine is under page-replacement
> pressure. And only when the machine has highmem.
>
> It'd be nice to understand _why_ it fixed it. Do we know why NFS
> was losing data when using KM_USER0? As far as I can see the new
> and old code look pretty darn similar. Interested.
Anton's Oops showed that kmap_atomic(page, KM_USER0) is sometimes failing to
return an address, something that we cannot accept in a networking bottom
half (performance and reliability would suck if we had to delay and retry).
That indicates that something is calling kmap_atomic() and then getting
interrupted before it can call kunmap_atomic().
in the *_highpage() helper routines in include/linux/highmem.h. These
routines are used in various places, but are usually not protected against
(soft and hard) interrupts or kernel pre-emption. Could it be that the latter
is what is causing trouble?
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/