Re: svn commit: r342699 - head/sbin/savecore
On Sun, Jun 28, 2020 at 6:55 PM Mark Johnston wrote:
> On Sun, Jun 28, 2020 at 06:40:59PM -0600, Alan Somers wrote:
> > On Wed, Jan 2, 2019 at 10:09 AM Mark Johnston wrote:
> >
> > > Author: markj
> > > Date: Wed Jan 2 17:09:35 2019
> > > New Revision: 342699
> > > URL: https://svnweb.freebsd.org/changeset/base/342699
> > >
> > > Log:
> > > Capsicumize savecore(8).
> > >
> > > - Use cap_fileargs(3) to open dump devices after entering capability
> > > mode, and use cap_syslog(3) to log messages.
> > > - Use a relative directory fd to open output files.
> > > - Use zdopen(3) to compress kernel dumps in capability mode.
> > >
> > > Reviewed by: cem, oshogbo
> > > MFC after:2 months
> > > Sponsored by: The FreeBSD Foundation
> > > Differential Revision:https://reviews.freebsd.org/D18458
> > >
> > > Modified:
> > > head/sbin/savecore/Makefile
> > > head/sbin/savecore/savecore.c
> > >
> > > Modified: head/sbin/savecore/savecore.c
> > >
> > >
> ==
> > > --- head/sbin/savecore/savecore.c Wed Jan 2 16:42:07 2019
> > > (r342698)
> > > +++ head/sbin/savecore/savecore.c Wed Jan 2 17:09:35 2019
> > > (r342699)
> > >
> > > +static char **
> > > +enum_dumpdevs(int *argcp)
> > > +{
> > > + struct fstab *fsp;
> > > + char **argv;
> > > + int argc, n;
> > > +
> > > + /*
> > > +* We cannot use getfsent(3) in capability mode, so we must
> > > +* scan /etc/fstab and build up a list of candidate devices
> > > +* before proceeding.
> > > +*/
> > > + argc = 0;
> > > + n = 8;
> > > + argv = malloc(n * sizeof(*argv));
> > >
> >
> > It looks like the memory allocated here
> >
> >
> > > + if (argv == NULL) {
> > > + logmsg(LOG_ERR, "malloc(): %m");
> > > + exit(1);
> > > + }
> > > + for (;;) {
> > > + fsp = getfsent();
> > > + if (fsp == NULL)
> > > + break;
> > > + if (strcmp(fsp->fs_vfstype, "swap") != 0 &&
> > > + strcmp(fsp->fs_vfstype, "dump") != 0)
> > > + continue;
> > > + if (argc >= n) {
> > > + n *= 2;
> > > + argv = realloc(argv, n * sizeof(*argv));
> > >
> >
> > and here
> >
> >
> > > + if (argv == NULL) {
> > > + logmsg(LOG_ERR, "realloc(): %m");
> > > + exit(1);
> > > + }
> > > + }
> > > + argv[argc] = strdup(fsp->fs_spec);
> > >
> >
> > and here is leaked. I can't find any corresponding free. However,
> neither
> > Valgrind nor Coverity complains. What am I missing? Does this memory
> > sneakily get freed by a subroutine somewhere, or does Capsicum confuse
> our
> > tools?
>
> I'm not sure why Capsicum would change anything. It would be worth
> testing devel/valgrind-devel with https://reviews.freebsd.org/D25452
> applied, to see if it's able to detect that bug.
>
Using that new valgrind-devel did not find the leaks. However, it _did_
print a helpful error message explaining why Capsicum interferes.
Commenting out caph_enter_casper allowed valgrind to find the leaks. It
also found two more than I didn't know about. Thanks for the tip.
https://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq
-Alan
___
svn-src-head@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"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 29/06/2020 16:11, Stefan Eßer wrote: Am 29.06.20 um 20:09 schrieb Ed Maste: On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: I suspect just doing the 'merge --record-only' is the simplest method assuming Git handles it ok. I suspect since Git ignores mergeinfo this is fine, but it would be good for Ed to confirm. You can always restore the tests in the future in contrib/bc when you want to add them. I think a --record-only merge is the best approach; in any case we have a number of these in the tree already and Git will have to deal with them. Thank you for this advice. There is a new version, which differs only in the man-pages. These used to mention optional features (of which only NLS support is actually optional in the version built on FreeBSD, all other are always compiled in, and I had mentioned to the author that this might irritate FreeBSD users). FWIW, since it was rewritten it would have been actually nice to have it in modern C++. I have suggested to the author to add SPDX BSD-2-Clause tags, which would change a large fraction of the currently committed files. We only use the SPDX tags for internal software. For stuff from contrib it is not necessary. Is it required to perform the --record-only merge, then? Since you are going to bring it through the vendor area you should keep the merge information yes. Or would it be OK to import the new release into the vendor branch and then svn copy that version completely (including the tests and other files that I had omitted in the initial import) to contrib? I expect the svn copy without prior svn merge --record-only to result in the same repository state after the conversion to Git, but I do not really know ... It is likely git won't care. cheers, Pedro. ___ svn-src-head@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 commit: r362790 - in head: sbin/savecore share/man/man5
Author: asomers
Date: Mon Jun 29 22:12:23 2020
New Revision: 362790
URL: https://svnweb.freebsd.org/changeset/base/362790
Log:
savecore: accept device names without the /dev/ prefix
dumpon has accepted device names without the prefix ever since r291207.
Since dumpon and savecore are always paired, they ought to accept the same
arguments. Prior to this change, specifying 'dumpdev="da3"' in
/etc/rc.conf, for example, would result in dumpon working just fine but
savecore complaining that "Dump device does not exist".
PR: 247618
Reviewed by: cem, bcr
MFC after:2 weeks
Sponsored by: Axcient
Differential Revision:https://reviews.freebsd.org/D25500
Modified:
head/sbin/savecore/savecore.c
head/share/man/man5/rc.conf.5
Modified: head/sbin/savecore/savecore.c
==
--- head/sbin/savecore/savecore.c Mon Jun 29 21:35:50 2020
(r362789)
+++ head/sbin/savecore/savecore.c Mon Jun 29 22:12:23 2020
(r362790)
@@ -973,7 +973,45 @@ closefd:
close(fddev);
}
+/* Prepend "/dev/" to any arguments that don't already have it */
static char **
+devify(int argc, char **argv)
+{
+ char **devs;
+ int i, l;
+
+ devs = malloc(argc * sizeof(*argv));
+ if (devs == NULL) {
+ logmsg(LOG_ERR, "malloc(): %m");
+ exit(1);
+ }
+ for (i = 0; i < argc; i++) {
+ if (strncmp(argv[i], _PATH_DEV, sizeof(_PATH_DEV) - 1) == 0)
+ devs[i] = strdup(argv[i]);
+ else {
+ char *fullpath;
+
+ fullpath = malloc(PATH_MAX);
+ if (fullpath == NULL) {
+ logmsg(LOG_ERR, "malloc(): %m");
+ exit(1);
+ }
+ l = snprintf(fullpath, PATH_MAX, "%s%s", _PATH_DEV,
+ argv[i]);
+ if (l < 0) {
+ logmsg(LOG_ERR, "snprintf(): %m");
+ exit(1);
+ } else if (l >= PATH_MAX) {
+ logmsg(LOG_ERR, "device name too long");
+ exit(1);
+ }
+ devs[i] = fullpath;
+ }
+ }
+ return (devs);
+}
+
+static char **
enum_dumpdevs(int *argcp)
{
struct fstab *fsp;
@@ -1069,6 +1107,7 @@ main(int argc, char **argv)
{
cap_rights_t rights;
const char *savedir;
+ char **devs;
int i, ch, error, savedirfd;
checkfor = compress = clear = force = keep = verbose = 0;
@@ -1132,7 +1171,9 @@ main(int argc, char **argv)
argv++;
}
if (argc == 0)
- argv = enum_dumpdevs();
+ devs = enum_dumpdevs();
+ else
+ devs = devify(argc, argv);
savedirfd = open(savedir, O_RDONLY | O_DIRECTORY);
if (savedirfd < 0) {
@@ -1148,10 +1189,10 @@ main(int argc, char **argv)
}
/* Enter capability mode. */
- init_caps(argc, argv);
+ init_caps(argc, devs);
for (i = 0; i < argc; i++)
- DoFile(savedir, savedirfd, argv[i]);
+ DoFile(savedir, savedirfd, devs[i]);
/* Emit minimal output. */
if (nfound == 0) {
Modified: head/share/man/man5/rc.conf.5
==
--- head/share/man/man5/rc.conf.5 Mon Jun 29 21:35:50 2020
(r362789)
+++ head/share/man/man5/rc.conf.5 Mon Jun 29 22:12:23 2020
(r362790)
@@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd June 23, 2020
+.Dd June 28, 2020
.Dt RC.CONF 5
.Os
.Sh NAME
@@ -3469,7 +3469,9 @@ the first suitable swap device listed in
.Pa /etc/fstab
will be used as dump device.
Otherwise, the value of this variable is passed as the argument to
-.Xr dumpon 8 .
+.Xr dumpon 8
+and
+.Xr savecore 8 .
To disable crash dumps, set this variable to
.Dq Li NO .
.It Va dumpon_flags
___
svn-src-head@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 commit: r362789 - head/sys/kern
Author: gallatin
Date: Mon Jun 29 21:35:50 2020
New Revision: 362789
URL: https://svnweb.freebsd.org/changeset/base/362789
Log:
Fix a panic when unloading firmware
LIST_FOREACH_SAFE() is not safe in the presence
of other threads removing list entries when a
mutex is released.
This is not in the critical path, so just restart
the scan each time we drop the lock, rather than
using a marker.
Reviewed by: jhb, markj
Sponsored by: Netflix
Modified:
head/sys/kern/subr_firmware.c
Modified: head/sys/kern/subr_firmware.c
==
--- head/sys/kern/subr_firmware.c Mon Jun 29 19:30:35 2020
(r362788)
+++ head/sys/kern/subr_firmware.c Mon Jun 29 21:35:50 2020
(r362789)
@@ -394,14 +394,12 @@ EVENTHANDLER_DEFINE(mountroot, firmware_mountroot, NUL
static void
unloadentry(void *unused1, int unused2)
{
- struct priv_fw *fp, *tmp;
+ struct priv_fw *fp;
int err;
- bool changed;
mtx_lock(_mtx);
- changed = false;
restart:
- LIST_FOREACH_SAFE(fp, _table, link, tmp) {
+ LIST_FOREACH(fp, _table, link) {
if (fp->file == NULL || fp->refcnt != 0 ||
(fp->flags & FW_UNLOAD) == 0)
continue;
@@ -412,7 +410,6 @@ restart:
* 2. clear FW_UNLOAD so we don't try this entry again.
* 3. release the lock while trying to unload the module.
*/
- changed = true;
fp->flags &= ~FW_UNLOAD;/* do not try again */
/*
@@ -422,9 +419,11 @@ restart:
mtx_unlock(_mtx);
err = linker_release_module(NULL, NULL, fp->file);
mtx_lock(_mtx);
- }
- if (changed) {
- changed = false;
+
+ /*
+* When we dropped the lock, another thread could have
+* removed an element, so we must restart the scan.
+*/
goto restart;
}
mtx_unlock(_mtx);
___
svn-src-head@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"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 6/29/20 2:11 PM, Stefan Eßer wrote: > Am 29.06.20 um 20:09 schrieb Ed Maste: >> On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: >>> >>> I suspect just doing the 'merge --record-only' is the simplest method >>> assuming Git handles it ok. I suspect since Git ignores mergeinfo this >>> is fine, but it would be good for Ed to confirm. You can always restore >>> the tests in the future in contrib/bc when you want to add them. >> >> I think a --record-only merge is the best approach; in any case we >> have a number of these in the tree already and Git will have to deal >> with them. > > Thank you for this advice. > > There is a new version, which differs only in the man-pages. These > used to mention optional features (of which only NLS support is > actually optional in the version built on FreeBSD, all other are > always compiled in, and I had mentioned to the author that this > might irritate FreeBSD users). > > I have suggested to the author to add SPDX BSD-2-Clause tags, which > would change a large fraction of the currently committed files. > > > Is it required to perform the --record-only merge, then? > > Or would it be OK to import the new release into the vendor branch > and then svn copy that version completely (including the tests and > other files that I had omitted in the initial import) to contrib? > > I expect the svn copy without prior svn merge --record-only to > result in the same repository state after the conversion to Git, > but I do not really know ... You can do a --record-only merge now, and then use 'svn merge' to merge in the new version via the normal workflow. -- John Baldwin ___ svn-src-head@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"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
Am 29.06.20 um 20:09 schrieb Ed Maste: > On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: >> >> I suspect just doing the 'merge --record-only' is the simplest method >> assuming Git handles it ok. I suspect since Git ignores mergeinfo this >> is fine, but it would be good for Ed to confirm. You can always restore >> the tests in the future in contrib/bc when you want to add them. > > I think a --record-only merge is the best approach; in any case we > have a number of these in the tree already and Git will have to deal > with them. Thank you for this advice. There is a new version, which differs only in the man-pages. These used to mention optional features (of which only NLS support is actually optional in the version built on FreeBSD, all other are always compiled in, and I had mentioned to the author that this might irritate FreeBSD users). I have suggested to the author to add SPDX BSD-2-Clause tags, which would change a large fraction of the currently committed files. Is it required to perform the --record-only merge, then? Or would it be OK to import the new release into the vendor branch and then svn copy that version completely (including the tests and other files that I had omitted in the initial import) to contrib? I expect the svn copy without prior svn merge --record-only to result in the same repository state after the conversion to Git, but I do not really know ... Regards, STefan ___ svn-src-head@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"
Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux
On Mon, 2020-06-29 at 14:26 -0600, Warner Losh wrote: > On Mon, Jun 29, 2020, 2:15 PM Ravi Pokala > wrote: > > > -Original Message- > > From: on behalf of Hans Petter > > Selasky > > > > Date: 2020-06-29, Monday at 06:08 > > To: , , < > > svn-src-head@freebsd.org> > > Subject: svn commit: r362781 - > > head/sys/compat/linuxkpi/common/include/linux > > > > Author: hselasky > > Date: Mon Jun 29 13:08:40 2020 > > New Revision: 362781 > > URL: https://svnweb.freebsd.org/changeset/base/362781 > > > > Log: > > Implement is_signed(), type_max() and type_min() function > > macros in > > the > > LinuxKPI. > > > > MFC after:1 week > > Sponsored by: Mellanox Technologies > > > > Modified: > > head/sys/compat/linuxkpi/common/include/linux/kernel.h > > > > Modified: > > head/sys/compat/linuxkpi/common/include/linux/kernel.h > > > > === > > === > > --- head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon > > Jun 29 > > 12:59:09 2020(r362780) > > +++ head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon > > Jun 29 > > 13:08:40 2020(r362781) > > @@ -564,4 +564,20 @@ linux_ratelimited(linux_ratelimit_t *rl) > > #define__is_constexpr(x) \ > > __builtin_constant_p(x) > > > > Hi Hans, > > > > +#defineis_signed(x) (((x)-1 / (x)2) == (x)0) > > > > It took me several reads to understand this, until I figured out > > that 'x' > > is not a variable, it's the name of a *type*. > > > > If 'x' is a variable, then '(x)-1' is subtraction, but '(x)2' and > > '(x)0' > > are nonsensical. > > > > If 'x' is a *type*, then '(x)-1' is typecasting '-1', and similarly > > for > > '(x)2' and '(x)0'. > > > > So, perhaps a comment, or a better name for 'x'? > > > > I had similar thoughts. Maybe 't' instead? > Or maybe since there's no one-character restriction on macro variable names, something actually descriptive like 'datatype'. -- Ian > Warner > > Thanks, > > > > Ravi (rpokala@) > > > > +#definetype_max(x) ( > > \ > > + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) > > : \ > > + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) > > : \ > > + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) > > : \ > > +(is_signed(x) ? INT8_MAX : UINT8_MAX) \ > > +) > > + > > +#definetype_min(x) > > ( \ > > + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) : \ > > + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) : \ > > + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) : \ > > +(is_signed(x) ? INT8_MIN : 0) \ > > +) > > + > > #endif /* _LINUX_KERNEL_H_ */ > > > > > > ___ svn-src-head@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"
Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux
From: on behalf of Warner Losh Date: 2020-06-29, Monday at 13:26 To: Ravi Pokala Cc: Hans Petter Selasky , src-committers , , Subject: Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux On Mon, Jun 29, 2020, 2:15 PM Ravi Pokala wrote: -Original Message- From: on behalf of Hans Petter Selasky Date: 2020-06-29, Monday at 06:08 To: , , Subject: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux Author: hselasky Date: Mon Jun 29 13:08:40 2020 New Revision: 362781 URL: https://svnweb.freebsd.org/changeset/base/362781 Log: Implement is_signed(), type_max() and type_min() function macros in the LinuxKPI. MFC after:1 week Sponsored by: Mellanox Technologies Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h == --- head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon Jun 29 12:59:09 2020(r362780) +++ head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon Jun 29 13:08:40 2020(r362781) @@ -564,4 +564,20 @@ linux_ratelimited(linux_ratelimit_t *rl) #define__is_constexpr(x) \ __builtin_constant_p(x) Hi Hans, +#defineis_signed(x) (((x)-1 / (x)2) == (x)0) It took me several reads to understand this, until I figured out that 'x' is not a variable, it's the name of a *type*. If 'x' is a variable, then '(x)-1' is subtraction, but '(x)2' and '(x)0' are nonsensical. If 'x' is a *type*, then '(x)-1' is typecasting '-1', and similarly for '(x)2' and '(x)0'. So, perhaps a comment, or a better name for 'x'? I had similar thoughts. Maybe 't' instead? Letters are cheap now, Warner; we can afford to spell out "type". :-) -Ravi (rpokala@) Warner Thanks, Ravi (rpokala@) +#definetype_max(x) ( \ + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) : \ + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) : \ + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) : \ +(is_signed(x) ? INT8_MAX : UINT8_MAX) \ +) + +#definetype_min(x) ( \ + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) : \ + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) : \ + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) : \ +(is_signed(x) ? INT8_MIN : 0) \ +) + #endif /* _LINUX_KERNEL_H_ */ ___ svn-src-head@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"
Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux
On Mon, Jun 29, 2020, 2:15 PM Ravi Pokala wrote: > -Original Message- > From: on behalf of Hans Petter Selasky > > Date: 2020-06-29, Monday at 06:08 > To: , , < > svn-src-head@freebsd.org> > Subject: svn commit: r362781 - > head/sys/compat/linuxkpi/common/include/linux > > Author: hselasky > Date: Mon Jun 29 13:08:40 2020 > New Revision: 362781 > URL: https://svnweb.freebsd.org/changeset/base/362781 > > Log: > Implement is_signed(), type_max() and type_min() function macros in > the > LinuxKPI. > > MFC after:1 week > Sponsored by: Mellanox Technologies > > Modified: > head/sys/compat/linuxkpi/common/include/linux/kernel.h > > Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h > > == > --- head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon Jun 29 > 12:59:09 2020(r362780) > +++ head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon Jun 29 > 13:08:40 2020(r362781) > @@ -564,4 +564,20 @@ linux_ratelimited(linux_ratelimit_t *rl) > #define__is_constexpr(x) \ > __builtin_constant_p(x) > > Hi Hans, > > +#defineis_signed(x) (((x)-1 / (x)2) == (x)0) > > It took me several reads to understand this, until I figured out that 'x' > is not a variable, it's the name of a *type*. > > If 'x' is a variable, then '(x)-1' is subtraction, but '(x)2' and '(x)0' > are nonsensical. > > If 'x' is a *type*, then '(x)-1' is typecasting '-1', and similarly for > '(x)2' and '(x)0'. > > So, perhaps a comment, or a better name for 'x'? > I had similar thoughts. Maybe 't' instead? Warner Thanks, > > Ravi (rpokala@) > > +#definetype_max(x) ( > \ > + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) : \ > + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) : \ > + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) : \ > +(is_signed(x) ? INT8_MAX : UINT8_MAX) \ > +) > + > +#definetype_min(x) ( \ > + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) : \ > + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) : \ > + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) : \ > +(is_signed(x) ? INT8_MIN : 0) \ > +) > + > #endif /* _LINUX_KERNEL_H_ */ > > > ___ svn-src-head@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"
Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux
-Original Message- From: on behalf of Hans Petter Selasky Date: 2020-06-29, Monday at 06:08 To: , , Subject: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux Author: hselasky Date: Mon Jun 29 13:08:40 2020 New Revision: 362781 URL: https://svnweb.freebsd.org/changeset/base/362781 Log: Implement is_signed(), type_max() and type_min() function macros in the LinuxKPI. MFC after:1 week Sponsored by: Mellanox Technologies Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h == --- head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon Jun 29 12:59:09 2020(r362780) +++ head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon Jun 29 13:08:40 2020(r362781) @@ -564,4 +564,20 @@ linux_ratelimited(linux_ratelimit_t *rl) #define__is_constexpr(x) \ __builtin_constant_p(x) Hi Hans, +#defineis_signed(x) (((x)-1 / (x)2) == (x)0) It took me several reads to understand this, until I figured out that 'x' is not a variable, it's the name of a *type*. If 'x' is a variable, then '(x)-1' is subtraction, but '(x)2' and '(x)0' are nonsensical. If 'x' is a *type*, then '(x)-1' is typecasting '-1', and similarly for '(x)2' and '(x)0'. So, perhaps a comment, or a better name for 'x'? Thanks, Ravi (rpokala@) +#definetype_max(x) ( \ + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) : \ + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) : \ + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) : \ +(is_signed(x) ? INT8_MAX : UINT8_MAX) \ +) + +#definetype_min(x) ( \ + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) : \ + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) : \ + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) : \ +(is_signed(x) ? INT8_MIN : 0) \ +) + #endif /* _LINUX_KERNEL_H_ */ ___ svn-src-head@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 commit: r362788 - head/lib/libc/riscv
Author: mhorne
Date: Mon Jun 29 19:30:35 2020
New Revision: 362788
URL: https://svnweb.freebsd.org/changeset/base/362788
Log:
Fix printf(3) output of long doubles on RISC-V
When the RISC-V port was initially committed to FreeBSD, GCC would
generate 64-bit long doubles, and the definitions in _fpmath.h reflected
that. This was changed to 128-bit in GCC later that year [1], but the
definitions were never updated, despite the documented workaround. This
causes printf(3) and friends to interpret only the low 64-bits of a long
double in ldtoa, thereby printing incorrect values.
Update the definitions now that both clang and GCC generate 128-bit long
doubles.
[1]
https://github.com/riscv/riscv-gcc/commit/54b21fc5ae83cefec44bc2caed4a8c664c274ba0
PR: 242067
Reported by: Dennis Clarke
MFC after:1 week
Differential Revision:https://reviews.freebsd.org/D25420
Modified:
head/lib/libc/riscv/_fpmath.h
Modified: head/lib/libc/riscv/_fpmath.h
==
--- head/lib/libc/riscv/_fpmath.h Mon Jun 29 18:06:00 2020
(r362787)
+++ head/lib/libc/riscv/_fpmath.h Mon Jun 29 19:30:35 2020
(r362788)
@@ -46,19 +46,6 @@ union IEEEl2bits {
#defineLDBL_IMPLICIT_NBIT
#definemask_nbit_l(u) ((void)0)
-#defineLDBL_MANH_SIZE 20
-#defineLDBL_MANL_SIZE 32
-
-#defineLDBL_TO_ARRAY32(u, a) do { \
- (a)[0] = (uint32_t)(u).bits.manl; \
- (a)[1] = (uint32_t)(u).bits.manh; \
-} while(0)
-
-/*
- * TODO: Due to compiler problem we are temporary using
- * LDBL_PREC == 53. Use code below for LDBL_PREC == 113
- */
-#if 0
#defineLDBL_MANH_SIZE 48
#defineLDBL_MANL_SIZE 64
@@ -68,4 +55,3 @@ union IEEEl2bits {
(a)[2] = (uint32_t)(u).bits.manh; \
(a)[3] = (uint32_t)((u).bits.manh >> 32); \
} while(0)
-#endif
___
svn-src-head@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"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: > > I suspect just doing the 'merge --record-only' is the simplest method > assuming Git handles it ok. I suspect since Git ignores mergeinfo this > is fine, but it would be good for Ed to confirm. You can always restore > the tests in the future in contrib/bc when you want to add them. I think a --record-only merge is the best approach; in any case we have a number of these in the tree already and Git will have to deal with them. ___ svn-src-head@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 commit: r362787 - head/usr.sbin/mailwrapper
Author: kevans
Date: Mon Jun 29 18:06:00 2020
New Revision: 362787
URL: https://svnweb.freebsd.org/changeset/base/362787
Log:
mailwrapper: switch mailer.conf to CONFS
This matches what was already being done in dma(8), and should again make
this merge with etcupdate/mergemaster.
Reported by: jhb
Modified:
head/usr.sbin/mailwrapper/Makefile
Modified: head/usr.sbin/mailwrapper/Makefile
==
--- head/usr.sbin/mailwrapper/Makefile Mon Jun 29 17:47:00 2020
(r362786)
+++ head/usr.sbin/mailwrapper/Makefile Mon Jun 29 18:06:00 2020
(r362787)
@@ -31,9 +31,9 @@ SYMLINKS+=..${BINDIR}/mailwrapper /bin/rmail
# dma(8) are installed and simply provide a default that can be changed for an
# alternative in ports.
.if ${MK_SENDMAIL} != "no" || ${MK_DMAGENT} == "no"
-FILES= ${SRCTOP}/etc/mail/mailer.conf
-FILESDIR= /etc/mail
-FILESMODE= 644
+CONFS= ${SRCTOP}/etc/mail/mailer.conf
+CONFSDIR= /etc/mail
+CONFSMODE= 644
.endif
.endif
___
svn-src-head@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"
Re: svn commit: r362769 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux
On Mon, Jun 29, 2020 at 12:42:49PM -0500, Kyle Evans wrote: > On Mon, Jun 29, 2020 at 10:27 AM Shawn Webb > wrote: > > > > Hey Kyle, > > > > On Mon, Jun 29, 2020 at 03:09:14AM +, Kyle Evans wrote: > > > Author: kevans > > > Date: Mon Jun 29 03:09:14 2020 > > > New Revision: 362769 > > > URL: https://svnweb.freebsd.org/changeset/base/362769 > > > > > > Log: > > > linuxolator: implement memfd_create syscall > > > > > > This effectively mirrors our libc implementation, but with minor > > > fudging -- > > > name needs to be copied in from userspace, so we just copy it straight > > > into > > > stack-allocated memfd_name into the correct position rather than > > > allocating > > > memory that needs to be cleaned up. > > > > > > The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have > > > also been implemented now that we support them. > > > > > > Note that this implementation is still not quite at feature parity > > > w.r.t. > > > the actual Linux version; some caveats, from my foggy memory: > > > > > > - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress) > > > - LTP wants the memfd name exposed to fdescfs > > > - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after > > > dup. > > > (?) > > > > > > Interested parties can install and run LTP from ports (devel/linux-ltp) > > > to > > > confirm any fixes. > > > > > > PR: 240874 > > > Reviewed by:kib, trasz > > > Differential Revision: https://reviews.freebsd.org/D21845 > > > > RELNOTES? > > > > > > > > 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.c > > > head/sys/compat/linux/linux.h > > > head/sys/compat/linux/linux_file.c > > > head/sys/compat/linux/linux_file.h > > > head/sys/i386/linux/linux_dummy.c > > > > Should __FreeBSD_version be bumped? > > > > I'm roping in trasz@, because I'm unsure on either of these points -- > I haven't paid attention and don't know if we typically include linux > syscalls that we implement in relnotes, and given that this commit > only really affects pre-compiled Linux binaries I'm not sure if > there's any utility in bumping __FreeBSD_version; presumably ports > folks can't do anything differently here, and binaries will work just > the same. Hey Kyle, I assumed as much, but I wasn't entirely sure. I thought I'd just ask anyways. Thanks for the clarification. :) -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
svn commit: r362786 - head/sys/compat/linux
Author: kevans Date: Mon Jun 29 17:47:00 2020 New Revision: 362786 URL: https://svnweb.freebsd.org/changeset/base/362786 Log: linux: reposition the comment for bsd_to_linux_bits/linux_to_bsd_bits rpokala notes that splitting the definitions like this is kind of silly, since the comment applies to both. Move the comment up (or the definition down, depending on your perspective on life) accordingly. Reported by: rpokala Modified: head/sys/compat/linux/linux.h Modified: head/sys/compat/linux/linux.h == --- head/sys/compat/linux/linux.h Mon Jun 29 17:19:08 2020 (r362785) +++ head/sys/compat/linux/linux.h Mon Jun 29 17:47:00 2020 (r362786) @@ -165,9 +165,6 @@ int bsd_to_linux_bits_(int value, struct bsd_to_linux_ int linux_to_bsd_bits_(int value, struct bsd_to_linux_bitmap *bitmap, size_t mapcnt, int no_value); -#definebsd_to_linux_bits(_val, _bmap, _noval) \ -bsd_to_linux_bits_((_val), (_bmap), nitems((_bmap)), (_noval)) - /* * These functions are used for simplification of BSD <-> Linux bit conversions. * Given `value`, a bit field, these functions will walk the given bitmap table @@ -176,6 +173,8 @@ int linux_to_bsd_bits_(int value, struct bsd_to_linux_ * represented with the bit values appropriate for the target platform. * Otherwise, the value supplied as `no_value` is returned. */ +#definebsd_to_linux_bits(_val, _bmap, _noval) \ +bsd_to_linux_bits_((_val), (_bmap), nitems((_bmap)), (_noval)) #definelinux_to_bsd_bits(_val, _bmap, _noval) \ linux_to_bsd_bits_((_val), (_bmap), nitems((_bmap)), (_noval)) ___ svn-src-head@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"
Re: svn commit: r362769 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux
On Mon, Jun 29, 2020 at 10:27 AM Shawn Webb wrote: > > Hey Kyle, > > On Mon, Jun 29, 2020 at 03:09:14AM +, Kyle Evans wrote: > > Author: kevans > > Date: Mon Jun 29 03:09:14 2020 > > New Revision: 362769 > > URL: https://svnweb.freebsd.org/changeset/base/362769 > > > > Log: > > linuxolator: implement memfd_create syscall > > > > This effectively mirrors our libc implementation, but with minor fudging > > -- > > name needs to be copied in from userspace, so we just copy it straight > > into > > stack-allocated memfd_name into the correct position rather than > > allocating > > memory that needs to be cleaned up. > > > > The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have > > also been implemented now that we support them. > > > > Note that this implementation is still not quite at feature parity w.r.t. > > the actual Linux version; some caveats, from my foggy memory: > > > > - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress) > > - LTP wants the memfd name exposed to fdescfs > > - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after dup. > > (?) > > > > Interested parties can install and run LTP from ports (devel/linux-ltp) to > > confirm any fixes. > > > > PR: 240874 > > Reviewed by:kib, trasz > > Differential Revision: https://reviews.freebsd.org/D21845 > > RELNOTES? > > > > > 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.c > > head/sys/compat/linux/linux.h > > head/sys/compat/linux/linux_file.c > > head/sys/compat/linux/linux_file.h > > head/sys/i386/linux/linux_dummy.c > > Should __FreeBSD_version be bumped? > I'm roping in trasz@, because I'm unsure on either of these points -- I haven't paid attention and don't know if we typically include linux syscalls that we implement in relnotes, and given that this commit only really affects pre-compiled Linux binaries I'm not sure if there's any utility in bumping __FreeBSD_version; presumably ports folks can't do anything differently here, and binaries will work just the same. Thanks, Kyle Evans ___ svn-src-head@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"
Re: svn commit: r361720 - in head: etc etc/mail usr.sbin/mailwrapper
In message <20200629190958.56a010736905355abb924...@bidouilliste.com>, Emmanuel Vadot writes: > On Mon, 29 Jun 2020 09:52:15 -0700 > Cy Schubert wrote: > > > In message <475e0172-0a4a-0201-3e2f-9e231b75f...@freebsd.org>, John Baldwin > > > wri > > tes: > > > On 6/1/20 7:38 PM, Kyle Evans wrote: > > > > Author: kevans > > > > Date: Tue Jun 2 02:38:54 2020 > > > > New Revision: 361720 > > > > URL: https://svnweb.freebsd.org/changeset/base/361720 > > > > > > > > Log: > > > > pkgbase: resolve mailer.conf conflict WITHOUT_SENDMAIL > > > > > > > > When WITHOUT_SENDMAIL is set, we end up with two different mailer.con > f th > > > at > > > > conflict, and hilarity ensues. There's currently three different plac > es t > > > hat > > > > we might install mailer.conf: > > > > > > Something about this change has made etcupdate stop updating this file. > > > Perhaps it is now a "plain" FILE instead of a config file, so 'installcon > fig' > > > no longer installs it? Given that users do edit this file (e.g. if using > > > postfix from ports), it does seem like this should be treated as a config > > > file? > > > > Yes, plain file vs config file. There was a change a couple of months ago > > by someone else that changed config files to plain files which totally > > messed up /etc after etcupdate was run. It also affected mergemaster BTW. > > This was https://svnweb.freebsd.org/base?view=revision=359294 > > > If pkgbase needs config files to be plain files we might need a knob to > > make it so when pkgbase is invoking make. > > It doesn't, pkg needs to know about config files, the problem with my > commit is more an etcupdate/mergemaster problem than a pkgbase one. > iirc etcupdate do a make distribution to find new files and diffs and > switching a config file from a plain files will cause the file to be > installed by installworld so etcupdate thinks that it was deleted. I've > tried a bit to fix that in etcupdate but couldn't find a proper way to > do it. Mergemaster also does make distribution. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ svn-src-head@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 commit: r362785 - head/lib/csu/arm
Author: jhb
Date: Mon Jun 29 17:19:08 2020
New Revision: 362785
URL: https://svnweb.freebsd.org/changeset/base/362785
Log:
Stop using STATIC_CFLAGS.
This was added in r293648 to pass -mlong-calls for crt1.o and gcrt1.o.
The use of -mlong-calls was removed in r358851 for LLVM 10.0, leaving
STATIC_CFLAGS empty.
Sponsored by: DARPA
Differential Revision:https://reviews.freebsd.org/D25305
Modified:
head/lib/csu/arm/Makefile
Modified: head/lib/csu/arm/Makefile
==
--- head/lib/csu/arm/Makefile Mon Jun 29 16:54:00 2020(r362784)
+++ head/lib/csu/arm/Makefile Mon Jun 29 17:19:08 2020(r362785)
@@ -21,13 +21,13 @@ CLEANFILES= ${OBJS} crt1_c.o crt1_s.o gcrt1_c.o Scrt1_
CLEANFILES+= crtbrand.o ignore_init_note.o
crt1_c.o: crt1_c.c
- ${CC} ${CFLAGS} ${STATIC_CFLAGS} -c -o ${.TARGET} ${.CURDIR}/crt1_c.c
+ ${CC} ${CFLAGS} -c -o ${.TARGET} ${.CURDIR}/crt1_c.c
crt1.o:crt1_c.o crt1_s.o crtbrand.o ignore_init_note.o
${LD} ${_LDFLAGS} -o ${.TARGET} -r ${.ALLSRC:M*.o}
gcrt1_c.o: crt1_c.c
- ${CC} ${CFLAGS} ${STATIC_CFLAGS} -DGCRT -c -o ${.TARGET}
${.CURDIR}/crt1_c.c
+ ${CC} ${CFLAGS} -DGCRT -c -o ${.TARGET} ${.CURDIR}/crt1_c.c
gcrt1.o: gcrt1_c.o crt1_s.o crtbrand.o ignore_init_note.o
${LD} ${_LDFLAGS} -o ${.TARGET} -r ${.ALLSRC:M*.o}
___
svn-src-head@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"
Re: svn commit: r361720 - in head: etc etc/mail usr.sbin/mailwrapper
On Mon, Jun 29, 2020 at 10:46 AM John Baldwin wrote: > > On 6/1/20 7:38 PM, Kyle Evans wrote: > > Author: kevans > > Date: Tue Jun 2 02:38:54 2020 > > New Revision: 361720 > > URL: https://svnweb.freebsd.org/changeset/base/361720 > > > > Log: > > pkgbase: resolve mailer.conf conflict WITHOUT_SENDMAIL > > > > When WITHOUT_SENDMAIL is set, we end up with two different mailer.conf > > that > > conflict, and hilarity ensues. There's currently three different places > > that > > we might install mailer.conf: > > Something about this change has made etcupdate stop updating this file. > Perhaps it is now a "plain" FILE instead of a config file, so 'installconfig' > no longer installs it? Given that users do edit this file (e.g. if using > postfix from ports), it does seem like this should be treated as a config > file? Ah, whoops, this is my bad indeed. :-( I had noticed that the mailwrapper install used FILES instead of CONFS like dma(8), but I forgot to go back and correct the inconsistency. Will fix ASAP. Thanks, Kyle Evans ___ svn-src-head@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"
Re: svn commit: r361720 - in head: etc etc/mail usr.sbin/mailwrapper
On Mon, 29 Jun 2020 09:52:15 -0700 Cy Schubert wrote: > In message <475e0172-0a4a-0201-3e2f-9e231b75f...@freebsd.org>, John Baldwin > wri > tes: > > On 6/1/20 7:38 PM, Kyle Evans wrote: > > > Author: kevans > > > Date: Tue Jun 2 02:38:54 2020 > > > New Revision: 361720 > > > URL: https://svnweb.freebsd.org/changeset/base/361720 > > > > > > Log: > > > pkgbase: resolve mailer.conf conflict WITHOUT_SENDMAIL > > > > > > When WITHOUT_SENDMAIL is set, we end up with two different mailer.conf > > > th > > at > > > conflict, and hilarity ensues. There's currently three different places > > > t > > hat > > > we might install mailer.conf: > > > > Something about this change has made etcupdate stop updating this file. > > Perhaps it is now a "plain" FILE instead of a config file, so > > 'installconfig' > > no longer installs it? Given that users do edit this file (e.g. if using > > postfix from ports), it does seem like this should be treated as a config > > file? > > Yes, plain file vs config file. There was a change a couple of months ago > by someone else that changed config files to plain files which totally > messed up /etc after etcupdate was run. It also affected mergemaster BTW. This was https://svnweb.freebsd.org/base?view=revision=359294 > If pkgbase needs config files to be plain files we might need a knob to > make it so when pkgbase is invoking make. It doesn't, pkg needs to know about config files, the problem with my commit is more an etcupdate/mergemaster problem than a pkgbase one. iirc etcupdate do a make distribution to find new files and diffs and switching a config file from a plain files will cause the file to be installed by installworld so etcupdate thinks that it was deleted. I've tried a bit to fix that in etcupdate but couldn't find a proper way to do it. And no we won't want a knob to have a "pkgbase build", this will cause more problems. > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > The need of the many outweighs the greed of the few. > > -- Emmanuel Vadot ___ svn-src-head@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"
Re: svn commit: r361720 - in head: etc etc/mail usr.sbin/mailwrapper
On 6/29/20 9:52 AM, Cy Schubert wrote: > In message <475e0172-0a4a-0201-3e2f-9e231b75f...@freebsd.org>, John Baldwin > wri > tes: >> On 6/1/20 7:38 PM, Kyle Evans wrote: >>> Author: kevans >>> Date: Tue Jun 2 02:38:54 2020 >>> New Revision: 361720 >>> URL: https://svnweb.freebsd.org/changeset/base/361720 >>> >>> Log: >>> pkgbase: resolve mailer.conf conflict WITHOUT_SENDMAIL >>> >>> When WITHOUT_SENDMAIL is set, we end up with two different mailer.conf th >> at >>> conflict, and hilarity ensues. There's currently three different places t >> hat >>> we might install mailer.conf: >> >> Something about this change has made etcupdate stop updating this file. >> Perhaps it is now a "plain" FILE instead of a config file, so 'installconfig' >> no longer installs it? Given that users do edit this file (e.g. if using >> postfix from ports), it does seem like this should be treated as a config >> file? > > Yes, plain file vs config file. There was a change a couple of months ago > by someone else that changed config files to plain files which totally > messed up /etc after etcupdate was run. It also affected mergemaster BTW. > > If pkgbase needs config files to be plain files we might need a knob to > make it so when pkgbase is invoking make. pkgbase understands config files I believe, I think it was just a bug in this commit to not set a suitable Makefile variable so mailer.conf is a "config" file. -- John Baldwin ___ svn-src-head@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 commit: r362784 - head/sys/vm
Author: cem
Date: Mon Jun 29 16:54:00 2020
New Revision: 362784
URL: https://svnweb.freebsd.org/changeset/base/362784
Log:
vm: Add missing WITNESS warnings for M_WAITOK allocation
vm_map_clip_{end,start} and lookup_clip_start allocate memory M_WAITOK
for !system_map vm_maps. Add WITNESS warning annotation for !system_map
callers who may be holding non-sleepable locks.
Reviewed by: markj
Sponsored by: Dell EMC Isilon
Differential Revision:https://reviews.freebsd.org/D25283
Modified:
head/sys/vm/vm_map.c
Modified: head/sys/vm/vm_map.c
==
--- head/sys/vm/vm_map.cMon Jun 29 15:15:14 2020(r362783)
+++ head/sys/vm/vm_map.cMon Jun 29 16:54:00 2020(r362784)
@@ -2379,6 +2379,11 @@ vm_map_clip_start(vm_map_t map, vm_map_entry_t entry,
{
vm_map_entry_t new_entry;
+ if (!map->system_map)
+ WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
+ "%s: map %p entry %p start 0x%jx", __func__, map, entry,
+ (uintmax_t)start);
+
if (start <= entry->start)
return;
@@ -2409,6 +2414,11 @@ vm_map_lookup_clip_start(vm_map_t map, vm_offset_t sta
{
vm_map_entry_t entry;
+ if (!map->system_map)
+ WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
+ "%s: map %p start 0x%jx prev %p", __func__, map,
+ (uintmax_t)start, prev_entry);
+
if (vm_map_lookup_entry(map, start, prev_entry)) {
entry = *prev_entry;
vm_map_clip_start(map, entry, start);
@@ -2430,6 +2440,11 @@ vm_map_clip_end(vm_map_t map, vm_map_entry_t entry, vm
{
vm_map_entry_t new_entry;
+ if (!map->system_map)
+ WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
+ "%s: map %p entry %p end 0x%jx", __func__, map, entry,
+ (uintmax_t)end);
+
if (end >= entry->end)
return;
@@ -3725,6 +3740,7 @@ vm_map_delete(vm_map_t map, vm_offset_t start, vm_offs
vm_map_entry_t entry, next_entry;
VM_MAP_ASSERT_LOCKED(map);
+
if (start == end)
return (KERN_SUCCESS);
___
svn-src-head@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"
Re: svn commit: r361720 - in head: etc etc/mail usr.sbin/mailwrapper
In message <475e0172-0a4a-0201-3e2f-9e231b75f...@freebsd.org>, John Baldwin wri tes: > On 6/1/20 7:38 PM, Kyle Evans wrote: > > Author: kevans > > Date: Tue Jun 2 02:38:54 2020 > > New Revision: 361720 > > URL: https://svnweb.freebsd.org/changeset/base/361720 > > > > Log: > > pkgbase: resolve mailer.conf conflict WITHOUT_SENDMAIL > > > > When WITHOUT_SENDMAIL is set, we end up with two different mailer.conf th > at > > conflict, and hilarity ensues. There's currently three different places t > hat > > we might install mailer.conf: > > Something about this change has made etcupdate stop updating this file. > Perhaps it is now a "plain" FILE instead of a config file, so 'installconfig' > no longer installs it? Given that users do edit this file (e.g. if using > postfix from ports), it does seem like this should be treated as a config > file? Yes, plain file vs config file. There was a change a couple of months ago by someone else that changed config files to plain files which totally messed up /etc after etcupdate was run. It also affected mergemaster BTW. If pkgbase needs config files to be plain files we might need a knob to make it so when pkgbase is invoking make. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ svn-src-head@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"
Re: svn commit: r361720 - in head: etc etc/mail usr.sbin/mailwrapper
On 6/1/20 7:38 PM, Kyle Evans wrote: > Author: kevans > Date: Tue Jun 2 02:38:54 2020 > New Revision: 361720 > URL: https://svnweb.freebsd.org/changeset/base/361720 > > Log: > pkgbase: resolve mailer.conf conflict WITHOUT_SENDMAIL > > When WITHOUT_SENDMAIL is set, we end up with two different mailer.conf that > conflict, and hilarity ensues. There's currently three different places that > we might install mailer.conf: Something about this change has made etcupdate stop updating this file. Perhaps it is now a "plain" FILE instead of a config file, so 'installconfig' no longer installs it? Given that users do edit this file (e.g. if using postfix from ports), it does seem like this should be treated as a config file? -- John Baldwin ___ svn-src-head@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"
Re: svn commit: r362769 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux
Hey Kyle, On Mon, Jun 29, 2020 at 03:09:14AM +, Kyle Evans wrote: > Author: kevans > Date: Mon Jun 29 03:09:14 2020 > New Revision: 362769 > URL: https://svnweb.freebsd.org/changeset/base/362769 > > Log: > linuxolator: implement memfd_create syscall > > This effectively mirrors our libc implementation, but with minor fudging -- > name needs to be copied in from userspace, so we just copy it straight into > stack-allocated memfd_name into the correct position rather than allocating > memory that needs to be cleaned up. > > The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have > also been implemented now that we support them. > > Note that this implementation is still not quite at feature parity w.r.t. > the actual Linux version; some caveats, from my foggy memory: > > - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress) > - LTP wants the memfd name exposed to fdescfs > - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after dup. > (?) > > Interested parties can install and run LTP from ports (devel/linux-ltp) to > confirm any fixes. > > PR: 240874 > Reviewed by:kib, trasz > Differential Revision: https://reviews.freebsd.org/D21845 RELNOTES? > > 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.c > head/sys/compat/linux/linux.h > head/sys/compat/linux/linux_file.c > head/sys/compat/linux/linux_file.h > head/sys/i386/linux/linux_dummy.c Should __FreeBSD_version be bumped? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 6/28/20 1:28 AM, Stefan Eßer wrote: > I could delete what's currently in contrib/bc and use svn copy to make > the whole contents of vendor/bc/dist available in contrib/bc. The tests > require 1112 KB of space, while the rest of the sources takes up less > than 900 KB. > > I could revert the full import to contrib/bc, but that would also revert > changes to e.g. usr.bin/Makefile and I'd rather remove just what's now > in contrib/bc and then use svn copy to make vendor/bc/dist available > there. The sources from the dist directory can be used unmodified, the > reason for cherry-picking was just that I did not want to import more > than is used at this time ... I do not think you should do a full revert but just fixup contrib/bc. I think it would be good to get advice from emaste@ about what is most Git-conversion-friendly. You might be able to just do a 'svn merge --record-only' to bootstrap the merge info and commit that. Barring that, you might be able to svn rm contrib/bc and then 'svn cp' it from the vendor area. You'd probably have to do that as two separate commits to make use of a URL for the 'svn cp' though which would break the tree for one commit. I suspect just doing the 'merge --record-only' is the simplest method assuming Git handles it ok. I suspect since Git ignores mergeinfo this is fine, but it would be good for Ed to confirm. You can always restore the tests in the future in contrib/bc when you want to add them. -- John Baldwin ___ svn-src-head@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 commit: r362783 - head/usr.bin/hexdump
Author: fernape (ports committer) Date: Mon Jun 29 15:15:14 2020 New Revision: 362783 URL: https://svnweb.freebsd.org/changeset/base/362783 Log: hexdump(1): Add EXAMPLES section * Add examples showing the use of -f, -C, -s, -n * Rework the two already present examples that were *format* examples * Remove .Tn suggested by mandoc(1) * Remove reference to gdb(1) since it is not present in current Approved by: manpages (gbe) Differential Revision:https://reviews.freebsd.org/D25406 Modified: head/usr.bin/hexdump/hexdump.1 Modified: head/usr.bin/hexdump/hexdump.1 == --- head/usr.bin/hexdump/hexdump.1 Mon Jun 29 13:30:48 2020 (r362782) +++ head/usr.bin/hexdump/hexdump.1 Mon Jun 29 15:15:14 2020 (r362783) @@ -28,7 +28,7 @@ .\"@(#)hexdump.1 8.2 (Berkeley) 4/18/94 .\" $FreeBSD$ .\" -.Dd October 29, 2014 +.Dd June 29, 2020 .Dt HEXDUMP 1 .Os .Sh NAME @@ -242,8 +242,7 @@ Output characters in the default character set. Nonprinting characters are displayed as a single .Dq Cm \&. . .It Cm _u -Output US -.Tn ASCII +Output US ASCII characters, with the exception that control characters are displayed using the following, lower-case, names. Characters greater than 0xff, hexadecimal, are displayed as hexadecimal @@ -330,18 +329,59 @@ option. .Sh EXIT STATUS .Ex -std hexdump hd .Sh EXAMPLES -Display the input in perusal format: +Dump input in canonical (hex+ASCII) form: .Bd -literal -offset indent +$ echo "FreeBSD: The power to serve" | hexdump -C + 46 72 65 65 42 53 44 3a 20 54 68 65 20 70 6f 77 |FreeBSD: The pow| +0010 65 72 20 74 6f 20 73 65 72 76 65 0a |er to serve.| +001c +.Ed +.Pp +Same as above but skipping the first 4 bytes of stdin and interpreting only 3 +bytes of input: +.Bd -literal -offset indent +$ echo "FreeBSD: The power to serve" | hexdump -C -s 4 -n 3 +0004 42 53 44 |BSD| +0007 +.Ed +.Pp +Assuming a format file named +.Pa format.txt +with the following contents that specify a perusal format: +.Bd -literal -offset indent "%06.6_ao " 12/1 "%3_u " "\et\et" "%_p " "\en" .Ed .Pp -Implement the \-x option: +Dump input in canonical form using the format in +.Pa format.txt : .Bd -literal -offset indent +$ echo "FreeBSD" | hexdump -f format.txt -C +00 F r e e B S D lf F r e e B S D . + 46 72 65 65 42 53 44 0a |FreeBSD.| +0008 +.Ed +.Pp +Assuming a format file named +.Pa format.txt +with the following contents that simulate the +.Fl x +option: +.Bd -literal -offset indent "%07.7_Ax\en" "%07.7_ax " 8/2 "%04x " "\en" .Ed +.Pp +Dump input in canonical form using the format in +.Pa format.txt : +.Bd -literal -offset indent +$ echo "FreeBSD: The power to serve" | hexdump -f format.txt -C +000 7246 6565 5342 3a44 5420 6568 7020 776f + 46 72 65 65 42 53 44 3a 20 54 68 65 20 70 6f 77 |FreeBSD: The pow| +010 7265 7420 206f 6573 7672 0a65 +0010 65 72 20 74 6f 20 73 65 72 76 65 0a |er to serve.| +001c +.Ed .Sh SEE ALSO -.Xr gdb 1 , .Xr od 1 ___ svn-src-head@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 commit: r362782 - head/contrib/file/magic/Magdir
Author: emaste
Date: Mon Jun 29 13:30:48 2020
New Revision: 362782
URL: https://svnweb.freebsd.org/changeset/base/362782
Log:
Revert r362261, "Re-apply r333944 to unbreak ports"
A file update in 2018 broke many ports as it misidentified shared
libraries as PIE binaries. r333944 reverted part of the change,
restoring ports builds but misidentifying objects in the opposite
direction.
Earlier this month file 5.39 was imported, and then the change
originally from r333944 was recommitted as r362261. However, the
issue was fixed upstream, so r362261 serves no purpose.
PR: 246960, 247461 [exp-run]
Sponsored by: The FreeBSD Foundation
Modified:
head/contrib/file/magic/Magdir/elf
Modified: head/contrib/file/magic/Magdir/elf
==
--- head/contrib/file/magic/Magdir/elf Mon Jun 29 13:08:40 2020
(r362781)
+++ head/contrib/file/magic/Magdir/elf Mon Jun 29 13:30:48 2020
(r362782)
@@ -50,8 +50,9 @@
!:mime application/x-object
>16leshort 2 executable,
!:mime application/x-executable
->16leshort 3 shared object,
-!:mime application/x-sharedlib
+>16leshort 3 ${x?pie executable:shared object},
+
+!:mime application/x-${x?pie-executable:sharedlib}
>16leshort 4 core file,
!:mime application/x-coredump
# OS-specific
___
svn-src-head@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 commit: r362781 - head/sys/compat/linuxkpi/common/include/linux
Author: hselasky Date: Mon Jun 29 13:08:40 2020 New Revision: 362781 URL: https://svnweb.freebsd.org/changeset/base/362781 Log: Implement is_signed(), type_max() and type_min() function macros in the LinuxKPI. MFC after:1 week Sponsored by: Mellanox Technologies Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h == --- head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon Jun 29 12:59:09 2020(r362780) +++ head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon Jun 29 13:08:40 2020(r362781) @@ -564,4 +564,20 @@ linux_ratelimited(linux_ratelimit_t *rl) #define__is_constexpr(x) \ __builtin_constant_p(x) +#defineis_signed(x) (((x)-1 / (x)2) == (x)0) + +#definetype_max(x) ( \ + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) : \ + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) : \ + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) : \ +(is_signed(x) ? INT8_MAX : UINT8_MAX) \ +) + +#definetype_min(x) ( \ + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) : \ + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) : \ + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) : \ +(is_signed(x) ? INT8_MIN : 0) \ +) + #endif /* _LINUX_KERNEL_H_ */ ___ svn-src-head@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 commit: r362780 - head/sys/arm64/coresight
Author: br
Date: Mon Jun 29 12:59:09 2020
New Revision: 362780
URL: https://svnweb.freebsd.org/changeset/base/362780
Log:
Coresight: provide device_attach method for FDT bus.
Sponsored by: DARPA, AFRL
Modified:
head/sys/arm64/coresight/coresight_funnel_fdt.c
head/sys/arm64/coresight/coresight_replicator_fdt.c
Modified: head/sys/arm64/coresight/coresight_funnel_fdt.c
==
--- head/sys/arm64/coresight/coresight_funnel_fdt.c Mon Jun 29 10:30:43
2020(r362779)
+++ head/sys/arm64/coresight/coresight_funnel_fdt.c Mon Jun 29 12:59:09
2020(r362780)
@@ -93,6 +93,7 @@ funnel_fdt_attach(device_t dev)
static device_method_t funnel_fdt_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, funnel_fdt_probe),
+ DEVMETHOD(device_attach,funnel_fdt_attach),
DEVMETHOD_END
};
Modified: head/sys/arm64/coresight/coresight_replicator_fdt.c
==
--- head/sys/arm64/coresight/coresight_replicator_fdt.c Mon Jun 29 10:30:43
2020(r362779)
+++ head/sys/arm64/coresight/coresight_replicator_fdt.c Mon Jun 29 12:59:09
2020(r362780)
@@ -68,7 +68,7 @@ replicator_fdt_probe(device_t dev)
}
static int
-replicator_acpi_attach(device_t dev)
+replicator_fdt_attach(device_t dev)
{
struct replicator_softc *sc;
@@ -81,6 +81,7 @@ replicator_acpi_attach(device_t dev)
static device_method_t replicator_fdt_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, replicator_fdt_probe),
+ DEVMETHOD(device_attach,replicator_fdt_attach),
DEVMETHOD_END
};
___
svn-src-head@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 commit: r362779 - head/share/man/man4
Author: gbe (doc committer) Date: Mon Jun 29 10:30:43 2020 New Revision: 362779 URL: https://svnweb.freebsd.org/changeset/base/362779 Log: gre(4): Add a STANDARDS section Expand the mentioned RFC in the SEE ALSO section and reference RFC1701 and RFC1702. PR: 240250 Reviewed by: bcr (mentor) Approved by: bcr (mentor) Obtained from:OpenBSD MFC after:7 days Differential Revision:https://reviews.freebsd.org/D25504 Modified: head/share/man/man4/gre.4 Modified: head/share/man/man4/gre.4 == --- head/share/man/man4/gre.4 Mon Jun 29 09:37:07 2020(r362778) +++ head/share/man/man4/gre.4 Mon Jun 29 10:30:43 2020(r362779) @@ -29,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd April 24, 2019 +.Dd June 29, 2020 .Dt GRE 4 .Os .Sh NAME @@ -219,8 +219,44 @@ variable to non-zero. .Xr protocols 5 , .Xr ifconfig 8 , .Xr sysctl 8 +.Sh STANDARDS +.Rs +.%A S. Hanks +.%A "T. Li" +.%A D. Farinacci +.%A P. Traina +.%D October 1994 +.%R RFC 1701 +.%T Generic Routing Encapsulation (GRE) +.Re .Pp -A description of GRE encapsulation can be found in RFC 2784 and RFC 2890. +.Rs +.%A S. Hanks +.%A "T. Li" +.%A D. Farinacci +.%A P. Traina +.%D October 1994 +.%R RFC 1702 +.%T Generic Routing Encapsulation over IPv4 networks +.Re +.Pp +.Rs +.%A D. Farinacci +.%A "T. Li" +.%A S. Hanks +.%A D. Meyer +.%A P. Traina +.%D March 2000 +.%R RFC 2784 +.%T Generic Routing Encapsulation (GRE) +.Re +.Pp +.Rs +.%A G. Dommety +.%D September 2000 +.%R RFC 2890 +.%T Key and Sequence Number Extensions to GRE +.Re .Sh AUTHORS .An Andrey V. Elsukov Aq Mt a...@freebsd.org .An Heiko W.Rupp Aq Mt h...@pilhuhn.de ___ svn-src-head@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 commit: r362778 - head/sys/arm64/arm64
Author: andrew Date: Mon Jun 29 09:37:07 2020 New Revision: 362778 URL: https://svnweb.freebsd.org/changeset/base/362778 Log: Fix the spelling of identify in the arm64 identcpu code Sponsored by: Innovate UK Modified: head/sys/arm64/arm64/identcpu.c Modified: head/sys/arm64/arm64/identcpu.c == --- head/sys/arm64/arm64/identcpu.c Mon Jun 29 09:08:36 2020 (r362777) +++ head/sys/arm64/arm64/identcpu.c Mon Jun 29 09:37:07 2020 (r362778) @@ -1096,7 +1096,7 @@ identify_cpu_sysinit(void *dummy __unused) install_undef_handler(true, user_mrs_handler); } -SYSINIT(idenrity_cpu, SI_SUB_SMP, SI_ORDER_ANY, identify_cpu_sysinit, NULL); +SYSINIT(identify_cpu, SI_SUB_SMP, SI_ORDER_ANY, identify_cpu_sysinit, NULL); static u_long parse_cpu_features_hwcap(u_int cpu) ___ svn-src-head@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 commit: r362777 - in head/sys/arm64: arm64 include
Author: andrew
Date: Mon Jun 29 09:08:36 2020
New Revision: 362777
URL: https://svnweb.freebsd.org/changeset/base/362777
Log:
Create a kernel arm64 ID register view
In preparation for using ifuncs in the kernel is is useful to have a common
view of the arm64 ID registers across all CPUs. Add this and extract the
logic for finding the lower value of two fields to a new helper function.
Sponsored by: Innovate UK
Differential Revision:https://reviews.freebsd.org/D25463
Modified:
head/sys/arm64/arm64/identcpu.c
head/sys/arm64/include/undefined.h
Modified: head/sys/arm64/arm64/identcpu.c
==
--- head/sys/arm64/arm64/identcpu.c Mon Jun 29 08:14:45 2020
(r362776)
+++ head/sys/arm64/arm64/identcpu.c Mon Jun 29 09:08:36 2020
(r362777)
@@ -134,6 +134,7 @@ struct cpu_desc {
};
static struct cpu_desc cpu_desc[MAXCPU];
+static struct cpu_desc kern_cpu_desc;
static struct cpu_desc user_cpu_desc;
static u_int cpu_print_regs;
#definePRINT_ID_AA64_AFR0 0x0001
@@ -936,46 +937,109 @@ extract_user_id_field(u_int reg, u_int field_shift, ui
return (false);
}
+bool
+get_kernel_reg(u_int reg, uint64_t *val)
+{
+ int i;
+
+ for (i = 0; i < nitems(user_regs); i++) {
+ if (user_regs[i].reg == reg) {
+ *val = CPU_DESC_FIELD(kern_cpu_desc, i);
+ return (true);
+ }
+ }
+
+ return (false);
+}
+
+static uint64_t
+update_lower_register(uint64_t val, uint64_t new_val, u_int shift,
+int width, bool sign)
+{
+ uint64_t mask;
+ uint64_t new_field, old_field;
+ bool update;
+
+ KASSERT(width > 0 && width < 64, ("%s: Invalid width %d", __func__,
+ width));
+
+ mask = (1ul << width) - 1;
+ new_field = (new_val >> shift) & mask;
+ old_field = (val >> shift) & mask;
+
+ update = false;
+ if (sign) {
+ /*
+* The field is signed. Toggle the upper bit so the comparison
+* works on unsigned values as this makes positive numbers,
+* i.e. those with a 0 bit, larger than negative numbers,
+* i.e. those with a 1 bit, in an unsigned comparison.
+*/
+ if ((new_field ^ (1ul << (width - 1))) <
+ (old_field ^ (1ul << (width - 1
+ update = true;
+ } else {
+ if (new_field < old_field)
+ update = true;
+ }
+
+ if (update) {
+ val &= ~(mask << shift);
+ val |= new_field << shift;
+ }
+
+ return (val);
+}
+
static void
-update_user_regs(u_int cpu)
+update_special_regs(u_int cpu)
{
struct mrs_field *fields;
- uint64_t cur, value;
- int i, j, cur_field, new_field;
+ uint64_t user_reg, kern_reg, value;
+ int i, j;
+ if (cpu == 0) {
+ /* Create a user visible cpu description with safe values */
+ memset(_cpu_desc, 0, sizeof(user_cpu_desc));
+ /* Safe values for these registers */
+ user_cpu_desc.id_aa64pfr0 = ID_AA64PFR0_AdvSIMD_NONE |
+ ID_AA64PFR0_FP_NONE | ID_AA64PFR0_EL1_64 |
+ ID_AA64PFR0_EL0_64;
+ user_cpu_desc.id_aa64dfr0 = ID_AA64DFR0_DebugVer_8;
+ }
+
for (i = 0; i < nitems(user_regs); i++) {
value = CPU_DESC_FIELD(cpu_desc[cpu], i);
- if (cpu == 0)
- cur = value;
- else
- cur = CPU_DESC_FIELD(user_cpu_desc, i);
+ if (cpu == 0) {
+ kern_reg = value;
+ user_reg = value;
+ } else {
+ kern_reg = CPU_DESC_FIELD(kern_cpu_desc, i);
+ user_reg = CPU_DESC_FIELD(user_cpu_desc, i);
+ }
fields = user_regs[i].fields;
for (j = 0; fields[j].type != 0; j++) {
switch (fields[j].type & MRS_TYPE_MASK) {
case MRS_EXACT:
- cur &= ~(0xfu << fields[j].shift);
- cur |=
+ user_reg &= ~(0xfu << fields[j].shift);
+ user_reg |=
(uint64_t)MRS_EXACT_FIELD(fields[j].type) <<
fields[j].shift;
break;
case MRS_LOWER:
- new_field = (value >> fields[j].shift) & 0xf;
- cur_field = (cur >> fields[j].shift) & 0xf;
- if ((fields[j].sign &&
-(int)new_field < (int)cur_field) ||
-
