All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toralf Förster" <toralf.foerster@gmx.de>
To: richard -rw- weinberger <richard.weinberger@gmail.com>
Cc: "user-mode-linux-devel@lists.sourceforge.net"
	<user-mode-linux-devel@lists.sourceforge.net>,
	trinity@vger.kernel.org
Subject: Re: [uml-devel] WARNING: at mm/mmap.c:2757 exit_mmap+0x161/0x170()
Date: Wed, 15 May 2013 21:30:54 +0200	[thread overview]
Message-ID: <5193E26E.90003@gmx.de> (raw)
In-Reply-To: <CAFLxGvxhDu6jVHZ0iOhjSBEfEY5JZRJ9xw0gxcduvuTR6BGOPg@mail.gmail.com>

On 05/15/2013 09:11 PM, richard -rw- weinberger wrote:
> On Wed, May 15, 2013 at 9:06 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>> On 05/13/2013 09:12 AM, richard -rw- weinberger wrote:
>>> This looks like another issue.
>>> Are you testing process_vm_writev() with trinity?
>>> Looks like it managed to overwrite the stub page of a process, which
>>> is not good.
>> nope, it is the mremap syscall.
>>
>> A command like
>>
>> $>trinity -c mremap -N 10
>>
>> immediately after starting a 32 bit Gentoo linux guest with current kernel 3.10-rc1-... +
>> strnlen + stub4 patch works, but later a
>>
>> $>trinity -c mremap -N 1000
>>
>> yields into
>>
>> 2013-05-15T21:02:04.061+02:00 trinity kernel: Stub registers -
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   0 - 100000
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   1 - 300000
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   2 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   3 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   4 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   5 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   6 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   7 - 7b
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   8 - 7b
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   9 - 0
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   10 - 33
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   11 - ffffffff
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   12 - 1000c3
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   13 - 73
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   14 - 10206
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   15 - 101028
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   16 - 7b
>> 2013-05-15T21:02:04.065+02:00 trinity kernel: wait_stub_done : failed to wait for SIGTRAP, pid = 15692, n = 15692, errno = 0, status = 0xb7f
>>
>> and now that process can't be killed - I had to stop the UML guest.
> 
> Hmm, you've remapped the stub page and therefore the process broke.
> I think it would make sense to kill the process in stead of writing
> the "wait_stub_done ..." message.
> Changing the stub page is as destructive than overwriting the stack.

Unfortunately no trinity process can be killed as soon as that happen.
Neither pgrep, pkill, nor "ps -efla" do return any result.
Killing any of those processes by its pid won't work too.

> Maybe we can teach triniy to no change the stub page.
> I'm sure trinity has also a mechanism to not destroy the stack.

@trinity Mailing list
	What do you think about that ?

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Toralf Förster" <toralf.foerster@gmx.de>
To: richard -rw- weinberger <richard.weinberger@gmail.com>
Cc: "user-mode-linux-devel@lists.sourceforge.net"
	<user-mode-linux-devel@lists.sourceforge.net>,
	trinity@vger.kernel.org
Subject: Re: [uml-devel] WARNING: at mm/mmap.c:2757 exit_mmap+0x161/0x170()
Date: Wed, 15 May 2013 21:30:54 +0200	[thread overview]
Message-ID: <5193E26E.90003@gmx.de> (raw)
In-Reply-To: <CAFLxGvxhDu6jVHZ0iOhjSBEfEY5JZRJ9xw0gxcduvuTR6BGOPg@mail.gmail.com>

