public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: Zdenek Kabelac <zkabelac@redhat.com>
Cc: chich21@mail.com, linux-kernel@vger.kernel.org, stable@kernel.org
Subject: Re: Linux kernel 2.6.34.7 lvm error
Date: Wed, 06 Oct 2010 14:29:50 +0100	[thread overview]
Message-ID: <4CAC79CE.4020800@canonical.com> (raw)
In-Reply-To: <4CA9D18F.7070003@redhat.com>

On 10/04/2010 02:07 PM, Zdenek Kabelac wrote:
> Dne 4.10.2010 10:46, Zdenek Kabelac napsal(a):
>> Dne 3.10.2010 11:56, chich21@mail.com napsal(a):
>>> With Linux kernel 2.6.34.7 from www.kernel.org the following error occurs.
>>>
>>> Issuing this command produces error.
>>>
>>> vgchange -ay
>>>
>>> outputs:
>>> Internal error: Maps lock 14317216 < unlock 14321312
>>>
>>> vgchange is part of lvm-tools.
>>>
>>> This doesn't happen with kernel 2.6.34 or 2.6.34.1 from www.kernel.org.
>>>
>>> Is there a patch for 2.6.34.x series coming for this error. As there is one
>>> for 2.6.35.x series.
>>>
>>> Please CC email me related posts.
>>
>>
>> Bug is related to stack guard fix - kernel 2.6.36-rc4 has this problem fixed.
>> Bug is present in 2.6.36-rc3 - so something between them fixes the problem.
>>
>> It looks like the [stack] mapping loses 1 page after each mlock/munlock cycle.
>> I'm probably going to play bisect game to find out missing fix.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=638525
>>
> 
> So - after bisecting - it seems that commit:
> 
> 39aa3cb3e8250db9188a6f1e3fb62ffa1a717678
> "mm: Move vma_stack_continue into mm.h"  by Stefan
> 
> had a nice 'bug-fixing' side effect which have not been mentioned in its
> description - it fixes misbehaving of mlock/munlock [stack] mapping size.
>

I have been asking for that to get picked up for stable (though no response,
yet). Unfortunately the better description (and the cc stable) got lost when
Linus merged two patches together).

The problem also might be related to the LVM version used (I could not see the
message with LVM2.02.54 with a kernel that still shows the gaps on the split
stack vma). But it definitely confuses anything that verifies the output of
/proc/<pid>/maps.

-Stefan

> So I assume this commit should be backported to stable kernels as well when
> there is stack-guard patch already added.
> 
> Cc: stable@
> 
> Zdenek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



      reply	other threads:[~2010-10-06 13:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-03  9:56 Linux kernel 2.6.34.7 lvm error chich21
2010-10-04  8:46 ` Zdenek Kabelac
2010-10-04 13:07   ` Zdenek Kabelac
2010-10-06 13:29     ` Stefan Bader [this message]

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=4CAC79CE.4020800@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=chich21@mail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=zkabelac@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox