re: CVS commit: src/sys/arch/aarch64/aarch64
> Log Message: > Fix build as crash(8); Protect db_md_meminfo_cmd() by defined(_KERNEL). thanks. surprised i never saw this as the change was in a tree for a few weeks, but i guess i was mostly doing kernels in that tree not full builds.. .mrg.
Re: CVS commit: src/sys/arch/powerpc/ibm4xx
On 2021/01/18 14:49, Rin Okuyama wrote:
(2) However, in clock.c rev 1.31 and prior, curcpu->ci_idepth was not
raised before calling {hard,stat}clock(). Therefore, cpu_intr_p()
wrongly returns false. As a result, callee functions misunderstood
that they are not running in the interrupt context.
1.31 --> 1.30
Sorry for bothering you many times...
rin
Re: CVS commit: src/sys/arch/powerpc/ibm4xx
On 2021/01/18 13:35, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Jan 18 04:35:05 UTC 2021
Modified Files:
src/sys/arch/powerpc/ibm4xx: clock.c
Log Message:
Invoke hardclock() and statclock() in the interrupt context.
Otherwise, entropy_enter() is used instead of entropy_enter_intr() in
statclock(), which results in KASSERT() failure.
To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/arch/powerpc/ibm4xx/clock.c
This message is somewhat misleading. I meant:
(1) Callers are interrupt handlers, therefore, {hard,stat}clock() are
apparently invoked in the interrupt context.
(2) However, in clock.c rev 1.31 and prior, curcpu->ci_idepth was not
raised before calling {hard,stat}clock(). Therefore, cpu_intr_p()
wrongly returns false. As a result, callee functions misunderstood
that they are not running in the interrupt context.
I have to improve my English writing skills ;-).
Thanks,
rin
Re: CVS commit: src/sys/compat/netbsd32
Hi Simon On 17/01/2021 11:26, Simon Burge wrote: On 15/01/2021 07:15, matthew green wrote: Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD and is the same struct on all BSD. While bringing the same functionality to IPv4, I elected to keep the same struct just to have the same API, warts and all. I like consistency. Does anyone else have an in_nbrinfo? I _think_ the "asked" member only seems to get assigned a 0 for ipv4, and with a long being 32-bits on any 32 bit platform making it a long instead of an int doesn't buy anything. No, it's currently unique to NetBSD. Other BSD's just don't have the infrastructure in their network for it either. I'll note that on a 64-bit platform it's 64 bits though so these do gains something. The value is similar to struct if_data counters really, so maybe it should be a uint64_t if you really want to change it. I would then argue that it might be better then to version it proper and move it out of compat32. I'm still keen to make this change (asked as an int instead of a long in in_nbrinfo) and announce a mini flag day for arp for -current users so that it's one less compat32 ioctl we have to maintain. I would just like arp to work without error. My personal preference would be to keep the same API and add compat. I've committed compat32 support for SIOCGNBRINFO_IN6 and in6_nbrinfo. Looks great! Also looks the same as what I did but couldn't get to work. Maybe I missed the netbsd32 on the long. Roy
Re: CVS commit: src/sys/dev/wscons
The change isn't wrong, but I booted the wrong kernel and it does not fix the aarch64 issue I am seeing. On Sun, 17 Jan 2021, Jared D. McNeill wrote: Module Name:src Committed By: jmcneill Date: Sun Jan 17 15:13:15 UTC 2021 Modified Files: src/sys/dev/wscons: wsdisplay_vconsvar.h Log Message: Add appropriate memory barriers around sc_busy accesses. Fixes an issue where character cells are sometimes not erased properly on aarch64 at boot. To generate a diff of this commit: cvs rdiff -u -r1.28 -r1.29 src/sys/dev/wscons/wsdisplay_vconsvar.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/compat/netbsd32
Hi Roy, Roy Marples wrote: > On 15/01/2021 07:15, matthew green wrote: > >> Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD > >> and is the same struct on all BSD. While bringing the same functionality to > >> IPv4, I elected to keep the same struct just to have the same API, warts > >> and all. I like consistency. Does anyone else have an in_nbrinfo? I _think_ the "asked" member only seems to get assigned a 0 for ipv4, and with a long being 32-bits on any 32 bit platform making it a long instead of an int doesn't buy anything. I'm still keen to make this change (asked as an int instead of a long in in_nbrinfo) and announce a mini flag day for arp for -current users so that it's one less compat32 ioctl we have to maintain. > > [ .. ] > >> > >> That breaks API/ABI though yes? As such it would require stuff in compat > >> anyway, but leaving it as it just needs n32 compat gunk instead which is > >> less impactful on other systems. > > > > in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can > > choose to break them in -current. there's a slight problem that -current > > has > > a minor flag day here, but it's not the compat issue you seem to think. > > CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2=text/x-cvsweb-markup_with_tag=netbsd-1-5 Sorry, I only checked the history of in_nbrinfo and just assumed that in6_nbrinfo was of a similar vintage. I've committed compat32 support for SIOCGNBRINFO_IN6 and in6_nbrinfo. Cheers, Simon.
re: CVS commit: src/share/man/man5
> Note that `entropy' is not an `rcvar' the way upsdriver is (if your ah! i missed this, and wasn't really even thinking about more than foo and foo_flags. thanks! .mrg.
re: CVS commit: src/sys/dev/acpi
"Jason R Thorpe" writes: > Module Name: src > Committed By: thorpej > Date: Sat Jan 16 01:23:04 UTC 2021 > > Modified Files: > src/sys/dev/acpi: tpm_acpi.c > > Log Message: > Match PNP0C31 as a TPM 1.2 device. Works on my ThinkPad X260, and > eliminates the last of the devices that attach to "isa". cool. now try to remove all the "at isa" devices in your config :-) (it explodes last i tried.)
Re: CVS commit: src/share/man/man5
On Sat, Jan 16, 2021 at 14:46:46 +1100, matthew green wrote: > > Log Message: > > Tweak wording for consistency: `if empty or not set', not `if unset'. > > is this correct? > > rc complains if unset or not set (ie, if "$foo" is zero length): > > /etc/rc.d/upsdriver: WARNING: $upsdriver is not set properly - see rc.conf(5). What Taylor said. The above warning reflects the status of checkyesnox() that checks that the value is yes/true/1 or no/false/0. -uwe
Re: CVS commit: src/share/man/man5
> Date: Sat, 16 Jan 2021 14:46:46 +1100 > from: matthew green > > > Log Message: > > Tweak wording for consistency: `if empty or not set', not `if unset'. > > is this correct? > > rc complains if unset or not set (ie, if "$foo" is zero length): > > /etc/rc.d/upsdriver: WARNING: $upsdriver is not set properly - see rc.conf(5). The allowed settings are: entropy=check entropy=wait entropy="" Note that `entropy' is not an `rcvar' the way upsdriver is (if your /etc/rc.d/upsdriver is pkgsrc/sysutils/ups-nut/files/upsdriver.sh). Compare, e.g., `domainname' or `hostname' in rc.conf(5).
re: CVS commit: src/share/man/man5
> Log Message: > Tweak wording for consistency: `if empty or not set', not `if unset'. is this correct? rc complains if unset or not set (ie, if "$foo" is zero length): /etc/rc.d/upsdriver: WARNING: $upsdriver is not set properly - see rc.conf(5). .mrg.
Re: CVS commit: src/sys/compat/netbsd32
On 15/01/2021 02:43, Simon Burge wrote: I'll test a bit more I can't actually test as my ERLite won't boot anymore. Console light is green, cu says I'm connected but I get nothing out of it. With cat5 cables plugged in the ports they flash green and then stick on amber. I'm guessing this is non recoverable :( If it is recoverable somehow I can put NetBSD back on it as I have a shiny new USG in it's place. Roy
Re: CVS commit: src/sys/compat/netbsd32
On 15/01/2021 07:15, matthew green wrote: Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD and is the same struct on all BSD. While bringing the same functionality to IPv4, I elected to keep the same struct just to have the same API, warts and all. I like consistency. [ .. ] That breaks API/ABI though yes? As such it would require stuff in compat anyway, but leaving it as it just needs n32 compat gunk instead which is less impactful on other systems. in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can choose to break them in -current. there's a slight problem that -current has a minor flag day here, but it's not the compat issue you seem to think. CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2=text/x-cvsweb-markup_with_tag=netbsd-1-5 Roy
re: CVS commit: src/sys/compat/netbsd32
> Oh, I quite agree. > However, in6_nbrinfo predates my involvement with NetBSD and is the same > struct > on all BSD. While bringing the same functionality to IPv4, I elected to keep > the > same struct just to have the same API, warts and all. I like consistency. [ .. ] > > That breaks API/ABI though yes? > As such it would require stuff in compat anyway, but leaving it as it just > needs > n32 compat gunk instead which is less impactful on other systems. in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can choose to break them in -current. there's a slight problem that -current has a minor flag day here, but it's not the compat issue you seem to think. with simon's proposed patch, the API doesn't change, so there no source compat issue to worry about either. this _only_ breaks -current in the last 4 months or so. i think we should do this, rather than add additional compat. we're allowed (and should!) fix -current issues like this. .mrg.
Re: CVS commit: src/sys/compat/netbsd32
On 15/01/2021 02:43, Simon Burge wrote: Hi Roy, Roy Marples wrote: On 14/01/2021 11:03, Simon Burge wrote: Sure, I will have a look. Anything IPv6 related I might need a helping hand to get a test case though :). As they share a similar structure, you solve one you likely solve the other. I can assume you have working IPv4 ;) In general where we can define the structure that are passed in an interface, regardless if it's a ioctl or sysctl or whatever, we should try to design the structure so that it's the same regardless of if it's built with 32-bit or 64-bit userlands. Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD and is the same struct on all BSD. While bringing the same functionality to IPv4, I elected to keep the same struct just to have the same API, warts and all. I like consistency. The issue with in_nbrinfo and in6_nbrinfo is that there's a "long" in the structure, so this has different sizes depending on your native long size. I _think_ this is the is value out of the la_asked member of struct llentry which is a uint16_t so we can just make it an int the your structures will align nicely. In both cases the ifname name is 16 bytes. For in_nbrinfo in_addr is effectively an int so we have just four ints after the ifname. For in6_nbrinfo the in6_addr is 128 bytes so aligns nicely, then a couple more ints after that. If "asked" is from struct llentry then the attached patch should work without requiring any compat32 support. If you're happy with this, I'll test a bit more then commit. That breaks API/ABI though yes? As such it would require stuff in compat anyway, but leaving it as it just needs n32 compat gunk instead which is less impactful on other systems. Roy
Re: CVS commit: src/sys/compat/netbsd32
Hi Roy,
Roy Marples wrote:
> On 14/01/2021 11:03, Simon Burge wrote:
> > Sure, I will have a look. Anything IPv6 related I might need a helping
> > hand to get a test case though :).
>
> As they share a similar structure, you solve one you likely solve the other.
> I can assume you have working IPv4 ;)
In general where we can define the structure that are passed in an
interface, regardless if it's a ioctl or sysctl or whatever, we should
try to design the structure so that it's the same regardless of if it's
built with 32-bit or 64-bit userlands. This is hard where you have
pointers, both otherwise is usually possible with a bit of planning.
You especially need to watch out for long which is a different size on
32-bit/64-bit userlands and also for int64_t which can align differently
depending on the architecture. If you can do a printf of the struct
size with a variety of arches and they're all the same then good! amd64,
i386, mips64 (n32), sparc would probably cover the range of cases to
test on (a compile test will do if you look at the generated code for
what is passed to printf). The general rule is if we can avoid touching
compat/netbsd32 then life is easier!
The issue with in_nbrinfo and in6_nbrinfo is that there's a "long" in
the structure, so this has different sizes depending on your native long
size.
I _think_ this is the is value out of the la_asked member of struct
llentry which is a uint16_t so we can just make it an int the your
structures will align nicely. In both cases the ifname name is 16
bytes. For in_nbrinfo in_addr is effectively an int so we have just
four ints after the ifname. For in6_nbrinfo the in6_addr is 128 bytes
so aligns nicely, then a couple more ints after that.
If "asked" is from struct llentry then the attached patch should work
without requiring any compat32 support. If you're happy with this, I'll
test a bit more then commit.
Cheers,
Simon.
Index: netinet/in_var.h
===
RCS file: /cvsroot/src/sys/netinet/in_var.h,v
retrieving revision 1.98
diff -d -p -u -r1.98 in_var.h
--- netinet/in_var.h11 Sep 2020 15:22:12 - 1.98
+++ netinet/in_var.h15 Jan 2021 02:18:01 -
@@ -118,7 +118,7 @@ struct in_ifaddr {
struct in_nbrinfo {
char ifname[IFNAMSIZ]; /* if name, e.g. "en0" */
struct in_addr addr;/* IPv4 address of the neighbor */
- longasked; /* number of queries already sent for this addr
*/
+ int asked; /* number of queries already sent for this addr
*/
int state; /* reachability state */
int expire; /* lifetime for NDP state transition */
};
Index: netinet6/nd6.h
===
RCS file: /cvsroot/src/sys/netinet6/nd6.h,v
retrieving revision 1.91
diff -d -p -u -r1.91 nd6.h
--- netinet6/nd6.h 11 Sep 2020 15:03:33 - 1.91
+++ netinet6/nd6.h 15 Jan 2021 02:18:01 -
@@ -83,7 +83,7 @@ struct nd_kifinfo {
struct in6_nbrinfo {
char ifname[IFNAMSIZ]; /* if name, e.g. "en0" */
struct in6_addr addr; /* IPv6 address of the neighbor */
- longasked; /* number of queries already sent for this addr
*/
+ int asked; /* number of queries already sent for this addr
*/
int isrouter; /* if it acts as a router */
int state; /* reachability state */
int expire; /* lifetime for NDP state transition */
Re: CVS commit: src/sys/compat/netbsd32
On 14/01/2021 11:03, Simon Burge wrote: Sure, I will have a look. Anything IPv6 related I might need a helping hand to get a test case though :). As they share a similar structure, you solve one you likely solve the other. I can assume you have working IPv4 ;) Roy
Re: CVS commit: src/distrib/sets/lists/debug
Module Name:src Committed By: pgoyette Date: Thu Jan 14 19:07:03 UTC 2021 Modified Files: src/distrib/sets/lists/debug: mi Log Message: /home/paul/XXX.txt Crap - meant to include the text file... Here's the good log info... Update sets lists to accomodate KERNEL_DIR. When both KERNEL_DIR and MKDEBUG are defined, we create an empty $DESTDIR/usr/libdata/debug/netbsd/ directory. Should fix ``build.sh release'' issue reported in kern/55923 XXX Since nothing ever seems to populate this directory, perhaps we should XXX simply prevent its creation? If we do create it, should its creation XXX perhaps be conditioned on MKKDEBUG rather than MKDEBUG? XXX There is still another problem with ``build.sh install-image'' but I XXX open a new PR for that. On Thu, 14 Jan 2021, Paul Goyette wrote: ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/sys/compat/netbsd32
Roy Marples wrote: > On 14/01/2021 08:00, Simon Burge wrote: > > Module Name:src > > Committed By: simonb > > Date: Thu Jan 14 08:00:45 UTC 2021 > > > > Modified Files: > > src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h > > > > Log Message: > > Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with compat32 now. > > XXX: FSSIOCSET50 and FSSIOCGET50 are not (yet) handled. > > Could I prompt you into looking at SIOCGNBRINFO (arp -a) and SIOCGNBRINFO_IN6 > (ndp -a) please? > > I could never get that working. Sure, I will have a look. Anything IPv6 related I might need a helping hand to get a test case though :). Cheers, Simon.
Re: CVS commit: src/sys/compat/netbsd32
On 14/01/2021 08:00, Simon Burge wrote: Module Name:src Committed By: simonb Date: Thu Jan 14 08:00:45 UTC 2021 Modified Files: src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h Log Message: Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with compat32 now. XXX: FSSIOCSET50 and FSSIOCGET50 are not (yet) handled. Could I prompt you into looking at SIOCGNBRINFO (arp -a) and SIOCGNBRINFO_IN6 (ndp -a) please? I could never get that working. Thanks Roy
Re: CVS commit: src/usr.bin/xlint/lint1
On 09.01.2021 17:42, Martin Husemann wrote: On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote: I guess a simple "make clean && make" will clear up the situation. Not quite, "make clean" will not remove the old ops.c file in the objdir, you need to manually kill it (or just remove all lint objdirs completely). Please add an entry to src/UPDATING, I would suggest something like: find $OBJDIR -type d -name \*lint\* | xargs rm -rf Thanks for the suggestion, I first did that. I was unsatisfied though that people would actively have to read src/UPDATING. Therefore, after reproducing the problem locally, I renamed ops.c to oper.c, after which the build ran successfully. Roland
Re: CVS commit: src/usr.bin/xlint/lint1
On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote: > I guess a simple "make clean && make" will clear up the situation. Not quite, "make clean" will not remove the old ops.c file in the objdir, you need to manually kill it (or just remove all lint objdirs completely). Please add an entry to src/UPDATING, I would suggest something like: find $OBJDIR -type d -name \*lint\* | xargs rm -rf Martin
Re: CVS commit: src/usr.bin/xlint/lint1
On 09.01.2021 12:42, Jared McNeill wrote: Not sure if it is this exact change, but I am no longer able to build tools on Ubuntu 20.04.1: --- lint1 --- # link lint1/lint1 /usr/bin/ld: ops.lo: in function `initmtab': ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN' That's weird for several reasons: 1. The word STRUCT_ASSIGN no longer appears in the whole source tree, as I removed the macro. 2. The compiler should have already caught this "implicit function declaration" with -Werror and never let the linker see this. I guess a simple "make clean && make" will clear up the situation. Roland
Re: CVS commit: src/usr.bin/xlint/lint1
Not sure if it is this exact change, but I am no longer able to build
tools on Ubuntu 20.04.1:
--- lint1 ---
# link lint1/lint1
cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-I/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/include/compat
-I/home/jmcneill/netbsd/cvs-src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1
-D_FILE_OFFSET_BITS=64
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1 -I.
-DPASS=\"lint1.h\"
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../arch/aarch64
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../common
-o lint1 cgram.lo decl.lo emit.lo emit1.lo err.lo func.lo init.lo
inittyp.lo main1.lo mem.lo mem1.lo ops.lo print.lo scan.lo tree.lo
tyname.lo
-L/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/lib
-lnbcompat -lrt -lz -lm
/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'
collect2: error: ld returned 1 exit status
*** [lint1] Error code 1
nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
1 error
nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
nbmake[2]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
*** Failed target: dependall-lint1
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/home/jmcneill/netbsd/cvs-src/tools" ;; *) this="${dir}/";
real="/home/jmcneill/netbsd/cvs-src/tools/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" &&
/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget lint1 dependall
*** Error code 2
Stop.
nbmake[1]: stopped in /home/jmcneill/netbsd/cvs-src/tools
*** [build_install] Error code 1
nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools
1 error
nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools
ERROR: Failed to make build_install in "tools"
*** BUILD ABORTED ***
On Tue, 5 Jan 2021, Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Tue Jan 5 23:50:29 UTC 2021
Modified Files:
src/usr.bin/xlint/lint1: Makefile op.h ops.def
Added Files:
src/usr.bin/xlint/lint1: ops.c
Removed Files:
src/usr.bin/xlint/lint1: Makefile.ops-c Makefile.ops-h mkops
Log Message:
lint: clean up generation of the operator tables
Instead of running a shell program that runs an AWK program that
generates the two files ops.c and ops.h, just define the operator tables
once in ops.def and use these definitions flexibly in ops.c and op.h.
To generate a diff of this commit:
cvs rdiff -u -r1.55 -r1.56 src/usr.bin/xlint/lint1/Makefile
cvs rdiff -u -r1.3 -r0 src/usr.bin/xlint/lint1/Makefile.ops-c \
src/usr.bin/xlint/lint1/Makefile.ops-h
cvs rdiff -u -r1.13 -r0 src/usr.bin/xlint/lint1/mkops
cvs rdiff -u -r1.9 -r1.10 src/usr.bin/xlint/lint1/op.h
cvs rdiff -u -r0 -r1.1 src/usr.bin/xlint/lint1/ops.c
cvs rdiff -u -r1.6 -r1.7 src/usr.bin/xlint/lint1/ops.def
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
Hi Roy !
That looks more semantics (the ones I know of - dynamic interface
scanning is one of my NTPd parts)
preserving now.
So far I see no other issues from the pitfalls I know of.
Lets hope our kernel and other SO_RERRORS systems miss any
interface scan worthy events.
Frank
On 01/03/21 12:03, Roy Marples wrote:
On 02/01/2021 23:33, Frank Kardel wrote:
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
...
This patch seems (by visual inspection) to break that logic.
Also the behavior now fully relies in the routing message
functionality which can be disabled
on serious procession errors - at that point the code robustness
relies on the periodic
re-scanning - so I am not sure whether the periodic re-scanning
should be completely
Valid points.
New patch sets disable_dynamic_updates if the -U 0 is given.
The only other code to touch disable_dynamic_updates is this
disable_dynamic_updates |= (sw_uid != 0); /* also notifies routing
message listener *
So this should be good now.
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/cmd_args.c
--- a/external/bsd/ntp/dist/ntpd/cmd_args.c Sat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/cmd_args.c Sun Jan 03 10:56:58
2021 +
@@ -181,9 +181,11 @@
if (HAVE_OPT( UPDATEINTERVAL )) {
long val = OPT_VALUE_UPDATEINTERVAL;
- if (val >= 0)
+ if (val >= 0) {
interface_interval = val;
- else {
+ if (interface_interval == 0)
+ disable_dynamic_updates = 1;
+ } else {
fprintf(stderr,
"command line interface update
interval %ld must not be negative\n",
val);
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sun Jan 03 10:56:58
2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSun Jan 03 10:56:58
2021 +
@@ -423,9 +423,11 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (!disable_dynamic_updates &&
+ interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
On 02/01/2021 23:33, Frank Kardel wrote: Also the behavior now fully relies in the routing message functionality which can be disabled on serious procession errors - at that point the code robustness relies on the periodic re-scanning - so I am not sure whether the periodic re-scanning should be completely disabled. Could you expand on this please? It sounds like you want it to be user disabled but not for routing messages? I don't understand. Roy
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
On 02/01/2021 23:33, Frank Kardel wrote:
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
...
This patch seems (by visual inspection) to break that logic.
Also the behavior now fully relies in the routing message functionality which
can be disabled
on serious procession errors - at that point the code robustness relies on the
periodic
re-scanning - so I am not sure whether the periodic re-scanning should be
completely
Valid points.
New patch sets disable_dynamic_updates if the -U 0 is given.
The only other code to touch disable_dynamic_updates is this
disable_dynamic_updates |= (sw_uid != 0); /* also notifies routing message
listener *
So this should be good now.
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/cmd_args.c
--- a/external/bsd/ntp/dist/ntpd/cmd_args.c Sat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/cmd_args.c Sun Jan 03 10:56:58 2021 +
@@ -181,9 +181,11 @@
if (HAVE_OPT( UPDATEINTERVAL )) {
long val = OPT_VALUE_UPDATEINTERVAL;
- if (val >= 0)
+ if (val >= 0) {
interface_interval = val;
- else {
+ if (interface_interval == 0)
+ disable_dynamic_updates = 1;
+ } else {
fprintf(stderr,
"command line interface update interval %ld
must not be negative\n",
val);
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sun Jan 03 10:56:58 2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSun Jan 03 10:56:58 2021 +
@@ -423,9 +423,11 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (!disable_dynamic_updates &&
+ interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
See man ntpd:
...
−U number, −−updateinterval=number
interval in seconds between scans for new or dropped
inter‐
faces. This option takes an integer number as its
argument.
Give the time in seconds between two scans for new or
dropped
interfaces. For systems with routing socket support the
scans will be performed shortly after the interface change
has been detected by the system. Use 0 to disable
scanning.
60 seconds is the minimum time between scans.
...
This patch seems (by visual inspection) to break that logic.
Also the behavior now fully relies in the routing message functionality
which can be disabled
on serious procession errors - at that point the code robustness relies
on the periodic
re-scanning - so I am not sure whether the periodic re-scanning should
be completely
disabled.
Best regards,
Frank
On 01/02/21 19:41, Roy Marples wrote:
On 02/01/2021 17:23, Roy Marples wrote:
That's a good point, with this we can now remove that forced sync on
a timer approach.
Does this look ok?
Better patch:
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 18:39:34
2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 18:39:34
2021 +
@@ -423,9 +423,10 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
On 02/01/2021 17:23, Roy Marples wrote:
That's a good point, with this we can now remove that forced sync on a timer
approach.
Does this look ok?
Better patch:
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 18:39:34 2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 18:39:34 2021 +
@@ -423,9 +423,10 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
Hi Frank
On 02/01/2021 09:55, Frank Kardel wrote:
I doubt that the explicit draining is helpful here as it already happens
I was aware of that.
I was just trying to avoid excess timer interface timeouts if we don't get
around to reading the next message in UPDATE_GRACE time.
Let's see what upstream says.
Also the ntp_io system will periodically refresh it interface lists in time as
it was explicitly designed to be robust against lost messages from the routing
socket.
That's a good point, with this we can now remove that forced sync on a timer
approach.
Does this look ok?
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 17:19:28 2021 +
@@ -423,9 +423,18 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (interface_timer && interface_timer <= current_time) {
+#ifdef SO_RERROR
+ /*
+* Because we can catch route(4) overflow, there is no
+* need to update interfaces every interface_interval.
+*/
+ interface_timer = 0;
+#else
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
+#endif
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
We should try to keep the differences to the up-stream code as little as
possible. Especially when the upstream code already handles the situation
reasonably the is no need for additional code.
Agreed.
I already submitted the diff upstream, but will adjust it to remove the forced
refresh.
Happy new year!
And the same to you!
Roy
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
Hi Roy ! I doubt that the explicit draining is helpful here as it already happens in the outer loop processing any routing socket input. All that is happening in the routing messages processing path is to call timer_interfacetimeout(current_time + UPDATE_GRACE) and this is robust for multiple calls. Ignoring ENOBUFS was ok here due to the automatic periodic interface updates. calling timer_interfacetimeout(current_time + UPDATE_GRACE) is also possible if you expect a single ENOBUFS within UPDATE_GRACE seconds. But there is no need o special case flushing the routing socket here. There is no functional improvement except for save a few cycles in the overflow case. Also the ntp_io system will periodically refresh it interface lists in time as it was explicitly designed to be robust against lost messages from the routing socket. We should try to keep the differences to the up-stream code as little as possible. Especially when the upstream code already handles the situation reasonably the is no need for additional code. Happy new year! Frank On 01/01/21 18:21, Roy Marples wrote: cvs rdiff -u -r1.27 -r1.28 src/external/bsd/ntp/dist/ntpd/ntp_io.c
Re: CVS commit: src
>sys/external/gpl2/dts/dist is meant for upstream dts files only. Do >you mind moving this to sys/arch/arm/dts with the other custom dts files? Ah, I Understood. Sorry, I didn't have a good grasp of the sys/external/gpl2/dts/dist/arch policy. I will move it to sys/arch/arm/dts. Thanks! -- ryo shimizu
Re: CVS commit: src/distrib/sets/lists/games
Please also add the appropriate entry to src/distrib/sets/lists/debug.mi for those of us who build with MKDEBUG=YES :) On Sat, 2 Jan 2021, Nathanial Sloss wrote: Module Name:src Committed By: nat Date: Sat Jan 2 03:24:02 UTC 2021 Modified Files: src/distrib/sets/lists/games: mi Log Message: Add testpat(6) to the games set. To generate a diff of this commit: cvs rdiff -u -r1.59 -r1.60 src/distrib/sets/lists/games/mi Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:5fefe793123761591715016! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/external/bsd/unbound/lib/libunbound
Date:Fri, 1 Jan 2021 20:38:36 + From:"Roy Marples" Message-ID: <20210101203836.2cadcf...@cvs.netbsd.org> | Modified Files: | src/external/bsd/unbound/lib/libunbound: Makefile | | Log Message: | libunbound: Now we use libevent, don't build mini_event or winsock_event. That changes the ABI of the library (libunbound) and so at the very least would require a major version bump. It also breaks the build. Please revert, and also (and this applies to *everyone*) please do release builds BEFORE committing changes which can (even remotely possibly) affect the rest of the build (which more or less means any change other than to doc - and even there if any doc is new or deleted). kre
Re: CVS commit: src
Hi! sys/external/gpl2/dts/dist is meant for upstream dts files only. Do you mind moving this to sys/arch/arm/dts with the other custom dts files? Thanks! Jared On Fri, 1 Jan 2021, Ryo Shimizu wrote: Module Name:src Committed By: ryo Date: Fri Jan 1 07:41:46 UTC 2021 Modified Files: src/distrib/sets/lists/dtb: ad.aarch64 ad.aarch64eb src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic: Makefile Added Files: src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic: meson-g12b-odroid-n2-plus.dts Log Message: add dts for odroid-N2 plus. meson-g12b-odroid-n2-plus.dts of linux is not optimized for the odroid-N2plus CPU clock. and the dts for odroid-n2-plus in the hardkernel repository is significantly changed, so cannot be imported without modification. Therefore, a simple meson-g12b-odroid-n2-plus.dts has been added based on "meson-g12b-odroid-n2.dts" with only the cpu_opp_table and regulator table changed. To generate a diff of this commit: cvs rdiff -u -r1.3 -r1.4 src/distrib/sets/lists/dtb/ad.aarch64 cvs rdiff -u -r1.2 -r1.3 src/distrib/sets/lists/dtb/ad.aarch64eb cvs rdiff -u -r1.1.1.7 -r1.2 \ src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic/Makefile cvs rdiff -u -r0 -r1.1 \ src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2-plus.dts Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/arm/rockchip
Oops. The change was to make sure that a devicetree node with a "rockchip,grf" property on a device type that doesn't provide a config struct doesn't deref a NULL ptr. On Fri, 1 Jan 2021, Jared D. McNeill wrote: Module Name:src Committed By: jmcneill Date: Fri Jan 1 11:44:41 UTC 2021 Modified Files: src/sys/arch/arm/rockchip: rk_i2s.c Log Message: rk_i2s.c To generate a diff of this commit: cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/rockchip/rk_i2s.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
re: CVS commit: src/usr.bin/make
"Roland Illig" writes:
> Module Name: src
> Committed By: rillig
> Date: Tue Dec 22 08:10:39 UTC 2020
>
> Modified Files:
> src/usr.bin/make: parse.c
i'm not sure which change did it (but before this one for sure),
but my builds crash early now (still trying to bootstrap nbmake):
cc -o nbmake *.o
assertion "*line_end == '\n'" failed: file "/usr/src/usr.bin/make/parse.c",
line 2844, function "ParseGetLine"
[1] Abort trap (core dumped) "${make}" -m ${TOP}/share/mk -s -B -f- _x_ <<...
ERROR: bomb_getmakevar MAKECONF: /tmp/nbbuild14989/nbmake failed
please fix :-)
.mrg.
Re: CVS commit: src/usr.bin/make
In article <20201213212746.3cfc3f...@cvs.netbsd.org>, Roland Illig wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: rillig >Date: Sun Dec 13 21:27:46 UTC 2020 > >Modified Files: > src/usr.bin/make: for.c meta.c parse.c var.c > >Log Message: >make(1): replace %zu with %u in printf calls > >This is needed to compile bmake with GCC 2.8.1 on SunOS 5.9. > >To support ancient systems like this, the whole code of usr.bin/make is >supposed to use only ISO C90 features, except for filemon, which is not >used on these systems. Please revert! This breaks everyone else. %zu is the format to print size_t. Last I checked SunOS 5.9 has been dead since 2014 and whoever is still using it might as well install a new compiler, or tie the box at the end of a long chain so it can find its true calling. If you really want to support it instead define MAKE_FMT_SIZE_T and conditionalize it properly for "ancient OS", windows, cygwin, mingwin, and regular folks (this does not even handle "ancient os"): https://github.com/file/file/blob/master/src/file.h#L55 I am still against it though... christos
Re: CVS commit: src/external/gpl2/diffutils/dist/src
On Sun, Dec 13, 2020 at 12:04:40AM +, Roy Marples wrote: > Module Name: src > Committed By: roy > Date: Sun Dec 13 00:04:40 UTC 2020 > > Modified Files: > src/external/gpl2/diffutils/dist/src: util.c > > Log Message: > diffutils: execl requires a NULL sentinel Strictly speaking, this needs a cast to work properly. It really needs to be a pointer and NULL isn't necessarily one. Joerg
Re: CVS commit: src/sys/dev/pci/ixgbe
On 2020/12/11 14:01, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Fri Dec 11 05:01:19 UTC 2020 Modified Files: src/sys/dev/pci/ixgbe: ixgbe.c ixgbe_type.h Log Message: Don't use EIMC_OTHER bit because it's read only other than 82598. Documents say: 82598: All of bit 31(OTHER bit) of EIxx are reserved. In reality, at least EIMS_OTHER and EIMC_OTHER exist and the OTHER interrupt doesn't work without EIMS_OTHER. Other than 82598: + EICR's bit 31 is defined and other EIXX's bit 31 are reserved. + In reality, EIMS_OTHER is read only and EIMC_OTHER doesn't exist. If one of bit 29..16 is set, EIMS_OTHER is set to 1 (Note that bit 30(TCP timer isn't included)). Even if write bit 31 of EIMC to 1, it's ignored (EIMS_OTHER doesn't set). We introduced new spin mutex in ixgbe.c rev. 1.260, so it's OK to remove EIMC_OTHER stuff. We already set EIMS_OTHER in if_init(), so keep it for 82598. No functional change other than 82598. Another solution is to control bit 30..16 directly to mask/unmask interrupt instead of the mutex. TODO: Some MSI-X interrupt(LSC, module insertion/removal etc.)'s mask/unmask code between ixgbe_msix_admin() and ixgbe_handle_admin() may be wrong. It'll be fixed later. To generate a diff of this commit: cvs rdiff -u -r1.261 -r1.262 src/sys/dev/pci/ixgbe/ixgbe.c cvs rdiff -u -r1.45 -r1.46 src/sys/dev/pci/ixgbe/ixgbe_type.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/external/gpl3/gdb/dist/gdb
On 10.12.2020 08:14, Rin Okuyama wrote: > Module Name: src > Committed By: rin > Date: Thu Dec 10 07:14:58 UTC 2020 > > Modified Files: > src/external/gpl3/gdb/dist/gdb: nbsd-nat.c > > Log Message: > Fix arm, for which PT_STEP is defined but unimplemented. > > XXX > Stop exposing PT_STEP to userland for arm? > Yes, please remove it from headers for arm. This was a hack for DTrace as far as I recall, to expose PT_STEP that way and get DTrace building. Then, please restore nbsd-nat.c to the previous state. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/netinet
> On Dec 4, 2020, at 8:57 AM, Christos Zoulas wrote: > > In article <20201204004439.90c25f...@cvs.netbsd.org>, > Jason R Thorpe wrote: >> -=-=-=-=-=- >> >> Module Name: src >> Committed By:thorpej >> Date:Fri Dec 4 00:44:39 UTC 2020 >> >> Modified Files: >> src/sys/netinet: files.ipfilter >> >> Log Message: >> Build ip_sync.c with -Wno-error to avoid failing due to excessive stack >> usage. > > Can you please make this more specific? Like -Wno-error=foo? Feel free to try. -Wno-error=stack-usage produced an error for me. -- thorpej
Re: CVS commit: src/sys/netinet
In article <20201204004439.90c25f...@cvs.netbsd.org>, Jason R Thorpe wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: thorpej >Date: Fri Dec 4 00:44:39 UTC 2020 > >Modified Files: > src/sys/netinet: files.ipfilter > >Log Message: >Build ip_sync.c with -Wno-error to avoid failing due to excessive stack >usage. Can you please make this more specific? Like -Wno-error=foo? christos
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
On 2020-11-28, Yorick Hardy wrote: > Module Name: src > Committed By: yhardy > Date: Sat Nov 28 22:53:06 UTC 2020 > > Modified Files: > src/external/cddl/osnet/dist/uts/common/fs/zfs: vdev_disk.c > > Log Message: > Use vn_close to release the vnodes in the error handling blocks, since > the vnodes were opened for writing. Fix proposed on current-users > and improved by hannken@. > > > To generate a diff of this commit: > cvs rdiff -u -r1.18 -r1.19 \ > src/external/cddl/osnet/dist/uts/common/fs/zfs/vdev_disk.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. Oops, that should have been "proposed on tech-kern": http://mail-index.netbsd.org/tech-kern/2020/11/28/msg026984.html -- Kind regards, Yorick Hardy
Re: CVS commit: src/sys/arch/arm/arm32
Excellent! Thank you so much for finding out and fixing this! Full ATF successfully completed for Raspberry Pi 2b, which formerly crashed due to "anon != NULL && anon->an_ref != 0" panic. Now, ATF is running on Cubietruck and Raspberry Pi Zero W. Thanks, rin On 2020/11/22 4:44, Nick Hudson wrote: Module Name:src Committed By: skrll Date: Sat Nov 21 19:44:52 UTC 2020 Modified Files: src/sys/arch/arm/arm32: cpuswitch.S Log Message: Ensure that r5 contains curlwp before DO_AST_AND_RESTORE_ALIGNMENT_FAULTS in lwp_trampoline as required by the move to make ASTs operate per-LWP rather than per-CPU. Thanks to martin@ for bisecting the amap corruption he was seeing and testing this fix. To generate a diff of this commit: cvs rdiff -u -r1.103 -r1.104 src/sys/arch/arm/arm32/cpuswitch.S Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys
Please pull up to netbsd-8 and netbsd-9 release branches. > On Nov 11, 2020, at 23:44, Simon Burge wrote: > > Module Name: src > Committed By: simonb > Date: Thu Nov 12 07:44:01 UTC 2020 > > Modified Files: > src/sys/conf: param.c > src/sys/kern: init_main.c > src/sys/sys: param.h > > Log Message: > Set a better default for MAXFILES on larger RAM machines if not > otherwise specified the kernel config file. Arbitary numbers are > 20,000 files for 16GB RAM or more and 10,000 files for 1GB RAM or > more. > > TODO: Adjust this and other values totally dynamically. > > > To generate a diff of this commit: > cvs rdiff -u -r1.68 -r1.69 src/sys/conf/param.c > cvs rdiff -u -r1.532 -r1.533 src/sys/kern/init_main.c > cvs rdiff -u -r1.678 -r1.679 src/sys/sys/param.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src
On Sun, Nov 08, 2020 at 09:56:48PM +, Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Sun Nov 8 21:56:48 UTC 2020 > > Modified Files: > src/external/bsd/kyua-cli: Makefile.inc > src/external/ibm-public/postfix: Makefile.inc > src/external/public-domain/sqlite: Makefile.inc > src/external/public-domain/sqlite/bin: Makefile > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > src/usr.sbin/makemandb: Makefile > > Log Message: > sqlite: do not build without multithreading support So the core issue here is that it actually does two separate things. It does not only enable threadsafety (which is good), but also enables the worker thread support (which is bad). There is little reason for wanting the latter in a general build, at least the way it is implemented right now. Just doing the former is a lot less intrusive... Joerg diff -r 2bb2635be785 external/public-domain/sqlite/Makefile.inc --- a/external/public-domain/sqlite/Makefile.incThu Nov 12 23:24:18 2020 +0100 +++ b/external/public-domain/sqlite/Makefile.incThu Nov 12 23:28:36 2020 +0100 @@ -15,6 +15,7 @@ -DHAVE_STRERROR_R=1 \ -DHAVE_USLEEP=1 \ -DHAVE_SYS_ENDIAN_H=1 \ + -DSQLITE_THREADSAFE \ -DSQLITE_MAX_WORKER_THREADS=0 \ -DSQLITE_ENABLE_COLUMN_METADATA \ -DSQLITE_ENABLE_FTS3_PARENTHESIS \
Re: CVS commit: src
On 2020/11/13 2:35, nia wrote: I'll revert the commit shortly. Thank you very much for your quick response. I wasn't expecting such major breakage (obviously) and actually did run a build but ran into different problems with libstdc++. Yeah, this is why we need tests, and also listen to others before making somewhat big changes. No one is perfect... Thanks, rin
Re: CVS commit: src
On Thu, Nov 12, 2020 at 07:58:13PM +, Taylor R Campbell wrote: > But there's a snag with heimdal. > > Heimdal exposes the sqlite3 library to clients via libgssapi.so which > links against libkrb5.so which brings in libsqlite3.so. So we get nice > situations like this: > > % ldd /pkg/2020Q2/bin/svn | grep sqlite > -lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0 > -lsqlite3.1 => /usr/lib/libsqlite3.so.1 > > This is also why the change to base sqlite3 affected, e.g., su(1). How about making sqlite3 just a private lib statically linked into whatever part of heimdahl actually needs it, and not exposing any symbols from it? Martin
Re: CVS commit: src
> Date: Thu, 12 Nov 2020 11:21:43 -0800 > From: Jason Thorpe > > > On Nov 12, 2020, at 9:40 AM, nia wrote: > > > > For the record I'm just trying to fix things so that running > > third-party software on NetBSD sucks less. If fewer third-party > > libraries were exposed by the base system this wouldn't be > > necessary. > > Why do we even have sqlite in the base system in the first place? apropos(1); a handful of other things also use it (heimdal, postfix). I suggested that we leave the bells & whistles out of base sqlite3, maybe even stop installing the .so symlink, and teach pkgsrc to just use pkgsrc sqlite3 (with all bells & whistles included) rather than base sqlite3 -- after all, sqlite3 is meant to be embedded and has lots of optional bells & whistles that apropos(1) has no need of, so it is silly to impose those costs on apropos(1) or make sqlite3 part of the NetBSD API. But there's a snag with heimdal. Heimdal exposes the sqlite3 library to clients via libgssapi.so which links against libkrb5.so which brings in libsqlite3.so. So we get nice situations like this: % ldd /pkg/2020Q2/bin/svn | grep sqlite -lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0 -lsqlite3.1 => /usr/lib/libsqlite3.so.1 This is also why the change to base sqlite3 affected, e.g., su(1). I have no idea what heimdal does with sqlite3, but it puts us in a pretty pickle: we can't reliably use pkgsrc sqlite3 on existing NetBSD installs for packages that use gssapi, and we can't rely on sqlite3 in existing NetBSD installs for packages that need newer/threaded/jsonned sqlite3 as we often encounter.
Re: CVS commit: src
> On Nov 12, 2020, at 9:40 AM, nia wrote: > > For the record I'm just trying to fix things so that running > third-party software on NetBSD sucks less. If fewer third-party > libraries were exposed by the base system this wouldn't be > necessary. Why do we even have sqlite in the base system in the first place? -- thorpej
Re: CVS commit: src
On Thu, Nov 12, 2020 at 05:35:44PM +, nia wrote: > I'll revert the commit shortly. > > I wasn't expecting such major breakage (obviously) and actually > did run a build but ran into different problems with libstdc++. For the record I'm just trying to fix things so that running third-party software on NetBSD sucks less. If fewer third-party libraries were exposed by the base system this wouldn't be necessary.
Re: CVS commit: src
I'll revert the commit shortly. I wasn't expecting such major breakage (obviously) and actually did run a build but ran into different problems with libstdc++.
Re: CVS commit: src
On 2020/11/12 23:03, Rin Okuyama wrote: The backtrace reads: | (gdb) bt | #0 0xfc2961bca308 in ?? () | #1 0xfc2961b9ec10 in __deregister_frame_info_bases () | from /usr/lib/libgcc_s.so.1 | #2 0xf88425b4 in _rtld_call_function_void (obj=0xfc2962917400, | addr=277254663434168) at /usr/src/libexec/ld.elf_so/rtld.h:514 | ... The fault address is anon memory w/o exec permission when su exits: | # pmap -p xxx | ... | FC2961BB1000 4K read/write /altroot/lib/libgcc_s.so.1.0 | FC2961BB6000 40K read/write [ anon ] | FC2961BE6000 40K read/write [ anon ] | ... Oops, correction: the fault address is not mapped when su exits; FC2961BB6000 + 40K = FC2961BC. The discussion thereafter does not change. Thanks, rin
Re: CVS commit: src
On 2020/11/11 1:50, nia wrote: On Tue, Nov 10, 2020 at 04:29:21PM +, Taylor R Campbell wrote: Module Name:src Committed By: nia Date: Sun Nov 8 21:56:48 UTC 2020 Modified Files: src/external/bsd/kyua-cli: Makefile.inc src/external/ibm-public/postfix: Makefile.inc src/external/public-domain/sqlite: Makefile.inc src/external/public-domain/sqlite/bin: Makefile src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in src/usr.sbin/makemandb: Makefile Log Message: sqlite: do not build without multithreading support at least a few pkgsrc packages avoid base sqlite because it fails this check, and it's probably a surprising performance penalty for unsuspecting users Why do we even expose NetBSD's libsqlite3.so to pkgsrc? Why not just have pkgsrc always use pkgsrc sqlite3, and change base to go back to the smaller non-threaded sqlite3 with only the options the things in base actually need? Also: What is the performance penalty? The sqlite3 documentation (https://www.sqlite.org/faq.html#q6) suggests that _enabling_ SQLITE_THREADSAFE has a performance penalty, not the other way around. It seems to me we've had a lot of problems over the years trying to use base sqlite3 for everything in pkgsrc. It's not clear to me that any of the recent changes are helpful for the three things in base that need sqlite3, and it's also not clear that they will help with running newer pkgsrc on older NetBSD. libevent is also problematic. Maybe there's just too many third-party libraries that are exposed that sholdn't be. A failure for cvs, suspected to be a fallout of threaded sqlite3 was reported in port-arm@. See thread starts with: http://mail-index.netbsd.org/port-arm/2020/11/12/msg007046.html Also, I encountered another fallout: ``su -'' receives SIGSEGV when exits (on aarch64, but I bet this is MI problem): | $ su | # exit | $ su - | # exit | [2] Segmentation fault (core dumped) su - The backtrace reads: | (gdb) bt | #0 0xfc2961bca308 in ?? () | #1 0xfc2961b9ec10 in __deregister_frame_info_bases () |from /usr/lib/libgcc_s.so.1 | #2 0xf88425b4 in _rtld_call_function_void (obj=0xfc2962917400, | addr=277254663434168) at /usr/src/libexec/ld.elf_so/rtld.h:514 | ... The fault address is anon memory w/o exec permission when su exits: | # pmap -p xxx | ... | FC2961BB1000 4K read/write/altroot/lib/libgcc_s.so.1.0 | FC2961BB6000 40K read/write [ anon ] | FC2961BE6000 40K read/write [ anon ] | ... However, when su is running, libpthread is loaded at this address: | # pmap -p xxx | ... | FC2961BB1000 4K read/write/altroot/lib/libgcc_s.so.1.0 | FC2961BB6000 40K read/write [ anon ] | FC2961BC 76K read/exec /altroot/lib/libpthread.so.1.4 | FC2961BD3000 64K /altroot/lib/libpthread.so.1.4 | ... su is not explicitly linked to libpthread, but it is loaded via libkrb5 via libpam. It registers its own deconstructor, however, it is unloaded before su exits. Then, SIGSEGV takes place as a result. IMO, this commit should be reverted ASAP. This kind of change needs more tests, and discussion in appropriate lists before commit. Unfortunately, the committer did not even carry out ``build.sh'' before commit (martin fixed the build failure due to this). This is not what we, at least, I expect our developers. Thanks, rin
Re: CVS commit: src/sys/arch/arm/arm
On 2020/11/12 6:52, matthew green wrote: "Rin Okuyama" writes: Module Name:src Committed By: rin Date: Tue Nov 10 21:40:07 UTC 2020 Modified Files: src/sys/arch/arm/arm: cpu_exec.c Log Message: Test (epp->ep_esch->es_emul != _netbsd) instead of nice, this is a step forward. an optimisation on it could be to remove this test entirely if neither MODULAR or COMAPT_NETBSD32 are set, as it will always be false there. Ah, yes. I will commit after some test. Thanks! rin
re: CVS commit: src/sys/arch/arm/arm
"Rin Okuyama" writes: > Module Name: src > Committed By: rin > Date: Tue Nov 10 21:40:07 UTC 2020 > > Modified Files: > src/sys/arch/arm/arm: cpu_exec.c > > Log Message: > Test (epp->ep_esch->es_emul != _netbsd) instead of nice, this is a step forward. an optimisation on it could be to remove this test entirely if neither MODULAR or COMAPT_NETBSD32 are set, as it will always be false there. thanks. .mrg.
Re: CVS commit: src
On Tue, Nov 10, 2020 at 04:29:21PM +, Taylor R Campbell wrote: > > Module Name:src > > Committed By: nia > > Date: Sun Nov 8 21:56:48 UTC 2020 > > > > Modified Files: > > src/external/bsd/kyua-cli: Makefile.inc > > src/external/ibm-public/postfix: Makefile.inc > > src/external/public-domain/sqlite: Makefile.inc > > src/external/public-domain/sqlite/bin: Makefile > > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > > src/usr.sbin/makemandb: Makefile > > > > Log Message: > > sqlite: do not build without multithreading support > > > > at least a few pkgsrc packages avoid base sqlite because it fails > > this check, and it's probably a surprising performance penalty for > > unsuspecting users > > Why do we even expose NetBSD's libsqlite3.so to pkgsrc? Why not just > have pkgsrc always use pkgsrc sqlite3, and change base to go back to > the smaller non-threaded sqlite3 with only the options the things in > base actually need? > > Also: What is the performance penalty? The sqlite3 documentation > (https://www.sqlite.org/faq.html#q6) suggests that _enabling_ > SQLITE_THREADSAFE has a performance penalty, not the other way around. > > It seems to me we've had a lot of problems over the years trying to > use base sqlite3 for everything in pkgsrc. It's not clear to me that > any of the recent changes are helpful for the three things in base > that need sqlite3, and it's also not clear that they will help with > running newer pkgsrc on older NetBSD. libevent is also problematic. Maybe there's just too many third-party libraries that are exposed that sholdn't be.
Re: CVS commit: src
> Module Name:src > Committed By: nia > Date: Sun Nov 8 21:56:48 UTC 2020 > > Modified Files: > src/external/bsd/kyua-cli: Makefile.inc > src/external/ibm-public/postfix: Makefile.inc > src/external/public-domain/sqlite: Makefile.inc > src/external/public-domain/sqlite/bin: Makefile > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > src/usr.sbin/makemandb: Makefile > > Log Message: > sqlite: do not build without multithreading support > > at least a few pkgsrc packages avoid base sqlite because it fails > this check, and it's probably a surprising performance penalty for > unsuspecting users Why do we even expose NetBSD's libsqlite3.so to pkgsrc? Why not just have pkgsrc always use pkgsrc sqlite3, and change base to go back to the smaller non-threaded sqlite3 with only the options the things in base actually need? Also: What is the performance penalty? The sqlite3 documentation (https://www.sqlite.org/faq.html#q6) suggests that _enabling_ SQLITE_THREADSAFE has a performance penalty, not the other way around. It seems to me we've had a lot of problems over the years trying to use base sqlite3 for everything in pkgsrc. It's not clear to me that any of the recent changes are helpful for the three things in base that need sqlite3, and it's also not clear that they will help with running newer pkgsrc on older NetBSD.
Re: CVS commit: src/share/mk
On 2020/11/10 1:15, Christos Zoulas wrote:
- when we need to run ctfconvert, go through an intermediate ${.TARGET}.o
file, instead of writing directly to ${.TARGET} and then overwriting
${.TARGET} with ctfconvert. This avoids build failures after a build
got interrupted (the "partially built from C" scourge).
Thanks, I wanted this!
rin
Re: CVS commit: src
On 08.11.2020 22:56, Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Sun Nov 8 21:56:48 UTC 2020 > > Modified Files: > src/external/bsd/kyua-cli: Makefile.inc > src/external/ibm-public/postfix: Makefile.inc > src/external/public-domain/sqlite: Makefile.inc > src/external/public-domain/sqlite/bin: Makefile > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > src/usr.sbin/makemandb: Makefile > > Log Message: > sqlite: do not build without multithreading support > > at least a few pkgsrc packages avoid base sqlite because it fails > this check, and it's probably a surprising performance penalty for > unsuspecting users > I'm getting: dependall ===> usr.sbin/makemandb nbmake[6]: nbmake[6]: don't know how to make -ltermlib. Stop nbmake[6]: stopped in /usr/src/usr.sbin/makemandb signature.asc Description: OpenPGP digital signature
Re: CVS commit: src
On 08.11.2020 17:55, Christos Zoulas wrote: > In article <20201108145236.3a009f...@cvs.netbsd.org>, > Kamil Rytarowski wrote: >> -=-=-=-=-=- >> >> Module Name: src >> Committed By:kamil >> Date:Sun Nov 8 14:52:36 UTC 2020 >> >> Modified Files: >> src: BUILDING >> src/distrib/sets: sets.subr >> src/doc: BUILDING.mdoc >> src/share/man/man5: mk.conf.5 >> src/share/mk: bsd.README bsd.man.mk bsd.own.mk >> >> Log Message: >> Remove the support for MKCATPAGES >> >> It was optional since 1999 and disabled by default since 2012. >> >> Proposed on tech-userlevel@. > > What about the sets? > > christos > I'm test-building a local patch removing the cat files, directories and a few other remnants. Once it will be done, I will land it. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src
In article <20201108145236.3a009f...@cvs.netbsd.org>, Kamil Rytarowski wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: kamil >Date: Sun Nov 8 14:52:36 UTC 2020 > >Modified Files: > src: BUILDING > src/distrib/sets: sets.subr > src/doc: BUILDING.mdoc > src/share/man/man5: mk.conf.5 > src/share/mk: bsd.README bsd.man.mk bsd.own.mk > >Log Message: >Remove the support for MKCATPAGES > >It was optional since 1999 and disabled by default since 2012. > >Proposed on tech-userlevel@. What about the sets? christos
Re: CVS commit: src/sys
Thanks for checking!
I agree with your proposed changes. If noone else objects, please
go ahead and commit.
On Sun, 8 Nov 2020, Rin Okuyama wrote:
Thanks Paul for finding out the bug!
Then, compat_netbsd32 and compat_netbsd32_coredump modules are
successfully load for kernel without COMPAT_NETBSD32 option.
However, OABI binaries still do not work. I found this is due to
there remains ``#ifdef COMPAT_NETBSD32'' codes in sys/arch/arm.
By fixing them, OABI binaries work and dump valid core files!
I changed two files.
(1) arm_netbsd_elf32_probe() in arm/cpu_exec.c
Previously, determine whether emulation is native or netbsd32 by
testing ``epp->ep_esch->es_emul == _netbsd32''. This requires
COMPAT_NETBSD32 option. However, we can use
``epp->ep_esch->es_emul != _netbsd'' for this purpose.
(2) arm_netbsd_elf32_coredump_setup() in arm/core_machdep.c
This seems simply a mistake; kernel sets EABI flag to OABI core
files. We can remove entire COMPAT_NETBSD32 codes.
I will commit them soon if there's no objection.
Thanks,
rin
On 2020/11/08 6:53, Paul Goyette wrote:
Thanks for fixing ...
On Sat, 7 Nov 2020, Christos Zoulas wrote:
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7
christos
On Nov 7, 2020, at 4:27 PM, Paul Goyette wrote:
OK, I think I found the problem, but I don't know how to solve it...
All of the undefined symbols are supposed to be provided by
.../sys/arch/arm/arm32/netbsd32_machdep.c
but there is no netbsd32_machdep.o included in the compat_netbsd32
module.?? This file should be included by the following code in
.../sys/modules/compat_netbsd32/Makefile
.if ${MACHINE_ARCH} == "arm"
.PATH:?? ${S}/arch/arm/arm32
SRCS+=?? netbsd32_machdep.c
.endif
but it seems not to work (or at least, it doesn't do what it was
intended to do).
On Thu, 5 Nov 2020, Rin Okuyama wrote:
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.?? But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
?? modload compat_netbsd32
?? modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
?? #include
?? int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD?? 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov?? 5 20:26:39 JST
2020 rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[?? 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_vm_default_addr' not found
[?? 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_machdep_md_init' not found
[?? 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_sendsig' not found
[?? 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `cpu_mcontext32_validate' not found
[?? 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `cpu_setmcontext32' not found
[?? 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_machdep_md_fini' not found
[?? 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `startlwp32' not found
[?? 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `cpu_getmcontext32' not found
[?? 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `machine32' not found
[?? 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_sysarch' not found
[?? 29.7318320] WARNING: module error: unable to affix module
`compat_netbsd32', error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in
files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail
addresses: |
| (Retired)?? | FA29 0E3B 35AF E8AE 6651 |
p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org
|
++--+---+
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail
addresses: |
|
Re: CVS commit: src/sys
Thanks Paul for finding out the bug!
Then, compat_netbsd32 and compat_netbsd32_coredump modules are
successfully load for kernel without COMPAT_NETBSD32 option.
However, OABI binaries still do not work. I found this is due to
there remains ``#ifdef COMPAT_NETBSD32'' codes in sys/arch/arm.
By fixing them, OABI binaries work and dump valid core files!
I changed two files.
(1) arm_netbsd_elf32_probe() in arm/cpu_exec.c
Previously, determine whether emulation is native or netbsd32 by
testing ``epp->ep_esch->es_emul == _netbsd32''. This requires
COMPAT_NETBSD32 option. However, we can use
``epp->ep_esch->es_emul != _netbsd'' for this purpose.
(2) arm_netbsd_elf32_coredump_setup() in arm/core_machdep.c
This seems simply a mistake; kernel sets EABI flag to OABI core
files. We can remove entire COMPAT_NETBSD32 codes.
I will commit them soon if there's no objection.
Thanks,
rin
On 2020/11/08 6:53, Paul Goyette wrote:
Thanks for fixing ...
On Sat, 7 Nov 2020, Christos Zoulas wrote:
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7
christos
On Nov 7, 2020, at 4:27 PM, Paul Goyette wrote:
OK, I think I found the problem, but I don't know how to solve it...
All of the undefined symbols are supposed to be provided by
.../sys/arch/arm/arm32/netbsd32_machdep.c
but there is no netbsd32_machdep.o included in the compat_netbsd32
module. This file should be included by the following code in
.../sys/modules/compat_netbsd32/Makefile
.if ${MACHINE_ARCH} == "arm"
.PATH: ${S}/arch/arm/arm32
SRCS+= netbsd32_machdep.c
.endif
but it seems not to work (or at least, it doesn't do what it was
intended to do).
On Thu, 5 Nov 2020, Rin Okuyama wrote:
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module `compat_netbsd32',
error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys
Thanks for fixing ...
On Sat, 7 Nov 2020, Christos Zoulas wrote:
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7
christos
On Nov 7, 2020, at 4:27 PM, Paul Goyette wrote:
OK, I think I found the problem, but I don't know how to solve it...
All of the undefined symbols are supposed to be provided by
.../sys/arch/arm/arm32/netbsd32_machdep.c
but there is no netbsd32_machdep.o included in the compat_netbsd32
module. This file should be included by the following code in
.../sys/modules/compat_netbsd32/Makefile
.if ${MACHINE_ARCH} == "arm"
.PATH: ${S}/arch/arm/arm32
SRCS+= netbsd32_machdep.c
.endif
but it seems not to work (or at least, it doesn't do what it was
intended to do).
On Thu, 5 Nov 2020, Rin Okuyama wrote:
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module `compat_netbsd32',
error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
re: CVS commit: src/sys
> .if ${MACHINE_ARCH} == "arm"
this is wrong. it should use MACHINE_CPU.
.mrg.
Re: CVS commit: src/sys
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7
christos
> On Nov 7, 2020, at 4:27 PM, Paul Goyette wrote:
>
> OK, I think I found the problem, but I don't know how to solve it...
>
> All of the undefined symbols are supposed to be provided by
>
> .../sys/arch/arm/arm32/netbsd32_machdep.c
>
> but there is no netbsd32_machdep.o included in the compat_netbsd32
> module. This file should be included by the following code in
> .../sys/modules/compat_netbsd32/Makefile
>
> .if ${MACHINE_ARCH} == "arm"
> .PATH: ${S}/arch/arm/arm32
> SRCS+= netbsd32_machdep.c
> .endif
>
> but it seems not to work (or at least, it doesn't do what it was
> intended to do).
>
>
>
>
>
>
> On Thu, 5 Nov 2020, Rin Okuyama wrote:
>
>> On 2020/11/05 5:43, Paul Goyette wrote:
>>> BTW, the patch you submitted with the initial message in this thread
>>> looks good for avoiding the issue. But I'm not sure it is a complete
>>> solution.
>>> In particular, you would need to build a 32-bit arm that contains ``no
>>> options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
>>> and compat_netbsd32_coredump modules
>>>
>>> modload compat_netbsd32
>>> modload compat_netbsd32_coredump
>>> Then see if emulation of the old ABI still works, and check if core-
>>> dump works for old-ADI programs; the test program I've been using for
>>> core-dump checking is
>>>
>>> #include
>>> int main(int argc, void *argv) { abort(); }
>>> I really have to leave and take care of some personal business, so I
>>> would greatly appreciate if you can check this out.
>>
>> Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
>>
>>
>> # uname -ap
>> NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
>> rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
>> # modload compat_netbsd32
>> [ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_vm_default_addr' not found
>> [ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_machdep_md_init' not found
>> [ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_sendsig' not found
>> [ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `cpu_mcontext32_validate' not found
>> [ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `cpu_setmcontext32' not found
>> [ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_machdep_md_fini' not found
>> [ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `startlwp32' not found
>> [ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `cpu_getmcontext32' not found
>> [ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `machine32' not found
>> [ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_sysarch' not found
>> [ 29.7318320] WARNING: module error: unable to affix module
>> `compat_netbsd32', error 8
>> modload: compat_netbsd32: Exec format error
>>
>>
>> This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
>> not included in compat_netbsd32 module. compat_netbsd32 module must not
>> work also for aarch64 and mips64 for the same reason, whereas amd64 and
>> sparc64 seem OK.
>>
>> Thanks,
>> rin
>>
>> !DSPAM:5fa3f309175521945872603!
>>
>>
>
> ++--+---+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
> ++--+---+
signature.asc
Description: Message signed with OpenPGP
Re: CVS commit: src/sys
OK, I think I found the problem, but I don't know how to solve it...
All of the undefined symbols are supposed to be provided by
.../sys/arch/arm/arm32/netbsd32_machdep.c
but there is no netbsd32_machdep.o included in the compat_netbsd32
module. This file should be included by the following code in
.../sys/modules/compat_netbsd32/Makefile
.if ${MACHINE_ARCH} == "arm"
.PATH: ${S}/arch/arm/arm32
SRCS+= netbsd32_machdep.c
.endif
but it seems not to work (or at least, it doesn't do what it was
intended to do).
On Thu, 5 Nov 2020, Rin Okuyama wrote:
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module
`compat_netbsd32', error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys
On 2020/11/05 23:07, Paul Goyette wrote: I will investigate. Thanks! Can you confirm that it works correctly if you have the built-in module? (ie, kernel with ``options COMPAT_NETBSD32'') Yes, it works fine. rin
Re: CVS commit: src/sys
I will investigate.
Can you confirm that it works correctly if you have the built-in
module? (ie, kernel with ``options COMPAT_NETBSD32'')
On Thu, 5 Nov 2020, Rin Okuyama wrote:
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module
`compat_netbsd32', error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module `compat_netbsd32',
error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
Re: CVS commit: src/sys/kern
On 2020/11/05 2:45, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> options PTRACE # Include ptrace(2) syscall
###> options PTRACE_HOOKS # Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd, ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd, ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Yes that would be a problem.
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
I have some prior obligations, so I won't be able to look at this
until this evening.
Thanks for the detailed analysis.
Fixed. Thanks!
rin
Re: CVS commit: src/sys
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Thanks!
On Wed, 4 Nov 2020, Paul Goyette wrote:
I guess I don't understand why a 32-bit architecture would also have
COMPAT_NETBSD32.
Christos, can you help out on this?
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hello again,
On 2020/11/02 3:51, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Nov 1 18:51:03 UTC 2020
Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile
Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.
Welcome to 7.99.75 !!!
To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:
panic: kernel diagnostic assertion "!*hooked" failed: file
"../../../../kern/kern_module_hook.c", line 70
Does the attached patch seem reasonable to you?
Thanks,
rin
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
!DSPAM:5fa2ae10252946113815662!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys/kern
OK, this is my mistake. When I change the calls in the ptrace_common
modcmd, I should also have renamed the functions (including their
entries in sys/ptrace.h). I will commit this shortly, before I leave.
Thanks for the "recipe" for reproducing the problem - I will try it
later when I return.
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd,
ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd,
ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of
'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
Thanks,
rin
!DSPAM:5fa2b869233318156490363!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys/kern
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd,
ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd,
ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Yes that would be a problem.
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of
'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
I have some prior obligations, so I won't be able to look at this
until this evening.
Thanks for the detailed analysis.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys/kern
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd,
ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd,
ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
Thanks,
rin
Re: CVS commit: src/sys
> On Nov 4, 2020, at 5:33 AM, Paul Goyette wrote: > > I guess I don't understand why a 32-bit architecture would also have > COMPAT_NETBSD32. In this particular case, it's for the old 32-bit ABI that predates the EABI standard the ARM port now uses. -- thorpej
Re: CVS commit: src/sys/kern
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys/kern
On 2020/11/04 22:31, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name: src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't use the ptrace module's
init/fini routines.
To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
Thanks,
rin
Re: CVS commit: src/sys
On Wed, Nov 04, 2020 at 05:33:29AM -0800, Paul Goyette wrote: > I guess I don't understand why a 32-bit architecture would also have > COMPAT_NETBSD32. (At least) mips and arm have various 32bit ABIs that are handled by COMPAT_NETBSD32. Martin
Re: CVS commit: src/sys
I guess I don't understand why a 32-bit architecture would also have COMPAT_NETBSD32. Christos, can you help out on this? On Wed, 4 Nov 2020, Rin Okuyama wrote: Hello again, On 2020/11/02 3:51, Paul Goyette wrote: Module Name:src Committed By: pgoyette Date: Sun Nov 1 18:51:03 UTC 2020 Modified Files: src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c sys_ptrace_common.c src/sys/modules: Makefile src/sys/modules/compat_netbsd32: Makefile src/sys/modules/coredump: Makefile src/sys/sys: compat_stub.h param.h signalvar.h Added Files: src/sys/modules/compat_netbsd32_coredump: Makefile Log Message: Separate the compat_netbsd32_coredump from the compat_netbsd32 and coredump modules, into its own module. Welcome to 7.99.75 !!! To generate a diff of this commit: cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm, coredump_elf32_hook is already hooked in the main kernel. Therefore, compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure: panic: kernel diagnostic assertion "!*hooked" failed: file "../../../../kern/kern_module_hook.c", line 70 Does the attached patch seem reasonable to you? Thanks, rin !DSPAM:5fa25cf9259143308188765! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/sys/kern
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't use the ptrace module's
init/fini routines.
To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys
Hello again,
On 2020/11/02 3:51, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Nov 1 18:51:03 UTC 2020
Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile
Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.
Welcome to 7.99.75 !!!
To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:
panic: kernel diagnostic assertion "!*hooked" failed: file
"../../../../kern/kern_module_hook.c", line 70
Does the attached patch seem reasonable to you?
Thanks,
rin
Index: sys/compat/netbsd32/netbsd32_core.c
===
RCS file: /home/netbsd/src/sys/compat/netbsd32/netbsd32_core.c,v
retrieving revision 1.16
diff -p -u -r1.16 netbsd32_core.c
--- sys/compat/netbsd32/netbsd32_core.c 1 Nov 2020 18:51:02 - 1.16
+++ sys/compat/netbsd32/netbsd32_core.c 4 Nov 2020 06:52:52 -
@@ -68,11 +68,15 @@ compat_netbsd32_coredump_modcmd(modcmd_t
switch (cmd) {
case MODULE_CMD_INIT:
MODULE_HOOK_SET(coredump_netbsd32_hook, real_coredump_netbsd32);
+#ifdef _LP64
MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
+#endif
return 0;
case MODULE_CMD_FINI:
MODULE_HOOK_UNSET(coredump_netbsd32_hook);
+#ifdef _LP64
MODULE_HOOK_UNSET(coredump_elf32_hook);
+#endif
return 0;
default:
return ENOTTY;
Re: CVS commit: src/sys/kern
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't use the ptrace module's
init/fini routines.
To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.
Thanks,
rin
Re: CVS commit: src/sys
On Sun, 1 Nov 2020, Paul Goyette wrote: Module Name:src Committed By: pgoyette Date: Sun Nov 1 18:51:03 UTC 2020 Modified Files: src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c sys_ptrace_common.c src/sys/modules: Makefile src/sys/modules/compat_netbsd32: Makefile src/sys/modules/coredump: Makefile src/sys/sys: compat_stub.h param.h signalvar.h Added Files: src/sys/modules/compat_netbsd32_coredump: Makefile Log Message: Separate the compat_netbsd32_coredump from the compat_netbsd32 and coredump modules, into its own module. Welcome to 7.99.75 !!! Of course, this should be "Welcome to 9.99.75" :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/external/bsd/tmux
I've asked. Best, christos > On Nov 1, 2020, at 11:19 AM, Kimmo Suominen wrote: > >> Log Message: >> CHANGED FROM 3.1b TO 3.1c >> >> * Do not write after the end of the array and overwrite the stack when >> colon-separated SGR sequences contain empty arguments. > > Pullup to -9 and -8 for security fix? > > https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/external/bsd/tmux
> Log Message: > CHANGED FROM 3.1b TO 3.1c > > * Do not write after the end of the array and overwrite the stack when > colon-separated SGR sequences contain empty arguments. Pullup to -9 and -8 for security fix? https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html
Re: CVS commit: src
On Wed, 2020-10-28 at 11:56 +, nia wrote: > On Tue, Oct 27, 2020 at 05:01:51PM -0400, David H. Gutteridge wrote: > > > i can have a look at mate-applets tomorrow, the current code looks > > > like it won't work with AMD CPUs on netbsd-9 and that should > > > ideally > > > be fixed. > > > > Yeah, that's my understanding. (I'm guessing Youri only had Intel > > hardware to test with, which was also true for me until recently. > > i actually can't get the mate-applets cpufreq thing to work at all, > it keeps thinking my CPU is running at 2 MHz. was it working for > you before the change? I just tried it with 9.99.72 from September (on an Intel i5-3340M), and I get the same bogus "2 MHz" value reported. I'd thought it had worked at some point in the past, but maybe I'm misremembering. (I don't normally use mate-applets myself; I only test it if I'm updating MATE packages to a new version. I'd remembered the code in question from looking through it some time ago.) Dave
Re: CVS commit: src
On Tue, Oct 27, 2020 at 05:01:51PM -0400, David H. Gutteridge wrote: > > i can have a look at mate-applets tomorrow, the current code looks > > like it won't work with AMD CPUs on netbsd-9 and that should ideally > > be fixed. > > Yeah, that's my understanding. (I'm guessing Youri only had Intel > hardware to test with, which was also true for me until recently. i actually can't get the mate-applets cpufreq thing to work at all, it keeps thinking my CPU is running at 2 MHz. was it working for you before the change?
Re: CVS commit: src
On Tue, 2020-10-27 at 19:54 +, nia wrote: > On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote: > > On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote: > > > On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote: > > > > this doesn't seem like the right design. we have cpus > > > > already that have multiple frequency domains, so this > > > > doesn't work with that setup, so attempt to use it as a > > > > general method for estd etc seems limited and thsu not > > > > the right method. > > > > > > > > eg, rk3399 systems have .cpu0 and .cpu4 domains for the > > > > 4 slow and 2 fast cores it has, and they have both > > > > separate controls as well as list of available freqs: > > > > > > > > machdep.cpufreq.cpu0.target = 1416 > > > > machdep.cpufreq.cpu0.current = 1416 > > > > machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408 > > > > machdep.cpufreq.cpu4.target = 1800 > > > > machdep.cpufreq.cpu4.current = 1800 > > > > machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 > > > > 600 408 > > > > > > > > > > yeah, i'm aware of this, my intent was really only to normalize > > > the variables that didn't have multi-cpu-domain support (since > > > those are already normalized as rk3399) > > > > > > do you think we should use the same variable and tie things to > > > under cpu0 when there isn't support for scaling independent CPUs? > > > > > > > additionally, if we are going to design a "good" API for > > > > this, it should publish things outside of "machdep". > > > > i'd go with hw.cpufreq probbaly. > > > > > > > > (i didn't look, but it sure would be annoying if the old > > > > nodes that have existed for over a decade were changed > > > > and any other 3rd party code or scrip tis now broken.) > > > > > > i actually picked this name because it was already in use and > > > thus already checked by estd. > > > > > > i agree it should go outside machdep, but i didn't want > > > to break existing code. > > > > This has impacted youri@'s NetBSD frequency handling patches in x11/ > > mate-applets, which only make references using > > "machdep.est.frequency" > > at present. > > > > Since this change removes pre-existing sysctl nodes, shouldn't this > > merit a kernel version bump? It potentially breaks things in user- > > space. (I see from the mailing list archives that Mouse asked about > > the idea of retaining old names for compatibility.) > > > > (Now, the mate-applets situation could be improved by the new, > > generic > > means of exposing this information. martin@ had asked for non-x86 > > support in PR pkg/53975, one of the barriers being I imagine few > > people > > have the hardware to test with. I don't.) > > > > Dave > > > > > > i can have a look at mate-applets tomorrow, the current code looks > like it won't work with AMD CPUs on netbsd-9 and that should ideally > be fixed. Yeah, that's my understanding. (I'm guessing Youri only had Intel hardware to test with, which was also true for me until recently.) > i thought kernel versions were specifically about module > compatibility. That may be the case, that was a question for any kernel developers at large. :) Dave
Re: CVS commit: src
On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote: > On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote: > >On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote: > >> this doesn't seem like the right design. we have cpus > >> already that have multiple frequency domains, so this > >> doesn't work with that setup, so attempt to use it as a > >> general method for estd etc seems limited and thsu not > >> the right method. > >> > >> eg, rk3399 systems have .cpu0 and .cpu4 domains for the > >> 4 slow and 2 fast cores it has, and they have both > >> separate controls as well as list of available freqs: > >> > >> machdep.cpufreq.cpu0.target = 1416 > >> machdep.cpufreq.cpu0.current = 1416 > >> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408 > >> machdep.cpufreq.cpu4.target = 1800 > >> machdep.cpufreq.cpu4.current = 1800 > >> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408 > >> > > > >yeah, i'm aware of this, my intent was really only to normalize > >the variables that didn't have multi-cpu-domain support (since > >those are already normalized as rk3399) > > > >do you think we should use the same variable and tie things to > >under cpu0 when there isn't support for scaling independent CPUs? > > > >> additionally, if we are going to design a "good" API for > >> this, it should publish things outside of "machdep". > >> i'd go with hw.cpufreq probbaly. > >> > >> (i didn't look, but it sure would be annoying if the old > >> nodes that have existed for over a decade were changed > >> and any other 3rd party code or scrip tis now broken.) > > > >i actually picked this name because it was already in use and > >thus already checked by estd. > > > >i agree it should go outside machdep, but i didn't want > >to break existing code. > > This has impacted youri@'s NetBSD frequency handling patches in x11/ > mate-applets, which only make references using "machdep.est.frequency" > at present. > > Since this change removes pre-existing sysctl nodes, shouldn't this > merit a kernel version bump? It potentially breaks things in user- > space. (I see from the mailing list archives that Mouse asked about > the idea of retaining old names for compatibility.) > > (Now, the mate-applets situation could be improved by the new, generic > means of exposing this information. martin@ had asked for non-x86 > support in PR pkg/53975, one of the barriers being I imagine few people > have the hardware to test with. I don't.) > > Dave > > i can have a look at mate-applets tomorrow, the current code looks like it won't work with AMD CPUs on netbsd-9 and that should ideally be fixed. i thought kernel versions were specifically about module compatibility.
Re: CVS commit: src
On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote: >On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote: >> this doesn't seem like the right design. we have cpus >> already that have multiple frequency domains, so this >> doesn't work with that setup, so attempt to use it as a >> general method for estd etc seems limited and thsu not >> the right method. >> >> eg, rk3399 systems have .cpu0 and .cpu4 domains for the >> 4 slow and 2 fast cores it has, and they have both >> separate controls as well as list of available freqs: >> >> machdep.cpufreq.cpu0.target = 1416 >> machdep.cpufreq.cpu0.current = 1416 >> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408 >> machdep.cpufreq.cpu4.target = 1800 >> machdep.cpufreq.cpu4.current = 1800 >> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408 >> > >yeah, i'm aware of this, my intent was really only to normalize >the variables that didn't have multi-cpu-domain support (since >those are already normalized as rk3399) > >do you think we should use the same variable and tie things to >under cpu0 when there isn't support for scaling independent CPUs? > >> additionally, if we are going to design a "good" API for >> this, it should publish things outside of "machdep". >> i'd go with hw.cpufreq probbaly. >> >> (i didn't look, but it sure would be annoying if the old >> nodes that have existed for over a decade were changed >> and any other 3rd party code or scrip tis now broken.) > >i actually picked this name because it was already in use and >thus already checked by estd. > >i agree it should go outside machdep, but i didn't want >to break existing code. This has impacted youri@'s NetBSD frequency handling patches in x11/ mate-applets, which only make references using "machdep.est.frequency" at present. Since this change removes pre-existing sysctl nodes, shouldn't this merit a kernel version bump? It potentially breaks things in user- space. (I see from the mailing list archives that Mouse asked about the idea of retaining old names for compatibility.) (Now, the mate-applets situation could be improved by the new, generic means of exposing this information. martin@ had asked for non-x86 support in PR pkg/53975, one of the barriers being I imagine few people have the hardware to test with. I don't.) Dave
Re: CVS commit: src
On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote: > this doesn't seem like the right design. we have cpus > already that have multiple frequency domains, so this > doesn't work with that setup, so attempt to use it as a > general method for estd etc seems limited and thsu not > the right method. > > eg, rk3399 systems have .cpu0 and .cpu4 domains for the > 4 slow and 2 fast cores it has, and they have both > separate controls as well as list of available freqs: > > machdep.cpufreq.cpu0.target = 1416 > machdep.cpufreq.cpu0.current = 1416 > machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408 > machdep.cpufreq.cpu4.target = 1800 > machdep.cpufreq.cpu4.current = 1800 > machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408 > yeah, i'm aware of this, my intent was really only to normalize the variables that didn't have multi-cpu-domain support (since those are already normalized as rk3399) do you think we should use the same variable and tie things to under cpu0 when there isn't support for scaling independent CPUs? > additionally, if we are going to design a "good" API for > this, it should publish things outside of "machdep". > i'd go with hw.cpufreq probbaly. > > (i didn't look, but it sure would be annoying if the old > nodes that have existed for over a decade were changed > and any other 3rd party code or scrip tis now broken.) i actually picked this name because it was already in use and thus already checked by estd. i agree it should go outside machdep, but i didn't want to break existing code.
Re: CVS commit: src/usr.bin/make
On Sun, Oct 25, 2020 at 05:37:36PM +, Simon J. Gerraty wrote: > Modified Files: > src/usr.bin/make: main.c > src/usr.bin/make/unit-tests: varmod-match-escape.exp > > Log Message: > Skip reading .MAKE.DEPENDFILE if set to > "/dev/null" or anything starting with "no". > > Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223564 I object to this, particularly the "no" part but also making /dev/null magic. This is an unnecessary workaround for a bug in freebsd's build system. If there's going to be a change, it should be removing the :T from the generated reference; there is no reason to remove the directory name from a user-supplied .MAKE.DEPENDFILE, and the default doesn't have a directory part. That would also remove the problem freebsd's seeing, and would be, y'know, actually correct. (also the application of :T is undocumented as well as wrong) kept for reference: > To generate a diff of this commit: > cvs rdiff -u -r1.388 -r1.389 src/usr.bin/make/main.c > cvs rdiff -u -r1.1 -r1.2 src/usr.bin/make/unit-tests/varmod-match-escape.exp -- David A. Holland dholl...@netbsd.org
re: CVS commit: src
"Nia Alarie" writes: > Module Name: src > Committed By: nia > Date: Sun Oct 25 16:39:00 UTC 2020 > > Modified Files: > src/share/man/man4: acpicpu.4 > src/share/man/man4/man4.x86: est.4 powernow.4 > src/sys/arch/evbmips/loongson: loongson_clock.c > src/sys/arch/macppc/dev: obio.c > src/sys/arch/x86/acpi: acpi_cpu_md.c > src/sys/arch/x86/x86: est.c powernow.c > > Log Message: > Normalize some machine dependent CPU frequenct sysctl variables. > > This moves machdep.*.frequency.* to machdep.cpu.frequency.*. > > This was proposed on tech-kern some time ago. The intention is to allow > third-party tools such as estd and conky to more easily and reliably > fetch or modify the current CPU frequency without iterating through > various machine-dependent variables to check their presence. sorry, i must have missed your tech-kern post. this doesn't seem like the right design. we have cpus already that have multiple frequency domains, so this doesn't work with that setup, so attempt to use it as a general method for estd etc seems limited and thsu not the right method. eg, rk3399 systems have .cpu0 and .cpu4 domains for the 4 slow and 2 fast cores it has, and they have both separate controls as well as list of available freqs: machdep.cpufreq.cpu0.target = 1416 machdep.cpufreq.cpu0.current = 1416 machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408 machdep.cpufreq.cpu4.target = 1800 machdep.cpufreq.cpu4.current = 1800 machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408 additionally, if we are going to design a "good" API for this, it should publish things outside of "machdep". i'd go with hw.cpufreq probbaly. .mrg. (i didn't look, but it sure would be annoying if the old nodes that have existed for over a decade were changed and any other 3rd party code or scrip tis now broken.)
Re: CVS commit: src/sbin/mount
On Sat, Oct 24, 2020 at 10:38:04PM +0700, Robert Elz wrote: > | file systems that are used as what spools? > > Ah, youth! > > The old text: > This option is useful for optimizing read performance on file systems > that are used as news spools. > was refering to netnews (usenet, NNTP or whatever). Don't worry, I know about usenet. I just think it's a particularly obscure use case today, even for netbsd! > Such a filesystem is almost certainly not going to care about access times > (this is about uses for the noatime flag, to save others needing to go look > at what changed) as the news articles are referenced by large numbers of > news readers, and outgoing feeds, and when any of that happened is of no > interest to the server or its maintainers, at all - but it happens (or > happened, when usenet was a big thing) a lot, and not bothering to update > the access times could mean a lot of unnecessary writes to an already very > busy filesystem. > > All that said, note that I am not objecting to the change (referring to > flash based filesystems rather than news spools) it is a little more > currently relevant. > > kre Thanks for the background information.
Re: CVS commit: src/sbin/mount
On Sat, Oct 24, 2020 at 10:51:34AM +, Nia Alarie wrote: > Modified Files: > src/sbin/mount: mount.8 > > Log Message: > file systems that are used as what spools? Kibozing caches. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/sparc64/dev
Hi Tobias, > If you're interested there is an older version[1] of envctrl in the > Attic that might be relevant to use for reference. It supported fan > speed controls on E450. IIRC I got some of the magic constants from > OpenSolaris. Sadly I don't own an E450 any more. > > [1] > cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/sparc64/dev/Attic/envctrl.c?rev=1.11=text/plain_with_tag=MAIN Thank you - that's useful information! Related to the magic offsets, I noticed that the value read from the sensor was always lower than the value written. However, it doesn't appear to be a constant difference (I see about 15 for most values, but only 5 for the minimum). I think that it's OK to keep the higher value - it'll mean that we run the fans slightly faster. The CPU temperature on my E250 doesn't reach the minimum threshold where the fan speed actually increases, so I don't think that this will have any impact. The GPIO values there helps to see what values I should be checking for too. It would be good to merge this with the current code, but I only have an E250 to test on, so I'll need to find a volunteer. Regards, Julian
Re: CVS commit: src/sys/arch/sparc64/dev
On Sat, 24 Oct 2020 15:16:39 + Julian Coleman wrote: > Module Name: src > Committed By: jdc > Date: Sat Oct 24 15:16:39 UTC 2020 > > Modified Files: > src/sys/arch/sparc64/dev: pcf8591_envctrl.c > > Log Message: > Add support for automatically changing the CPU fan speed on the E250 in a > similar way to the SB1000/SB2000. > The fan control information was determined by experiment, as it's only > partially available in OFW. > Hardcode the missing information for E250 fan control into the driver > (it should be possible to support the E450 in future too). If you're interested there is an older version[1] of envctrl in the Attic that might be relevant to use for reference. It supported fan speed controls on E450. IIRC I got some of the magic constants from OpenSolaris. Sadly I don't own an E450 any more. [1] cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/sparc64/dev/Attic/envctrl.c?rev=1.11=text/plain_with_tag=MAIN
