Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 448238 - [PATCH] <sys-fs/lvm2-2.02.99: mlock fails on ARM
Summary: [PATCH] <sys-fs/lvm2-2.02.99: mlock fails on ARM
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: ARM Linux
: Normal normal (vote)
Assignee: Robin Johnson
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2012-12-22 22:51 UTC by Matija "hook" Šuklje
Modified: 2013-09-12 20:53 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matija "hook" Šuklje 2012-12-22 22:51:42 UTC
On recent kernels, the current stable LVM2 on ARM causes such as:
   ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]: mlock failed: Cannot allocate memory
   ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]: munlock failed: Cannot allocate memory

The fix is a very simple one-liner that will be included into 2.02.99, but for any older versions the patch should be applied.

Apparently, lvm2 tries to mlock/munlock all readable maps it finds in "proc/self/maps", i.e also the "[vectors]" page.  Between 3.0 and 3.4 there has been the change f9d4861f "ARM: 7294/1: vectors: use gate_vma for vectors user
mapping", which might have changed the behaviour when mlocking vectors.

Bug described on:
https://www.redhat.com/archives/linux-lvm/2012-June/msg00019.html

A one-liner patch on (will be included in sys-fs/lvm2-2.02.99):
https://www.redhat.com/archives/lvm-devel/2012-November/msg00039.html
Comment 1 Matija "hook" Šuklje 2012-12-22 23:30:42 UTC
I tried the patch manually and it works fine.

Changing back to critical, as upstream says without it, LVM2 is unusable on some ARM arches.
Comment 2 Markos Chandras (RETIRED) gentoo-dev 2012-12-24 09:49:29 UTC
Please don't re-assign the severity of the bugs. It's the maintainer who needs to decide that.
Comment 3 Matija "hook" Šuklje 2012-12-24 12:42:06 UTC
(In reply to comment #2)
> Please don't re-assign the severity of the bugs. It's the maintainer who
> needs to decide that.

I was not aware of that. Sorry, will not do it again.
Comment 4 Ján Ondrušek 2013-04-08 08:38:48 UTC
I created an ebuild with mentioned one-liner fix and now I'm getting this:

 vgchange -a y
  device-mapper: resume ioctl on  failed: Invalid argument
  Unable to resume data--vg-data (254:0)
  1 logical volume(s) in volume group "data-vg" now active

lvm version  
  LVM version:     2.02.98(2) (2012-10-15)
  Library version: 1.02.77 (2012-10-15)
  Driver version:  4.23.0

Could you please post more info about how did you manage it to work?
Thanks
Comment 5 Matija "hook" Šuklje 2013-04-16 09:56:12 UTC
(In reply to comment #4)
> I created an ebuild with mentioned one-liner fix and now I'm getting this:
> 
>  vgchange -a y
>   device-mapper: resume ioctl on  failed: Invalid argument
>   Unable to resume data--vg-data (254:0)
>   1 logical volume(s) in volume group "data-vg" now active
> 
> lvm version  
>   LVM version:     2.02.98(2) (2012-10-15)
>   Library version: 1.02.77 (2012-10-15)
>   Driver version:  4.23.0
> 
> Could you please post more info about how did you manage it to work?
> Thanks

I vaguely recall there was something with the `vgchange -a y`, but I think ultimately it was just that it worked even if it complained at start.
Comment 6 Samuli Suominen gentoo-dev 2013-09-12 20:53:05 UTC
As per $subject with <2.02.99 it implies 2.02.99 is fixed. Also, 2.02.100 is now in Portage.
No need to keep this bug open, next stabilization will take care of this.