Re: svn commit: r365371 - in head: . contrib/jemalloc contrib/jemalloc/doc lib/libc/stdlib/jemalloc share/man/man5 share/mk tools/build/options
On 9/5/20 4:30 PM, Dimitry Andric wrote: > Author: dim > Date: Sat Sep 5 23:30:17 2020 > New Revision: 365371 > URL: https://svnweb.freebsd.org/changeset/base/365371 > > Log: > Turn MALLOC_PRODUCTION into a regular src.conf(5) option > > Added: head/tools/build/options/WITHOUT_MALLOC_PRODUCTION > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/tools/build/options/WITHOUT_MALLOC_PRODUCTIONSat Sep 5 > 23:30:17 2020(r365371) > @@ -0,0 +1,5 @@ > +.\" $FreeBSD$ > +Set to enable assertions and statistics gathering in > +.Xr malloc 3 . > +It also defaults the A and J runtime options to on. > +Enabled by default on -CURRENT. > > Added: head/tools/build/options/WITH_MALLOC_PRODUCTION > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/tools/build/options/WITH_MALLOC_PRODUCTION Sat Sep 5 23:30:17 > 2020(r365371) > @@ -0,0 +1,5 @@ > +.\" $FreeBSD$ > +Set to disable assertions and statistics gathering in > +.Xr malloc 3 . > +It also defaults the A and J runtime options to off. > +Disabled by default on -CURRENT. I think this last sentence doesn't quite read correctly. That is, I read it as saying that "assertions and statistics gathering" is disabled by default on -CURRENT, which isn't correct. It also won't be very meaningful to someone reading src.conf.5 on a stable branch if this is MFC'd (or when it ends up in stable/13). I think it would be best to just leave the last sentence off completely. The result would be that on head src.conf(5) would say: WITH_MALLOC_PRODUCTION Set to disable assertions... And on stable src.conf(5) would say: WITHOUT_MALLOC_PRODUCTION Set to enable assertions... Just as when other defaults change across branches, the current vs stable different is handled by the contents of src.conf.5 on each branch. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365371 - in head: . contrib/jemalloc contrib/jemalloc/doc lib/libc/stdlib/jemalloc share/man/man5 share/mk tools/build/options
Author: dim
Date: Sat Sep 5 23:30:17 2020
New Revision: 365371
URL: https://svnweb.freebsd.org/changeset/base/365371
Log:
Turn MALLOC_PRODUCTION into a regular src.conf(5) option
For historical reasons, defining MALLOC_PRODUCTION in /etc/make.conf has
been used to turn off potentially expensive debug checks and statistics
gathering in the implementation of malloc(3).
It seems more consistent to turn this into a regular src.conf(5) option,
e.g. WITH_MALLOC_PRODUCTION / WITHOUT_MALLOC_PRODUCTION. This can then
be toggled similar to any other source build option, and turned on or
off by default for e.g. stable branches.
Reviewed by: imp, #manpages
MFC after:1 week
Differential Revision: https://reviews.freebsd.org/D26337
Added:
head/tools/build/options/WITHOUT_MALLOC_PRODUCTION (contents, props changed)
head/tools/build/options/WITH_MALLOC_PRODUCTION (contents, props changed)
Modified:
head/UPDATING
head/contrib/jemalloc/FREEBSD-diffs
head/contrib/jemalloc/doc/jemalloc.3
head/lib/libc/stdlib/jemalloc/Makefile.inc
head/share/man/man5/make.conf.5
head/share/man/man5/src.conf.5
head/share/mk/src.opts.mk
Modified: head/UPDATING
==
--- head/UPDATING Sat Sep 5 22:48:27 2020(r365370)
+++ head/UPDATING Sat Sep 5 23:30:17 2020(r365371)
@@ -22,9 +22,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
debugging flags in userland, and various verbose features in the
kernel. Many developers choose to disable these features on build
machines to maximize performance. (To completely disable malloc
- debugging, define MALLOC_PRODUCTION in /etc/make.conf, or to merely
- disable the most expensive debugging functionality run
- "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
+ debugging, define WITH_MALLOC_PRODUCTION in /etc/src.conf and rebuild
+ world, or to merely disable the most expensive debugging functionality
+ at runtime, run "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
20200824:
OpenZFS support has been integrated. Do not upgrade root pools until
Modified: head/contrib/jemalloc/FREEBSD-diffs
==
--- head/contrib/jemalloc/FREEBSD-diffs Sat Sep 5 22:48:27 2020
(r365370)
+++ head/contrib/jemalloc/FREEBSD-diffs Sat Sep 5 23:30:17 2020
(r365371)
@@ -14,7 +14,7 @@ index 7fecda7c..d5ca5e86 100644
+--with-malloc-conf=abort_conf:false.
+Additionally, --enable-debug is enabled in development
+versions of FreeBSD (controlled by the
-+MALLOC_PRODUCTION make variable).
++MK_MALLOC_PRODUCTION make variable).
+
Modified: head/contrib/jemalloc/doc/jemalloc.3
==
--- head/contrib/jemalloc/doc/jemalloc.3Sat Sep 5 22:48:27 2020
(r365370)
+++ head/contrib/jemalloc/doc/jemalloc.3Sat Sep 5 23:30:17 2020
(r365371)
@@ -43,7 +43,7 @@ The following configuration options are enabled in lib
\fB\-\-with\-malloc\-conf=abort_conf:false\fR\&. Additionally,
\fB\-\-enable\-debug\fR
is enabled in development versions of FreeBSD (controlled by the
-\fBMALLOC_PRODUCTION\fR
+\fBMK_MALLOC_PRODUCTION\fR
make variable)\&.
.SH "SYNOPSIS"
.sp
Modified: head/lib/libc/stdlib/jemalloc/Makefile.inc
==
--- head/lib/libc/stdlib/jemalloc/Makefile.inc Sat Sep 5 22:48:27 2020
(r365370)
+++ head/lib/libc/stdlib/jemalloc/Makefile.inc Sat Sep 5 23:30:17 2020
(r365371)
@@ -45,6 +45,6 @@ MLINKS+= \
jemalloc.3 nallocx.3 \
jemalloc.3 malloc.conf.5
-.if defined(MALLOC_PRODUCTION)
+.if ${MK_MALLOC_PRODUCTION} != "no"
CFLAGS+= -DMALLOC_PRODUCTION
.endif
Modified: head/share/man/man5/make.conf.5
==
--- head/share/man/man5/make.conf.5 Sat Sep 5 22:48:27 2020
(r365370)
+++ head/share/man/man5/make.conf.5 Sat Sep 5 23:30:17 2020
(r365371)
@@ -401,12 +401,6 @@ console driver to
and allow access over FireWire(IEEE1394) using
.Xr dconschat 8 .
Currently, only i386 and amd64 are supported.
-.It Va MALLOC_PRODUCTION
-.Pq Vt bool
-Set this to disable assertions and statistics gathering in
-.Xr malloc 3 .
-It also defaults the A and J runtime options to off.
-Disabled by default on -CURRENT.
.It Va MAN_ARCH
.Pq Vt str
Space-delimited list of one or more MACHINE and/or MACHINE_ARCH values
Modified: head/share/man/man5/src.conf.5
==
--- head/share/man/man5/src.conf.5 Sat Sep 5 22:48:27 2020
(r365370)
+++ head/share/man/man5/src.conf.5 Sat Sep 5 23:30:17 2020
(r365371)
@@
svn commit: r365370 - head/libexec/rtld-elf
Author: kib
Date: Sat Sep 5 22:48:27 2020
New Revision: 365370
URL: https://svnweb.freebsd.org/changeset/base/365370
Log:
Undo 'fix off by one' part of r365360.
Noted by: emaste
Sponsored by: The FreeBSD Foundation
MFC after:6 days
Modified:
head/libexec/rtld-elf/map_object.c
Modified: head/libexec/rtld-elf/map_object.c
==
--- head/libexec/rtld-elf/map_object.c Sat Sep 5 22:44:38 2020
(r365369)
+++ head/libexec/rtld-elf/map_object.c Sat Sep 5 22:48:27 2020
(r365370)
@@ -49,7 +49,7 @@ int __getosreldate(void);
static bool
phdr_in_zero_page(const Elf_Ehdr *hdr)
{
- return (hdr->e_phoff + hdr->e_phnum * sizeof(Elf_Phdr) <
+ return (hdr->e_phoff + hdr->e_phnum * sizeof(Elf_Phdr) <=
(size_t)PAGE_SIZE);
}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365369 - head/libexec/rtld-elf
Author: kib
Date: Sat Sep 5 22:44:38 2020
New Revision: 365369
URL: https://svnweb.freebsd.org/changeset/base/365369
Log:
rtld: do not refuse to relocate objects without dynamic symtabs.
Such objects can still have valid relocations not requiring symbolic
references.
PR: 249121
Reported by: w...@riski.sh
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/libexec/rtld-elf/rtld.c
Modified: head/libexec/rtld-elf/rtld.c
==
--- head/libexec/rtld-elf/rtld.cSat Sep 5 22:41:31 2020
(r365368)
+++ head/libexec/rtld-elf/rtld.cSat Sep 5 22:44:38 2020
(r365369)
@@ -3013,11 +3013,8 @@ relocate_object(Obj_Entry *obj, bool bind_now, Obj_Ent
dbg("relocating \"%s\"", obj->path);
if (obj->symtab == NULL || obj->strtab == NULL ||
- !(obj->valid_hash_sysv || obj->valid_hash_gnu)) {
- _rtld_error("%s: Shared object has no run-time symbol table",
- obj->path);
- return (-1);
- }
+ !(obj->valid_hash_sysv || obj->valid_hash_gnu))
+ dbg("object %s has no run-time symbol table", obj->path);
/* There are relocations to the write-protected text segment. */
if (obj->textrel && reloc_textrel_prot(obj, true) != 0)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365368 - head/libexec/rtld-elf
Author: kib
Date: Sat Sep 5 22:41:31 2020
New Revision: 365368
URL: https://svnweb.freebsd.org/changeset/base/365368
Log:
rtld: do not process absent dynamic.
If object has no dynamic phdr, do not try to dereference NULL. This
means that we cannot process any relocation, and that there cannot be
symbols defined, but it is up to static linker to produce meaningful
objects.
PR: 249121
Reported by: w...@riski.sh
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/libexec/rtld-elf/rtld.c
Modified: head/libexec/rtld-elf/rtld.c
==
--- head/libexec/rtld-elf/rtld.cSat Sep 5 20:22:02 2020
(r365367)
+++ head/libexec/rtld-elf/rtld.cSat Sep 5 22:41:31 2020
(r365368)
@@ -1089,7 +1089,10 @@ digest_dynamic1(Obj_Entry *obj, int early, const Elf_D
*dyn_runpath = NULL;
obj->bind_now = false;
-for (dynp = obj->dynamic; dynp->d_tag != DT_NULL; dynp++) {
+dynp = obj->dynamic;
+if (dynp == NULL)
+ return;
+for (; dynp->d_tag != DT_NULL; dynp++) {
switch (dynp->d_tag) {
case DT_REL:
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
> From: Ed Maste > Date: Sat, 5 Sep 2020 17:26:47 -0400 > Subject: Re: svn commit: r365071 - in head/sys: net net/altq net/route > net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu > netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgraph... > On Sat, 5 Sep 2020 at 16:41, Warner Losh wrote: > > > >> Fixed: > >> - *_FOREACH now has a space before (, equivalent to for (;;) > > > > Except pretty much everywhere we don't have a space there... > Why not? Why should TAILQ_FOREACH have a different style from a for loop? Because it is a macro, maybe? And all the other invocations are done that way. > > broke all alignment of variables and comments that were done. > > broke purposely outdented code in statistics function > > broke all err() calls to wrap too much > I had all of these under "indifferent" already, or are more examples > of already covered cases (e.g. what seems to be string argument > wrapping). I don't consider those indifferent. > > extra headers still included. > This is probably not the job of a formatter though. > >> - function argument wrapping (see write_glyph_buf) > >> - leading indentation and args-per-line (print_font_info) > > > > An interesting experiment, but there's far more worse after than before. > > The rearranging of carefully aligned elements is an especially galling > > change for some people (myself included). > I disagree this is far worse. If we fixed the wrapping on the second > line of if/for conditions I'd say the benefit of letting tooling take > care of the formatting outweighs the perhaps slightly less appealing > formatting. I'm with Warner on this. I saw a lot to dislike in the changes, and very little actual improvement. If we were starting from scratch, I might be willing to accept the changes to have a formatter (albeit begrudingly), but we are not starting from scratch. The churn would be horrible, and the benefit very little in comparison. Interesting experiment, but let's keep it just an experiment. Mike ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
On Sat, 5 Sep 2020 at 16:41, Warner Losh wrote: > >> Fixed: >> - *_FOREACH now has a space before (, equivalent to for (;;) > > Except pretty much everywhere we don't have a space there... Why not? Why should TAILQ_FOREACH have a different style from a for loop? > broke all alignment of variables and comments that were done. > broke purposely outdented code in statistics function > broke all err() calls to wrap too much I had all of these under "indifferent" already, or are more examples of already covered cases (e.g. what seems to be string argument wrapping). > extra headers still included. This is probably not the job of a formatter though. >> - function argument wrapping (see write_glyph_buf) >> - leading indentation and args-per-line (print_font_info) > > An interesting experiment, but there's far more worse after than before. The > rearranging of carefully aligned elements is an especially galling change for > some people (myself included). I disagree this is far worse. If we fixed the wrapping on the second line of if/for conditions I'd say the benefit of letting tooling take care of the formatting outweighs the perhaps slightly less appealing formatting. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365366 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake usr.bin/bmake/unit-tests
On Sat, 2020-09-05 at 19:29 +, Simon J. Gerraty wrote:
> o new debug option -dl: LINT mode, does the equivalent of := for all
> variable assignments so that file and line number are reported for
> variable parse errors.
Doesn't -dl already have a meaning ("loud" builds)?
-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365367 - head/share/man/man9
Author: mjg Date: Sat Sep 5 20:22:02 2020 New Revision: 365367 URL: https://svnweb.freebsd.org/changeset/base/365367 Log: sx: fix up manpage after r363113 No date change as there is no new information. Submitted by: sig...@gmail.com Differential Revision: https://reviews.freebsd.org/D26341 Modified: head/share/man/man9/sx.9 Modified: head/share/man/man9/sx.9 == --- head/share/man/man9/sx.9Sat Sep 5 19:29:42 2020(r365366) +++ head/share/man/man9/sx.9Sat Sep 5 20:22:02 2020(r365367) @@ -124,6 +124,7 @@ argument to specifies a set of optional flags to alter the behavior of .Fa sx . It contains one or more of the following flags: +.Bl -tag -width SX_NOWITNESS .It Dv SX_DUPOK Witness should not log messages about duplicate locks being acquired. .It Dv SX_NOWITNESS ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365366 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake usr.bin/bmake/unit-tests
Author: sjg Date: Sat Sep 5 19:29:42 2020 New Revision: 365366 URL: https://svnweb.freebsd.org/changeset/base/365366 Log: Update to bmake-20200902 Lots of code refactoring, simplification and cleanup. Lots of new unit-tests providing much higher code coverage. All courtesy of rillig at netbsd. Other significant changes: o new read-only variable .SHELL which provides the path of the shell used to run scripts (as defined by the .SHELL target). o variable parsing detects more errors. o new debug option -dl: LINT mode, does the equivalent of := for all variable assignments so that file and line number are reported for variable parse errors. Added: head/contrib/bmake/enum.c - copied unchanged from r365363, vendor/NetBSD/bmake/dist/enum.c head/contrib/bmake/enum.h - copied unchanged from r365363, vendor/NetBSD/bmake/dist/enum.h head/contrib/bmake/lst.c - copied unchanged from r365363, vendor/NetBSD/bmake/dist/lst.c head/contrib/bmake/mk/dirdeps-cache-update.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/mk/dirdeps-cache-update.mk head/contrib/bmake/unit-tests/archive-suffix.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/archive-suffix.exp head/contrib/bmake/unit-tests/archive-suffix.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/archive-suffix.mk head/contrib/bmake/unit-tests/archive.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/archive.exp head/contrib/bmake/unit-tests/archive.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/archive.mk head/contrib/bmake/unit-tests/cmd-interrupt.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cmd-interrupt.exp head/contrib/bmake/unit-tests/cmd-interrupt.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cmd-interrupt.mk head/contrib/bmake/unit-tests/cmdline.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cmdline.exp head/contrib/bmake/unit-tests/cmdline.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cmdline.mk head/contrib/bmake/unit-tests/cond-cmp-numeric-eq.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-eq.exp head/contrib/bmake/unit-tests/cond-cmp-numeric-eq.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-eq.mk head/contrib/bmake/unit-tests/cond-cmp-numeric-ge.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-ge.exp head/contrib/bmake/unit-tests/cond-cmp-numeric-ge.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-ge.mk head/contrib/bmake/unit-tests/cond-cmp-numeric-gt.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-gt.exp head/contrib/bmake/unit-tests/cond-cmp-numeric-gt.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-gt.mk head/contrib/bmake/unit-tests/cond-cmp-numeric-le.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-le.exp head/contrib/bmake/unit-tests/cond-cmp-numeric-le.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-le.mk head/contrib/bmake/unit-tests/cond-cmp-numeric-lt.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-lt.exp head/contrib/bmake/unit-tests/cond-cmp-numeric-lt.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-lt.mk head/contrib/bmake/unit-tests/cond-cmp-numeric-ne.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-ne.exp head/contrib/bmake/unit-tests/cond-cmp-numeric-ne.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-ne.mk head/contrib/bmake/unit-tests/cond-cmp-numeric.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric.exp head/contrib/bmake/unit-tests/cond-cmp-numeric.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric.mk head/contrib/bmake/unit-tests/cond-cmp-string.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-string.exp head/contrib/bmake/unit-tests/cond-cmp-string.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-string.mk head/contrib/bmake/unit-tests/cond-func-commands.exp - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-func-commands.exp head/contrib/bmake/unit-tests/cond-func-commands.mk - copied unchanged from r365363, vendor/NetBSD/bmake/dist/unit-tests/cond-func-commands.mk head/contrib/bmake/unit-tests/cond-
svn commit: r365365 - head/tools/boot
Author: emaste
Date: Sat Sep 5 19:03:34 2020
New Revision: 365365
URL: https://svnweb.freebsd.org/changeset/base/365365
Log:
ci-qemu-test.sh: use pkgbase
Reviewed by: bcran (earlier), manu (earlier), imp
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D24276
Modified:
head/tools/boot/ci-qemu-test.sh
Modified: head/tools/boot/ci-qemu-test.sh
==
--- head/tools/boot/ci-qemu-test.sh Sat Sep 5 17:02:48 2020
(r365364)
+++ head/tools/boot/ci-qemu-test.sh Sat Sep 5 19:03:34 2020
(r365365)
@@ -1,11 +1,12 @@
#!/bin/sh
-# Install loader, kernel, and enough of userland to boot in QEMU and echo
-# "Hello world." from init, as a very quick smoke test for CI. Uses QEMU's
-# virtual FAT filesystem to avoid the need to create a disk image. While
-# designed for CI automated testing, this script can also be run by hand as
-# a quick smoke-test. The rootgen.sh and related scripts generate much more
-# extensive tests for many combinations of boot env (ufs, zfs, geli, etc).
+# Install pkgbase packages for loader, kernel, and enough of userland to boot
+# in QEMU and echo "Hello world." from init, as a very quick smoke test for CI.
+# Uses QEMU's virtual FAT filesystem to avoid the need to create a disk image.
+# While designed for CI automated testing, this script can also be run by hand
+# as a quick smoke-test as long as pkgbase packages have been built. The
+# rootgen.sh and related scripts generate much more extensive tests for many
+# combinations of boot env (ufs, zfs, geli, etc).
#
# $FreeBSD$
@@ -26,32 +27,22 @@ tempdir_cleanup()
tempdir_setup()
{
# Create minimal directory structure and populate it.
- # Caller must cd ${SRCTOP} before calling this function.
for dir in dev bin efi/boot etc lib libexec sbin usr/lib usr/libexec; do
mkdir -p ${ROOTDIR}/${dir}
done
# Install kernel, loader and minimal userland.
+ cat<${ROOTDIR}/pkg.conf
+REPOS_DIR=[]
+repositories={local {url = file://$(dirname $OBJTOP)/repo/\${ABI}/latest}}
+EOF
+ ASSUME_ALWAYS_YES=true INSTALL_AS_USER=true pkg \
+ -o ABI_FILE=$OBJTOP/bin/sh/sh \
+ -C ${ROOTDIR}/pkg.conf -r ${ROOTDIR} install \
+ FreeBSD-kernel-generic FreeBSD-bootloader \
+ FreeBSD-clibs FreeBSD-runtime
- make -DNO_ROOT DESTDIR=${ROOTDIR} \
- MODULES_OVERRIDE= \
- WITHOUT_DEBUG_FILES=yes \
- WITHOUT_KERNEL_SYMBOLS=yes \
- installkernel
- for dir in stand \
- lib/libc lib/libedit lib/ncurses \
- libexec/rtld-elf \
- bin/sh sbin/init sbin/shutdown sbin/sysctl; do
- make -DNO_ROOT DESTDIR=${ROOTDIR} INSTALL="install -U" \
- WITHOUT_DEBUG_FILES= \
- WITHOUT_MAN= \
- WITHOUT_PROFILE= \
- WITHOUT_TESTS= \
- WITHOUT_TOOLCHAIN= \
- -C ${dir} install
- done
-
# Put loader in standard EFI location.
mv ${ROOTDIR}/boot/loader.efi ${ROOTDIR}/efi/boot/BOOTx64.EFI
@@ -80,6 +71,10 @@ EOF
: ${SRCTOP:=$(make -V SRCTOP)}
if [ -z "${SRCTOP}" ]; then
die "Cannot locate top of source tree"
+fi
+: ${OBJTOP:=$(make -V OBJTOP)}
+if [ -z "${OBJTOP}" ]; then
+ die "Cannot locate top of object tree"
fi
# Locate the uefi firmware file used by qemu.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365364 - stable/12/usr.bin/systat
Author: mr
Date: Sat Sep 5 17:02:48 2020
New Revision: 365364
URL: https://svnweb.freebsd.org/changeset/base/365364
Log:
MFC r363095:
Handle device removal and removal+add cases to fix infinity rate.
PR: 219829
Submitted by: o...@j.email.ne.jp
Reported by: r...@live.cn
Differential Revision:https://reviews.freebsd.org/D25226
Modified:
stable/12/usr.bin/systat/ifcmds.c
stable/12/usr.bin/systat/ifstat.c
stable/12/usr.bin/systat/systat.1
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/usr.bin/systat/ifcmds.c
==
--- stable/12/usr.bin/systat/ifcmds.c Sat Sep 5 16:44:37 2020
(r365363)
+++ stable/12/usr.bin/systat/ifcmds.c Sat Sep 5 17:02:48 2020
(r365364)
@@ -74,6 +74,8 @@ ifcmd(const char *cmd, const char *args)
}
} else if (prefix(cmd, "pps"))
showpps = !showpps;
+ else
+ return (0);
return (1);
}
Modified: stable/12/usr.bin/systat/ifstat.c
==
--- stable/12/usr.bin/systat/ifstat.c Sat Sep 5 16:44:37 2020
(r365363)
+++ stable/12/usr.bin/systat/ifstat.c Sat Sep 5 17:02:48 2020
(r365364)
@@ -37,6 +37,7 @@
#include
#include
+#include
#include
#include
#include
@@ -67,7 +68,8 @@ SLIST_HEAD(, if_stat_disp)displist;
struct if_stat {
SLIST_ENTRY(if_stat) link;
- charif_name[IF_NAMESIZE];
+ chardisplay_name[IF_NAMESIZE];
+ chardev_name[IFNAMSIZ]; /* copied from ifmibdata */
struct ifmibdata if_mib;
struct timeval tv;
struct timeval tv_lastchanged;
@@ -81,7 +83,7 @@ struct if_stat {
uint64_t if_out_pps_peak;
u_int if_row; /* Index into ifmib sysctl */
int if_ypos;/* -1 if not being displayed */
- u_int display;
+ booldisplay;
u_int match;
};
@@ -91,11 +93,13 @@ extern int showpps;
extern int needsort;
static int needclear = 0;
+static bool displayall = false;
-static void right_align_string(struct if_stat *);
-static void getifmibdata(const int, struct ifmibdata *);
+static void format_device_name(struct if_stat *);
+static int getifmibdata(const int, struct ifmibdata *);
static void sort_interface_list(void);
static u_int getifnum(void);
+static void clearifstat(void);
#define IFSTAT_ERR(n, s) do {\
putchar('\014');\
@@ -165,7 +169,7 @@ static u_int getifnum(void);
} while (0)
#define PUTNAME(p) do {
\
- mvprintw(p->if_ypos, 0, "%s", p->if_name); \
+ mvprintw(p->if_ypos, 0, "%s", p->display_name); \
mvprintw(p->if_ypos, col2-3, "%s", (const char *)"in"); \
mvprintw(p->if_ypos+1, col2-3, "%s", (const char *)"out"); \
} while (0)
@@ -214,7 +218,7 @@ showifstat(void)
SLIST_FOREACH(ifp, &curlist, link) {
if (ifp->if_ypos < LINES - 3 && ifp->if_ypos != -1)
- if (ifp->display == 0 || ifp->match == 0) {
+ if (!ifp->display || ifp->match == 0) {
wmove(wnd, ifp->if_ypos, 0);
wclrtoeol(wnd);
wmove(wnd, ifp->if_ypos + 1, 0);
@@ -235,7 +239,7 @@ int
initifstat(void)
{
struct if_stat *p = NULL;
- u_intn = 0, i = 0;
+ u_intn, i;
n = getifnum();
if (n <= 0)
@@ -247,18 +251,21 @@ initifstat(void)
p = (struct if_stat *)calloc(1, sizeof(struct if_stat));
if (p == NULL)
IFSTAT_ERR(1, "out of memory");
- SLIST_INSERT_HEAD(&curlist, p, link);
p->if_row = i+1;
- getifmibdata(p->if_row, &p->if_mib);
- right_align_string(p);
+ if (getifmibdata(p->if_row, &p->if_mib) == -1) {
+ free(p);
+ continue;
+ }
+ SLIST_INSERT_HEAD(&curlist, p, link);
+ format_device_name(p);
p->match = 1;
/*
* Initially, we only display interfaces that have
-* received some traffic.
+* received some traffic unless display-all is on.
*/
- if (p->if_mib.ifmd_data.ifi_ibytes != 0)
- p->display = 1;
+ if (displayall || p->if_mib.ifmd_data.ifi_ibytes != 0)
+ p->display = true;
}
sort_interface_list();
@@ -269,13 +276,13 @@ initifstat(void)
void
fetc
svn commit: r365363 - vendor/NetBSD/bmake/20200902
Author: sjg Date: Sat Sep 5 16:44:37 2020 New Revision: 365363 URL: https://svnweb.freebsd.org/changeset/base/365363 Log: tag bmake-20200902 Added: vendor/NetBSD/bmake/20200902/ - copied from r365362, vendor/NetBSD/bmake/dist/ ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365362 - head/sys/net
Author: emaste
Date: Sat Sep 5 16:13:36 2020
New Revision: 365362
URL: https://svnweb.freebsd.org/changeset/base/365362
Log:
rtsock.c: remove extraneous space
Submitted by: Neel Chauhan
Differential Revision:https://reviews.freebsd.org/D26249
Modified:
head/sys/net/rtsock.c
Modified: head/sys/net/rtsock.c
==
--- head/sys/net/rtsock.c Sat Sep 5 16:11:04 2020(r365361)
+++ head/sys/net/rtsock.c Sat Sep 5 16:13:36 2020(r365362)
@@ -2137,7 +2137,7 @@ static struct protosw routesw[] = {
static struct domain routedomain = {
.dom_family = PF_ROUTE,
- .dom_name = "route",
+ .dom_name = "route",
.dom_protosw = routesw,
.dom_protoswNPROTOSW = &routesw[nitems(routesw)]
};
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365361 - in vendor/NetBSD/bmake/dist: . lst.lib mk mk/sys unit-tests
Author: sjg Date: Sat Sep 5 16:11:04 2020 New Revision: 365361 URL: https://svnweb.freebsd.org/changeset/base/365361 Log: Import bmake-20200902 Lots of code refactoring, simplification and cleanup. Lots of new unit-tests providing much higher code coverage. All courtesy of rillig at netbsd. Other significant changes: o new read-only variable .SHELL which provides the path of the shell used to run scripts (as defined by the .SHELL target). o new debug option -dl: LINT mode, does the equivalent of := for all variable assignments so that file and line number are reported for variable parse errors. Added: vendor/NetBSD/bmake/dist/enum.c (contents, props changed) vendor/NetBSD/bmake/dist/enum.h (contents, props changed) vendor/NetBSD/bmake/dist/lst.c (contents, props changed) vendor/NetBSD/bmake/dist/mk/dirdeps-cache-update.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/archive-suffix.exp (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/archive-suffix.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/archive.exp vendor/NetBSD/bmake/dist/unit-tests/archive.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cmd-interrupt.exp (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cmd-interrupt.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cmdline.exp vendor/NetBSD/bmake/dist/unit-tests/cmdline.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-eq.exp vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-eq.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-ge.exp vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-ge.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-gt.exp vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-gt.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-le.exp vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-le.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-lt.exp vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-lt.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-ne.exp vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric-ne.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric.exp vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-numeric.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-string.exp vendor/NetBSD/bmake/dist/unit-tests/cond-cmp-string.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-func-commands.exp vendor/NetBSD/bmake/dist/unit-tests/cond-func-commands.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-func-defined.exp vendor/NetBSD/bmake/dist/unit-tests/cond-func-defined.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-func-empty.exp vendor/NetBSD/bmake/dist/unit-tests/cond-func-empty.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-func-exists.exp vendor/NetBSD/bmake/dist/unit-tests/cond-func-exists.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-func-make.exp vendor/NetBSD/bmake/dist/unit-tests/cond-func-make.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-func-target.exp vendor/NetBSD/bmake/dist/unit-tests/cond-func-target.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-func.exp vendor/NetBSD/bmake/dist/unit-tests/cond-func.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-op-and.exp vendor/NetBSD/bmake/dist/unit-tests/cond-op-and.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-op-not.exp vendor/NetBSD/bmake/dist/unit-tests/cond-op-not.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-op-or.exp vendor/NetBSD/bmake/dist/unit-tests/cond-op-or.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-op-parentheses.exp vendor/NetBSD/bmake/dist/unit-tests/cond-op-parentheses.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-op.exp vendor/NetBSD/bmake/dist/unit-tests/cond-op.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-token-number.exp vendor/NetBSD/bmake/dist/unit-tests/cond-token-number.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-token-plain.exp vendor/NetBSD/bmake/dist/unit-tests/cond-token-plain.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-token-string.exp vendor/NetBSD/bmake/dist/unit-tests/cond-token-string.mk (contents, props changed) vendor/NetBSD/bmake/dist/unit-tests/cond-token-var.exp vendor/NetBSD/bmake/dist/unit-tests/cond-token-var.mk (contents, props changed) vendor/Ne
Re: svn commit: r365326 - stable/12/sys/sys
On 4 Sep 2020, at 14:36, Jessica Clarke wrote:
> On 4 Sep 2020, at 14:09, Konstantin Belousov wrote:
>> On Fri, Sep 04, 2020 at 11:22:18AM +, Marcin Wojtas wrote:
>>> Author: mw
>>> Date: Fri Sep 4 11:22:18 2020
>>> New Revision: 365326
>>> URL: https://svnweb.freebsd.org/changeset/base/365326
>>>
>>> Log:
>>> MFC: r346593
>>>
>>> Add barrier in buf ring peek function to prevent race in ARM and ARM64.
>>>
>>> Obtained from: Semihalf
>>> Sponsored by: Amazon, Inc.
>>>
>>> Modified:
>>> stable/12/sys/sys/buf_ring.h
>>> Directory Properties:
>>> stable/12/ (props changed)
>>>
>>> Modified: stable/12/sys/sys/buf_ring.h
>>> ==
>>> --- stable/12/sys/sys/buf_ring.hFri Sep 4 04:31:56 2020
>>> (r365325)
>>> +++ stable/12/sys/sys/buf_ring.hFri Sep 4 11:22:18 2020
>>> (r365326)
>>> @@ -310,14 +310,23 @@ buf_ring_peek_clear_sc(struct buf_ring *br)
>>> if (!mtx_owned(br->br_lock))
>>> panic("lock not held on single consumer dequeue");
>>> #endif
>>> - /*
>>> -* I believe it is safe to not have a memory barrier
>>> -* here because we control cons and tail is worst case
>>> -* a lagging indicator so we worst case we might
>>> -* return NULL immediately after a buffer has been enqueued
>>> -*/
>>> +
>>> if (br->br_cons_head == br->br_prod_tail)
>>> return (NULL);
>>> +
>>> +#if defined(__arm__) || defined(__aarch64__)
>>> + /*
>>> +* The barrier is required there on ARM and ARM64 to ensure, that
>>> +* br->br_ring[br->br_cons_head] will not be fetched before the above
>>> +* condition is checked.
>>> +* Without the barrier, it is possible, that buffer will be fetched
>>> +* before the enqueue will put mbuf into br, then, in the meantime, the
>>> +* enqueue will update the array and the br_prod_tail, and the
>>> +* conditional check will be true, so we will return previously fetched
>>> +* (and invalid) buffer.
>>> +*/
>>> + atomic_thread_fence_acq();
>>> +#endif
>>
>> Putting the semantic of the change aside, why did you added the fence (it is
>> a fence, not barrier as stated in the comment) only to arm* ? If it is
>> needed, it is needed for all arches.
>
> Agreed. The code looks fine, though I would have made it an acquire
> load of br_prod_tail myself to be able to take advantage load-acquire
> instructions when present, and better document what the exact issue is.
> I also don't think the comment needs to be quite so extensive
> (especially since atomic_load_acq_32 is somewhat self-documenting in
> terms of one half of the race); if we had a comment like this for every
> fence in the kernel we'd never get anything done.
>
> There's also an ARM-specific fence in buf_ring_dequeue_sc:
>
>> /*
>> * This is a workaround to allow using buf_ring on ARM and ARM64.
>> * ARM64TODO: Fix buf_ring in a generic way.
>> * REMARKS: It is suspected that br_cons_head does not require
>> * load_acq operation, but this change was extensively tested
>> * and confirmed it's working. To be reviewed once again in
>> * FreeBSD-12.
>> *
>> * Preventing following situation:
>>
>> * Core(0) - buf_ring_enqueue()
>> Core(1) - buf_ring_dequeue_sc()
>> * -
>>--
>> *
>> *
>> cons_head = br->br_cons_head;
>> * atomic_cmpset_acq_32(&br->br_prod_head, ...));
>> *
>> buf = br->br_ring[cons_head]; >
>> * br->br_ring[prod_head] = buf;
>> * atomic_store_rel_32(&br->br_prod_tail, ...);
>> *
>> prod_tail = br->br_prod_tail;
>> *
>> if (cons_head == prod_tail)
>> *
>> return (NULL);
>> *
>> `
>> *
>> * <1> Load (on core 1) from br->br_ring[cons_head] can be reordered
>> (speculative readed) by CPU.
>> */
>> #if defined(__arm__) || defined(__aarch64__)
>> cons_head = atomic_load_acq_32(&br->br_cons_head);
>> #else
>> cons_head = br->br_cons_head;
>> #endif
>> prod_tail = atomic_load_acq_32(&br->br_prod_tail);
>
>
> The comment is completely correct that the ARM-specific fence is a
> waste of time. It's the single-consumer path, so such fences are just
> synchronising with the current thread and thus pointless. The important
> o
svn commit: r365360 - head/libexec/rtld-elf
Author: kib
Date: Sat Sep 5 10:16:24 2020
New Revision: 365360
URL: https://svnweb.freebsd.org/changeset/base/365360
Log:
rtld: Handle ELF dso with program headers outside the first page.
Reported by: Alex Arslan
PR: 229708
Reviewed by: dim (previous version), emaste
Sponsored by: The FreeBSD Foundation
Differential revision:https://reviews.freebsd.org/D26323
Modified:
head/libexec/rtld-elf/map_object.c
Modified: head/libexec/rtld-elf/map_object.c
==
--- head/libexec/rtld-elf/map_object.c Sat Sep 5 10:12:06 2020
(r365359)
+++ head/libexec/rtld-elf/map_object.c Sat Sep 5 10:16:24 2020
(r365360)
@@ -40,11 +40,19 @@
#include "debug.h"
#include "rtld.h"
-static Elf_Ehdr *get_elf_header(int, const char *, const struct stat *);
+static Elf_Ehdr *get_elf_header(int, const char *, const struct stat *,
+Elf_Phdr **phdr);
static int convert_flags(int); /* Elf flags -> mmap flags */
int __getosreldate(void);
+static bool
+phdr_in_zero_page(const Elf_Ehdr *hdr)
+{
+ return (hdr->e_phoff + hdr->e_phnum * sizeof(Elf_Phdr) <
+ (size_t)PAGE_SIZE);
+}
+
/*
* Map a shared object into memory. The "fd" argument is a file descriptor,
* which must be open on the object and positioned at its beginning.
@@ -95,17 +103,15 @@ map_object(int fd, const char *path, const struct stat
size_t note_map_len;
Elf_Addr text_end;
-hdr = get_elf_header(fd, path, sb);
+hdr = get_elf_header(fd, path, sb, &phdr);
if (hdr == NULL)
return (NULL);
/*
* Scan the program header entries, and save key information.
- *
* We expect that the loadable segments are ordered by load address.
*/
-phdr = (Elf_Phdr *)((char *)hdr + hdr->e_phoff);
-phsize = hdr->e_phnum * sizeof (phdr[0]);
+phsize = hdr->e_phnum * sizeof(phdr[0]);
phlimit = phdr + hdr->e_phnum;
nsegs = -1;
phdyn = phinterp = phtls = NULL;
@@ -332,14 +338,18 @@ error1:
error:
if (note_map != NULL && note_map != MAP_FAILED)
munmap(note_map, note_map_len);
+if (!phdr_in_zero_page(hdr))
+ munmap(phdr, hdr->e_phnum * sizeof(phdr[0]));
munmap(hdr, PAGE_SIZE);
return (NULL);
}
static Elf_Ehdr *
-get_elf_header(int fd, const char *path, const struct stat *sbp)
+get_elf_header(int fd, const char *path, const struct stat *sbp,
+Elf_Phdr **phdr_p)
{
Elf_Ehdr *hdr;
+ Elf_Phdr *phdr;
/* Make sure file has enough data for the ELF header */
if (sbp != NULL && sbp->st_size < (off_t)sizeof(Elf_Ehdr)) {
@@ -388,11 +398,19 @@ get_elf_header(int fd, const char *path, const struct
"%s: invalid shared object: e_phentsize != sizeof(Elf_Phdr)", path);
goto error;
}
- if (hdr->e_phoff + hdr->e_phnum * sizeof(Elf_Phdr) >
- (size_t)PAGE_SIZE) {
- _rtld_error("%s: program header too large", path);
- goto error;
+ if (phdr_in_zero_page(hdr)) {
+ phdr = (Elf_Phdr *)((char *)hdr + hdr->e_phoff);
+ } else {
+ phdr = mmap(NULL, hdr->e_phnum * sizeof(phdr[0]),
+ PROT_READ, MAP_PRIVATE | MAP_PREFAULT_READ, fd,
+ hdr->e_phoff);
+ if (phdr == MAP_FAILED) {
+ _rtld_error("%s: error mapping phdr: %s", path,
+ rtld_strerror(errno));
+ goto error;
+ }
}
+ *phdr_p = phdr;
return (hdr);
error:
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365359 - in stable/12/sys: kern sys
Author: kib
Date: Sat Sep 5 10:12:06 2020
New Revision: 365359
URL: https://svnweb.freebsd.org/changeset/base/365359
Log:
MFC r361967 (by mjg), r362910 (by mjg), r364495:
Fix several issues with process group orphanage.
Modified:
stable/12/sys/kern/kern_exit.c
stable/12/sys/kern/kern_proc.c
stable/12/sys/sys/proc.h
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/kern/kern_exit.c
==
--- stable/12/sys/kern/kern_exit.c Sat Sep 5 04:20:29 2020
(r365358)
+++ stable/12/sys/kern/kern_exit.c Sat Sep 5 10:12:06 2020
(r365359)
@@ -394,7 +394,6 @@ exit1(struct thread *td, int rval, int signo)
}
vmspace_exit(td);
- killjobc();
(void)acct_process(td);
#ifdef KTRACE
@@ -440,6 +439,12 @@ exit1(struct thread *td, int rval, int signo)
PROC_LOCK(p);
p->p_flag &= ~(P_TRACED | P_PPWAIT | P_PPTRACE);
PROC_UNLOCK(p);
+
+ /*
+* killjobc() might drop and re-acquire proctree_lock to
+* revoke control tty if exiting process was a session leader.
+*/
+ killjobc();
/*
* Reparent all children processes:
Modified: stable/12/sys/kern/kern_proc.c
==
--- stable/12/sys/kern/kern_proc.c Sat Sep 5 04:20:29 2020
(r365358)
+++ stable/12/sys/kern/kern_proc.c Sat Sep 5 10:12:06 2020
(r365359)
@@ -108,13 +108,14 @@ MALLOC_DEFINE(M_SESSION, "session", "session header");
static MALLOC_DEFINE(M_PROC, "proc", "Proc structures");
MALLOC_DEFINE(M_SUBPROC, "subproc", "Proc sub-structures");
+static void fixjobc_enterpgrp(struct proc *p, struct pgrp *pgrp);
static void doenterpgrp(struct proc *, struct pgrp *);
static void orphanpg(struct pgrp *pg);
static void fill_kinfo_aggregate(struct proc *p, struct kinfo_proc *kp);
static void fill_kinfo_proc_only(struct proc *p, struct kinfo_proc *kp);
static void fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp,
int preferthread);
-static void pgadjustjobc(struct pgrp *pgrp, int entering);
+static void pgadjustjobc(struct pgrp *pgrp, bool entering);
static void pgdelete(struct pgrp *);
static int proc_ctor(void *mem, int size, void *arg, int flags);
static void proc_dtor(void *mem, int size, void *arg);
@@ -545,6 +546,43 @@ enterthispgrp(struct proc *p, struct pgrp *pgrp)
}
/*
+ * If true, any child of q which belongs to group pgrp, qualifies the
+ * process group pgrp as not orphaned.
+ */
+static bool
+isjobproc(struct proc *q, struct pgrp *pgrp)
+{
+ sx_assert(&proctree_lock, SX_LOCKED);
+ return (q->p_pgrp != pgrp &&
+ q->p_pgrp->pg_session == pgrp->pg_session);
+}
+
+#ifdef INVARIANTS
+static void
+check_pgrp_jobc(struct pgrp *pgrp)
+{
+ struct proc *q;
+ int cnt;
+
+ sx_assert(&proctree_lock, SX_LOCKED);
+ PGRP_LOCK_ASSERT(pgrp, MA_NOTOWNED);
+
+ cnt = 0;
+ PGRP_LOCK(pgrp);
+ LIST_FOREACH(q, &pgrp->pg_members, p_pglist) {
+ if ((q->p_treeflag & P_TREE_GRPEXITED) != 0 ||
+ q->p_pptr == NULL)
+ continue;
+ if (isjobproc(q->p_pptr, pgrp))
+ cnt++;
+ }
+ KASSERT(pgrp->pg_jobc == cnt, ("pgrp %d %p pg_jobc %d cnt %d",
+ pgrp->pg_id, pgrp, pgrp->pg_jobc, cnt));
+ PGRP_UNLOCK(pgrp);
+}
+#endif
+
+/*
* Move p to a process group
*/
static void
@@ -560,13 +598,15 @@ doenterpgrp(struct proc *p, struct pgrp *pgrp)
savepgrp = p->p_pgrp;
+#ifdef INVARIANTS
+ check_pgrp_jobc(pgrp);
+ check_pgrp_jobc(savepgrp);
+#endif
+
/*
* Adjust eligibility of affected pgrps to participate in job control.
-* Increment eligibility counts before decrementing, otherwise we
-* could reach 0 spuriously during the first call.
*/
- fixjobc(p, pgrp, 1);
- fixjobc(p, p->p_pgrp, 0);
+ fixjobc_enterpgrp(p, pgrp);
PGRP_LOCK(pgrp);
PGRP_LOCK(savepgrp);
@@ -639,13 +679,15 @@ pgdelete(struct pgrp *pgrp)
}
static void
-pgadjustjobc(struct pgrp *pgrp, int entering)
+pgadjustjobc(struct pgrp *pgrp, bool entering)
{
PGRP_LOCK(pgrp);
- if (entering)
+ if (entering) {
+ MPASS(pgrp->pg_jobc >= 0);
pgrp->pg_jobc++;
- else {
+ } else {
+ MPASS(pgrp->pg_jobc > 0);
--pgrp->pg_jobc;
if (pgrp->pg_jobc == 0)
orphanpg(pgrp);
@@ -660,43 +702,95 @@ pgadjustjobc(struct pgrp *pgrp, int entering)
* process group of the same session). If that count reaches zero, the
* process group becomes orphaned. Check both the specified process'
* process group and that of its children.
- * entering == 0 => p is leaving specified group.
- * entering == 1 => p is enter
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
On Fri, Sep 4, 2020 at 10:30 PM Warner Losh wrote: > > > > On Fri, Sep 4, 2020, 11:24 PM Kevin Bowling wrote: >> >> It's happening right now, and a few times a year at minimum from my >> memory. > > > Can I get a pointer? >From recent lossy memory, intel networking drivers (multiply), and the TCP stacks which are not very conforming. If click differential in phab and insert the query "style" you can see a lot of patches to fix things incrementally, as well as people commenting about it in review (usually respectfully as part of other review), or asking for people to break style changes out of behavior changes. > Warner > >> Any time someone proposes a formatter they are thrown shade, >> so the lack of progress there isn't surprising since the current >> culture would require a flame proof suit to make progress. It's kind >> of tautological that the status quo doesn't bother long time >> contributors due to selection bias, and doesn't mean for instance the >> lack of modern tooling is not off putting to younger developers that >> learn new tools and wonder why >> >> we remain in the stone age. An example >> we are finally overcoming is the git migration. Must we drag our feet >> every opportunity given to modernize ourselves from the other popular >> open source OS, or can we make obvious decisions to get ahead of them? >> I think if you ask anyone under the age of 30 you will get a pretty >> unanimous desire for automatic formatting. > > > Why strictly enforce anything is my point? It's one more thing to bounce a > commit for an issue that's about 30th on the list of problems. Why put any > energy at all into this when there is all cost and no benefit. Is this a common opinion? If people are this relaxed about it then I agree with you. > Warner > > Warner > >> On Fri, Sep 4, 2020 at 8:48 PM Warner Losh wrote: >> > >> > >> > >> > On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling >> > wrote: >> >> >> >> I disagree that the problem is intractable. It's just a decision and >> >> it has a one time cost with long term benefits like paying off a high >> >> interest loan. The intractability opinion seemed justifiable for a >> >> long time but it's been proven false by other communities, >> >> particularly Go and Rust and there is nothing syntactically special >> >> about these languages that enable this; it's just a decision to make >> >> the style fit an extant formatter. An arbitrary formater may leave a >> >> little bit of annoyance to each person's taste, but that is a tiny >> >> drop in the bucket compared to never having to discuss and especially >> >> correct (which may /seem/ helpful but is pretty offputting to >> >> newcomers). A tool does it, and it takes the wind out of any passive >> >> aggressive bike shed opportunities from either maintainer or >> >> contributor. It sucks that downstreams have to fall in line, but that >> >> doesn't stop progress on any other major changes in FreeBSD. >> > >> > >> > How often are there really such bikesheds these days? I've seen no >> > evidence of them in the hundreds of phab reviews I've seen. It is the >> > ghost of the past when 10 or 15 years ago it was a big deal. Why bother >> > creating yet another barrier to commits because we used to suck, but now >> > have barely a rumble of bad behavior around it... >> > >> > Warner >> > >> >> On Fri, Sep 4, 2020 at 7:57 PM Warner Losh wrote: >> >> > >> >> > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon wrote: >> >> > >> >> > > On Fri, Sep 04, 2020 at 02:15:04PM -0400, Andrew Gallatin wrote: >> >> > > > and I also anticipate it will cause problems with MFCs >> >> > > >> > >> > >> >> > > And existing PRs and DRs. >> >> > > >> >> > >> >> > Or we could just not bother we these changes at all. It's a pipe dream >> >> > we >> >> > will ever be style(9) compliant in all our code, or that we can >> >> > magically >> >> > have a tool to enforce in new commits. We have better things to worry >> >> > about. We should continue to ignore this non problem and for new users >> >> > point them at the 95% correct format thing to run their submitted >> >> > patches >> >> > if they submit something too far out of whack. >> >> > >> >> > The last sweep deleted a boatload of blank lines that were in there on >> >> > purpose. Not worth adding them back, but still annoying to no real >> >> > benefit. >> >> > >> >> > I just don't see the benefits at all of doing anything here. The few >> >> > reviews that I've seen mention it seem to be the right level of effort. >> >> > >> >> > Warner >> >> > >> >> > > >> >> > ___ >> >> > svn-src-h...@freebsd.org mailing list >> >> > https://lists.freebsd.org/mailman/listinfo/svn-src-head >> >> > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
On Sat, Sep 5, 2020 at 12:00 AM Kevin Bowling wrote: > On Fri, Sep 4, 2020 at 10:30 PM Warner Losh wrote: > > > > > > > > On Fri, Sep 4, 2020, 11:24 PM Kevin Bowling > wrote: > >> > >> It's happening right now, and a few times a year at minimum from my > >> memory. > > > > > > Can I get a pointer? > > From recent lossy memory, intel networking drivers (multiply), and the > TCP stacks which are not very conforming. If click differential in > phab and insert the query "style" you can see a lot of patches to fix > things incrementally, as well as people commenting about it in review > (usually respectfully as part of other review), or asking for people > to break style changes out of behavior changes. > None of that is passive aggressive maintainers blocking things over style issues. Asking people to fix style issues is a normal patch review. I see it in the half a dozen other projects I subscribe to in enough detail to see. All the times I've seen it appear to be normal and healthy. I get asked to do it myself at times. We fixed the social dysfunction years ago in the project that had lead to the near weekly style(9) passive aggressive outbursts. I just don't see the passive aggressive side of this at all these days. To be clear: I'm not opposed to creating a style(9) tool to format code. In fact, we have one. I'm not opposed to people using it on their own code. I just don't think the relatively large amount of churn it would take would warrant a full-sale run on the tree. Nor do I think it adds enough value to be part of a pre-commit review process, especially given the strong culture of 'the file's style is more important.' And the issues in the TCP stacks I think proves the point. The style isn't super strict about style(9) yet conforms in spirit and is still easy to read for people that have read the rest of the kernel. Bulk reformatting that would be an even bigger mistake because it's still being actively developed and throwing a wrench into those efforts would negate a lot of the good will that FreeBSD has at Netflix. And that's not to mention all the other down streams that would have even more trouble rebasing their changes forward in our tree. So against those very tangible costs, the benefit is what exactly? I'm just not seeing any real ROI to enforcing that when we can't even go a week w/o at least one build breakage it seems and our performance is all over the map due to a very real lack of on-going horizontal regression testing. I think there's other, bigger fish to try than this one, that's all. Warner > > Warner > > > >> Any time someone proposes a formatter they are thrown shade, > >> so the lack of progress there isn't surprising since the current > >> culture would require a flame proof suit to make progress. It's kind > >> of tautological that the status quo doesn't bother long time > >> contributors due to selection bias, and doesn't mean for instance the > >> lack of modern tooling is not off putting to younger developers that > >> learn new tools and wonder why > >> > >> we remain in the stone age. An example > >> we are finally overcoming is the git migration. Must we drag our feet > >> every opportunity given to modernize ourselves from the other popular > >> open source OS, or can we make obvious decisions to get ahead of them? > >> I think if you ask anyone under the age of 30 you will get a pretty > >> unanimous desire for automatic formatting. > > > > > > Why strictly enforce anything is my point? It's one more thing to bounce > a commit for an issue that's about 30th on the list of problems. Why put > any energy at all into this when there is all cost and no benefit. > > Is this a common opinion? If people are this relaxed about it then I > agree with you. > > > Warner > > > > Warner > > > >> On Fri, Sep 4, 2020 at 8:48 PM Warner Losh wrote: > >> > > >> > > >> > > >> > On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling > wrote: > >> >> > >> >> I disagree that the problem is intractable. It's just a decision and > >> >> it has a one time cost with long term benefits like paying off a high > >> >> interest loan. The intractability opinion seemed justifiable for a > >> >> long time but it's been proven false by other communities, > >> >> particularly Go and Rust and there is nothing syntactically special > >> >> about these languages that enable this; it's just a decision to make > >> >> the style fit an extant formatter. An arbitrary formater may leave a > >> >> little bit of annoyance to each person's taste, but that is a tiny > >> >> drop in the bucket compared to never having to discuss and especially > >> >> correct (which may /seem/ helpful but is pretty offputting to > >> >> newcomers). A tool does it, and it takes the wind out of any passive > >> >> aggressive bike shed opportunities from either maintainer or > >> >> contributor. It sucks that downstreams have to fall in line, but > that > >> >> doesn't stop progress on any other major changes in FreeBSD.
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
It's happening right now, and a few times a year at minimum from my memory. Any time someone proposes a formatter they are thrown shade, so the lack of progress there isn't surprising since the current culture would require a flame proof suit to make progress. It's kind of tautological that the status quo doesn't bother long time contributors due to selection bias, and doesn't mean for instance the lack of modern tooling is not off putting to younger developers that learn new tools and wonder why we remain in the stone age. An example we are finally overcoming is the git migration. Must we drag our feet every opportunity given to modernize ourselves from the other popular open source OS, or can we make obvious decisions to get ahead of them? I think if you ask anyone under the age of 30 you will get a pretty unanimous desire for automatic formatting. On Fri, Sep 4, 2020 at 8:48 PM Warner Losh wrote: > > > > On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling wrote: >> >> I disagree that the problem is intractable. It's just a decision and >> it has a one time cost with long term benefits like paying off a high >> interest loan. The intractability opinion seemed justifiable for a >> long time but it's been proven false by other communities, >> particularly Go and Rust and there is nothing syntactically special >> about these languages that enable this; it's just a decision to make >> the style fit an extant formatter. An arbitrary formater may leave a >> little bit of annoyance to each person's taste, but that is a tiny >> drop in the bucket compared to never having to discuss and especially >> correct (which may /seem/ helpful but is pretty offputting to >> newcomers). A tool does it, and it takes the wind out of any passive >> aggressive bike shed opportunities from either maintainer or >> contributor. It sucks that downstreams have to fall in line, but that >> doesn't stop progress on any other major changes in FreeBSD. > > > How often are there really such bikesheds these days? I've seen no evidence > of them in the hundreds of phab reviews I've seen. It is the ghost of the > past when 10 or 15 years ago it was a big deal. Why bother creating yet > another barrier to commits because we used to suck, but now have barely a > rumble of bad behavior around it... > > Warner > >> On Fri, Sep 4, 2020 at 7:57 PM Warner Losh wrote: >> > >> > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon wrote: >> > >> > > On Fri, Sep 04, 2020 at 02:15:04PM -0400, Andrew Gallatin wrote: >> > > > and I also anticipate it will cause problems with MFCs >> > > > > >> > > And existing PRs and DRs. >> > > >> > >> > Or we could just not bother we these changes at all. It's a pipe dream we >> > will ever be style(9) compliant in all our code, or that we can magically >> > have a tool to enforce in new commits. We have better things to worry >> > about. We should continue to ignore this non problem and for new users >> > point them at the 95% correct format thing to run their submitted patches >> > if they submit something too far out of whack. >> > >> > The last sweep deleted a boatload of blank lines that were in there on >> > purpose. Not worth adding them back, but still annoying to no real benefit. >> > >> > I just don't see the benefits at all of doing anything here. The few >> > reviews that I've seen mention it seem to be the right level of effort. >> > >> > Warner >> > >> > > >> > ___ >> > svn-src-h...@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/svn-src-head >> > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling wrote: > I disagree that the problem is intractable. It's just a decision and > it has a one time cost with long term benefits like paying off a high > interest loan. The intractability opinion seemed justifiable for a > long time but it's been proven false by other communities, > particularly Go and Rust and there is nothing syntactically special > about these languages that enable this; it's just a decision to make > the style fit an extant formatter. An arbitrary formater may leave a > little bit of annoyance to each person's taste, but that is a tiny > drop in the bucket compared to never having to discuss and especially > correct (which may /seem/ helpful but is pretty offputting to > newcomers). A tool does it, and it takes the wind out of any passive > aggressive bike shed opportunities from either maintainer or > contributor. It sucks that downstreams have to fall in line, but that > doesn't stop progress on any other major changes in FreeBSD. > How often are there really such bikesheds these days? I've seen no evidence of them in the hundreds of phab reviews I've seen. It is the ghost of the past when 10 or 15 years ago it was a big deal. Why bother creating yet another barrier to commits because we used to suck, but now have barely a rumble of bad behavior around it... Warner On Fri, Sep 4, 2020 at 7:57 PM Warner Losh wrote: > > > > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon wrote: > > > > > On Fri, Sep 04, 2020 at 02:15:04PM -0400, Andrew Gallatin wrote: > > > > and I also anticipate it will cause problems with MFCs > > > > > > And existing PRs and DRs. > > > > > > > Or we could just not bother we these changes at all. It's a pipe dream we > > will ever be style(9) compliant in all our code, or that we can magically > > have a tool to enforce in new commits. We have better things to worry > > about. We should continue to ignore this non problem and for new users > > point them at the 95% correct format thing to run their submitted patches > > if they submit something too far out of whack. > > > > The last sweep deleted a boatload of blank lines that were in there on > > purpose. Not worth adding them back, but still annoying to no real > benefit. > > > > I just don't see the benefits at all of doing anything here. The few > > reviews that I've seen mention it seem to be the right level of effort. > > > > Warner > > > > > > > ___ > > svn-src-h...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/svn-src-head > > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
I disagree that the problem is intractable. It's just a decision and it has a one time cost with long term benefits like paying off a high interest loan. The intractability opinion seemed justifiable for a long time but it's been proven false by other communities, particularly Go and Rust and there is nothing syntactically special about these languages that enable this; it's just a decision to make the style fit an extant formatter. An arbitrary formater may leave a little bit of annoyance to each person's taste, but that is a tiny drop in the bucket compared to never having to discuss and especially correct (which may /seem/ helpful but is pretty offputting to newcomers). A tool does it, and it takes the wind out of any passive aggressive bike shed opportunities from either maintainer or contributor. It sucks that downstreams have to fall in line, but that doesn't stop progress on any other major changes in FreeBSD. On Fri, Sep 4, 2020 at 7:57 PM Warner Losh wrote: > > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon wrote: > > > On Fri, Sep 04, 2020 at 02:15:04PM -0400, Andrew Gallatin wrote: > > > and I also anticipate it will cause problems with MFCs > > > > And existing PRs and DRs. > > > > Or we could just not bother we these changes at all. It's a pipe dream we > will ever be style(9) compliant in all our code, or that we can magically > have a tool to enforce in new commits. We have better things to worry > about. We should continue to ignore this non problem and for new users > point them at the 95% correct format thing to run their submitted patches > if they submit something too far out of whack. > > The last sweep deleted a boatload of blank lines that were in there on > purpose. Not worth adding them back, but still annoying to no real benefit. > > I just don't see the benefits at all of doing anything here. The few > reviews that I've seen mention it seem to be the right level of effort. > > Warner > > > > ___ > svn-src-h...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
