Bug 643834

Summary:	lvm could report Internal error: Maps lock for some operation
Product:	[Fedora] Fedora	Reporter:	Zdenek Kabelac <zkabelac>
Component:	kernel	Assignee:	Zdenek Kabelac <zkabelac>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	agk, bmarzins, bmr, cristian.ciupitu, dwysocha, gansalmon, heinzm, itamar, jonathan, kernel-maint, lvm-team, madhu.chinakonda, mbroz, msnitzer, prajnoha, prockai
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	643500	Environment:
Last Closed:	2011-06-17 10:40:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Zdenek Kabelac 2010-10-18 09:16:07 UTC

+++ 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

Comment 1 Cristian Ciupitu 2010-10-18 12:36:26 UTC

Version-Release number of selected component is really:
kernel-2.6.34.7-56.fc13.x86_64.rpm

Comment 2 Zdenek Kabelac 2010-10-18 12:47:35 UTC

For fc13 kernel - problem is probably more related to this  Bug #638525

Comment 3 Cristian Ciupitu 2010-10-18 13:36:06 UTC

"You are not authorized to access bug #638525."

Comment 4 Zdenek Kabelac 2010-10-18 13:54:37 UTC

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>
---

Comment 5 Alasdair Kergon 2011-02-09 20:24:53 UTC

Is this fixed now?

Comment 6 Zdenek Kabelac 2011-02-11 10:41:42 UTC

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.

Comment 7 Alasdair Kergon 2011-02-11 12:05:53 UTC

(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.