NetBSD Problem Report #25664

Received: (qmail 9143 invoked by uid 605); 22 May 2004 03:13:47 -0000
Message-Id: <200405220313.i4M3Djfn024540@netbsd0.msu.montana.edu>
Date: Fri, 21 May 2004 21:13:45 -0600 (MDT)
From: mhitch@netbsd.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: mhitch@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: exec_sigcode_map() fails with OSF dynamically linked executables after uvm_map_findspace() changes
X-Send-Pr-Version: 3.95

>Number:         25664
>Category:       kern
>Synopsis:       OSF dynamically linked executables no longer work
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    chs
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 22 03:14:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Wed Nov 28 05:47:55 +0000 2018
>Originator:     Michael L. Hitch
>Release:        NetBSD 1.6ZC
>Organization:

>Environment:


System: NetBSD netbsd0 1.6ZC NetBSD 1.6ZC (GENERIC.MP) #23: Fri May 21 11:18:40 MDT 2004 mhitch@:/usr/staff/mhitch/200310030000/src/sys/arch/alpha/compile/GENERIC.MP alpha
Architecture: alpha
Machine: alpha
>Description:
	Since October 2003, OSF dynamically linked executables can no longer
	be run on alphas.  I ran into this several months ago, and after a brief
	look at the time, I couldn't determine what might be the problem.
	Since I needed to run a -current kernel to troubleshoot and fix another
	problem, I decided to take a look at this again.  The immediate symptom
	of the problem was a kernel panic from user-mode, which is documented
	in another PR, kern/25663.

	This PR is to document the problem that lead to the panics (fixing the
	panic to prevent users from crashing the system is separate from this
	problem, since the panics could potentially be caused by other problems)
	and provide a workaround fix.

	I tracked down the point in time when the OSF executables started failing
	to October 3, 2003 by changes in uvm_map_findspace().  I was able to
	to determine that uvm_map_findspace() had a bug prior to that time,
	and the fixing of that bug caused uvm_map() to fail in exec_sigcode_map().

	Previously, exec_sigcode_map() was added to support non-executable
	stacks by mapping the location for the trampoline separately outside
	the stack.  That mapping uses the data address of the program being
	started to locate where the trampoline code is mapped.  In the case
	of an OSF dynamically linked executable, that program is /bin/loader,
	the Tru64 equivalent of ld_elf.so.  Tru64 loads /bin/loader at the
	end of the user virtual memory space, so the hint of where to map
	the trampoline code ended up just after the last address of the
	user virtual memory.  Because of the bug in uvm_map_findspace(),
	it was mapping the trampoline code after the user VM and was able
	to function.  When uvm_map_findspace() was changed, that mapping
	was no longer valid, and exec_sigcode_map() would fail [which would
	cause a panic later because of another bug in sys_execve()].

>How-To-Repeat:
	Fix the problem documented in PR kern/25663 and attempt to run
	an OSF dynamically linked executable and watch it fail.

>Fix:
	I was able to get a workaround for this by checking of the
	hint VA was equal to the max_offset of the vm_map, and
	changing the hint VA to be prior to the text address of
	the program being started.  This totally ignores TOPDOWN, but
	does work on the alpha with the Tru64 /bin/loader.

Index: sys/kern/kern_exec.c
===================================================================
RCS file: /cvsroot/src/sys/kern/kern_exec.c,v
retrieving revision 1.185
diff -u -r1.185 kern_exec.c
--- sys/kern/kern_exec.c	26 Mar 2004 17:13:37 -0000	1.185
+++ sys/kern/kern_exec.c	22 May 2004 03:05:58 -0000
@@ -1324,6 +1326,9 @@

 	/* Just a hint to uvm_map where to put it. */
 	va = VM_DEFAULT_ADDRESS(p->p_vmspace->vm_daddr, round_page(sz));
+	if (va == (vaddr_t)p->p_vmspace->vm_map.max_offset) {
+		va = (vaddr_t)p->p_vmspace->vm_taddr - round_page(sz);
+	}
 	(*uobj->pgops->pgo_reference)(uobj);
 	error = uvm_map(&p->p_vmspace->vm_map, &va, round_page(sz),
 			uobj, 0, 0,
>Release-Note:
>Audit-Trail:

From: Chuck Silvers <chs@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:  
Subject: pr/25664 CVS commit: src/sys/kern
Date: Sun, 27 Jun 2004 00:55:08 +0000 (UTC)

 Module Name:	src
 Committed By:	chs
 Date:		Sun Jun 27 00:55:08 UTC 2004

 Modified Files:
 	src/sys/kern: kern_exec.c

 Log Message:
 add a workaround for PR 25664 (failure to map sigcode for Tru64 binaries).


 To generate a diff of this commit:
 cvs rdiff -r1.186 -r1.187 src/sys/kern/kern_exec.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.


From: Chuck Silvers <chuq@chuq.com>
To: mhitch@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/25664: exec_sigcode_map() fails with OSF dynamically linked executables after uvm_map_findspace() changes
Date: Sat, 26 Jun 2004 18:03:43 -0700

 hi michael,

 I committed your work-around for now.  this can probably be fixed
 more elegantly when the alpha gains support for topdown-vm.

 -Chuck

From: Havard Eidnes <he@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:  
Subject: pr/25664 CVS commit: [netbsd-2-0] src/sys/kern
Date: Sun, 27 Jun 2004 13:33:52 +0000 (UTC)

 Module Name:	src
 Committed By:	he
 Date:		Sun Jun 27 13:33:52 UTC 2004

 Modified Files:
 	src/sys/kern [netbsd-2-0]: kern_exec.c

 Log Message:
 Pull up revision 1.187 (requested by chs in ticket #558):
   Add a workaround for PR#25664, which describes a failure
   to map sigcode for Tru64 binaries.


 To generate a diff of this commit:
 cvs rdiff -r1.185.2.1 -r1.185.2.2 src/sys/kern/kern_exec.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: kern-bug-people->chs
Responsible-Changed-By: maya@NetBSD.org
Responsible-Changed-When: Wed, 28 Nov 2018 05:47:55 +0000
Responsible-Changed-Why:
Alpha has topdown-vm, but the ifdef is still there. Requesting more elegant fix, please :-)


>Unformatted:

Home	PR Database Search