svn commit: r356220 - head/libexec/rtld-elf
Author: cem Date: Tue Dec 31 05:41:47 2019 New Revision: 356220 URL: https://svnweb.freebsd.org/changeset/base/356220 Log: rtld(1): Do booleans like C99 Reviewed by: kib, rlibby Differential Revision:https://reviews.freebsd.org/D22964 Modified: head/libexec/rtld-elf/rtld.h Modified: head/libexec/rtld-elf/rtld.h == --- head/libexec/rtld-elf/rtld.hTue Dec 31 05:39:27 2019 (r356219) +++ head/libexec/rtld-elf/rtld.hTue Dec 31 05:41:47 2019 (r356220) @@ -37,6 +37,7 @@ #include #include #include +#include #include #include @@ -45,11 +46,6 @@ #define NEW(type) ((type *) xmalloc(sizeof(type))) #define CNEW(type) ((type *) xcalloc(1, sizeof(type))) - -/* We might as well do booleans like C++. */ -typedef unsigned char bool; -#define false 0 -#define true 1 extern size_t tls_last_offset; extern size_t tls_last_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: r356219 - head/sys/nfs
Author: rmacklem
Date: Tue Dec 31 05:39:27 2019
New Revision: 356219
URL: https://svnweb.freebsd.org/changeset/base/356219
Log:
Switch r356210 to use gone_in() instead of printf().
Suggested by: cem
Modified:
head/sys/nfs/nfs_lock.c
Modified: head/sys/nfs/nfs_lock.c
==
--- head/sys/nfs/nfs_lock.c Tue Dec 31 04:53:50 2019(r356218)
+++ head/sys/nfs/nfs_lock.c Tue Dec 31 05:39:27 2019(r356219)
@@ -89,8 +89,7 @@ nfslock_open(struct cdev *dev, int oflags, int devtype
{
int error;
- printf("WARNING: uses Giant and will be removed before FreeBSD 13\n"
- "\tuse the kernel NFSLOCKD/nfslockd.ko\n");
+ gone_in(13, "uses Giant; replace with NFSLOCKD/nfslockd.ko");
error = priv_check(td, PRIV_NFS_LOCKD);
if (error)
return (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: r356218 - head/usr.sbin/inetd
Author: kevans
Date: Tue Dec 31 04:53:50 2019
New Revision: 356218
URL: https://svnweb.freebsd.org/changeset/base/356218
Log:
inetd: prefer strlcpy to strlen(3) check + strcpy(3), NFC
This is again functionally equivalent but more concise.
Modified:
head/usr.sbin/inetd/inetd.c
Modified: head/usr.sbin/inetd/inetd.c
==
--- head/usr.sbin/inetd/inetd.c Tue Dec 31 04:36:14 2019(r356217)
+++ head/usr.sbin/inetd/inetd.c Tue Dec 31 04:53:50 2019(r356218)
@@ -1612,6 +1612,7 @@ getconfigent(void)
int v6bind;
#endif
int i;
+ size_t unsz;
#ifdef IPSEC
policy = NULL;
@@ -1832,16 +1833,18 @@ more:
break;
#endif
case AF_UNIX:
- if (strlen(sep->se_service) >=
sizeof(sep->se_ctrladdr_un.sun_path)) {
- syslog(LOG_ERR,
+#defineSUN_PATH_MAXSIZEsizeof(sep->se_ctrladdr_un.sun_path)
+ memset(>se_ctrladdr, 0, sizeof(sep->se_ctrladdr));
+ sep->se_ctrladdr_un.sun_family = sep->se_family;
+ if ((unsz = strlcpy(sep->se_ctrladdr_un.sun_path,
+ sep->se_service, SUN_PATH_MAXSIZE) >= SUN_PATH_MAXSIZE)) {
+ syslog(LOG_ERR,
"domain socket pathname too long for service %s",
sep->se_service);
goto more;
}
- memset(>se_ctrladdr, 0, sizeof(sep->se_ctrladdr));
- sep->se_ctrladdr_un.sun_family = sep->se_family;
- sep->se_ctrladdr_un.sun_len = strlen(sep->se_service);
- strcpy(sep->se_ctrladdr_un.sun_path, sep->se_service);
+ sep->se_ctrladdr_un.sun_len = unsz;
+#undef SUN_PATH_MAXSIZE
sep->se_ctrladdr_size = SUN_LEN(>se_ctrladdr_un);
}
arg = sskip();
___
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: r356217 - head/usr.sbin/inetd
Author: kevans
Date: Tue Dec 31 04:36:14 2019
New Revision: 356217
URL: https://svnweb.freebsd.org/changeset/base/356217
Log:
inetd: prefer strtonum(3) to strspn(3)+atoi(3), NFC
strtonum(3) does effectively the same validation as we had, but it's more
concise.
Modified:
head/usr.sbin/inetd/builtins.c
Modified: head/usr.sbin/inetd/builtins.c
==
--- head/usr.sbin/inetd/builtins.c Tue Dec 31 04:16:52 2019
(r356216)
+++ head/usr.sbin/inetd/builtins.c Tue Dec 31 04:36:14 2019
(r356217)
@@ -649,8 +649,14 @@ ident_stream(int s, struct servtab *sep)
goto fakeid_fail;
if (!Fflag) {
if (iflag) {
- if (p[strspn(p, "0123456789")] == '\0' &&
- getpwuid(atoi(p)) != NULL)
+ const char *errstr;
+ uid_t uid;
+
+ uid = strtonum(p, 0, UID_MAX, );
+ if (errstr != NULL)
+ goto fakeid_fail;
+
+ if (getpwuid(uid) != NULL)
goto fakeid_fail;
} else {
if (getpwnam(p) != NULL)
___
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: r356216 - head/sys/dev/ioat
Author: mav
Date: Tue Dec 31 04:16:52 2019
New Revision: 356216
URL: https://svnweb.freebsd.org/changeset/base/356216
Log:
Don't spin on cleanup_lock if we are not interrupt.
If somebody else holds that lock, it will likely do the work for us.
If it won't, then we return here later and retry.
Under heavy load it allows to avoid lock congestion between interrupt and
polling threads.
MFC after:1 week
Sponsored by: iXsystems, Inc.
Modified:
head/sys/dev/ioat/ioat.c
Modified: head/sys/dev/ioat/ioat.c
==
--- head/sys/dev/ioat/ioat.cTue Dec 31 04:00:24 2019(r356215)
+++ head/sys/dev/ioat/ioat.cTue Dec 31 04:16:52 2019(r356216)
@@ -789,7 +789,12 @@ ioat_process_events(struct ioat_softc *ioat, boolean_t
uint32_t completed, chanerr;
int error;
- mtx_lock(>cleanup_lock);
+ if (intr) {
+ mtx_lock(>cleanup_lock);
+ } else {
+ if (!mtx_trylock(>cleanup_lock))
+ return;
+ }
/*
* Don't run while the hardware is being reset. Reset is responsible
___
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: r356215 - head/usr.sbin/inetd
Author: kevans
Date: Tue Dec 31 04:00:24 2019
New Revision: 356215
URL: https://svnweb.freebsd.org/changeset/base/356215
Log:
inetd: knock out some clang analyze warnings
chargen_dg: clang-analyze is convinced that endring could be non-NULL at
entry, and thus wants to assume that rs == NULL. Just independently
initialize rs if it's NULL to appease the analyzer.
getconfigent: policy leaks on return
free_connlist: reorganize the loop to make it clear that we're not going to
access `conn` after it's been freed.
cpmip/hashval: left-shifts performed will result in UB as we take
signed 0xABC3D20F and left shift it by 5.
Modified:
head/usr.sbin/inetd/builtins.c
head/usr.sbin/inetd/inetd.c
Modified: head/usr.sbin/inetd/builtins.c
==
--- head/usr.sbin/inetd/builtins.c Tue Dec 31 03:43:13 2019
(r356214)
+++ head/usr.sbin/inetd/builtins.c Tue Dec 31 04:00:24 2019
(r356215)
@@ -132,10 +132,10 @@ chargen_dg(int s, struct servtab *sep)
socklen_t size;
char text[LINESIZ+2];
- if (endring == 0) {
+ if (endring == NULL)
initring();
+ if (rs == NULL)
rs = ring;
- }
size = sizeof(ss);
if (recvfrom(s, text, sizeof(text), 0,
Modified: head/usr.sbin/inetd/inetd.c
==
--- head/usr.sbin/inetd/inetd.c Tue Dec 31 03:43:13 2019(r356214)
+++ head/usr.sbin/inetd/inetd.c Tue Dec 31 04:00:24 2019(r356215)
@@ -1646,8 +1646,11 @@ more:
continue;
break;
}
- if (cp == NULL)
- return ((struct servtab *)0);
+ if (cp == NULL) {
+ free(policy);
+ return (NULL);
+ }
+
/*
* clear the static buffer, since some fields (se_ctrladdr,
* for example) don't get initialized here.
@@ -2206,7 +2209,7 @@ cpmip(const struct servtab *sep, int ctrl)
(sep->se_family == AF_INET || sep->se_family == AF_INET6) &&
getpeername(ctrl, (struct sockaddr *), ) == 0 ) {
time_t t = time(NULL);
- int hv = 0xABC3D20F;
+ unsigned int hv = 0xABC3D20F;
int i;
int cnt = 0;
CHash *chBest = NULL;
@@ -2493,11 +2496,15 @@ resize_conn(struct servtab *sep, int maxpip)
static void
free_connlist(struct servtab *sep)
{
- struct conninfo *conn;
+ struct conninfo *conn, *conn_temp;
int i, j;
for (i = 0; i < PERIPSIZE; ++i) {
- while ((conn = LIST_FIRST(>se_conn[i])) != NULL) {
+ LIST_FOREACH_SAFE(conn, >se_conn[i], co_link, conn_temp) {
+ if (conn == NULL) {
+ LIST_REMOVE(conn, co_link);
+ continue;
+ }
for (j = 0; j < conn->co_numchild; ++j)
free_proc(conn->co_proc[j]);
conn->co_numchild = 0;
@@ -2553,7 +2560,8 @@ free_proc(struct procinfo *proc)
static int
hashval(char *p, int len)
{
- int i, hv = 0xABC3D20F;
+ unsigned int hv = 0xABC3D20F;
+ int i;
for (i = 0; i < len; ++i, ++p)
hv = (hv << 5) ^ (hv >> 23) ^ *p;
___
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: r356214 - head/sys/geom
Author: mav
Date: Tue Dec 31 03:43:13 2019
New Revision: 356214
URL: https://svnweb.freebsd.org/changeset/base/356214
Log:
Avoid few memory accesses in g_disk_done().
Modified:
head/sys/geom/geom_disk.c
Modified: head/sys/geom/geom_disk.c
==
--- head/sys/geom/geom_disk.c Tue Dec 31 00:07:10 2019(r356213)
+++ head/sys/geom/geom_disk.c Tue Dec 31 03:43:13 2019(r356214)
@@ -65,6 +65,7 @@ __FBSDID("$FreeBSD$");
struct g_disk_softc {
struct disk *dp;
+ struct devstat *d_devstat;
struct sysctl_ctx_list sysctl_ctx;
struct sysctl_oid *sysctl_tree;
charled[64];
@@ -231,15 +232,13 @@ g_disk_done(struct bio *bp)
struct g_disk_softc *sc;
/* See "notes" for why we need a mutex here */
- /* XXX: will witness accept a mix of Giant/unGiant drivers here ? */
+ sc = bp->bio_caller1;
bp2 = bp->bio_parent;
- sc = bp2->bio_to->private;
- bp->bio_completed = bp->bio_length - bp->bio_resid;
binuptime();
mtx_lock(>done_mtx);
if (bp2->bio_error == 0)
bp2->bio_error = bp->bio_error;
- bp2->bio_completed += bp->bio_completed;
+ bp2->bio_completed += bp->bio_length - bp->bio_resid;
switch (bp->bio_cmd) {
case BIO_ZONE:
@@ -249,7 +248,7 @@ g_disk_done(struct bio *bp)
case BIO_WRITE:
case BIO_DELETE:
case BIO_FLUSH:
- devstat_end_transaction_bio_bt(sc->dp->d_devstat, bp, );
+ devstat_end_transaction_bio_bt(sc->d_devstat, bp, );
break;
default:
break;
@@ -469,6 +468,7 @@ g_disk_start(struct bio *bp)
bp->bio_error = ENOMEM;
}
bp2->bio_done = g_disk_done;
+ bp2->bio_caller1 = sc;
bp2->bio_pblkno = bp2->bio_offset / dp->d_sectorsize;
bp2->bio_bcount = bp2->bio_length;
bp2->bio_disk = dp;
@@ -555,6 +555,7 @@ g_disk_start(struct bio *bp)
return;
}
bp2->bio_done = g_disk_done;
+ bp2->bio_caller1 = sc;
bp2->bio_disk = dp;
devstat_start_transaction_bio(dp->d_devstat, bp2);
dp->d_strategy(bp2);
@@ -706,6 +707,7 @@ g_disk_create(void *arg, int flag)
sc = g_malloc(sizeof(*sc), M_WAITOK | M_ZERO);
mtx_init(>done_mtx, "g_disk_done", NULL, MTX_DEF);
sc->dp = dp;
+ sc->d_devstat = dp->d_devstat;
gp = g_new_geomf(_disk_class, "%s%d", dp->d_name, dp->d_unit);
gp->softc = sc;
LIST_FOREACH(dap, >d_aliases, da_next) {
___
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: r356210 - head/sys/nfs
Hi Rick,
One suggestion:
On Mon, Dec 30, 2019 at 2:39 PM Rick Macklem wrote:
>
> Author: rmacklem
> Date: Mon Dec 30 22:39:29 2019
> New Revision: 356210
> ...
> --- head/sys/nfs/nfs_lock.c Mon Dec 30 22:05:57 2019(r356209)
> +++ head/sys/nfs/nfs_lock.c Mon Dec 30 22:39:29 2019(r356210)
> @@ -89,6 +89,8 @@ nfslock_open(struct cdev *dev, int oflags, int devtype
> {
> int error;
>
> + printf("WARNING: uses Giant and will be removed before FreeBSD 13\n"
> + "\tuse the kernel NFSLOCKD/nfslockd.ko\n");
This could be 'gone_in(13, "uses Giant; replace with NFSLOCKD/nfslockd.ko");'
Best,
Conrad
___
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: r356213 - head/usr.bin/nfsstat
Author: rmacklem Date: Tue Dec 31 00:07:10 2019 New Revision: 356213 URL: https://svnweb.freebsd.org/changeset/base/356213 Log: Replace .h files included from old NFS directories with the new NFS ones. Prior to this patch, nfsstat.c includes files from sys/nfs, sys/nfsclient and sys/nfsserver. These .h files (particularily the ones in sys/nfsclient and sys/nfsserver) are from the old NFS code and should eventually be deprecated/removed. This patch changes nfsstat.c to include files from the new/current NFS code instead of the old ones in preparation for eventual removal. Modified: head/usr.bin/nfsstat/nfsstat.c Modified: head/usr.bin/nfsstat/nfsstat.c == --- head/usr.bin/nfsstat/nfsstat.c Tue Dec 31 00:05:06 2019 (r356212) +++ head/usr.bin/nfsstat/nfsstat.c Tue Dec 31 00:07:10 2019 (r356213) @@ -79,11 +79,9 @@ static const char rcsid[] = #include #include #include -#include -#include -#include #include +#include #include #include ___ 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: r356212 - in head: contrib/libarchive contrib/libarchive/libarchive contrib/libarchive/libarchive/test contrib/libarchive/test_utils lib/libarchive/tests usr.bin/bsdcat usr.bin/cpio usr...
Author: mm Date: Tue Dec 31 00:05:06 2019 New Revision: 356212 URL: https://svnweb.freebsd.org/changeset/base/356212 Log: MFV r356163,r356197: Update libarchive to 3.4.1 Relevant vendor changes since last update: Issue #351: Refactor and implement private state logic for write filters PR #1252: RAR5 reader - verify window size for solid files (OSS-Fuzz 15482) PR #1255: zip writer - don't append unused NUL for directories PR #1260: Fix sparse file offset overflow on 32-bit systems PR #1263: UNICODE filename support for reading lha/lzh format Issue #1276: Bugfix and optimize archive_wstring_append_from_mbs() PR #1288: Add the "xattrhdr" option to pax write options PR #1295: 7z reader - fix reading archives with digests in PackInfo PR #1296: RAR5 reader - verify window size for multivolume archives PR #1297: ZIP reader - support LZMA_STREAM_END marker in 'lzma alone' files Issue #1298: Fix a heap-buffer-overflow in archive_string_append_from_wcs() OSS-Fuzz 19360, 19362: LHA reader - plug two memory leaks on error Fix possible off-by-one when dealing with readlink(2) MFC after:2 weeks Added: head/contrib/libarchive/libarchive/test/test_pax_xattr_header.c - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_pax_xattr_header.c head/contrib/libarchive/libarchive/test/test_pax_xattr_header_all.tar.uu - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_pax_xattr_header_all.tar.uu head/contrib/libarchive/libarchive/test/test_pax_xattr_header_libarchive.tar.uu - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_pax_xattr_header_libarchive.tar.uu head/contrib/libarchive/libarchive/test/test_pax_xattr_header_schily.tar.uu - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_pax_xattr_header_schily.tar.uu head/contrib/libarchive/libarchive/test/test_read_format_7zip_packinfo_digests.7z.uu - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_read_format_7zip_packinfo_digests.7z.uu head/contrib/libarchive/libarchive/test/test_read_format_7zip_packinfo_digests.c - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_read_format_7zip_packinfo_digests.c head/contrib/libarchive/libarchive/test/test_read_format_lha_filename_utf16.c - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_read_format_lha_filename_utf16.c head/contrib/libarchive/libarchive/test/test_read_format_lha_filename_utf16.lzh.uu - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_read_format_lha_filename_utf16.lzh.uu head/contrib/libarchive/libarchive/test/test_read_format_rar5_different_solid_window_size.rar.uu - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_read_format_rar5_different_solid_window_size.rar.uu head/contrib/libarchive/libarchive/test/test_read_format_rar5_different_winsize_on_merge.rar.uu - copied unchanged from r356163, vendor/libarchive/dist/libarchive/test/test_read_format_rar5_different_winsize_on_merge.rar.uu Modified: head/contrib/libarchive/NEWS head/contrib/libarchive/libarchive/archive.h head/contrib/libarchive/libarchive/archive_entry.h head/contrib/libarchive/libarchive/archive_entry_acl.3 head/contrib/libarchive/libarchive/archive_hmac.c head/contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c head/contrib/libarchive/libarchive/archive_read_disk_posix.c head/contrib/libarchive/libarchive/archive_read_support_format_7zip.c head/contrib/libarchive/libarchive/archive_read_support_format_lha.c head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c head/contrib/libarchive/libarchive/archive_read_support_format_zip.c head/contrib/libarchive/libarchive/archive_string.c head/contrib/libarchive/libarchive/archive_write.c head/contrib/libarchive/libarchive/archive_write_add_filter_b64encode.c head/contrib/libarchive/libarchive/archive_write_add_filter_bzip2.c head/contrib/libarchive/libarchive/archive_write_add_filter_compress.c head/contrib/libarchive/libarchive/archive_write_add_filter_gzip.c head/contrib/libarchive/libarchive/archive_write_add_filter_lz4.c head/contrib/libarchive/libarchive/archive_write_add_filter_lzop.c head/contrib/libarchive/libarchive/archive_write_add_filter_program.c head/contrib/libarchive/libarchive/archive_write_add_filter_uuencode.c head/contrib/libarchive/libarchive/archive_write_add_filter_xz.c head/contrib/libarchive/libarchive/archive_write_add_filter_zstd.c head/contrib/libarchive/libarchive/archive_write_disk_posix.c head/contrib/libarchive/libarchive/archive_write_private.h head/contrib/libarchive/libarchive/archive_write_set_format_pax.c head/contrib/libarchive/libarchive/archive_write_set_format_zip.c
svn commit: r356211 - in head/sys: arm/arm conf
Author: ian
Date: Mon Dec 30 23:20:46 2019
New Revision: 356211
URL: https://svnweb.freebsd.org/changeset/base/356211
Log:
Set a "kernbase" symbol in 32-bit arm locore.S and use it with ldscript.arm.
This brings arm into line with how every other arch does it. For some
reason, only arm lacked a definition of a symbol named kernbase in its
locore.S file(s) for use in its ldscript.arm file. Needlessly different
means harder to maintain.
Using a common symbol name also eases work in progress on a script to help
generate arm and arm64 kernels packaged in various ways (like with a header
blob needed for a bootloader prepended to the kernel file).
Modified:
head/sys/arm/arm/locore-v4.S
head/sys/arm/arm/locore-v6.S
head/sys/conf/Makefile.arm
Modified: head/sys/arm/arm/locore-v4.S
==
--- head/sys/arm/arm/locore-v4.SMon Dec 30 22:39:29 2019
(r356210)
+++ head/sys/arm/arm/locore-v4.SMon Dec 30 23:20:46 2019
(r356211)
@@ -62,9 +62,11 @@ __FBSDID("$FreeBSD$");
*/
.text
.align 2
+
+ .globl kernbase
+ .set kernbase,KERNVIRTADDR
+
#ifdef PHYSADDR
-.globl kernbase
-.set kernbase,KERNBASE
.globl physaddr
.set physaddr,PHYSADDR
#endif
Modified: head/sys/arm/arm/locore-v6.S
==
--- head/sys/arm/arm/locore-v6.SMon Dec 30 22:39:29 2019
(r356210)
+++ head/sys/arm/arm/locore-v6.SMon Dec 30 23:20:46 2019
(r356211)
@@ -59,6 +59,9 @@ __FBSDID("$FreeBSD$");
.text
.align 2
+ .globl kernbase
+ .set kernbase,KERNVIRTADDR
+
#if __ARM_ARCH >= 7
#defineHANDLE_HYP
\
/* Leave HYP mode */;\
Modified: head/sys/conf/Makefile.arm
==
--- head/sys/conf/Makefile.arm Mon Dec 30 22:39:29 2019(r356210)
+++ head/sys/conf/Makefile.arm Mon Dec 30 23:20:46 2019(r356211)
@@ -61,7 +61,7 @@ KERNVIRTADDR= 0xc000
# "ELF for the ARM architecture" for more info on the mapping symbols.
SYSTEM_LD= \
${SYSTEM_LD_BASECMD} \
- --defsym='text_start=${KERNVIRTADDR} + SIZEOF_HEADERS' \
+ --defsym='text_start=kernbase + SIZEOF_HEADERS' \
-o ${.TARGET} ${SYSTEM_OBJS} vers.o; \
$(OBJCOPY) \
--wildcard \
@@ -77,7 +77,7 @@ KERNEL_EXTRA_INSTALL+= ${KERNEL_KO}.bin
${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
@echo "linking ${.TARGET}"
@${SYSTEM_LD_BASECMD} \
- --defsym='text_start=${KERNVIRTADDR}' \
+ --defsym='text_start=kernbase' \
-o ${.TARGET} ${SYSTEM_OBJS} vers.o
${SIZE} ${.TARGET}
@${OBJCOPY} \
___
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: r356210 - head/sys/nfs
Author: rmacklem
Date: Mon Dec 30 22:39:29 2019
New Revision: 356210
URL: https://svnweb.freebsd.org/changeset/base/356210
Log:
Add warning printf w.r.t. removal of sys/nfs/nfs_lock.c.
The code in sys/nfs/nfs_lock.c has not been run by default since March 2008
when it was replaced by the in kernel sys/nlm code.
It uses Giant, so it needs to be removed before the FreeBSD 13 release.
This will happen in a couple of months, since few if any users run
the code anyhow and can easily switch to the default in kernel NFSLOCKD.
Modified:
head/sys/nfs/nfs_lock.c
Modified: head/sys/nfs/nfs_lock.c
==
--- head/sys/nfs/nfs_lock.c Mon Dec 30 22:05:57 2019(r356209)
+++ head/sys/nfs/nfs_lock.c Mon Dec 30 22:39:29 2019(r356210)
@@ -89,6 +89,8 @@ nfslock_open(struct cdev *dev, int oflags, int devtype
{
int error;
+ printf("WARNING: uses Giant and will be removed before FreeBSD 13\n"
+ "\tuse the kernel NFSLOCKD/nfslockd.ko\n");
error = priv_check(td, PRIV_NFS_LOCKD);
if (error)
return (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: r356209 - head/share/man/man7
Author: jhb Date: Mon Dec 30 22:05:57 2019 New Revision: 356209 URL: https://svnweb.freebsd.org/changeset/base/356209 Log: Formatting fixes for tables, no content changes. - Add missing .Pp after the end of some lists so that there is a blank line before the subsequent paragraph. - Use a more typical '-tag' bullet list of the make variable descriptions at the end. This adds separation between bullets and is the formatting typically used in manpages for this sort of list. Modified: head/share/man/man7/arch.7 Modified: head/share/man/man7/arch.7 == --- head/share/man/man7/arch.7 Mon Dec 30 21:32:55 2019(r356208) +++ head/share/man/man7/arch.7 Mon Dec 30 22:05:57 2019(r356209) @@ -139,6 +139,7 @@ and .Vt void * are 8 bytes. .El +.Pp Compilers define the .Dv _LP64 symbol when compiling for an @@ -163,6 +164,7 @@ Examples are: .It Dv mips64* Ta Dv mips* .It Dv aarch64 Ta Dv armv6/armv7 .El +.Pp .Dv aarch64 will support execution of .Dv armv6 @@ -184,6 +186,7 @@ On all supported architectures: .It float Ta 4 .It double Ta 8 .El +.Pp Integers are represented in two's complement. Alignment of integer and pointer types is natural, that is, the address of the variable must be congruent to zero modulo the type size. @@ -421,8 +424,9 @@ Most of the externally settable variables are defined man page. These variables are not otherwise documented and are used extensively in the build system. -.Bl -column -offset indent "Sy Variable" "Sy Meaning and usage" -.It Dv MACHINE Represent the hardware platform. +.Bl -tag -width "MACHINE_CPUARCH" +.It Dv MACHINE +Represent the hardware platform. This is the same as the native platform's .Xr uname 1 .Fl m @@ -457,7 +461,8 @@ Generally, .Dv MACHINE should only be used in src/sys and src/stand or in system imagers or installers. -.It Dv MACHINE_ARCHRepresents the CPU processor architecture. +.It Dv MACHINE_ARCH +Represents the CPU processor architecture. This is the same as the native platforms .Xr uname 1 .Fl p @@ -488,7 +493,8 @@ It is unfortunate that amd64 specifies the 64-bit evol platform (it matches the 'first rule') as everybody else uses x86_64. There is no standard name for the processor: each OS selects its own conventions. -.It Dv MACHINE_CPUARCH Represents the source location for a given +.It Dv MACHINE_CPUARCH +Represents the source location for a given .Dv MACHINE_ARCH . It is generally the common prefix for all the MACHINE_ARCH that share the same implementation, though 'riscv' breaks this rule. @@ -502,25 +508,29 @@ The FreeBSD source base supports amd64 and i386 with t distinct source bases living in subdirectories named amd64 and i386 (though behind the scenes there's some sharing that fits into this framework). -.It Dv CPUTYPE Sets the flavor of +.It Dv CPUTYPE +Sets the flavor of .Dv MACHINE_ARCH to build. It is used to optimize the build for a specific CPU / core that the binaries run on. Generally, this does not change the ABI, though it can be a fine line between optimization for specific cases. -.It Dv TARGET Used to set +.It Dv TARGET +Used to set .Dv MACHINE in the top level Makefile for cross building. Unused outside of that scope. It is not passed down to the rest of the build. Makefiles outside of the top level should not use it at all (though some have their own private copy for hysterical raisons). -.It Dv TARGET_ARCH Used to set +.It Dv TARGET_ARCH +Used to set .Dv MACHINE_ARCH by the top level Makefile for cross building. Like -.Dv TARGET , it is unused outside of that scope. +.Dv TARGET , +it is unused outside of that scope. .El .Sh SEE ALSO .Xr src.conf 5 , ___ 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: r356207 - in head/sys/arm64: arm64 include
On 12/30/19 2:59 PM, Colin Percival wrote: On 2019-12-30 12:30, Alan Cox wrote: Author: alc Date: Mon Dec 30 20:30:31 2019 New Revision: 356207 URL: https://svnweb.freebsd.org/changeset/base/356207 Log: Determine whether the MMU hardware is capable of updating a page table entry's access flag and dirty state, and enable this feature when it's available. Am I right in thinking that this should result in improved performance under load? (I'm wondering if it's time to redo my amd64 vs arm64 EC2 benchmarks.) Yes, a modest one. ___ 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: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys
In message , Warner Losh writes: >I never enabled it because I never had a good car size as the default. I'm >guessing it's somewhere on the order of 2 times the queue size in >hardware, but with modern drives I think phk might be right and that >disabling disksort entirely might be optimal, or close to optimal. I think that is a given for SSDs. For disks I fear it would be a model-by-model determination. The situation is quite different for "traditional" and shingled drives for instance, or if, God forbid, the rumours are true and we'll see IBM3380-style dual head assemblies in the market again. I guess the kernel could turn the disksort on/off a few times and only leave it on if it improves things. But first, Somebody Should™ benchmark to see if disksort *ever* is an improvement on contemporary disks. Poul-Henning PS: If somebody really want to improve disk- and ssd- performance, the low-hanging fruit is to write a log-structured storage engine under UFS, to make life easier for flash-adaptation layers and shingling drives. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: r356208 - head/bin/sh/tests/execution
Author: jilles
Date: Mon Dec 30 21:32:55 2019
New Revision: 356208
URL: https://svnweb.freebsd.org/changeset/base/356208
Log:
sh: Test that executing various binary files is rejected
If executing a file fails with an [ENOEXEC] error, the shell executes the
file as a shell script, except that this execution may instead result in an
error message if the file is binary.
Per a recent Austin Group interpretation, we will need to change this to
allow a concatenation of a shell script and a binary payload. See
Austin Group bugs #1226 and #1250.
MFC after:1 week
Added:
head/bin/sh/tests/execution/shellproc2.0 (contents, props changed)
head/bin/sh/tests/execution/shellproc3.0 (contents, props changed)
head/bin/sh/tests/execution/shellproc4.0 (contents, props changed)
head/bin/sh/tests/execution/shellproc5.0 (contents, props changed)
Modified:
head/bin/sh/tests/execution/Makefile
Modified: head/bin/sh/tests/execution/Makefile
==
--- head/bin/sh/tests/execution/MakefileMon Dec 30 20:30:31 2019
(r356207)
+++ head/bin/sh/tests/execution/MakefileMon Dec 30 21:32:55 2019
(r356208)
@@ -55,6 +55,10 @@ ${PACKAGE}FILES+=set-x2.0
${PACKAGE}FILES+= set-x3.0
${PACKAGE}FILES+= set-x4.0
${PACKAGE}FILES+= shellproc1.0
+${PACKAGE}FILES+= shellproc2.0
+${PACKAGE}FILES+= shellproc3.0
+${PACKAGE}FILES+= shellproc4.0
+${PACKAGE}FILES+= shellproc5.0
${PACKAGE}FILES+= subshell1.0 subshell1.0.stdout
${PACKAGE}FILES+= subshell2.0
${PACKAGE}FILES+= subshell3.0
Added: head/bin/sh/tests/execution/shellproc2.0
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/bin/sh/tests/execution/shellproc2.0Mon Dec 30 21:32:55 2019
(r356208)
@@ -0,0 +1,18 @@
+# $FreeBSD$
+# This tests a quality of implementation issue.
+# Shells are not required to reject executing binary files as shell scripts
+# but executing, for example, ELF files for a different architecture as
+# shell scripts may have annoying side effects.
+
+T=`mktemp -d "${TMPDIR:-/tmp}/sh-test."` || exit
+trap 'rm -rf "${T}"' 0
+printf '\0' >"$T/testshellproc"
+chmod 755 "$T/testshellproc"
+if [ ! -s "$T/testshellproc" ]; then
+ printf "printf did not write a NUL character\n" >&2
+ exit 2
+fi
+PATH=$T:$PATH
+errout=`testshellproc 3>&2 2>&1 >&3 3>&-`
+r=$?
+[ "$r" = 126 ] && [ -n "$errout" ]
Added: head/bin/sh/tests/execution/shellproc3.0
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/bin/sh/tests/execution/shellproc3.0Mon Dec 30 21:32:55 2019
(r356208)
@@ -0,0 +1,14 @@
+# $FreeBSD$
+# This tests a quality of implementation issue.
+# Shells are not required to reject executing binary files as shell scripts
+# but executing, for example, ELF files for a different architecture as
+# shell scripts may have annoying side effects.
+
+T=`mktemp -d "${TMPDIR:-/tmp}/sh-test."` || exit
+trap 'rm -rf "${T}"' 0
+printf '\177ELF\001!!\011\0\0\0\0\0\0\0\0' >"$T/testshellproc"
+chmod 755 "$T/testshellproc"
+PATH=$T:$PATH
+errout=`testshellproc 3>&2 2>&1 >&3 3>&-`
+r=$?
+[ "$r" = 126 ] && [ -n "$errout" ]
Added: head/bin/sh/tests/execution/shellproc4.0
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/bin/sh/tests/execution/shellproc4.0Mon Dec 30 21:32:55 2019
(r356208)
@@ -0,0 +1,14 @@
+# $FreeBSD$
+# This tests a quality of implementation issue.
+# Shells are not required to reject executing binary files as shell scripts
+# but executing, for example, ELF files for a different architecture as
+# shell scripts may have annoying side effects.
+
+T=`mktemp -d "${TMPDIR:-/tmp}/sh-test."` || exit
+trap 'rm -rf "${T}"' 0
+printf '\211PNG\015\012\032\012\0\0\0\015IHDR' >"$T/testshellproc"
+chmod 755 "$T/testshellproc"
+PATH=$T:$PATH
+errout=`testshellproc 3>&2 2>&1 >&3 3>&-`
+r=$?
+[ "$r" = 126 ] && [ -n "$errout" ]
Added: head/bin/sh/tests/execution/shellproc5.0
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/bin/sh/tests/execution/shellproc5.0Mon Dec 30 21:32:55 2019
(r356208)
@@ -0,0 +1,14 @@
+# $FreeBSD$
+# This tests a quality of implementation issue.
+# Shells are not required to reject executing binary files as shell scripts
+# but executing, for example, ELF files for a different architecture as
+# shell scripts may have annoying side effects.
+
+T=`mktemp -d "${TMPDIR:-/tmp}/sh-test."` ||
Re: svn commit: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys
On Mon, 30 Dec 2019, Warner Losh wrote: On Mon, Dec 30, 2019 at 12:55 PM Alexander Motin wrote: On 30.12.2019 12:02, Alexey Dokuchaev wrote: > On Mon, Dec 30, 2019 at 08:55:14AM -0700, Warner Losh wrote: >> On Mon, Dec 30, 2019, 5:32 AM Alexey Dokuchaev wrote: >>> On Sun, Dec 29, 2019 at 09:16:04PM +, Alexander Motin wrote: New Revision: 356185 URL: https://svnweb.freebsd.org/changeset/base/356185 Log: ? ?Remove GEOM_SCHED class and gsched tool. ? ?[...] >>> >>> Wow, that was unexpected, I use it on all my machines' HDD drives. >>> Is there a planned replacement, or I'd better create a port for the >>> GEOM_SCHED class and gsched(8) tool? >> >> How much of a performance improvement do you see with it? >> >> There has been no tweaks to this geom in years and years. It was tuned >> to 10 year old hard drives and never retuned for anything newer. > > Well, hard drives essentially didn't change since then, still being the > same roration media. :) At least some papers about gsched I read mention adX devices, which means old ATA stack and no NCQ.? It can be quite a significant change to let HDD to do its own scheduling.? Also about a year ago in r335066 Warner added sysctl debug.bioq_batchsize, which if set to non-zero value may, I think, improve fairness between several processes, just not sure why it was never enabled. I never?enabled it because I never had a good?car size as the default. I'm guessing? it's somewhere?on the order of 2 times the queue size in hardware, but with modern drives I think phk might be right and that disabling disksort entirely might be optimal, or close to optimal. ? >> And when I played with it a few years ago, I saw no improvements... > > Admittedly, I've only did some tests no later than in 8.4 times when I > first started using it.? Fair point, though, I should redo them again. I'm sorry to create a regression for you, if there is really one.? As I have written I don't have so much against the scheduler part itself, as against the accumulated technical debt and the way integration is done, such as mechanism of live insertion, etc.? Without unmapped I/O and direct dispatch I bet it must be quite slow on bigger systems, that is why I doubted anybody really use it. > Is there a planned replacement, or I'd better create a port for the > GEOM_SCHED class and gsched(8) tool? I wasn't planning replacement.? And moving it to ports would be a problem, since in process I removed few capabilities critical for it: nstart/nend for live insertion and BIO classification for scheduling. But the last I don't mind to return if there appear to be a need.? It is only the first I am strongly against.? But if somebody would like to reimplement it, may be it would be better to consider merging it with CAM I/O scheduler by Warner?? The one at least knows about device queue depth, etc.? We could return the BIO classification to be used by CAM scheduler instead, if needed. I'd be keen on helping anybody that wants to experiment with hard disk drive optmizations in iosched. My doodles to make it better showed no early improvements, so Iv'e not tried to bring them into the tree. However, our workload is basically 'large block random' which isn't the same as others and others might have a workload that could benefit. I've found a marginal improvement from the read over writes bias in our workload, and another?marginal improvement for favoring metadata reads over normal reads (because?for us, sendfile blocks for some of these reads, but others may see no improvement). I'm working to clean up the metadata read stuff to get it into the tree. I've not tested it on ZFS, though, so there will be no ZFS metadata labeling in the initial commit. So I like the idea, and would love to work with someone that needs it and/or whose work loads can be improved by it. The biggest issue I have found with drive sorting and traditional elevator algorithms is that it is not latency limiting. We have other problems at higher layers where we scheduling too many writes simultaneously that contribute substantially to I/O latency. Also read-after-writes are blocked in the buffer cache while a senseless number of buffers are queued and locked. An algorithm I have found effective and implemented at least twice is to estimate I/O time and then give a maximum sort latency. For many drives you have to go further and starve them for I/O until they complete a particularly long running operation or they can continue to decide to
Re: svn commit: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys
On Mon, Dec 30, 2019 at 12:55 PM Alexander Motin wrote: > On 30.12.2019 12:02, Alexey Dokuchaev wrote: > > On Mon, Dec 30, 2019 at 08:55:14AM -0700, Warner Losh wrote: > >> On Mon, Dec 30, 2019, 5:32 AM Alexey Dokuchaev wrote: > >>> On Sun, Dec 29, 2019 at 09:16:04PM +, Alexander Motin wrote: > New Revision: 356185 > URL: https://svnweb.freebsd.org/changeset/base/356185 > > Log: > Remove GEOM_SCHED class and gsched tool. > [...] > >>> > >>> Wow, that was unexpected, I use it on all my machines' HDD drives. > >>> Is there a planned replacement, or I'd better create a port for the > >>> GEOM_SCHED class and gsched(8) tool? > >> > >> How much of a performance improvement do you see with it? > >> > >> There has been no tweaks to this geom in years and years. It was tuned > >> to 10 year old hard drives and never retuned for anything newer. > > > > Well, hard drives essentially didn't change since then, still being the > > same roration media. :) > > At least some papers about gsched I read mention adX devices, which > means old ATA stack and no NCQ. It can be quite a significant change to > let HDD to do its own scheduling. Also about a year ago in r335066 > Warner added sysctl debug.bioq_batchsize, which if set to non-zero value > may, I think, improve fairness between several processes, just not sure > why it was never enabled. > I never enabled it because I never had a good car size as the default. I'm guessing it's somewhere on the order of 2 times the queue size in hardware, but with modern drives I think phk might be right and that disabling disksort entirely might be optimal, or close to optimal. > >> And when I played with it a few years ago, I saw no improvements... > > > > Admittedly, I've only did some tests no later than in 8.4 times when I > > first started using it. Fair point, though, I should redo them again. > > I'm sorry to create a regression for you, if there is really one. As I > have written I don't have so much against the scheduler part itself, as > against the accumulated technical debt and the way integration is done, > such as mechanism of live insertion, etc. Without unmapped I/O and > direct dispatch I bet it must be quite slow on bigger systems, that is > why I doubted anybody really use it. > > > Is there a planned replacement, or I'd better create a port for the > > GEOM_SCHED class and gsched(8) tool? > > I wasn't planning replacement. And moving it to ports would be a > problem, since in process I removed few capabilities critical for it: > nstart/nend for live insertion and BIO classification for scheduling. > But the last I don't mind to return if there appear to be a need. It is > only the first I am strongly against. But if somebody would like to > reimplement it, may be it would be better to consider merging it with > CAM I/O scheduler by Warner? The one at least knows about device queue > depth, etc. We could return the BIO classification to be used by CAM > scheduler instead, if needed. > I'd be keen on helping anybody that wants to experiment with hard disk drive optmizations in iosched. My doodles to make it better showed no early improvements, so Iv'e not tried to bring them into the tree. However, our workload is basically 'large block random' which isn't the same as others and others might have a workload that could benefit. I've found a marginal improvement from the read over writes bias in our workload, and another marginal improvement for favoring metadata reads over normal reads (because for us, sendfile blocks for some of these reads, but others may see no improvement). I'm working to clean up the metadata read stuff to get it into the tree. I've not tested it on ZFS, though, so there will be no ZFS metadata labeling in the initial commit. So I like the idea, and would love to work with someone that needs it and/or whose work loads can be improved by it. Warner -- > Alexander Motin > ___ 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: r356207 - in head/sys/arm64: arm64 include
On 2019-12-30 12:30, Alan Cox wrote: > Author: alc > Date: Mon Dec 30 20:30:31 2019 > New Revision: 356207 > URL: https://svnweb.freebsd.org/changeset/base/356207 > > Log: > Determine whether the MMU hardware is capable of updating a page table > entry's access flag and dirty state, and enable this feature when it's > available. Am I right in thinking that this should result in improved performance under load? (I'm wondering if it's time to redo my amd64 vs arm64 EC2 benchmarks.) -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ 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: r356207 - in head/sys/arm64: arm64 include
Author: alc
Date: Mon Dec 30 20:30:31 2019
New Revision: 356207
URL: https://svnweb.freebsd.org/changeset/base/356207
Log:
Determine whether the MMU hardware is capable of updating a page table
entry's access flag and dirty state, and enable this feature when it's
available.
Ensure that we don't overlook a dirty state update that is concurrent
with a call to pmap_enter(). (Previously, all dirty state updates would
have occurred with the containing pmap's lock held, so a page table entry's
dirty state could not have changed while pmap_enter() held that same lock.)
Reviewed by: andrew, markj
MFC after:2 weeks
Differential Revision:https://reviews.freebsd.org/D22907
Modified:
head/sys/arm64/arm64/locore.S
head/sys/arm64/arm64/pmap.c
head/sys/arm64/include/armreg.h
Modified: head/sys/arm64/arm64/locore.S
==
--- head/sys/arm64/arm64/locore.S Mon Dec 30 18:11:06 2019
(r356206)
+++ head/sys/arm64/arm64/locore.S Mon Dec 30 20:30:31 2019
(r356207)
@@ -683,7 +683,8 @@ start_mmu:
/*
* Setup TCR according to the PARange and ASIDBits fields
-* from ID_AA64MMFR0_EL1. More precisely, set TCR_EL1.AS
+* from ID_AA64MMFR0_EL1 and the HAFDBS field from the
+* ID_AA64MMFR1_EL1. More precisely, set TCR_EL1.AS
* to 1 only if the ASIDBits field equals 0b0010.
*/
ldr x2, tcr
@@ -700,6 +701,21 @@ start_mmu:
/* Set TCR.AS with x3 */
bfi x2, x3, #(TCR_ASID_SHIFT), #(TCR_ASID_WIDTH)
+ /*
+* Check if the HW supports access flag and dirty state updates,
+* and set TCR_EL1.HA and TCR_EL1.HD accordingly.
+*/
+ mrs x3, id_aa64mmfr1_el1
+ and x3, x3, #(ID_AA64MMFR1_HAFDBS_MASK)
+ cmp x3, #1
+ b.ne1f
+ orr x2, x2, #(TCR_HA)
+ b 2f
+1:
+ cmp x3, #2
+ b.ne2f
+ orr x2, x2, #(TCR_HA | TCR_HD)
+2:
msr tcr_el1, x2
/*
Modified: head/sys/arm64/arm64/pmap.c
==
--- head/sys/arm64/arm64/pmap.c Mon Dec 30 18:11:06 2019(r356206)
+++ head/sys/arm64/arm64/pmap.c Mon Dec 30 20:30:31 2019(r356207)
@@ -3510,8 +3510,7 @@ validate:
KASSERT(opa == pa, ("pmap_enter: invalid update"));
if ((orig_l3 & ~ATTR_AF) != (new_l3 & ~ATTR_AF)) {
/* same PA, different attributes */
- /* XXXMJ need to reload orig_l3 for hardware DBM. */
- pmap_load_store(l3, new_l3);
+ orig_l3 = pmap_load_store(l3, new_l3);
pmap_invalidate_page(pmap, va);
if ((orig_l3 & ATTR_SW_MANAGED) != 0 &&
pmap_pte_dirty(orig_l3))
Modified: head/sys/arm64/include/armreg.h
==
--- head/sys/arm64/include/armreg.h Mon Dec 30 18:11:06 2019
(r356206)
+++ head/sys/arm64/include/armreg.h Mon Dec 30 20:30:31 2019
(r356207)
@@ -619,6 +619,11 @@
#definePSR_FLAGS 0xf000
/* TCR_EL1 - Translation Control Register */
+#defineTCR_HD_SHIFT40
+#defineTCR_HD (0x1UL << TCR_HD_SHIFT)
+#defineTCR_HA_SHIFT39
+#defineTCR_HA (0x1UL << TCR_HA_SHIFT)
+
#defineTCR_ASID_SHIFT 36
#defineTCR_ASID_WIDTH 1
#defineTCR_ASID_16 (0x1UL << TCR_ASID_SHIFT)
___
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: r356142 - in head/sys: dev/ofw sys
On Sun, Dec 29, 2019, 8:02 PM Kevin P. Neal wrote: > On Sat, Dec 28, 2019 at 10:11:48AM -1000, Jeff Roberson wrote: > > It seems to be the prevailing theory that headers are not even really > > copyrightable. This has even been tested in court a few times (bsd, > java). > > > > http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html > > > > The original definitions from this file were part of posix.1b and so it's > > hard to argue they are anything but public. Coincidentally I know Greg > and > > Wow is Google v Oracle going to screw this up. I fully expect the US > Supreme > Court to make a total hash of that case and cause havoc for the whole > software industry. > > The right thing for FreeBSD to do is decrease the size of the attack > surface > by getting the licenses as straight as possible. IMHO. But IANAL. > > > In my opinion, this has already wasted everyone's time with an irrelevant > > nit-picking argument. The onus is not on Pedro to chase this down just > so > > Lawyers make a living nit-picking. That's why one has to be very careful > to do a preemptive nit-pick before they get involved. > Nit picking with no sound legal basis by an engineer who has no license to practice law, however, could be more trouble than it's worth. We as a project have been doing this for at least 20 years, and there have been several legal reviews by companies using FreeBSD that haven't flagged this as an issue. Being nit-picky just to be nit-picky isn't helpful if the nits picked are snipe hunts without any benefit. Especially when accompanied by a arrogant and condescending tone and a know it all attitude with no professional credentials to back it. So we need, as a project, to be careful what we spend time on. Doubly so for stupid nit picks that we know have no merit. Those drain enthusiasm from the volunteers far in excess of any possible benefit the unit picks may bring to the project. Warner -- > Kevin P. Nealhttp://www.pobox.com/~kpn/ >On the community of supercomputer fans: > "But what we lack in size we make up for in eccentricity." > from Steve Gombosi, comp.sys.super, 31 Jul 2000 11:22:43 -0600 > ___ 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: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys
On 30.12.2019 12:02, Alexey Dokuchaev wrote: > On Mon, Dec 30, 2019 at 08:55:14AM -0700, Warner Losh wrote: >> On Mon, Dec 30, 2019, 5:32 AM Alexey Dokuchaev wrote: >>> On Sun, Dec 29, 2019 at 09:16:04PM +, Alexander Motin wrote: New Revision: 356185 URL: https://svnweb.freebsd.org/changeset/base/356185 Log: Remove GEOM_SCHED class and gsched tool. [...] >>> >>> Wow, that was unexpected, I use it on all my machines' HDD drives. >>> Is there a planned replacement, or I'd better create a port for the >>> GEOM_SCHED class and gsched(8) tool? >> >> How much of a performance improvement do you see with it? >> >> There has been no tweaks to this geom in years and years. It was tuned >> to 10 year old hard drives and never retuned for anything newer. > > Well, hard drives essentially didn't change since then, still being the > same roration media. :) At least some papers about gsched I read mention adX devices, which means old ATA stack and no NCQ. It can be quite a significant change to let HDD to do its own scheduling. Also about a year ago in r335066 Warner added sysctl debug.bioq_batchsize, which if set to non-zero value may, I think, improve fairness between several processes, just not sure why it was never enabled. >> And when I played with it a few years ago, I saw no improvements... > > Admittedly, I've only did some tests no later than in 8.4 times when I > first started using it. Fair point, though, I should redo them again. I'm sorry to create a regression for you, if there is really one. As I have written I don't have so much against the scheduler part itself, as against the accumulated technical debt and the way integration is done, such as mechanism of live insertion, etc. Without unmapped I/O and direct dispatch I bet it must be quite slow on bigger systems, that is why I doubted anybody really use it. > Is there a planned replacement, or I'd better create a port for the > GEOM_SCHED class and gsched(8) tool? I wasn't planning replacement. And moving it to ports would be a problem, since in process I removed few capabilities critical for it: nstart/nend for live insertion and BIO classification for scheduling. But the last I don't mind to return if there appear to be a need. It is only the first I am strongly against. But if somebody would like to reimplement it, may be it would be better to consider merging it with CAM I/O scheduler by Warner? The one at least knows about device queue depth, etc. We could return the BIO classification to be used by CAM scheduler instead, if needed. -- Alexander Motin ___ 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: r356142 - in head/sys: dev/ofw sys
On Sun, 29 Dec 2019, Kevin P. Neal wrote: On Sat, Dec 28, 2019 at 10:11:48AM -1000, Jeff Roberson wrote: It seems to be the prevailing theory that headers are not even really copyrightable. This has even been tested in court a few times (bsd, java). http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html The original definitions from this file were part of posix.1b and so it's hard to argue they are anything but public. Coincidentally I know Greg and Wow is Google v Oracle going to screw this up. I fully expect the US Supreme Court to make a total hash of that case and cause havoc for the whole software industry. The right thing for FreeBSD to do is decrease the size of the attack surface by getting the licenses as straight as possible. IMHO. But IANAL. In my opinion, this has already wasted everyone's time with an irrelevant nit-picking argument. The onus is not on Pedro to chase this down just so Lawyers make a living nit-picking. That's why one has to be very careful to do a preemptive nit-pick before they get involved. I personally participated when a fortune < 100 company sent a team of lawyers to audit the licensing terms of FreeBSD to ensure compliance in a multi-billion dollar a year product. None of them batted an eye at this. It is my understanding that this has taken place multiple times and once even resulted in phk receiving an official beer from a similarly sized company per the terms of his beerware license. Do we actually believe that someone somewhere is going to sue the project or it's users on behalf of myself or greg because the user is in compliance with one bsd license and not the other? I trust the lawyer's opinions over yours. The problem here isn't the license. It's that everyone who allegedly thinks this is of such dire importance that they must continue spaming the list and arguing about it hasn't thought it important enough to send a single email to Greg Ansley so they personally can commit a simplification. It literally would've taken less time to simply copy Greg, ask approval, and commit a change and no one would've argued. I would argue that we don't even need greg's approval to copy 8 standards defined function prototypes. Richard Stallman seems to argue the same and I guarantee he's spent more time with copyright lawyers than any of us. I assert that the point here is not the license at all or it would've been resolved already. I see a lot of low effort sniping on the list off and on since my return to opensource. In most cases it is not even from particularly active contributors. It is very discourging to donate time and energy to the project only to be rewarded with criticism delivered with an air of superiority. It drives people away at a time when operating systems are all facing declining and aging developer populations. Jeff -- Kevin P. Nealhttp://www.pobox.com/~kpn/ On the community of supercomputer fans: "But what we lack in size we make up for in eccentricity." from Steve Gombosi, comp.sys.super, 31 Jul 2000 11:22:43 -0600 ___ 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: r356206 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux
Author: kaktus
Date: Mon Dec 30 18:11:06 2019
New Revision: 356206
URL: https://svnweb.freebsd.org/changeset/base/356206
Log:
linux(4): implement copy_file_range(2)
copy_file_range(2) is implemented natively since r350315, make it available
for Linux binaries too.
Reviewed by: kib (mentor), trasz (previous version)
Approved by: kib (mentor)
Differential Revision:https://reviews.freebsd.org/D22959
Modified:
head/sys/amd64/linux/linux_dummy.c
head/sys/amd64/linux32/linux32_dummy.c
head/sys/arm64/linux/linux_dummy.c
head/sys/compat/linux/linux_file.c
head/sys/i386/linux/linux_dummy.c
Modified: head/sys/amd64/linux/linux_dummy.c
==
--- head/sys/amd64/linux/linux_dummy.c Mon Dec 30 17:18:50 2019
(r356205)
+++ head/sys/amd64/linux/linux_dummy.c Mon Dec 30 18:11:06 2019
(r356206)
@@ -144,8 +144,6 @@ DUMMY(userfaultfd);
DUMMY(membarrier);
/* Linux 4.4: */
DUMMY(mlock2);
-/* Linux 4.5: */
-DUMMY(copy_file_range);
/* Linux 4.6: */
DUMMY(preadv2);
DUMMY(pwritev2);
Modified: head/sys/amd64/linux32/linux32_dummy.c
==
--- head/sys/amd64/linux32/linux32_dummy.c Mon Dec 30 17:18:50 2019
(r356205)
+++ head/sys/amd64/linux32/linux32_dummy.c Mon Dec 30 18:11:06 2019
(r356206)
@@ -148,8 +148,6 @@ DUMMY(userfaultfd);
DUMMY(membarrier);
/* Linux 4.4: */
DUMMY(mlock2);
-/* Linux 4.5: */
-DUMMY(copy_file_range);
/* Linux 4.6: */
DUMMY(preadv2);
DUMMY(pwritev2);
Modified: head/sys/arm64/linux/linux_dummy.c
==
--- head/sys/arm64/linux/linux_dummy.c Mon Dec 30 17:18:50 2019
(r356205)
+++ head/sys/arm64/linux/linux_dummy.c Mon Dec 30 18:11:06 2019
(r356206)
@@ -142,8 +142,6 @@ DUMMY(userfaultfd);
DUMMY(membarrier);
/* Linux 4.4: */
DUMMY(mlock2);
-/* Linux 4.5: */
-DUMMY(copy_file_range);
/* Linux 4.6: */
DUMMY(preadv2);
DUMMY(pwritev2);
Modified: head/sys/compat/linux/linux_file.c
==
--- head/sys/compat/linux/linux_file.c Mon Dec 30 17:18:50 2019
(r356205)
+++ head/sys/compat/linux/linux_file.c Mon Dec 30 18:11:06 2019
(r356206)
@@ -1565,3 +1565,44 @@ linux_fallocate(struct thread *td, struct linux_falloc
return (kern_posix_fallocate(td, args->fd, args->offset,
args->len));
}
+
+int
+linux_copy_file_range(struct thread *td, struct linux_copy_file_range_args
+*args)
+{
+ l_loff_t inoff, outoff, *inoffp, *outoffp;
+ int error, flags;
+
+ /*
+* copy_file_range(2) on Linux doesn't define any flags (yet), so is
+* the native implementation. Enforce it.
+*/
+ if (args->flags != 0) {
+ linux_msg(td, "copy_file_range unsupported flags 0x%x",
+ args->flags);
+ return (EINVAL);
+ }
+ flags = 0;
+ inoffp = outoffp = NULL;
+ if (args->off_in != NULL) {
+ error = copyin(args->off_in, , sizeof(l_loff_t));
+ if (error != 0)
+ return (error);
+ inoffp =
+ }
+ if (args->off_out != NULL) {
+ error = copyin(args->off_out, , sizeof(l_loff_t));
+ if (error != 0)
+ return (error);
+ outoffp =
+ }
+
+ error = kern_copy_file_range(td, args->fd_in, inoffp, args->fd_out,
+ outoffp, args->len, flags);
+ if (error == 0 && args->off_in != NULL)
+ error = copyout(inoffp, args->off_in, sizeof(l_loff_t));
+ if (error == 0 && args->off_out != NULL)
+ error = copyout(outoffp, args->off_out, sizeof(l_loff_t));
+ return (error);
+}
+
Modified: head/sys/i386/linux/linux_dummy.c
==
--- head/sys/i386/linux/linux_dummy.c Mon Dec 30 17:18:50 2019
(r356205)
+++ head/sys/i386/linux/linux_dummy.c Mon Dec 30 18:11:06 2019
(r356206)
@@ -144,8 +144,6 @@ DUMMY(userfaultfd);
DUMMY(membarrier);
/* Linux 4.4: */
DUMMY(mlock2);
-/* Linux 4.5: */
-DUMMY(copy_file_range);
/* Linux 4.6: */
DUMMY(preadv2);
DUMMY(pwritev2);
___
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: r356205 - head/sys/riscv/riscv
Author: br Date: Mon Dec 30 17:18:50 2019 New Revision: 356205 URL: https://svnweb.freebsd.org/changeset/base/356205 Log: Don't hard-code field offsets of struct riscv_bootparams. Submitted by: James Clarke Sponsored by: DARPA, AFRL Differential Revision:https://reviews.freebsd.org/D22970 Modified: head/sys/riscv/riscv/genassym.c head/sys/riscv/riscv/locore.S Modified: head/sys/riscv/riscv/genassym.c == --- head/sys/riscv/riscv/genassym.c Mon Dec 30 15:54:36 2019 (r356204) +++ head/sys/riscv/riscv/genassym.c Mon Dec 30 17:18:50 2019 (r356205) @@ -101,3 +101,9 @@ ASSYM(TF_SCAUSE, offsetof(struct trapframe, tf_scause) ASSYM(TF_SSTATUS, offsetof(struct trapframe, tf_sstatus)); ASSYM(RISCV_BOOTPARAMS_SIZE, sizeof(struct riscv_bootparams)); +ASSYM(RISCV_BOOTPARAMS_KERN_L1PT, offsetof(struct riscv_bootparams, kern_l1pt)); +ASSYM(RISCV_BOOTPARAMS_KERN_PHYS, offsetof(struct riscv_bootparams, kern_phys)); +ASSYM(RISCV_BOOTPARAMS_KERN_STACK, offsetof(struct riscv_bootparams, +kern_stack)); +ASSYM(RISCV_BOOTPARAMS_DTBP_VIRT, offsetof(struct riscv_bootparams, dtbp_virt)); +ASSYM(RISCV_BOOTPARAMS_DTBP_PHYS, offsetof(struct riscv_bootparams, dtbp_phys)); Modified: head/sys/riscv/riscv/locore.S == --- head/sys/riscv/riscv/locore.S Mon Dec 30 15:54:36 2019 (r356204) +++ head/sys/riscv/riscv/locore.S Mon Dec 30 17:18:50 2019 (r356205) @@ -206,15 +206,15 @@ va: /* Fill riscv_bootparams */ la t0, pagetable_l1 - sd t0, 0(sp) /* kern_l1pt */ - sd s9, 8(sp) /* kern_phys */ + sd t0, RISCV_BOOTPARAMS_KERN_L1PT(sp) + sd s9, RISCV_BOOTPARAMS_KERN_PHYS(sp) la t0, initstack - sd t0, 16(sp) /* kern_stack */ + sd t0, RISCV_BOOTPARAMS_KERN_STACK(sp) li t0, (VM_MAX_KERNEL_ADDRESS - 2 * L2_SIZE) - sd t0, 24(sp) /* dtbp_virt */ - sd a1, 32(sp) /* dtbp_phys */ + sd t0, RISCV_BOOTPARAMS_DTBP_VIRT(sp) + sd a1, RISCV_BOOTPARAMS_DTBP_PHYS(sp) mv a0, sp call_C_LABEL(initriscv) /* Off we go */ ___ 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: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys
On Mon, Dec 30, 2019 at 08:55:14AM -0700, Warner Losh wrote: > On Mon, Dec 30, 2019, 5:32 AM Alexey Dokuchaev wrote: > > On Sun, Dec 29, 2019 at 09:16:04PM +, Alexander Motin wrote: > > > New Revision: 356185 > > > URL: https://svnweb.freebsd.org/changeset/base/356185 > > > > > > Log: > > > Remove GEOM_SCHED class and gsched tool. > > > [...] > > > > Wow, that was unexpected, I use it on all my machines' HDD drives. > > Is there a planned replacement, or I'd better create a port for the > > GEOM_SCHED class and gsched(8) tool? > > How much of a performance improvement do you see with it? > > There has been no tweaks to this geom in years and years. It was tuned > to 10 year old hard drives and never retuned for anything newer. Well, hard drives essentially didn't change since then, still being the same roration media. :) > And when I played with it a few years ago, I saw no improvements... Admittedly, I've only did some tests no later than in 8.4 times when I first started using it. Fair point, though, I should redo them again. ./danfe ___ 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: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys
On Mon, Dec 30, 2019, 5:32 AM Alexey Dokuchaev wrote: > On Sun, Dec 29, 2019 at 09:16:04PM +, Alexander Motin wrote: > > New Revision: 356185 > > URL: https://svnweb.freebsd.org/changeset/base/356185 > > > > Log: > > Remove GEOM_SCHED class and gsched tool. > > > > This code was not actively maintained since it was introduced 10 years > ago. > > It lacks support for many later GEOM features, such as direct dispatch, > > unmapped I/O, stripesize/stripeoffset, resize, etc. Plus it is the > only > > remaining use of GEOM nstart/nend request counters, used there to > implement > > live insertion/removal, questionable by itself. > > Wow, that was unexpected, I use it on all my machines' HDD drives. > Is there a planned replacement, or I'd better create a port for the > GEOM_SCHED class and gsched(8) tool? How much of a performance improvement do you see with it? There has been no tweaks to this geom in years and years. It was tuned to 10 year old hard drives and never retuned for anything newer. And when I played with it a few years ago, I saw no improvements... Warner > ___ 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: r356204 - head/usr.sbin/inetd
Author: kevans
Date: Mon Dec 30 15:54:36 2019
New Revision: 356204
URL: https://svnweb.freebsd.org/changeset/base/356204
Log:
inetd: don't leak `policy` on return
sep->se_policy gets a strdup'd version of policy, so we don't need it to
stick around afterwards.
While here, remove a couple of NULL checks prior to free(policy).
CID: 1006865
MFC after:3 days
Modified:
head/usr.sbin/inetd/inetd.c
Modified: head/usr.sbin/inetd/inetd.c
==
--- head/usr.sbin/inetd/inetd.c Mon Dec 30 14:38:06 2019(r356203)
+++ head/usr.sbin/inetd/inetd.c Mon Dec 30 15:54:36 2019(r356204)
@@ -1629,12 +1629,10 @@ more:
for (p = cp + 2; p && *p && isspace(*p); p++)
;
if (*p == '\0') {
- if (policy)
- free(policy);
+ free(policy);
policy = NULL;
} else if (ipsec_get_policylen(p) >= 0) {
- if (policy)
- free(policy);
+ free(policy);
policy = newstr(p);
} else {
syslog(LOG_ERR,
@@ -1969,6 +1967,7 @@ more:
LIST_INIT(>se_conn[i]);
#ifdef IPSEC
sep->se_policy = policy ? newstr(policy) : NULL;
+ free(policy);
#endif
return (sep);
}
___
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: r356203 - head/sys/riscv/riscv
Author: br
Date: Mon Dec 30 14:38:06 2019
New Revision: 356203
URL: https://svnweb.freebsd.org/changeset/base/356203
Log:
Don't hard-code size of struct riscv_bootparams.
Submitted by: James Clarke
Sponsored by: DARPA, AFRL
Differential Revision:https://reviews.freebsd.org/D22968
Modified:
head/sys/riscv/riscv/genassym.c
head/sys/riscv/riscv/locore.S
Modified: head/sys/riscv/riscv/genassym.c
==
--- head/sys/riscv/riscv/genassym.c Mon Dec 30 13:29:30 2019
(r356202)
+++ head/sys/riscv/riscv/genassym.c Mon Dec 30 14:38:06 2019
(r356203)
@@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
ASSYM(KERNBASE, KERNBASE);
ASSYM(VM_MAXUSER_ADDRESS, VM_MAXUSER_ADDRESS);
@@ -98,3 +99,5 @@ ASSYM(TF_SEPC, offsetof(struct trapframe, tf_sepc));
ASSYM(TF_STVAL, offsetof(struct trapframe, tf_stval));
ASSYM(TF_SCAUSE, offsetof(struct trapframe, tf_scause));
ASSYM(TF_SSTATUS, offsetof(struct trapframe, tf_sstatus));
+
+ASSYM(RISCV_BOOTPARAMS_SIZE, sizeof(struct riscv_bootparams));
Modified: head/sys/riscv/riscv/locore.S
==
--- head/sys/riscv/riscv/locore.S Mon Dec 30 13:29:30 2019
(r356202)
+++ head/sys/riscv/riscv/locore.S Mon Dec 30 14:38:06 2019
(r356203)
@@ -188,7 +188,7 @@ va:
mv sp, s3
/* Allocate space for thread0 PCB and riscv_bootparams */
- addisp, sp, -(PCB_SIZE + 40) & ~STACKALIGNBYTES
+ addisp, sp, -(PCB_SIZE + RISCV_BOOTPARAMS_SIZE) & ~STACKALIGNBYTES
/* Clear BSS */
la s0, _C_LABEL(__bss_start)
___
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: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys
On 2019-12-30 06:32, Alexey Dokuchaev wrote: > On Sun, Dec 29, 2019 at 09:16:04PM +, Alexander Motin wrote: >> New Revision: 356185 >> URL: https://svnweb.freebsd.org/changeset/base/356185 >> >> Log: >> Remove GEOM_SCHED class and gsched tool. >> >> This code was not actively maintained since it was introduced 10 years ago. >> It lacks support for many later GEOM features, such as direct dispatch, >> unmapped I/O, stripesize/stripeoffset, resize, etc. Plus it is the only >> remaining use of GEOM nstart/nend request counters, used there to implement >> live insertion/removal, questionable by itself. > Wow, that was unexpected, I use it on all my machines' HDD drives. There was a posting by mav@ on the -arch list : " gsched: modernize or remove?". It was a short notice (Dec 27), but there was strong agreement from the author. > Is there a planned replacement, or I'd better create a port for the > GEOM_SCHED class and gsched(8) tool? If you can convince someone to update it with the enhancements suggested in the -arch post, I guess it could be resurrected, otherwise a port. Pedro. ___ 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: r356092 - head/sys/dev/kbdmux
On 2019-12-27 16:34, Hans Petter Selasky wrote: On 2019-12-27 17:28, Kyle Evans wrote: At the risk of asking a dumb question, where are you wanting to make this distinction at? For example when implementing applications which allow playing the piano via the system keyboard this is useful. See here for example: https://doc.qt.io/qt-5/qkeyevent.html#isAutoRepeat Needs to be implemented for FreeBSD, though! What do you think? I see the evdev.c layer detects automagically if a key is already down, and treat that as a key-repeat event. But I couldn't find similar logic in xf86-input-keyboard . --HPS ___ 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: r356202 - head/sys/riscv/riscv
Author: br Date: Mon Dec 30 13:29:30 2019 New Revision: 356202 URL: https://svnweb.freebsd.org/changeset/base/356202 Log: Round the kernel stack allocation up as required. Submitted by: James Clarke Sponsored by: DARPA, AFRL Differential Revision:https://reviews.freebsd.org/D22961 Modified: head/sys/riscv/riscv/locore.S Modified: head/sys/riscv/riscv/locore.S == --- head/sys/riscv/riscv/locore.S Mon Dec 30 09:22:52 2019 (r356201) +++ head/sys/riscv/riscv/locore.S Mon Dec 30 13:29:30 2019 (r356202) @@ -186,8 +186,10 @@ va: /* Initialize stack pointer */ la s3, initstack_end mv sp, s3 - addisp, sp, -PCB_SIZE + /* Allocate space for thread0 PCB and riscv_bootparams */ + addisp, sp, -(PCB_SIZE + 40) & ~STACKALIGNBYTES + /* Clear BSS */ la s0, _C_LABEL(__bss_start) la s1, _C_LABEL(_end) @@ -203,8 +205,6 @@ va: #endif /* Fill riscv_bootparams */ - addisp, sp, -40 - la t0, pagetable_l1 sd t0, 0(sp) /* kern_l1pt */ sd s9, 8(sp) /* kern_phys */ ___ 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: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys
On Sun, Dec 29, 2019 at 09:16:04PM +, Alexander Motin wrote: > New Revision: 356185 > URL: https://svnweb.freebsd.org/changeset/base/356185 > > Log: > Remove GEOM_SCHED class and gsched tool. > > This code was not actively maintained since it was introduced 10 years ago. > It lacks support for many later GEOM features, such as direct dispatch, > unmapped I/O, stripesize/stripeoffset, resize, etc. Plus it is the only > remaining use of GEOM nstart/nend request counters, used there to implement > live insertion/removal, questionable by itself. Wow, that was unexpected, I use it on all my machines' HDD drives. Is there a planned replacement, or I'd better create a port for the GEOM_SCHED class and gsched(8) tool? ./danfe ___ 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: r356201 - head/sys/dev/hyperv/netvsc
Author: hselasky
Date: Mon Dec 30 09:22:52 2019
New Revision: 356201
URL: https://svnweb.freebsd.org/changeset/base/356201
Log:
Fix spelling.
PR: 242891
MFC after:1 week
Sponsored by: Mellanox Technologies
Modified:
head/sys/dev/hyperv/netvsc/if_hn.c
Modified: head/sys/dev/hyperv/netvsc/if_hn.c
==
--- head/sys/dev/hyperv/netvsc/if_hn.c Mon Dec 30 03:13:38 2019
(r356200)
+++ head/sys/dev/hyperv/netvsc/if_hn.c Mon Dec 30 09:22:52 2019
(r356201)
@@ -1506,7 +1506,7 @@ hn_vf_rss_fixup(struct hn_softc *sc, bool reconf)
strlcpy(ifrk.ifrk_name, vf_ifp->if_xname, sizeof(ifrk.ifrk_name));
error = vf_ifp->if_ioctl(vf_ifp, SIOCGIFRSSKEY, (caddr_t));
if (error) {
- if_printf(ifp, "%s SIOCGRSSKEY failed: %d\n",
+ if_printf(ifp, "%s SIOCGIFRSSKEY failed: %d\n",
vf_ifp->if_xname, error);
goto done;
}
___
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"
