From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UchPj-0004LA-L2 for user-mode-linux-devel@lists.sourceforge.net; Wed, 15 May 2013 19:31:03 +0000 Received: from mout.gmx.net ([212.227.17.21]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UchPh-0007Wg-Lk for user-mode-linux-devel@lists.sourceforge.net; Wed, 15 May 2013 19:31:03 +0000 Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Me67s-1UsbhW0Ozu-00PrKH for ; Wed, 15 May 2013 21:30:56 +0200 Message-ID: <5193E26E.90003@gmx.de> Date: Wed, 15 May 2013 21:30:54 +0200 From: =?UTF-8?B?VG9yYWxmIEbDtnJzdGVy?= MIME-Version: 1.0 References: <518FB97A.5070907@gmx.de> <518FBE6A.50605@gmx.de> <518FE33B.60701@gmx.de> <518FF354.7020408@gmx.de> <518FFBA3.6000800@gmx.de> <51901400.4060302@gmx.de> <5193DCA7.1070708@gmx.de> In-Reply-To: List-Id: The user-mode Linux development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: user-mode-linux-devel-bounces@lists.sourceforge.net Subject: Re: [uml-devel] WARNING: at mm/mmap.c:2757 exit_mmap+0x161/0x170() To: richard -rw- weinberger Cc: "user-mode-linux-devel@lists.sourceforge.net" , trinity@vger.kernel.org T24gMDUvMTUvMjAxMyAwOToxMSBQTSwgcmljaGFyZCAtcnctIHdlaW5iZXJnZXIgd3JvdGU6Cj4g T24gV2VkLCBNYXkgMTUsIDIwMTMgYXQgOTowNiBQTSwgVG9yYWxmIEbDtnJzdGVyIDx0b3JhbGYu Zm9lcnN0ZXJAZ214LmRlPiB3cm90ZToKPj4gT24gMDUvMTMvMjAxMyAwOToxMiBBTSwgcmljaGFy ZCAtcnctIHdlaW5iZXJnZXIgd3JvdGU6Cj4+PiBUaGlzIGxvb2tzIGxpa2UgYW5vdGhlciBpc3N1 ZS4KPj4+IEFyZSB5b3UgdGVzdGluZyBwcm9jZXNzX3ZtX3dyaXRldigpIHdpdGggdHJpbml0eT8K Pj4+IExvb2tzIGxpa2UgaXQgbWFuYWdlZCB0byBvdmVyd3JpdGUgdGhlIHN0dWIgcGFnZSBvZiBh IHByb2Nlc3MsIHdoaWNoCj4+PiBpcyBub3QgZ29vZC4KPj4gbm9wZSwgaXQgaXMgdGhlIG1yZW1h cCBzeXNjYWxsLgo+Pgo+PiBBIGNvbW1hbmQgbGlrZQo+Pgo+PiAkPnRyaW5pdHkgLWMgbXJlbWFw IC1OIDEwCj4+Cj4+IGltbWVkaWF0ZWx5IGFmdGVyIHN0YXJ0aW5nIGEgMzIgYml0IEdlbnRvbyBs aW51eCBndWVzdCB3aXRoIGN1cnJlbnQga2VybmVsIDMuMTAtcmMxLS4uLiArCj4+IHN0cm5sZW4g KyBzdHViNCBwYXRjaCB3b3JrcywgYnV0IGxhdGVyIGEKPj4KPj4gJD50cmluaXR5IC1jIG1yZW1h cCAtTiAxMDAwCj4+Cj4+IHlpZWxkcyBpbnRvCj4+Cj4+IDIwMTMtMDUtMTVUMjE6MDI6MDQuMDYx KzAyOjAwIHRyaW5pdHkga2VybmVsOiBTdHViIHJlZ2lzdGVycyAtCj4+IDIwMTMtMDUtMTVUMjE6 MDI6MDQuMDYxKzAyOjAwIHRyaW5pdHkga2VybmVsOiAgIDAgLSAxMDAwMDAKPj4gMjAxMy0wNS0x NVQyMTowMjowNC4wNjErMDI6MDAgdHJpbml0eSBrZXJuZWw6ICAgMSAtIDMwMDAwMAo+PiAyMDEz LTA1LTE1VDIxOjAyOjA0LjA2MSswMjowMCB0cmluaXR5IGtlcm5lbDogICAyIC0gMAo+PiAyMDEz LTA1LTE1VDIxOjAyOjA0LjA2MSswMjowMCB0cmluaXR5IGtlcm5lbDogICAzIC0gMAo+PiAyMDEz LTA1LTE1VDIxOjAyOjA0LjA2MSswMjowMCB0cmluaXR5IGtlcm5lbDogICA0IC0gMAo+PiAyMDEz LTA1LTE1VDIxOjAyOjA0LjA2MSswMjowMCB0cmluaXR5IGtlcm5lbDogICA1IC0gMAo+PiAyMDEz LTA1LTE1VDIxOjAyOjA0LjA2MSswMjowMCB0cmluaXR5IGtlcm5lbDogICA2IC0gMAo+PiAyMDEz LTA1LTE1VDIxOjAyOjA0LjA2MSswMjowMCB0cmluaXR5IGtlcm5lbDogICA3IC0gN2IKPj4gMjAx My0wNS0xNVQyMTowMjowNC4wNjErMDI6MDAgdHJpbml0eSBrZXJuZWw6ICAgOCAtIDdiCj4+IDIw MTMtMDUtMTVUMjE6MDI6MDQuMDY1KzAyOjAwIHRyaW5pdHkga2VybmVsOiAgIDkgLSAwCj4+IDIw MTMtMDUtMTVUMjE6MDI6MDQuMDY1KzAyOjAwIHRyaW5pdHkga2VybmVsOiAgIDEwIC0gMzMKPj4g MjAxMy0wNS0xNVQyMTowMjowNC4wNjUrMDI6MDAgdHJpbml0eSBrZXJuZWw6ICAgMTEgLSBmZmZm ZmZmZgo+PiAyMDEzLTA1LTE1VDIxOjAyOjA0LjA2NSswMjowMCB0cmluaXR5IGtlcm5lbDogICAx MiAtIDEwMDBjMwo+PiAyMDEzLTA1LTE1VDIxOjAyOjA0LjA2NSswMjowMCB0cmluaXR5IGtlcm5l bDogICAxMyAtIDczCj4+IDIwMTMtMDUtMTVUMjE6MDI6MDQuMDY1KzAyOjAwIHRyaW5pdHkga2Vy bmVsOiAgIDE0IC0gMTAyMDYKPj4gMjAxMy0wNS0xNVQyMTowMjowNC4wNjUrMDI6MDAgdHJpbml0 eSBrZXJuZWw6ICAgMTUgLSAxMDEwMjgKPj4gMjAxMy0wNS0xNVQyMTowMjowNC4wNjUrMDI6MDAg dHJpbml0eSBrZXJuZWw6ICAgMTYgLSA3Ygo+PiAyMDEzLTA1LTE1VDIxOjAyOjA0LjA2NSswMjow MCB0cmluaXR5IGtlcm5lbDogd2FpdF9zdHViX2RvbmUgOiBmYWlsZWQgdG8gd2FpdCBmb3IgU0lH VFJBUCwgcGlkID0gMTU2OTIsIG4gPSAxNTY5MiwgZXJybm8gPSAwLCBzdGF0dXMgPSAweGI3Zgo+ Pgo+PiBhbmQgbm93IHRoYXQgcHJvY2VzcyBjYW4ndCBiZSBraWxsZWQgLSBJIGhhZCB0byBzdG9w IHRoZSBVTUwgZ3Vlc3QuCj4gCj4gSG1tLCB5b3UndmUgcmVtYXBwZWQgdGhlIHN0dWIgcGFnZSBh bmQgdGhlcmVmb3JlIHRoZSBwcm9jZXNzIGJyb2tlLgo+IEkgdGhpbmsgaXQgd291bGQgbWFrZSBz ZW5zZSB0byBraWxsIHRoZSBwcm9jZXNzIGluIHN0ZWFkIG9mIHdyaXRpbmcKPiB0aGUgIndhaXRf c3R1Yl9kb25lIC4uLiIgbWVzc2FnZS4KPiBDaGFuZ2luZyB0aGUgc3R1YiBwYWdlIGlzIGFzIGRl c3RydWN0aXZlIHRoYW4gb3ZlcndyaXRpbmcgdGhlIHN0YWNrLgoKVW5mb3J0dW5hdGVseSBubyB0 cmluaXR5IHByb2Nlc3MgY2FuIGJlIGtpbGxlZCBhcyBzb29uIGFzIHRoYXQgaGFwcGVuLgpOZWl0 aGVyIHBncmVwLCBwa2lsbCwgbm9yICJwcyAtZWZsYSIgZG8gcmV0dXJuIGFueSByZXN1bHQuCktp bGxpbmcgYW55IG9mIHRob3NlIHByb2Nlc3NlcyBieSBpdHMgcGlkIHdvbid0IHdvcmsgdG9vLgoK PiBNYXliZSB3ZSBjYW4gdGVhY2ggdHJpbml5IHRvIG5vIGNoYW5nZSB0aGUgc3R1YiBwYWdlLgo+ IEknbSBzdXJlIHRyaW5pdHkgaGFzIGFsc28gYSBtZWNoYW5pc20gdG8gbm90IGRlc3Ryb3kgdGhl IHN0YWNrLgoKQHRyaW5pdHkgTWFpbGluZyBsaXN0CglXaGF0IGRvIHlvdSB0aGluayBhYm91dCB0 aGF0ID8KCi0tIApNZkcvU2luY2VyZWx5ClRvcmFsZiBGw7Zyc3RlcgpwZ3AgZmluZ2VyIHByaW50 OiA3QjFBIDA3RjQgRUM4MiAwRjkwIEQ0QzIgODkzNiA4NzJBIEU1MDggN0RCNiA5REEzCgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KQWxpZW5WYXVsdCBVbmlmaWVkIFNlY3VyaXR5IE1hbmFnZW1lbnQg KFVTTSkgcGxhdGZvcm0gZGVsaXZlcnMgY29tcGxldGUKc2VjdXJpdHkgdmlzaWJpbGl0eSB3aXRo IHRoZSBlc3NlbnRpYWwgc2VjdXJpdHkgY2FwYWJpbGl0aWVzLiBFYXNpbHkgYW5kCmVmZmljaWVu dGx5IGNvbmZpZ3VyZSwgbWFuYWdlLCBhbmQgb3BlcmF0ZSBhbGwgb2YgeW91ciBzZWN1cml0eSBj b250cm9scwpmcm9tIGEgc2luZ2xlIGNvbnNvbGUgYW5kIG9uZSB1bmlmaWVkIGZyYW1ld29yay4g RG93bmxvYWQgYSBmcmVlIHRyaWFsLgpodHRwOi8vcC5zZi5uZXQvc2Z1L2FsaWVudmF1bHRfZDJk Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClVzZXItbW9k ZS1saW51eC1kZXZlbCBtYWlsaW5nIGxpc3QKVXNlci1tb2RlLWxpbnV4LWRldmVsQGxpc3RzLnNv dXJjZWZvcmdlLm5ldApodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5m by91c2VyLW1vZGUtbGludXgtZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?VG9yYWxmIEbDtnJzdGVy?= Subject: Re: [uml-devel] WARNING: at mm/mmap.c:2757 exit_mmap+0x161/0x170() Date: Wed, 15 May 2013 21:30:54 +0200 Message-ID: <5193E26E.90003@gmx.de> References: <518FB97A.5070907@gmx.de> <518FBE6A.50605@gmx.de> <518FE33B.60701@gmx.de> <518FF354.7020408@gmx.de> <518FFBA3.6000800@gmx.de> <51901400.4060302@gmx.de> <5193DCA7.1070708@gmx.de> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: trinity-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" To: richard -rw- weinberger Cc: "user-mode-linux-devel@lists.sourceforge.net" , trinity@vger.kernel.org On 05/15/2013 09:11 PM, richard -rw- weinberger wrote: > On Wed, May 15, 2013 at 9:06 PM, Toralf F=C3=B6rster 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, whic= h >>> 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 : faile= d to wait for SIGTRAP, pid =3D 15692, n =3D 15692, errno =3D 0, status = =3D 0xb7f >> >> and now that process can't be killed - I had to stop the UML guest. >=20 > 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 ? --=20 MfG/Sincerely Toralf F=C3=B6rster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3