On 05/15/2013 09:11 PM, richard -rw- weinberger wrote:
> On Wed, May 15, 2013 at 9:06 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>> On 05/13/2013 09:12 AM, richard -rw- weinberger wrote:
>>> This looks like another issue.
>>> Are you testing process_vm_writev() with trinity?
>>> Looks like it managed to overwrite the stub page of a process, which
>>> is not good.
>> nope, it is the mremap syscall.
>>
>> A command like
>>
>> $>trinity -c mremap -N 10
>>
>> immediately after starting a 32 bit Gentoo linux guest with current kernel 3.10-rc1-... +
>> strnlen + stub4 patch works, but later a
>>
>> $>trinity -c mremap -N 1000
>>
>> yields into
>>
>> 2013-05-15T21:02:04.061+02:00 trinity kernel: Stub registers -
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   0 - 100000
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   1 - 300000
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   2 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   3 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   4 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   5 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   6 - 0
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   7 - 7b
>> 2013-05-15T21:02:04.061+02:00 trinity kernel:   8 - 7b
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   9 - 0
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   10 - 33
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   11 - ffffffff
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   12 - 1000c3
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   13 - 73
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   14 - 10206
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   15 - 101028
>> 2013-05-15T21:02:04.065+02:00 trinity kernel:   16 - 7b
>> 2013-05-15T21:02:04.065+02:00 trinity kernel: wait_stub_done : failed to wait for SIGTRAP, pid = 15692, n = 15692, errno = 0, status = 0xb7f
>>
>> and now that process can't be killed - I had to stop the UML guest.
> 
> Hmm, you've remapped the stub page and therefore the process broke.
> I think it would make sense to kill the process in stead of writing
> the "wait_stub_done ..." message.
> Changing the stub page is as destructive than overwriting the stack.

Unfortunately no trinity process can be killed as soon as that happen.
Neither pgrep, pkill, nor "ps -efla" do return any result.
Killing any of those processes by its pid won't work too.

> Maybe we can teach triniy to no change the stub page.
> I'm sure trinity has also a mechanism to not destroy the stack.

@trinity Mailing list
	What do you think about that ?

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

  reply	other threads:[~2013-05-15 19:31 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-12 15:47 [uml-devel] WARNING: at mm/mmap.c:2757 exit_mmap+0x161/0x170() Toralf Förster
2013-05-12 15:58 ` richard -rw- weinberger
2013-05-12 16:08   ` Toralf Förster
2013-05-12 16:10     ` richard -rw- weinberger
2013-05-12 16:31       ` richard -rw- weinberger
2013-05-12 18:13         ` Toralf Förster
2013-05-12 18:45         ` Toralf Förster
2013-05-12 19:45           ` richard -rw- weinberger
2013-05-12 19:53             ` Toralf Förster
2013-05-12 19:56               ` richard -rw- weinberger
2013-05-12 20:29                 ` Toralf Förster
2013-05-12 20:31                   ` richard -rw- weinberger
2013-05-12 21:28                     ` richard -rw- weinberger
2013-05-12 22:13                       ` Toralf Förster
2013-05-13  7:12                         ` richard -rw- weinberger
2013-05-13 18:00                           ` Toralf Förster
2013-05-15 19:06                           ` Toralf Förster
2013-05-15 19:11                             ` richard -rw- weinberger
2013-05-15 19:30                               ` Toralf Förster [this message]
2013-05-15 19:30                                 ` Toralf Förster
2013-05-15 19:35                                 ` richard -rw- weinberger
2013-05-15 19:35                                   ` richard -rw- weinberger
2013-05-17 10:00                                   ` richard -rw- weinberger
2013-05-17 10:00                                     ` richard -rw- weinberger
2013-05-17 12:22                                     ` richard -rw- weinberger
2013-05-17 12:22                                       ` richard -rw- weinberger
2013-05-17 14:28                                       ` Toralf Förster
2013-05-17 14:28                                         ` Toralf Förster
2013-05-17 14:50                                         ` Richard RW. Weinberger
2013-05-17 14:50                                           ` Richard RW. Weinberger

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=5193E26E.90003@gmx.de \
    --to=toralf.foerster@gmx.de \
    --cc=richard.weinberger@gmail.com \
    --cc=trinity@vger.kernel.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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.