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:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.