From: Zdenek Kabelac <zkabelac@redhat.com>
To: Simon Baatz <gmbnomis@gmail.com>
Cc: Thiago Jung Bauermann <thiago.bauermann@gmail.com>,
linux-arm-kernel@lists.infradead.org, linux-lvm@redhat.com
Subject: Re: [linux-lvm] Kernel 3.4 error on Dreamplug: [vectors]: mlock failed: Cannot allocate memory
Date: Mon, 11 Jun 2012 15:06:13 +0200 [thread overview]
Message-ID: <4FD5ED45.50208@redhat.com> (raw)
In-Reply-To: <20120610201625.GA26603@schnuecks.de>
Dne 10.6.2012 22:16, Simon Baatz napsal(a):
> Hi,
>
> [cross posted to linux-lvm, because I think it is a lvm problem]
>
> On Wed, May 30, 2012 at 03:06:23PM -0300, Thiago Jung Bauermann wrote:
>> I have just upgraded my Dreamplug to the 3.4 kernel, and when creating
>> an LVM snapshot volume, I see errors for which I didn't find any report
>> yet:
>>
>> # lvcreate -s -L 80M -n root-fsck-snapshot marv2-vg/root
>> ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
>> 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
>> ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
>> 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
>> Logical volume "root-fsck-snapshot" created
>>
>> Ironically, the main reason I upgraded the kernel from 3.0.0 was to get
>
> I see similar errors on an IB-NAS6210 box. 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.
>
> In LVM2, there is a list in lib/mm/memlock.c of maps to ignore:
>
> /* list of maps, that are unconditionaly ignored */
> static const char * const _ignore_maps[] = {
> "[vdso]",
> "[vsyscall]",
> };
>
> "[vdso]" seem to be based on gate_vma as well. Thus, I think
> "[vectors]" needs to be added to this list.
Opps - missed multilist posting - so again with all copies...
Yep, looks like simple patch to add.
Is there any other area which is missing ?
Zdenek
WARNING: multiple messages have this Message-ID (diff)
From: zkabelac@redhat.com (Zdenek Kabelac)
To: linux-arm-kernel@lists.infradead.org
Subject: Kernel 3.4 error on Dreamplug: [vectors]: mlock failed: Cannot allocate memory
Date: Mon, 11 Jun 2012 15:06:13 +0200 [thread overview]
Message-ID: <4FD5ED45.50208@redhat.com> (raw)
In-Reply-To: <20120610201625.GA26603@schnuecks.de>
Dne 10.6.2012 22:16, Simon Baatz napsal(a):
> Hi,
>
> [cross posted to linux-lvm, because I think it is a lvm problem]
>
> On Wed, May 30, 2012 at 03:06:23PM -0300, Thiago Jung Bauermann wrote:
>> I have just upgraded my Dreamplug to the 3.4 kernel, and when creating
>> an LVM snapshot volume, I see errors for which I didn't find any report
>> yet:
>>
>> # lvcreate -s -L 80M -n root-fsck-snapshot marv2-vg/root
>> ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
>> 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
>> ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
>> 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
>> Logical volume "root-fsck-snapshot" created
>>
>> Ironically, the main reason I upgraded the kernel from 3.0.0 was to get
>
> I see similar errors on an IB-NAS6210 box. 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.
>
> In LVM2, there is a list in lib/mm/memlock.c of maps to ignore:
>
> /* list of maps, that are unconditionaly ignored */
> static const char * const _ignore_maps[] = {
> "[vdso]",
> "[vsyscall]",
> };
>
> "[vdso]" seem to be based on gate_vma as well. Thus, I think
> "[vectors]" needs to be added to this list.
Opps - missed multilist posting - so again with all copies...
Yep, looks like simple patch to add.
Is there any other area which is missing ?
Zdenek
next prev parent reply other threads:[~2012-06-11 13:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-30 18:06 Kernel 3.4 error on Dreamplug: [vectors]: mlock failed: Cannot allocate memory Thiago Jung Bauermann
2012-05-31 0:51 ` Jason Cooper
2012-05-31 2:24 ` Thiago Jung Bauermann
2012-05-31 3:09 ` Jason Cooper
2012-05-31 4:32 ` Thiago Jung Bauermann
2012-05-31 13:31 ` Jason Cooper
2012-06-01 2:17 ` Thiago Jung Bauermann
2012-06-01 10:50 ` Jason Cooper
2012-06-10 20:16 ` [linux-lvm] " Simon Baatz
2012-06-10 20:16 ` Simon Baatz
2012-06-11 13:04 ` Zdenek Kabelac
2012-06-11 13:06 ` Zdenek Kabelac [this message]
2012-06-11 13:06 ` Zdenek Kabelac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD5ED45.50208@redhat.com \
--to=zkabelac@redhat.com \
--cc=gmbnomis@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-lvm@redhat.com \
--cc=thiago.bauermann@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.