+++ This bug was initially created as a clone of Bug #643500 +++ Description of problem: With stack-guard kernel patch lvm2 now sometimes reports Internal error: - where map sizes for memory locking and unlocking mismatch (which would be sign of wrong internal behaviour) - however with recent kernel changes it looks like we could read some lines twice if using single read/lock loop. This problem has been already fixed upstream: http://www.redhat.com/archives/lvm-devel/2010-October/msg00129.html Problem itself isn't serious - but users my get very confused by scary messages: Internal error: Maps lock 14270464 < unlock 14274560 Internal error: Maps lock 14274560 < unlock 14278656 Internal error: Maps lock 14278656 < unlock 14282752 Version-Release number of selected component (if applicable): kernel-2.6.18-226.el5 How reproducible: Steps to Reproduce: 1. bug is rather time depended 2. 3. Actual results: Expected results: Additional info: Bug is going to be fixed with next release of lvm2 package for Fedora
Version-Release number of selected component is really: kernel-2.6.34.7-56.fc13.x86_64.rpm
For fc13 kernel - problem is probably more related to this Bug #638525
"You are not authorized to access bug #638525."
Bugzilla is about missing upstream patch in stable kernels: --- Prevent inconsistencies in /proc/maps (which LVM2 reads to decide which memory to mlock/munlock). This patch was added upstream after the recent guard page changes that protect against security concerns (BZ 607859). commit 39aa3cb3e8250db9188a6f1e3fb62ffa1a717678 Author: Stefan Bader <stefan.bader> Date: Tue Aug 31 15:52:27 2010 +0200 mm: Move vma_stack_continue into mm.h So it can be used by all that need to check for that. Signed-off-by: Stefan Bader <stefan.bader> Signed-off-by: Linus Torvalds <torvalds> ---
Is this fixed now?
This problem should be currently fixed in Rawhide for the lvm side - there should be no report in mismatching mlock/munlock sizes. However I'm not particularly sure there isn't some other problem for now. Using attachment from Bug 638525 gives currently this with 2.6.38 kernel: interesting cut from the output: mlock 12KiB 7fbde93e7000-7fbde93ea000 rw-p 00000000 00:00 0 mlock 4KiB 7fbde9415000-7fbde9416000 rw-p 00000000 00:00 0 mlock 4KiB 7fbde9416000-7fbde9417000 rw-p 00000000 00:00 0 mlock 4KiB 7fbde9417000-7fbde9418000 rw-p 00000000 00:00 0 mlock 4KiB 7fbde9418000-7fbde9419000 r--p 00020000 08:02 391790 /lib64/ld-2.13.90.so mlock 4KiB 7fbde9419000-7fbde941a000 rw-p 00021000 08:02 391790 /lib64/ld-2.13.90.so mlock 4KiB 7fbde941a000-7fbde941b000 rw-p 00000000 00:00 0 mlock 0KiB 7ffff65e9000-7ffff65e9000 rw-p 00000000 00:00 0 mlock 132KiB 7ffff65e9000-7ffff660a000 rw-p 00000000 00:00 0 [stack] ---- munlock 12KiB 7fbde93e7000-7fbde93ea000 rw-p 00000000 00:00 0 munlock 8KiB 7fbde9415000-7fbde9417000 rw-p 00000000 00:00 0 munlock 4KiB 7fbde9417000-7fbde9418000 rw-p 00000000 00:00 0 munlock 4KiB 7fbde9418000-7fbde9419000 r--p 00020000 08:02 391790 /lib64/ld-2.13.90.so munlock 4KiB 7fbde9419000-7fbde941a000 rw-p 00021000 08:02 391790 /lib64/ld-2.13.90.so munlock 4KiB 7fbde941a000-7fbde941b000 rw-p 00000000 00:00 0 munlock 132KiB 7ffff65e9000-7ffff660a000 rw-p 00000000 00:00 0 [stack] As could be seen - the total sum of pages is matching - however line entries seems to be splited without obvious reason. (Same could be observed with enabled debug for lvm2 functions). For LVM2 side I think this bug can be closed as fixed upstream.
(In reply to comment #6) > This problem should be currently fixed in Rawhide for the lvm side - there > should be no report in mismatching mlock/munlock sizes. Then close it. > For LVM2 side I think this bug can be closed as fixed upstream. This is a *kernel* bugzilla not lvm2.