NetBSD Problem Report #52598
From www@NetBSD.org Sat Oct 7 09:03:15 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 1D5577A1FA
for <gnats-bugs@gnats.NetBSD.org>; Sat, 7 Oct 2017 09:03:15 +0000 (UTC)
Message-Id: <20171007090314.5FE2B7A2B3@mollari.NetBSD.org>
Date: Sat, 7 Oct 2017 09:03:14 +0000 (UTC)
From: coypu@sdf.org
Reply-To: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Subject: /proc/self/exe misbehaves if it's on a null mount
X-Send-Pr-Version: www-1.0
>Number: 52598
>Category: kern
>Synopsis: /proc/self/exe misbehaves if it's on a null mount
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Oct 07 09:05:00 +0000 2017
>Closed-Date: Mon Jan 27 19:46:05 +0000 2020
>Last-Modified: Mon Jan 27 19:46:05 +0000 2020
>Originator: coypu
>Release: NetBSD 8.99.2
>Organization:
>Environment:
NetBSD localhost 8.99.2 NetBSD 8.99.2 (GENERIC) #1: Fri Sep 1 02:38:58 IDT 2017 fly@loggy:/home/fly/x86/sys/arch/amd64/compile/GENERIC amd64
>Description:
# mount -t null /rescue /mnt
# /rescue/ls -l /proc/self/exe
lr-xr-xr-x 1 root wheel 10 Oct 7 11:55 /proc/self/exe -> /rescue/ls
# /mnt/ls -l /proc/self/exe
lr-xr-xr-x 1 root wheel 1 Oct 7 11:55 /proc/self/exe -> /
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sat, 09 Dec 2017 21:49:00 +0000
State-Changed-Why:
Fixed by christos.
From: Pierre Pronchery <khorben@defora.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Thu, 17 Jan 2019 16:37:20 +0100
On 09/12/2017 22:49, maya@NetBSD.org wrote:
> Synopsis: /proc/self/exe misbehaves if it's on a null mount
>
> State-Changed-From-To: open->closed
> State-Changed-By: maya@NetBSD.org
> State-Changed-When: Sat, 09 Dec 2017 21:49:00 +0000
> State-Changed-Why:
> Fixed by christos.
Any chance this could be pulled up to the relevant stable branches?
I am hitting this on netbsd-8.
Cheers,
--
khorben
State-Changed-From-To: closed->needs-pullups
State-Changed-By: maya@NetBSD.org
State-Changed-When: Fri, 18 Jan 2019 01:15:29 +0000
State-Changed-Why:
we have a state for this, unfortunately it will need investigation to find the exact combination of commits...
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: Pierre Pronchery <khorben@defora.org>, maya@NetBSD.org,
christos@NetBSD.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Mon, 13 Jan 2020 23:23:27 +0100
I tried to apply the changes made by christos to introduce p_path in
struct proc to netbsd-8-0-RELEASE:
cvs rdiff -u -r1.197.2.2 -r1.200 src/sys/miscfs/procfs/procfs_vnops.c
cvs rdiff -u -r1.340.6.1 -r1.343 src/sys/sys/proc.h
Now I get the following behavior:
# ls -l /proc/curproc
lr-xr-xr-x 1 root wheel 2 Jan 13 23:09 /proc/curproc -> 49
# ls -l /proc/curproc/
causes a fatal page fault.
The backtrace I got using crash(1):
# crash -M netbsd.9.core
Crash version 8.0, image version 8.0.
System panicked: trap
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
?() at ffff800064978000
vpanic() at vpanic+0x166
snprintf() at snprintf
trap() at trap+0xa00
--- trap (number 6) ---
strlen() at strlen+0x20
VOP_GETATTR() at VOP_GETATTR+0x4d
vn_stat() at vn_stat+0x3d
do_sys_statat() at do_sys_statat+0x89
sys___lstat50() at sys___lstat50+0x25
syscall() at syscall+0x1ec
--- syscall (number 441) ---
7f5df9ca17ba:
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Mon, 13 Jan 2020 18:17:14 -0500
there are many more changes needed I think in the exec code. can you reprodu=
ce the crash on head or 9?
christos
> On Jan 13, 2020, at 5:35 PM, Fr=C3=A9d=C3=A9ric Fauberteau <triaxx@netbsd.=
org> wrote:
>=20
> =EF=BB=BFThe following reply was made to PR kern/52598; it has been noted b=
y GNATS.
>=20
> From: =3D?UTF-8?Q?Fr=3DC3=3DA9d=3DC3=3DA9ric_Fauberteau?=3D <triaxx@NetBSD=
.org>
> To: gnats-bugs@NetBSD.org
> Cc: Pierre Pronchery <khorben@defora.org>, maya@NetBSD.org,
> christos@NetBSD.org
> Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount=
)
> Date: Mon, 13 Jan 2020 23:23:27 +0100
>=20
> I tried to apply the changes made by christos to introduce p_path in=20
> struct proc to netbsd-8-0-RELEASE:
> cvs rdiff -u -r1.197.2.2 -r1.200 src/sys/miscfs/procfs/procfs_vnops.c
> cvs rdiff -u -r1.340.6.1 -r1.343 src/sys/sys/proc.h
>=20
> Now I get the following behavior:
> # ls -l /proc/curproc
> lr-xr-xr-x 1 root wheel 2 Jan 13 23:09 /proc/curproc -> 49
> # ls -l /proc/curproc/
> causes a fatal page fault.
>=20
> The backtrace I got using crash(1):
> # crash -M netbsd.9.core
> Crash version 8.0, image version 8.0.
> System panicked: trap
> Backtrace from time of crash is available.
> crash> bt
> _KERNEL_OPT_NARCNET() at 0
> ?() at ffff800064978000
> vpanic() at vpanic+0x166
> snprintf() at snprintf
> trap() at trap+0xa00
> --- trap (number 6) ---
> strlen() at strlen+0x20
> VOP_GETATTR() at VOP_GETATTR+0x4d
> vn_stat() at vn_stat+0x3d
> do_sys_statat() at do_sys_statat+0x89
> sys___lstat50() at sys___lstat50+0x25
> syscall() at syscall+0x1ec
> --- syscall (number 441) ---
> 7f5df9ca17ba:
>=20
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: Christos Zoulas <christos@zoulas.com>, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Tue, 14 Jan 2020 05:42:25 +0100
Le 2020-01-14 00:17, Christos Zoulas a écrit :
> there are many more changes needed I think in the exec code. can you
> reproduce the crash on head or 9?
>
> christos
I did not test on 9 and I think there is no issue. I want to make the
exec code work on 8 because I think it fixes pkg/53244 too.
Yes, there are. And you kindly list the files here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/proc.h?rev=1.343&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
Fred
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Tue, 14 Jan 2020 05:57:55 +0100
Le 2020-01-14 05:42, Frédéric Fauberteau a écrit :
> Yes, there are. And you kindly list the files here:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/proc.h?rev=1.343&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
So I continue my investigations and tests following this way.
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, coypu@sdf.org,
christos@netbsd.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Tue, 14 Jan 2020 22:10:18 +0100
Le 2020-01-14 06:00, Frédéric Fauberteau a écrit :
> The following reply was made to PR kern/52598; it has been noted by
> GNATS.
>
> From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
> To: Christos Zoulas <christos@zoulas.com>
> Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
> netbsd-bugs@netbsd.org, coypu@sdf.org
> Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null
> mount)
> Date: Tue, 14 Jan 2020 05:57:55 +0100
>
> Le 2020-01-14 05:42, Frédéric Fauberteau a écrit :
> > Yes, there are. And you kindly list the files here:
> >
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/proc.h?rev=1.343&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>
> So I continue my investigations and tests following this way.
Ok, by applying these changes, I have a NetBSD 8.0 that can mount a
working /proc in a chroot environment:
cvs rdiff -u -r1.90.4.1 -r1.93 src/sys/kern/exec_elf.c
cvs rdiff -u -r1.442.4.3 -r1.450 src/sys/kern/kern_exec.c
cvs rdiff -u -r1.268.8.1 -r1.270 src/sys/kern/kern_exit.c
cvs rdiff -u -r1.202 -r1.203 src/sys/kern/kern_fork.c
cvs rdiff -u -r1.206.6.4 -r1.208 src/sys/kern/kern_proc.c
cvs rdiff -u -r1.63 -r1.64 src/sys/kern/subr_kmem.c
cvs rdiff -u -r1.197.2.2 -r1.200 src/sys/miscfs/procfs/procfs_vnops.c
cvs rdiff -u -r1.151 -r1.152 src/sys/sys/exec.h
cvs rdiff -u -r1.9 -r1.10 src/sys/sys/kmem.h
cvs rdiff -u -r1.542.2.4 -r1.550 src/sys/sys/param.h
cvs rdiff -u -r1.340.6.1 -r1.343 src/sys/sys/proc.h
I should be able to build lang/rust with pbulk in a chrooted sandbox. I
am testing.
But I fear it is not possible to submit a pullup request since a bump
revision seems to be done for these changes (8.99.6 if I am correct). Do
you confirm?
Fred
From: christos@zoulas.com (Christos Zoulas)
To: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>,
gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Tue, 14 Jan 2020 17:31:52 -0500
On Jan 14, 10:10pm, triaxx@NetBSD.org (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?=) wrote:
-- Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount
| > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/proc.h?rev=1.343&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
| >
| > So I continue my investigations and tests following this way.
|
| Ok, by applying these changes, I have a NetBSD 8.0 that can mount a
| working /proc in a chroot environment:
| cvs rdiff -u -r1.90.4.1 -r1.93 src/sys/kern/exec_elf.c
| cvs rdiff -u -r1.442.4.3 -r1.450 src/sys/kern/kern_exec.c
| cvs rdiff -u -r1.268.8.1 -r1.270 src/sys/kern/kern_exit.c
| cvs rdiff -u -r1.202 -r1.203 src/sys/kern/kern_fork.c
| cvs rdiff -u -r1.206.6.4 -r1.208 src/sys/kern/kern_proc.c
| cvs rdiff -u -r1.63 -r1.64 src/sys/kern/subr_kmem.c
| cvs rdiff -u -r1.197.2.2 -r1.200 src/sys/miscfs/procfs/procfs_vnops.c
| cvs rdiff -u -r1.151 -r1.152 src/sys/sys/exec.h
| cvs rdiff -u -r1.9 -r1.10 src/sys/sys/kmem.h
| cvs rdiff -u -r1.542.2.4 -r1.550 src/sys/sys/param.h
| cvs rdiff -u -r1.340.6.1 -r1.343 src/sys/sys/proc.h
|
| I should be able to build lang/rust with pbulk in a chrooted sandbox. I
| am testing.
|
| But I fear it is not possible to submit a pullup request since a bump
| revision seems to be done for these changes (8.99.6 if I am correct). Do
| you confirm?
Well, you need a kernel bump because sizeof(struct proc) changes...
This would probably be put on 8.2...
christos
From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: =?iso-8859-1?Q?Fr=E9d=E9ric?= Fauberteau <triaxx@NetBSD.org>,
gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Wed, 15 Jan 2020 09:06:02 +0100
On Tue, Jan 14, 2020 at 05:31:52PM -0500, Christos Zoulas wrote:
> Well, you need a kernel bump because sizeof(struct proc) changes...
> This would probably be put on 8.2...
This would prevent pullup according to current releng policies.
We can make exceptions and document them carefully in case that are
considered extremely important, as the main idea behind the rule is
to prevent binaries compiled for newer netbsd-8 to not work on (say)
NetBSD 8.1.
This change is userland visible, and kmem users may break. It is not clear
to me if the what exactly the amount of breakage would be and if the
benefit of the change would be higher.
I have not followed the thread closely from the beginning, is this about
ld.elf_so's ORIGIN handling? I thought we don't rely on that in pkgsrc
rust anyway (past bootstrap).
Martin
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Wed, 15 Jan 2020 10:16:34 +0100
Le 2020-01-15 09:10, Martin Husemann a écrit :
> I have not followed the thread closely from the beginning, is this
> about
> ld.elf_so's ORIGIN handling? I thought we don't rely on that in pkgsrc
> rust anyway (past bootstrap).
I though I suffered from pkg/53348 or pkg/53671 on NetBSD 8.0. I though
that backport the fix of kern/52598 should fix them. I need this host
since it build sets of custom packages for several domU running 8.0.
Otherwise, I would have updated it to 9.0_RC1.
Unfortunately, the system just crashes during a bulk build (when
building lang/spidermonkey52) with the following backtrace:
# crash -M netbsd.10.core
Crash version 8.0, image version sys/arch/amd64/c.
WARNING: versions differ, you may not be able to examine this image.
System panicked: trap
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
?() at ffff800065288000
log() at log+0x9c
vlog() at vlog+0x51
trap() at trap+0xa00
--- trap (number 6) ---
memmove() at memmove+0x10
VOP_LOCK() at VOP_LOCK+0x13
do_sys_symlinkat.isra.4() at do_sys_symlinkat.isra.4+0x1a5
syscall() at syscall+0x1ec
--- syscall (number 58) ---
792a4923e20a:
I admit I don't understand the WARNING message.
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Wed, 15 Jan 2020 07:59:05 -0500
--Apple-Mail=_331AE787-3AEB-41E3-9D6A-533C532DC7D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On Jan 15, 2020, at 4:20 AM, Fr=C3=A9d=C3=A9ric Fauberteau =
<triaxx@NetBSD.org> wrote:
[stuff deleted]
>=20
> I admit I don't understand the WARNING message.
>=20
The warning is about crash being compiled against what it thinks is a =
different
version of the kernel. This crash is strange; are you using any modules? =
If you
do, you need to recompile them and re-install them because you changed =
struct proc...
Make sure that you have a clean compile (and install) of the kernel and =
modules and see if
you can reproduce this.
christos
--Apple-Mail=_331AE787-3AEB-41E3-9D6A-533C532DC7D0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCXh8MmQAKCRBxESqxbLM7
OtioAKDn6kqANkJJ6hwlLu3S9aGlohFYEgCgkQ8LPyIkogksSMmVLFA3kzSySHY=
=ePB6
-----END PGP SIGNATURE-----
--Apple-Mail=_331AE787-3AEB-41E3-9D6A-533C532DC7D0--
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: Christos Zoulas <christos@zoulas.com>, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Wed, 15 Jan 2020 17:20:53 +0100
Le 2020-01-15 13:59, Christos Zoulas a écrit :
>> On Jan 15, 2020, at 4:20 AM, Frédéric Fauberteau <triaxx@NetBSD.org>
>> wrote:
>
> [stuff deleted]
>>
>> I admit I don't understand the WARNING message.
>>
>
> The warning is about crash being compiled against what it thinks is a
> different
> version of the kernel. This crash is strange; are you using any
> modules? If you
> do, you need to recompile them and re-install them because you changed
> struct proc...
> Make sure that you have a clean compile (and install) of the kernel
> and modules and see if
> you can reproduce this.
>
> christos
I do not use module. To compile and install system, I use the following
commands:
# sysbuild build (with INCREMENTAL_BUILD="yes")
# sysupgrade auto
Do I rebuild with INCREMENTAL_BUILD="no"?
Thank you Christos,
Fred
From: christos@zoulas.com (Christos Zoulas)
To: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>,
gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Wed, 15 Jan 2020 13:54:11 -0500
On Jan 15, 5:20pm, triaxx@NetBSD.org (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?=) wrote:
-- Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount
| Le 2020-01-15 13:59, Christos Zoulas a écrit :
| >> On Jan 15, 2020, at 4:20 AM, Frédéric Fauberteau <triaxx@NetBSD.org>
| >> wrote:
| >
| > [stuff deleted]
| >>
| >> I admit I don't understand the WARNING message.
| >>
| >
| > The warning is about crash being compiled against what it thinks is a
| > different
| > version of the kernel. This crash is strange; are you using any
| > modules? If you
| > do, you need to recompile them and re-install them because you changed
| > struct proc...
| > Make sure that you have a clean compile (and install) of the kernel
| > and modules and see if
| > you can reproduce this.
| >
| > christos
|
| I do not use module. To compile and install system, I use the following
| commands:
| # sysbuild build (with INCREMENTAL_BUILD="yes")
| # sysupgrade auto
|
| Do I rebuild with INCREMENTAL_BUILD="no"?
Yes, I would try that (this will make clean first).
christos
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Fri, 17 Jan 2020 07:09:13 +0100
Le 2020-01-15 19:55, christos@zoulas.com a écrit :
> Yes, I would try that (this will make clean first).
>
> christos
I rebuilt the system by making clean first but it still crashes. It
seems deterministic since the crash occurs when configuring
lang/spidermonkey52 with the following backtrace:
# crash -M netbsd.2.core
Crash version 8.0, image version 8.0.
System panicked: trap
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
?() at ffff800064ba8000
vpanic() at vpanic+0x166
snprintf() at snprintf
trap() at trap+0xa00
--- trap (number 6) ---
strlcpy() at strlcpy+0x16
execve_runproc() at execve_runproc+0x27c
execve1() at execve1+0x3f
syscall() at syscall+0x1ec
--- syscall (number 59) ---
717f9b23e4aa:
The verbose log of lang/spidermonkey52 configuration:
http://pkg.triaxx.org/pub/pkgsrc/logs/devel/spidermonkey52/spidermonkey52-52.7.4/configure.log
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Fauberteau?= <triaxx@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, coypu@sdf.org
Subject: Re: kern/52598 (/proc/self/exe misbehaves if it's on a null mount)
Date: Sun, 19 Jan 2020 21:58:04 +0100
The following change fix the crash:
-cvs rdiff -u -r1.442.4.3 -r1.450 src/sys/kern/kern_exec.c
+cvs rdiff -u -r1.442.4.3 -r1.454 src/sys/kern/kern_exec.c
Before the christos modifications, lang/rust building failed on NetBSD
8.0 when done in a chroot environment:
--- stderr
thread 'main' panicked at 'failed to get current_exe: /proc/curproc/exe
doesn't point to regular file.',
src/librustc/session/filesearch.rs:167:23
Now, it builds successfully:
$ ls -1 /mnt/ccd0/sandbox/nbsd8-hydralisk/pkg/All | grep rust
rust-1.40.0.tgz
The current status of this PR is 'needs-pullups'. What could we do to
close it?
My personal need is to have a 8.0 able to build bulk sets of packages
for several 8.0 domU. If theses changes can only be integrated in 8.2, I
finally should upgrade all my 8.0 to 8.2. I would to avoid upgrading but
if I have to do, I might as well do it to 9.0. So I can continue while
waiting with my custom 8.0. Is there a need to add this fix in a future
8.X release? In this case, what should I provide to contribute?
State-Changed-From-To: needs-pullups->closed
State-Changed-By: triaxx@NetBSD.org
State-Changed-When: Mon, 27 Jan 2020 19:46:05 +0000
State-Changed-Why:
Coud not be pulled-up: christos' fixes change the kernel ABI.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home