Messages in this thread | | | Date | Thu, 2 Oct 2003 17:51:16 -0700 | From | Mike Fedyk <> | Subject | Re: 2.4.23pre6aa1 |
| |
On Thu, Oct 02, 2003 at 05:26:48PM +0200, Andrea Arcangeli wrote: > Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1 > > This fixes a longstanding bug for a number of archs that haven't the > dirty bit updated in hardware. For those archs we can't mark the pte > writeable when it's still in swap cache, unless we don't mark it dirty > too at the same time. Otherwise the cpu will go ahead writing to the > page, no fault will happen and the swapcache will be still clean, and > the data will be lost at the next zeroIO swapout leading to userspace > data corruption and segfaults during swap. Affected archs are > alpha/s390/s390x for example. > > This bug was specific to the -aa VM, it couldn't happen > in mainline. In my tree I optimized the code to exploited > properties of archs that updates the bit in hardware for the > first time. Hence the first need of a #define to differentiate the > two code paths. The logic in the software-dirty-bit case will > be less efficient of course (that's why there's a difference > in the first place).
What does rmap do in this case then? - 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/
| |