All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: xen-devel <xen-devel@lists.xen.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: domU panic on nested call to arch_enter_lazy_mmu_mode()
Date: Wed, 10 Apr 2013 11:35:35 -0400 (EDT)	[thread overview]
Message-ID: <1476610678.2256112.1365608135270.JavaMail.root@redhat.com> (raw)
In-Reply-To: <1167409089.2244980.1365606532813.JavaMail.root@redhat.com>

Hi all,

A couple years ago a thread[1] popped up here for a bug report that
Jeremy followed up to with this patch[2]. That patch was never
committed though (likely because the issue was difficult to
reproduce/test). We've got a report now of the same issue for the
rhel6 kernel running on EC2. It's pretty certain that it's the same,
because the reproducer steps[3] given would certainly generate the
same call sequences shown in [1], and applying the proposed patch[2]
to the rhel6 kernel fixes it.

Now, while the grant table code has changed some between what rhel6
has and recent kernels, I believe the issue should still be present
with recent kernels. However, we attempted to reproduce using a
Fedora18 kernel (>3.8) and could not. So I'm writing to see if I'm
missing something in my analysis - meaning upstream is no longer at
risk of hitting this bug, and/or if Jeremy's proposed patch was
rejected for other reasons than not being testable (or just
forgotten). If not, then I'd suggest we repost it.

Thanks,
drew

[1] http://lists.xen.org/archives/html/xen-devel/2010-12/msg00440.html
[2] http://lists.xen.org/archives/html/xen-devel/2010-12/msg00505.html
[3] Reproducer steps
1. Start a instance which is a c1.xlarge of Amazon EC2 Instance type.
   (c1.xlarge has 8 cores)

2. create 7 file systems(ext3) on top of Amazon EBS volumes 

3. mount 7 file sytemes you created

4. For increasing page table operations, create a following program

--
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main(void)
{
        int status;
        pid_t pid; 
        for (;;) {
                pid = fork();
                if (pid == 0) {
                        return 0;
                }
                wait(&status);
        }
}
--

5. run the program  pinning CPU0

# gcc fork.c
# taskset -c 0 ./a.out  


6. For using grant table, execute simultaneous write operation to 7 EBS volumes.
  ( c1.xlarge can use 8CPU so execute simultaneous write to CPU1-CPU7 except CPU0 )

For instance:
--
for i in `seq 1 7`;
do
        taskset -c $i dd if=/dev/zero of=/mnt/$i/testfile bs=10M count=10000 oflag=direct &
done

       reply	other threads:[~2013-04-10 15:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1167409089.2244980.1365606532813.JavaMail.root@redhat.com>
2013-04-10 15:35 ` Andrew Jones [this message]
2013-05-03 13:03   ` domU panic on nested call to arch_enter_lazy_mmu_mode() Konrad Rzeszutek Wilk

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=1476610678.2256112.1365608135270.JavaMail.root@redhat.com \
    --to=drjones@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xen.org \
    /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.