On Mon, Aug 26, 2013 at 03:08:45PM -0700, Hugh Dickins wrote: > > That said, google does find "swap_free: Unused swap offset entry" > > reports from over the years. Most of them seem to be single-bit > > errors, though (ie when the entry is 00000100 or similar I'm more > > inclined to blame a bit error > > Yes, historically they have usually represented either single-bit > errors, or corruption of page tables by other kernel data. The > swap subsystem discovers it, but it's rarely an error of swap. Just to rule out bad hardware, I've seen this on two systems (admittedly the exact same spec, but still..) > So I don't care for Dave's suggestion much earlier in this thread, > that swapoff should fail with -EINVAL if there has been a bad page > taint: that doesn't necessarily interfere with swapoff at all. > > And besides, swapoff is killable: yes, if counts go wrong, it > can cycle around endlessly, but it checks for signal_pending() > each time around the loop. It might be killable, but if I've done /sbin/reboot, and the kernel dies in sys_swapoff because of the corruption, I won't get a chance to kill it, because at that point the shutdown process has killed my shell, sshd, and just about everything else. It mieans a grumpy walk to the other side of the house to prod a reset button. So yeah, it might not be a mergable thing, but at least while bisecting it's pretty much a must-have. > I just did a quick diff of 3.11-rc7/mm against 3.10, and here's > a line in mremap which worries me. That set_pte_at() is operating > on anything that isn't pte_none(), so the pte_mksoft_dirty() looks > prone to corrupt a swap entry. > > I've not tried matching up bits with Dave's reports, and just going > into a meeting now, but this patch looks worth a try: probably Cyrill > can improve it meanwhile to what he actually wants there (I'm > surprised anything special is needed for just moving a pte). > > Hugh > > --- 3.11-rc7/mm/mremap.c 2013-07-14 17:10:16.640003652 -0700 > +++ linux/mm/mremap.c 2013-08-26 14:46:14.460027627 -0700 > @@ -126,7 +126,7 @@ static void move_ptes(struct vm_area_str > continue; > pte = ptep_get_and_clear(mm, old_addr, old_pte); > pte = move_pte(pte, new_vma->vm_page_prot, old_addr, new_addr); > - set_pte_at(mm, new_addr, new_pte, pte_mksoft_dirty(pte)); > + set_pte_at(mm, new_addr, new_pte, pte); > } I'll give this a shot once I'm done with the bisect. Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>