svn commit: r334873 - head/usr.bin/ncal
Author: eadler Date: Sat Jun 9 04:40:17 2018 New Revision: 334873 URL: https://svnweb.freebsd.org/changeset/base/334873 Log: ncal: correct history section originally reported Todd C. Miller[0] Additional data see [1][2]. While here, pet igor. Closes #152 (github pr) Sbmitted by: Raf Czlonka [0] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cal/cal.1?rev=1.28=text/x-cvsweb-markup [1] https://www.bell-labs.com/usr/dmr/www/1stEdman.html [2] https://www.bell-labs.com/usr/dmr/www/man61.pdf Modified: head/usr.bin/ncal/ncal.1 Modified: head/usr.bin/ncal/ncal.1 == --- head/usr.bin/ncal/ncal.1Sat Jun 9 04:05:18 2018(r334872) +++ head/usr.bin/ncal/ncal.1Sat Jun 9 04:40:17 2018(r334873) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd March 14, 2009 +.Dd June 08, 2018 .Dt CAL 1 .Os .Sh NAME @@ -154,15 +154,18 @@ note the year must be fully specified: .Dq Li cal 89 will .Em not -display a calendar for 1989. Two parameters denote the month and +display a calendar for 1989. +Two parameters denote the month and year; the month is either a number between 1 and 12, or a full or -abbreviated name as specified by the current locale. Month and +abbreviated name as specified by the current locale. +Month and year default to those of the current system clock and time zone (so .Dq Li cal -m 8 will display a calendar for the month of August in the current year). .Pp -Not all options can be used together. For example +Not all options can be used together. +For example .Dq Li -3 -A 2 -B 3 -y -m 7 would mean: show me the three months around the seventh month, three before @@ -180,7 +183,7 @@ Highlighting of dates is disabled if stdout is not a t A .Nm command appeared in -.At v5 . +.At v1 . The .Nm ncal command appeared in ___ 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: r334874 - head/usr.sbin/pmc
Author: eadler
Date: Sat Jun 9 04:54:36 2018
New Revision: 334874
URL: https://svnweb.freebsd.org/changeset/base/334874
Log:
pmc: mark some dead functions as such
Also change a single instance of the comma operator to a semi-colon.
Reviewed by: mmacy
Modified:
head/usr.sbin/pmc/cmd_pmc_filter.cc
head/usr.sbin/pmc/cmd_pmc_list.c
head/usr.sbin/pmc/cmd_pmc_stat.c
head/usr.sbin/pmc/cmd_pmc_summary.cc
head/usr.sbin/pmc/pmc.c
Modified: head/usr.sbin/pmc/cmd_pmc_filter.cc
==
--- head/usr.sbin/pmc/cmd_pmc_filter.cc Sat Jun 9 04:40:17 2018
(r334873)
+++ head/usr.sbin/pmc/cmd_pmc_filter.cc Sat Jun 9 04:54:36 2018
(r334874)
@@ -89,7 +89,7 @@ static struct option longopts[] = {
{NULL, 0, NULL, 0}
};
-static void
+static void __dead2
usage(void)
{
errx(EX_USAGE,
Modified: head/usr.sbin/pmc/cmd_pmc_list.c
==
--- head/usr.sbin/pmc/cmd_pmc_list.cSat Jun 9 04:40:17 2018
(r334873)
+++ head/usr.sbin/pmc/cmd_pmc_list.cSat Jun 9 04:54:36 2018
(r334874)
@@ -75,7 +75,7 @@ static struct option longopts[] = {
{NULL, 0, NULL, 0}
};
-static void
+static void __dead2
usage(void)
{
errx(EX_USAGE,
Modified: head/usr.sbin/pmc/cmd_pmc_stat.c
==
--- head/usr.sbin/pmc/cmd_pmc_stat.cSat Jun 9 04:40:17 2018
(r334873)
+++ head/usr.sbin/pmc/cmd_pmc_stat.cSat Jun 9 04:54:36 2018
(r334874)
@@ -106,7 +106,7 @@ static const char *pmc_stat_mode_names[] = {
static int pmcstat_sockpair[NSOCKPAIRFD];
-static void
+static void __dead2
usage(void)
{
errx(EX_USAGE,
@@ -127,8 +127,10 @@ showtime(FILE *out, struct timespec *before, struct ti
after->tv_sec -= before->tv_sec;
after->tv_nsec -= before->tv_nsec;
- if (after->tv_nsec < 0)
- after->tv_sec--, after->tv_nsec += 10;
+ if (after->tv_nsec < 0) {
+ after->tv_sec--;
+ after->tv_nsec += 10;
+ }
real = (after->tv_sec * 10 + after->tv_nsec) / 1000;
user = ru->ru_utime.tv_sec * 100 + ru->ru_utime.tv_usec;
Modified: head/usr.sbin/pmc/cmd_pmc_summary.cc
==
--- head/usr.sbin/pmc/cmd_pmc_summary.ccSat Jun 9 04:40:17 2018
(r334873)
+++ head/usr.sbin/pmc/cmd_pmc_summary.ccSat Jun 9 04:54:36 2018
(r334874)
@@ -83,7 +83,7 @@ typedef unordered_map https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r334869 - head/usr.bin/top
Author: eadler
Date: Sat Jun 9 02:47:02 2018
New Revision: 334869
URL: https://svnweb.freebsd.org/changeset/base/334869
Log:
top(1): correct header, align it.
THR is always 6 digits or longer. Now that the PID/THR change is
separated, use correct headers.
PR: 228823
Reported by: trond.endres...@ximalas.info
Modified:
head/usr.bin/top/machine.c
Modified: head/usr.bin/top/machine.c
==
--- head/usr.bin/top/machine.c Sat Jun 9 02:41:51 2018(r334868)
+++ head/usr.bin/top/machine.c Sat Jun 9 02:47:02 2018(r334869)
@@ -94,17 +94,20 @@ static const char io_header[] =
static const char io_Proc_format[] =
"%5d%*s %-*.*s %6ld %6ld %6ld %6ld %6ld %6ld %6.2f%% %.*s";
+/* XXX: build up header instead of statically defining them.
+ * This will also allow for a "format string" to be supplied
+ * as an argument to top(1) instead of having predefined options */
static const char smp_header_thr_and_pid[] =
-" PID%*s %-*.*s THR PRI NICE SIZERES%*s STATE C TIME %7s
COMMAND";
-static const char smp_header_tid_only[] =
-" THR%*s %-*.*s " "PRI NICE SIZERES%*s STATE C TIME %7s
COMMAND";
+" %s%*s %-*.*s THR PRI NICE SIZERES%*s STATE C TIME %7s
COMMAND";
+static const char smp_header_id_only[] =
+" %s%*s %-*.*s PRI NICE SIZERES%*s STATE C TIME %7s COMMAND";
static const char smp_Proc_format[] =
"%5d%*s %-*.*s %s%3d %4s%7s %6s%*.*s %-6.6s %2d%7s %6.2f%% %.*s";
static char up_header_thr_and_pid[] =
" PID%*s %-*.*s THR PRI NICE SIZERES%*s STATETIME %7s COMMAND";
-static char up_header_tid_only[] =
-" THR%*s %-*.*s " "PRI NICE SIZERES%*s STATETIME %7s COMMAND";
+static char up_header_id_only[] =
+" %s%*s %-*.*s PRI NICE SIZERES%*s STATETIME %7s COMMAND";
static char up_Proc_format[] =
"%5d%*s %-*.*s %s%3d %4s%7s %6s%*.*s %-6.6s%.0d%7s %6.2f%% %.*s";
@@ -425,19 +428,31 @@ format_header(const char *uname_field)
switch (displaymode) {
case DISP_CPU:
/*
-* The logic of picking the right header format seems reverse
-* here because we only want to display a THR column when
-* "thread mode" is off (and threads are not listed as
-* separate lines).
+* The logic of picking the right header is confusing, and
+* depends on too much. We should instead have a struct of
+* "header name", and "header format" which we build up.
+* This would also fix the duplicate of effort into up vs smp
+* mode.
*/
- prehead = smpmode ?
- (ps.thread_id ? smp_header_tid_only :
smp_header_thr_and_pid) :
- (ps.thread_id ? up_header_tid_only : up_header_thr_and_pid);
- snprintf(Header, sizeof(Header), prehead,
- jidlength, ps.jail ? " JID" : "",
- namelength, namelength, uname_field,
- swaplength, ps.swap ? " SWAP" : "",
- ps.wcpu ? "WCPU" : "CPU");
+ if (smpmode) {
+ prehead = ps.thread ?
+ smp_header_id_only : smp_header_thr_and_pid;
+ snprintf(Header, sizeof(Header), prehead,
+ ps.thread_id ? " THR" : "PID",
+ jidlength, ps.jail ? " JID" : "",
+ namelength, namelength, uname_field,
+ swaplength, ps.swap ? " SWAP" : "",
+ ps.wcpu ? "WCPU" : "CPU");
+ } else {
+ prehead = ps.thread ?
+ up_header_id_only : up_header_thr_and_pid;
+ snprintf(Header, sizeof(Header), prehead,
+ ps.thread_id ? " THR" : "PID",
+ jidlength, ps.jail ? " JID" : "",
+ namelength, namelength, uname_field,
+ swaplength, ps.swap ? " SWAP" : "",
+ ps.wcpu ? "WCPU" : "CPU");
+ }
break;
case DISP_IO:
prehead = io_header;
___
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: r334868 - head/stand/libsa
Author: sjg
Date: Sat Jun 9 02:41:51 2018
New Revision: 334868
URL: https://svnweb.freebsd.org/changeset/base/334868
Log:
Add st_mtime, st_ino and st_dev for ufs_stat
Differential Revision:D15064
Modified:
head/stand/libsa/ufs.c
Modified: head/stand/libsa/ufs.c
==
--- head/stand/libsa/ufs.c Sat Jun 9 02:25:18 2018(r334867)
+++ head/stand/libsa/ufs.c Sat Jun 9 02:41:51 2018(r334868)
@@ -124,6 +124,7 @@ struct file {
ufs2_daddr_tf_buf_blkno;/* block number of data block */
char*f_buf; /* buffer for data block */
size_t f_buf_size; /* size of data block */
+ int f_inumber; /* inumber */
};
#define DIP(fp, field) \
((fp)->f_fs->fs_magic == FS_UFS1_MAGIC ? \
@@ -190,6 +191,7 @@ read_inode(inumber, f)
fp->f_buf_blkno = -1;
}
fp->f_seekp = 0;
+ fp->f_inumber = inumber;
out:
free(buf);
return (rc);
@@ -836,6 +838,20 @@ ufs_stat(f, sb)
sb->st_uid = DIP(fp, di_uid);
sb->st_gid = DIP(fp, di_gid);
sb->st_size = DIP(fp, di_size);
+ sb->st_mtime = DIP(fp, di_mtime);
+ /*
+* The items below are ufs specific!
+* Other fs types will need their own solution
+* if these fields are needed.
+*/
+ sb->st_ino = fp->f_inumber;
+ /*
+* We need something to differentiate devs.
+* fs_id is unique but 64bit, we xor the two
+* halves to squeeze it into 32bits.
+*/
+ sb->st_dev = (dev_t)(fp->f_fs->fs_id[0] ^ fp->f_fs->fs_id[1]);
+
return (0);
}
___
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: r334867 - in head: lib usr.sbin
Author: mmacy
Date: Sat Jun 9 02:25:18 2018
New Revision: 334867
URL: https://svnweb.freebsd.org/changeset/base/334867
Log:
pmc: fix logic in skipping riscv
Modified:
head/lib/Makefile
head/usr.sbin/Makefile
Modified: head/lib/Makefile
==
--- head/lib/Makefile Sat Jun 9 02:18:15 2018(r334866)
+++ head/lib/Makefile Sat Jun 9 02:25:18 2018(r334867)
@@ -202,7 +202,7 @@ _libdl= libdl
.endif
SUBDIR.${MK_OPENSSL}+= libmp
-.if (${COMPILER_TYPE} == "clang" || (${COMPILER_TYPE} == "gcc" &&
${COMPILER_VERSION} >= 60100) && ${MACHINE_CPUARCH} != "riscv")
+.if (${COMPILER_TYPE} == "clang" || (${COMPILER_TYPE} == "gcc" &&
${COMPILER_VERSION} >= 60100 && ${MACHINE_CPUARCH} != "riscv"))
SUBDIR.${MK_PMC}+= libpmc libpmcstat
.endif
SUBDIR.${MK_RADIUS_SUPPORT}+= libradius
Modified: head/usr.sbin/Makefile
==
--- head/usr.sbin/Makefile Sat Jun 9 02:18:15 2018(r334866)
+++ head/usr.sbin/Makefile Sat Jun 9 02:25:18 2018(r334867)
@@ -179,7 +179,7 @@ SUBDIR.${MK_OPENSSL}+= keyserv
SUBDIR.${MK_PC_SYSINSTALL}+= pc-sysinstall
SUBDIR.${MK_PF}+= ftp-proxy
SUBDIR.${MK_PKGBOOTSTRAP}+=pkg
-.if (${COMPILER_TYPE} == "clang" || (${COMPILER_TYPE} == "gcc" &&
${COMPILER_VERSION} >= 60100) && ${MACHINE_CPUARCH} != "riscv")
+.if (${COMPILER_TYPE} == "clang" || (${COMPILER_TYPE} == "gcc" &&
${COMPILER_VERSION} >= 60100 && ${MACHINE_CPUARCH} != "riscv"))
SUBDIR.${MK_PMC}+= pmc
SUBDIR.${MK_PMC}+= pmcannotate
SUBDIR.${MK_PMC}+= pmccontrol
___
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: r334871 - head
Author: eadler Date: Sat Jun 9 03:08:04 2018 New Revision: 334871 URL: https://svnweb.freebsd.org/changeset/base/334871 Log: LOCKS: update current locks - use a wild card for releng instead of listing them out. This ignores a technicality that re@ owns the branches during release cycles, but this has not been document in this file in a long time (if ever). Approved by: core Modified: head/LOCKS Modified: head/LOCKS == --- head/LOCKS Sat Jun 9 03:01:38 2018(r334870) +++ head/LOCKS Sat Jun 9 03:08:04 2018(r334871) @@ -7,11 +7,7 @@ subsystem login expires notes -- Special cases: -releng/4.* Requires Security Officer approval. -releng/5.* Requires Security Officer approval. -releng/6.* Requires Security Officer approval. -releng/7.* Requires Security Officer approval. -releng/8.* Requires Security Officer approval. +releng/* Requires Security Officer approval. head/sys/dev/randomRequires Security Officer approval. head/sys/libkern/arc4random.c Requires Security Officer approval. stable/*/sys/dev/randomRequires Security Officer approval. ___ 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: r334865 - in head: lib usr.sbin
Author: mmacy
Date: Sat Jun 9 02:15:45 2018
New Revision: 334865
URL: https://svnweb.freebsd.org/changeset/base/334865
Log:
pmc: don't build on riscv where there's no kmod support
Modified:
head/lib/Makefile
head/usr.sbin/Makefile
Modified: head/lib/Makefile
==
--- head/lib/Makefile Sat Jun 9 02:14:33 2018(r334864)
+++ head/lib/Makefile Sat Jun 9 02:15:45 2018(r334865)
@@ -202,7 +202,7 @@ _libdl= libdl
.endif
SUBDIR.${MK_OPENSSL}+= libmp
-.if (${COMPILER_TYPE} == "clang" || (${COMPILER_TYPE} == "gcc" &&
${COMPILER_VERSION} >= 60100))
+.if (${COMPILER_TYPE} == "clang" || (${COMPILER_TYPE} == "gcc" &&
${COMPILER_VERSION} >= 60100) && ${MACHINE_CPUARCH} != "riscv")
SUBDIR.${MK_PMC}+= libpmc libpmcstat
.endif
SUBDIR.${MK_RADIUS_SUPPORT}+= libradius
Modified: head/usr.sbin/Makefile
==
--- head/usr.sbin/Makefile Sat Jun 9 02:14:33 2018(r334864)
+++ head/usr.sbin/Makefile Sat Jun 9 02:15:45 2018(r334865)
@@ -179,7 +179,7 @@ SUBDIR.${MK_OPENSSL}+= keyserv
SUBDIR.${MK_PC_SYSINSTALL}+= pc-sysinstall
SUBDIR.${MK_PF}+= ftp-proxy
SUBDIR.${MK_PKGBOOTSTRAP}+=pkg
-.if (${COMPILER_TYPE} == "clang" || (${COMPILER_TYPE} == "gcc" &&
${COMPILER_VERSION} >= 60100))
+.if (${COMPILER_TYPE} == "clang" || (${COMPILER_TYPE} == "gcc" &&
${COMPILER_VERSION} >= 60100) && ${MACHINE_CPUARCH} != "riscv")
SUBDIR.${MK_PMC}+= pmc
SUBDIR.${MK_PMC}+= pmcannotate
SUBDIR.${MK_PMC}+= pmccontrol
___
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: r334474 - head/usr.bin/top
On 4 June 2018 at 04:29, Florian Smeets wrote: > On Mon, Jun 04, 2018 at 03:42:40AM -0700, Eitan Adler wrote: >> On 3 June 2018 at 22:45, Baptiste Daroussin wrote: >> >> Hi, >> >> >> > IMHO showing TIDs should >> >> be a separate flag, 'h' maybe, as this commit changes current/expected >> >> behavior (POLA?). >> >> Its a reasonable idea to split this out into a separate flag. I'll do that. >> > > Ok, thanks. r334864 -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ 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: r334864 - head/usr.bin/top
Author: eadler
Date: Sat Jun 9 02:14:33 2018
New Revision: 334864
URL: https://svnweb.freebsd.org/changeset/base/334864
Log:
top(1): use a different command to toggle tid vs pid
- By popular demand, implement a different switch ("T") for toggling
between thread id and process id.
- Add an assert that the size of command chars is as expected.
- Also clean up some messiness I found when implementing this.
- Further document the new flag.
Requested by: flo, ronald-li...@klop.ws, bapt
PR: 139389 (for the record)
X-MFC-With: r334474
Modified:
head/usr.bin/top/commands.c
head/usr.bin/top/machine.c
head/usr.bin/top/machine.h
head/usr.bin/top/top.1
head/usr.bin/top/top.c
head/usr.bin/top/top.h
Modified: head/usr.bin/top/commands.c
==
--- head/usr.bin/top/commands.c Fri Jun 8 22:06:32 2018(r334863)
+++ head/usr.bin/top/commands.c Sat Jun 9 02:14:33 2018(r334864)
@@ -99,6 +99,7 @@ r - renice a process\n\
s - change number of seconds to delay between updates\n\
S - toggle the displaying of system processes\n\
a - toggle the displaying of process titles\n\
+T - toggle the displaying of thread IDs\n\
t - toggle the display of this process\n\
u - display processes for only one user (+ selects all users)\n\
w - toggle the display of swap use for each process\n\
Modified: head/usr.bin/top/machine.c
==
--- head/usr.bin/top/machine.c Fri Jun 8 22:06:32 2018(r334863)
+++ head/usr.bin/top/machine.c Sat Jun 9 02:14:33 2018(r334864)
@@ -433,8 +433,8 @@ format_header(const char *uname_field)
* separate lines).
*/
prehead = smpmode ?
- (ps.thread ? smp_header_tid_only : smp_header_thr_and_pid) :
- (ps.thread ? up_header_tid_only : up_header_thr_and_pid);
+ (ps.thread_id ? smp_header_tid_only :
smp_header_thr_and_pid) :
+ (ps.thread_id ? up_header_tid_only : up_header_thr_and_pid);
snprintf(Header, sizeof(Header), prehead,
jidlength, ps.jail ? " JID" : "",
namelength, namelength, uname_field,
@@ -828,7 +828,7 @@ get_process_info(struct system_info *si, struct proces
/* not in use */
continue;
- if (sel->self != -1 && pp->ki_pid == sel->self)
+ if (!sel->self && pp->ki_pid == mypid)
/* skip self */
continue;
Modified: head/usr.bin/top/machine.h
==
--- head/usr.bin/top/machine.h Fri Jun 8 22:06:32 2018(r334863)
+++ head/usr.bin/top/machine.h Sat Jun 9 02:14:33 2018(r334864)
@@ -58,25 +58,26 @@ struct system_info
*/
/*
- * the process_select struct tells get_process_info what processes we
- * are interested in seeing
+ * the process_select struct tells get_process_info what processes
+ * and information we are interested in seeing
*/
struct process_select
{
-int idle; /* show idle processes */
-int self; /* show self */
-int system;/* show system processes */
-int thread;/* show threads */
+bool idle; /* show idle processes */
+bool self; /* show self */
+bool system; /* show system processes */
+bool thread; /* show threads */
+bool thread_id;/* show thread ids */
#define TOP_MAX_UIDS 8
int uid[TOP_MAX_UIDS]; /* only these uids (unless uid[0] == -1) */
-int wcpu; /* show weighted cpu */
+bool wcpu; /* show weighted cpu */
int jid; /* only this jid (unless jid == -1) */
-int jail; /* show jail ID */
-int swap; /* show swap usage */
-int kidle; /* show per-CPU idle threads */
-pid_t pid; /* only this pid (unless pid == -1) */
-char *command; /* only this command (unless == NULL) */
+bool jail; /* show jail ID */
+bool swap; /* show swap usage */
+bool kidle;/* show per-CPU idle threads */
+int pid; /* only this pid (unless pid == -1) */
+const char *command; /* only this command (unless == NULL) */
};
/* routines defined by the machine dependent module */
Modified: head/usr.bin/top/top.1
==
--- head/usr.bin/top/top.1 Fri Jun 8 22:06:32 2018(r334863)
+++ head/usr.bin/top/top.1 Sat Jun 9 02:14:33 2018(r334864)
@@ -116,6 +116,9 @@ Display the
.IR jail (8)
ID.
.TP
+.B \-T
+Toggle displaying thread ID (tid) instead of
Re: svn commit: r334474 - head/usr.bin/top
On 8 June 2018 at 19:14, Eitan Adler wrote: > On 4 June 2018 at 04:29, Florian Smeets wrote: >> On Mon, Jun 04, 2018 at 03:42:40AM -0700, Eitan Adler wrote: >>> On 3 June 2018 at 22:45, Baptiste Daroussin wrote: >>> >> Hi, >>> >> >>> > IMHO showing TIDs should >>> >> be a separate flag, 'h' maybe, as this commit changes current/expected >>> >> behavior (POLA?). >>> >>> Its a reasonable idea to split this out into a separate flag. I'll do that. >>> >> >> Ok, thanks. > > r334864 ... and r334866 -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ 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: r334866 - head/usr.bin/top
Author: eadler Date: Sat Jun 9 02:18:15 2018 New Revision: 334866 URL: https://svnweb.freebsd.org/changeset/base/334866 Log: top(1): actually make change for tid vs pid Modified: head/usr.bin/top/machine.c Modified: head/usr.bin/top/machine.c == --- head/usr.bin/top/machine.c Sat Jun 9 02:15:45 2018(r334865) +++ head/usr.bin/top/machine.c Sat Jun 9 02:18:15 2018(r334866) @@ -98,7 +98,6 @@ static const char smp_header_thr_and_pid[] = " PID%*s %-*.*s THR PRI NICE SIZERES%*s STATE C TIME %7s COMMAND"; static const char smp_header_tid_only[] = " THR%*s %-*.*s " "PRI NICE SIZERES%*s STATE C TIME %7s COMMAND"; - static const char smp_Proc_format[] = "%5d%*s %-*.*s %s%3d %4s%7s %6s%*.*s %-6.6s %2d%7s %6.2f%% %.*s"; @@ -106,7 +105,6 @@ static char up_header_thr_and_pid[] = " PID%*s %-*.*s THR PRI NICE SIZERES%*s STATETIME %7s COMMAND"; static char up_header_tid_only[] = " THR%*s %-*.*s " "PRI NICE SIZERES%*s STATETIME %7s COMMAND"; - static char up_Proc_format[] = "%5d%*s %-*.*s %s%3d %4s%7s %6s%*.*s %-6.6s%.0d%7s %6.2f%% %.*s"; @@ -1131,7 +1129,7 @@ format_next_process(void* xhandle, char *(*get_userid) (int)(sizeof(thr_buf) - 2), pp->ki_numthreads); snprintf(fmt, sizeof(fmt), proc_fmt, - (ps.thread) ? pp->ki_tid : pp->ki_pid, + (ps.thread_id) ? pp->ki_tid : pp->ki_pid, jidlength, jid_buf, namelength, namelength, (*get_userid)(pp->ki_ruid), thr_buf, ___ 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: r334819 - head/sys/vm
On Fri, Jun 08, 2018 at 03:07:07PM +1000, Kubilay Kocak wrote: K> > UMA memory debugging enabled with INVARIANTS consists of two things: K> > trashing freed memory and checking that allocated memory is properly K> > trashed, and also of keeping a bitset of freed items. Trashing/checking K> > creates a lot of CPU cache poisoning, while keeping debugging bitsets K> > consistent creates a lot of contention on UMA zone lock(s). The performance K> > difference between INVARIANTS kernel and normal one is mostly attributed K> > to UMA debugging, rather than to all KASSERT checks in the kernel. K> > K> > Add loader tunable vm.debug.divisor that allows either to turn off UMA K> K> Is 'sample interval' a standard/common enough term for this kind of K> mechanism to name the sysctl with it rather than the implementation? K> K> Or 'sample frequency' Interval definitely doesn't fit here. Frequency is closer, but still not the right term, IMHO. Native speaker required here to judge. I am okay if anyone who is confident changes wording here. -- Gleb Smirnoff ___ 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: r334824 - head/sys/vm
On Fri, Jun 08, 2018 at 03:16:17AM +, Mateusz Guzik wrote: M> Author: mjg M> Date: Fri Jun 8 03:16:16 2018 M> New Revision: 334824 M> URL: https://svnweb.freebsd.org/changeset/base/334824 M> M> Log: M> uma: remove M_ZERO support for pcpu zones M> M> Nothing in the tree uses it and pcpu zones have a fundamentally different use M> case than the regular zones - they are not supposed to be allocated and freed M> all the time. M> M> This reduces pollution in the allocation fast path. Now counter(9) is broken and r334830 doesn't yet fix the problem. This won't happen if commit was reviewed. -- Gleb Smirnoff ___ 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: r334545 - in head/sys: contrib/zstd/lib/freebsd kern netinet/libalias sys
On Tue, Jun 05, 2018 at 06:35:37PM +0200, Mateusz Guzik wrote:
M> > On 06/02/2018 17:20, Mateusz Guzik wrote:
M> > > +#ifdef _KERNEL
M> > > +#define malloc(size, type, flags) ({\
M> > > + void *_malloc_item; \
M> > > + size_t _size = (size); \
M> > > + if (__builtin_constant_p(size) && __builtin_constant_p(flags) &&\
M> > > + ((flags) & M_ZERO)) { \
M> > > + _malloc_item = malloc(_size, type, (flags) &~ M_ZERO); \
M> > > + if (((flags) & M_WAITOK) || _malloc_item != NULL) \
M> > > + bzero(_malloc_item, _size); \
M> > > + } else {\
M> > > + _malloc_item = malloc(_size, type, flags); \
M> > > + } \
M> > > + _malloc_item; \
M> > > +})
M> > > +#endif
M> >
M> > Mateusz,
M> >
M> > Thank you for this and for all of your performance work. It is all very
M> > interesting stuff.
M> >
M> >
M> Thank you for the kind words. It is positive feedback like this which
M> keeps me going!
Btw, what was the point of checking flags || result? Most places in kernel
ignore flags and just test result regerdless of M_WAITOK/M_NOWAIT.
The result is already in a register, why do you think checking for absense
of M_WAITOK is faster that checking for !NULL _malloc_item?
--
Gleb Smirnoff
___
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: r334545 - in head/sys: contrib/zstd/lib/freebsd kern netinet/libalias sys
On Wed, Jun 06, 2018 at 12:56:47AM +0200, Mateusz Guzik wrote: M> > M> Thank you for the kind words. It is positive feedback like this which M> > M> keeps me going! M> > M> > Btw, what was the point of checking flags || result? Most places in kernel M> > ignore flags and just test result regerdless of M_WAITOK/M_NOWAIT. M> > M> > The result is already in a register, why do you think checking for absense M> > of M_WAITOK is faster that checking for !NULL _malloc_item? M> > M> M> This part is only reachable if flags are known at compilation time. If they M> contain M> M_WAITOK, the flag check will get elided along (we know for a fact it M> passes) M> and subsequently the NULL check will be short circuited, iow for known M> M_WAITOK|M_ZERO flags this is: M> M> _malloc_item = malloc(_size, type, flags & ~ M_ZERO); M> bzero(_malloc_item, _size); Thanks a lot for explanation! -- Gleb Smirnoff ___ 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: r334807 - head/usr.bin/grep
On 7 June 2018 at 11:36, Kyle Evans wrote: > Author: kevans > Date: Thu Jun 7 18:36:12 2018 > New Revision: 334807 > URL: https://svnweb.freebsd.org/changeset/base/334807 > > Log: > bsdgrep(1): whoops, garbage collect the now write-only variable Picking a random email to respond to: thanks for your work on grep! It's nice to have someone working on it :) -- Eitan Adler ___ 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: r334863 - head/sys/kern
Author: mjg
Date: Fri Jun 8 22:06:32 2018
New Revision: 334863
URL: https://svnweb.freebsd.org/changeset/base/334863
Log:
counter: add a bit missed in r334858
It happens to be a noop.
Modified:
head/sys/kern/subr_counter.c
Modified: head/sys/kern/subr_counter.c
==
--- head/sys/kern/subr_counter.cFri Jun 8 21:49:19 2018
(r334862)
+++ head/sys/kern/subr_counter.cFri Jun 8 22:06:32 2018
(r334863)
@@ -62,7 +62,7 @@ counter_u64_alloc(int flags)
{
counter_u64_t r;
- r = uma_zalloc(pcpu_zone_64, flags & ~M_ZERO);
+ r = uma_zalloc_pcpu(pcpu_zone_64, flags);
if (r != NULL)
counter_u64_zero(r);
@@ -73,7 +73,7 @@ void
counter_u64_free(counter_u64_t c)
{
- uma_zfree(pcpu_zone_64, c);
+ uma_zfree_pcpu(pcpu_zone_64, c);
}
int
___
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: r334862 - head/sys/net
Author: shurd
Date: Fri Jun 8 21:49:19 2018
New Revision: 334862
URL: https://svnweb.freebsd.org/changeset/base/334862
Log:
Remove tx task spinning added in r333686
This caused issues with PASTE. Just remove the reschedule since the DELAY()
should be enough for use cases such as pkt-gen which were failing before the
change.
Reported by: Michio Honda
Sponsored by: Limelight Networks
Modified:
head/sys/net/iflib.c
Modified: head/sys/net/iflib.c
==
--- head/sys/net/iflib.cFri Jun 8 21:47:17 2018(r334861)
+++ head/sys/net/iflib.cFri Jun 8 21:49:19 2018(r334862)
@@ -3728,16 +3728,6 @@ _task_fn_tx(void *context)
*/
if (ctx->isc_txd_credits_update(ctx->ifc_softc, txq->ift_id,
false))
netmap_tx_irq(ifp, txq->ift_id);
- else {
-#ifdef DEV_NETMAP
- if (!(ctx->ifc_flags & IFC_NETMAP_TX_IRQ)) {
- struct netmap_kring *kring =
NA(ctx->ifc_ifp)->tx_rings[txq->ift_id];
-
- if (kring->nr_hwtail != nm_prev(kring->rhead,
kring->nkr_num_slots - 1))
- GROUPTASK_ENQUEUE(>ift_task);
- }
-#endif
- }
IFDI_TX_QUEUE_INTR_ENABLE(ctx, txq->ift_id);
return;
}
___
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: r334858 - in head/sys: netipsec netpfil/ipfw vm
Author: mjg
Date: Fri Jun 8 21:40:03 2018
New Revision: 334858
URL: https://svnweb.freebsd.org/changeset/base/334858
Log:
uma: implement provisional api for per-cpu zones
Per-cpu zone allocations are very rarely done compared to regular zones.
The intent is to avoid pessimizing the latter case with per-cpu specific
code.
In particular contrary to the claim in r334824, M_ZERO is sometimes being
used for such zones. But the zeroing method is completely different and
braching on it in the fast path for regular zones is a waste of time.
Modified:
head/sys/netipsec/key.c
head/sys/netpfil/ipfw/ip_fw_sockopt.c
head/sys/vm/uma.h
head/sys/vm/uma_core.c
Modified: head/sys/netipsec/key.c
==
--- head/sys/netipsec/key.c Fri Jun 8 20:39:49 2018(r334857)
+++ head/sys/netipsec/key.c Fri Jun 8 21:40:03 2018(r334858)
@@ -2957,7 +2957,7 @@ key_newsav(const struct sadb_msghdr *mhp, struct secas
goto done;
}
mtx_init(sav->lock, "ipsec association", NULL, MTX_DEF);
- sav->lft_c = uma_zalloc(V_key_lft_zone, M_NOWAIT);
+ sav->lft_c = uma_zalloc_pcpu(V_key_lft_zone, M_NOWAIT);
if (sav->lft_c == NULL) {
*errp = ENOBUFS;
goto done;
@@ -3049,7 +3049,7 @@ done:
free(sav->lock, M_IPSEC_MISC);
}
if (sav->lft_c != NULL)
- uma_zfree(V_key_lft_zone, sav->lft_c);
+ uma_zfree_pcpu(V_key_lft_zone, sav->lft_c);
free(sav, M_IPSEC_SA), sav = NULL;
}
if (sah != NULL)
Modified: head/sys/netpfil/ipfw/ip_fw_sockopt.c
==
--- head/sys/netpfil/ipfw/ip_fw_sockopt.c Fri Jun 8 20:39:49 2018
(r334857)
+++ head/sys/netpfil/ipfw/ip_fw_sockopt.c Fri Jun 8 21:40:03 2018
(r334858)
@@ -208,7 +208,7 @@ ipfw_alloc_rule(struct ip_fw_chain *chain, size_t rule
struct ip_fw *rule;
rule = malloc(rulesize, M_IPFW, M_WAITOK | M_ZERO);
- rule->cntr = uma_zalloc(V_ipfw_cntr_zone, M_WAITOK | M_ZERO);
+ rule->cntr = uma_zalloc_pcpu(V_ipfw_cntr_zone, M_WAITOK | M_ZERO);
return (rule);
}
@@ -217,7 +217,7 @@ static void
free_rule(struct ip_fw *rule)
{
- uma_zfree(V_ipfw_cntr_zone, rule->cntr);
+ uma_zfree_pcpu(V_ipfw_cntr_zone, rule->cntr);
free(rule, M_IPFW);
}
Modified: head/sys/vm/uma.h
==
--- head/sys/vm/uma.h Fri Jun 8 20:39:49 2018(r334857)
+++ head/sys/vm/uma.h Fri Jun 8 21:40:03 2018(r334858)
@@ -333,6 +333,7 @@ void uma_zdestroy(uma_zone_t zone);
*/
void *uma_zalloc_arg(uma_zone_t zone, void *arg, int flags);
+void *uma_zalloc_pcpu_arg(uma_zone_t zone, void *arg, int flags);
/*
* Allocate an item from a specific NUMA domain. This uses a slow path in
@@ -354,6 +355,7 @@ void *uma_zalloc_domain(uma_zone_t zone, void *arg, in
*
*/
static __inline void *uma_zalloc(uma_zone_t zone, int flags);
+static __inline void *uma_zalloc_pcpu(uma_zone_t zone, int flags);
static __inline void *
uma_zalloc(uma_zone_t zone, int flags)
@@ -361,6 +363,12 @@ uma_zalloc(uma_zone_t zone, int flags)
return uma_zalloc_arg(zone, NULL, flags);
}
+static __inline void *
+uma_zalloc_pcpu(uma_zone_t zone, int flags)
+{
+ return uma_zalloc_pcpu_arg(zone, NULL, flags);
+}
+
/*
* Frees an item back into the specified zone.
*
@@ -374,6 +382,7 @@ uma_zalloc(uma_zone_t zone, int flags)
*/
void uma_zfree_arg(uma_zone_t zone, void *item, void *arg);
+void uma_zfree_pcpu_arg(uma_zone_t zone, void *item, void *arg);
/*
* Frees an item back to the specified zone's domain specific pool.
@@ -392,11 +401,18 @@ void uma_zfree_domain(uma_zone_t zone, void *item, voi
*
*/
static __inline void uma_zfree(uma_zone_t zone, void *item);
+static __inline void uma_zfree_pcpu(uma_zone_t zone, void *item);
static __inline void
uma_zfree(uma_zone_t zone, void *item)
{
uma_zfree_arg(zone, item, NULL);
+}
+
+static __inline void
+uma_zfree_pcpu(uma_zone_t zone, void *item)
+{
+ uma_zfree_pcpu_arg(zone, item, NULL);
}
/*
Modified: head/sys/vm/uma_core.c
==
--- head/sys/vm/uma_core.c Fri Jun 8 20:39:49 2018(r334857)
+++ head/sys/vm/uma_core.c Fri Jun 8 21:40:03 2018(r334858)
@@ -2230,6 +2230,32 @@ uma_zwait(uma_zone_t zone)
uma_zfree(zone, item);
}
+void *
+uma_zalloc_pcpu_arg(uma_zone_t zone, void *udata, int flags)
+{
+ void *item;
+ int i;
+
+ MPASS(zone->uz_flags & UMA_ZONE_PCPU);
+ item = uma_zalloc_arg(zone, udata, flags &~ M_ZERO);
svn commit: r334857 - head/sys/dev/hwpmc
Author: mmacy
Date: Fri Jun 8 20:39:49 2018
New Revision: 334857
URL: https://svnweb.freebsd.org/changeset/base/334857
Log:
hwpmc: remove dangling references to hwpmc_xscale
Reported by: mjg
Modified:
head/sys/dev/hwpmc/hwpmc_arm.c
Modified: head/sys/dev/hwpmc/hwpmc_arm.c
==
--- head/sys/dev/hwpmc/hwpmc_arm.c Fri Jun 8 20:35:58 2018
(r334856)
+++ head/sys/dev/hwpmc/hwpmc_arm.c Fri Jun 8 20:39:49 2018
(r334857)
@@ -58,10 +58,6 @@ __FBSDID("$FreeBSD$");
struct pmc_mdep *
pmc_md_initialize()
{
-#ifdef CPU_XSCALE_IXP425
- if (cpu_class == CPU_CLASS_XSCALE)
- return pmc_xscale_initialize();
-#endif
#ifdef CPU_CORTEXA
if (cpu_class == CPU_CLASS_CORTEXA)
return pmc_armv7_initialize();
@@ -72,13 +68,6 @@ pmc_md_initialize()
void
pmc_md_finalize(struct pmc_mdep *md)
{
-#ifdef CPU_XSCALE_IXP425
- if (cpu_class == CPU_CLASS_XSCALE)
- pmc_xscale_finalize(md);
- else
- KASSERT(0, ("[arm,%d] Unknown CPU Class 0x%x", __LINE__,
- cpu_class));
-#endif
#ifdef CPU_CORTEXA
if (cpu_class == CPU_CLASS_CORTEXA)
pmc_armv7_finalize(md);
___
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: r334856 - head/sys/amd64/amd64
Author: tychon Date: Fri Jun 8 20:35:58 2018 New Revision: 334856 URL: https://svnweb.freebsd.org/changeset/base/334856 Log: Don't bother looking for non-executable pages when a process is excluded from PTI. Reviewed by: kib Sponsored by: Dell EMC Isilon Differential Revision:https://reviews.freebsd.org/D15708 Modified: head/sys/amd64/amd64/trap.c Modified: head/sys/amd64/amd64/trap.c == --- head/sys/amd64/amd64/trap.c Fri Jun 8 20:31:59 2018(r334855) +++ head/sys/amd64/amd64/trap.c Fri Jun 8 20:35:58 2018(r334856) @@ -770,7 +770,8 @@ trap_pfault(struct trapframe *frame, int usermode) * If nx protection of the usermode portion of kernel page * tables caused trap, panic. */ - if (pti && usermode && pg_nx != 0 && (frame->tf_err & (PGEX_P | PGEX_W | + if (PCPU_GET(curpmap)->pm_ucr3 != PMAP_NO_CR3 && usermode && + pg_nx != 0 && (frame->tf_err & (PGEX_P | PGEX_W | PGEX_U | PGEX_I)) == (PGEX_P | PGEX_U | PGEX_I) && (curpcb->pcb_saved_ucr3 & ~CR3_PCID_MASK)== (PCPU_GET(curpmap)->pm_cr3 & ~CR3_PCID_MASK)) ___ 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: r334855 - head/sys/kern
Author: mmacy
Date: Fri Jun 8 20:31:59 2018
New Revision: 334855
URL: https://svnweb.freebsd.org/changeset/base/334855
Log:
AF_UNIX: bring uipc_ready in compliance with new locking protocol
PR: 228742
Submitted by: markj
Reviewed by: markj
Modified:
head/sys/kern/uipc_usrreq.c
Modified: head/sys/kern/uipc_usrreq.c
==
--- head/sys/kern/uipc_usrreq.c Fri Jun 8 19:47:04 2018(r334854)
+++ head/sys/kern/uipc_usrreq.c Fri Jun 8 20:31:59 2018(r334855)
@@ -1262,14 +1262,21 @@ uipc_ready(struct socket *so, struct mbuf *m, int coun
unp = sotounpcb(so);
- UNP_LINK_RLOCK();
+ UNP_PCB_LOCK(unp);
if ((unp2 = unp->unp_conn) == NULL) {
- UNP_LINK_RUNLOCK();
- for (int i = 0; i < count; i++)
- m = m_free(m);
- return (ECONNRESET);
+ UNP_PCB_UNLOCK(unp);
+ goto error;
}
- UNP_PCB_LOCK(unp2);
+ if (unp != unp2) {
+ if (UNP_PCB_TRYLOCK(unp2) == 0) {
+ unp_pcb_hold(unp2);
+ UNP_PCB_UNLOCK(unp);
+ UNP_PCB_LOCK(unp2);
+ if (unp_pcb_rele(unp2))
+ goto error;
+ } else
+ UNP_PCB_UNLOCK(unp);
+ }
so2 = unp2->unp_socket;
SOCKBUF_LOCK(>so_rcv);
@@ -1279,9 +1286,12 @@ uipc_ready(struct socket *so, struct mbuf *m, int coun
SOCKBUF_UNLOCK(>so_rcv);
UNP_PCB_UNLOCK(unp2);
- UNP_LINK_RUNLOCK();
return (error);
+ error:
+ for (int i = 0; i < count; i++)
+ m = m_free(m);
+ return (ECONNRESET);
}
static int
___
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: r334854 - head/share/man/man9
Author: jtl Date: Fri Jun 8 19:47:04 2018 New Revision: 334854 URL: https://svnweb.freebsd.org/changeset/base/334854 Log: Create a symlink for sodtor_set(9) to the socket(9) man page. Modified: head/share/man/man9/Makefile Modified: head/share/man/man9/Makefile == --- head/share/man/man9/MakefileFri Jun 8 19:35:24 2018 (r334853) +++ head/share/man/man9/MakefileFri Jun 8 19:47:04 2018 (r334854) @@ -1895,6 +1895,7 @@ MLINKS+=socket.9 soabort.9 \ socket.9 soconnect.9 \ socket.9 socreate.9 \ socket.9 sodisconnect.9 \ + socket.9 sodtor_set.9 \ socket.9 sodupsockaddr.9 \ socket.9 sofree.9 \ socket.9 sogetopt.9 \ ___ 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: r334853 - in head: share/man/man9 sys/kern sys/sys
Author: jtl
Date: Fri Jun 8 19:35:24 2018
New Revision: 334853
URL: https://svnweb.freebsd.org/changeset/base/334853
Log:
Add a socket destructor callback. This allows kernel providers to set
callbacks to perform additional cleanup actions at the time a socket is
closed.
Michio Honda presented a use for this at BSDCan 2018.
(See https://www.bsdcan.org/2018/schedule/events/965.en.html .)
Submitted by: Michio Honda (previous version)
Reviewed by: lstewart (previous version)
Differential Revision:https://reviews.freebsd.org/D15706
Modified:
head/share/man/man9/socket.9
head/sys/kern/uipc_socket.c
head/sys/sys/socketvar.h
Modified: head/share/man/man9/socket.9
==
--- head/share/man/man9/socket.9Fri Jun 8 18:54:47 2018
(r334852)
+++ head/share/man/man9/socket.9Fri Jun 8 19:35:24 2018
(r334853)
@@ -26,7 +26,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd May 26, 2014
+.Dd June 8, 2018
.Dt SOCKET 9
.Os
.Sh NAME
@@ -54,6 +54,11 @@
.Fc
.Ft int
.Fn sodisconnect "struct socket *so"
+.Ft void
+.Fo sodtor_set
+.Fa "struct socket *so"
+.Fa "void (*func)(struct socket *)"
+.Fc
.Ft struct sockaddr *
.Fn sodupsockaddr "const struct sockaddr *sa" "int mflags"
.Ft void
@@ -369,6 +374,13 @@ be cleared, with
.Dv SO_RCV
or
.Dv SO_SND .
+.Ss Socket Destructor Callback
+A kernel system can use the
+.Fn sodtor_set
+function to set a destructor for a socket.
+The destructor is called when the socket is closed.
+The destructor is called after the protocol close routine has completed.
+The destructor can serve as a callback to initiate additional cleanup actions.
.Ss Socket I/O
The
.Fn soreceive
Modified: head/sys/kern/uipc_socket.c
==
--- head/sys/kern/uipc_socket.c Fri Jun 8 18:54:47 2018(r334852)
+++ head/sys/kern/uipc_socket.c Fri Jun 8 19:35:24 2018(r334853)
@@ -1101,6 +1101,8 @@ soclose(struct socket *so)
drop:
if (so->so_proto->pr_usrreqs->pru_close != NULL)
(*so->so_proto->pr_usrreqs->pru_close)(so);
+ if (so->so_dtor != NULL)
+ so->so_dtor(so);
SOCK_LOCK(so);
if ((listening = (so->so_options & SO_ACCEPTCONN))) {
@@ -3810,6 +3812,17 @@ sodupsockaddr(const struct sockaddr *sa, int mflags)
if (sa2)
bcopy(sa, sa2, sa->sa_len);
return sa2;
+}
+
+/*
+ * Register per-socket destructor.
+ */
+void
+sodtor_set(struct socket *so, so_dtor_t *func)
+{
+
+ SOCK_LOCK_ASSERT(so);
+ so->so_dtor = func;
}
/*
Modified: head/sys/sys/socketvar.h
==
--- head/sys/sys/socketvar.hFri Jun 8 18:54:47 2018(r334852)
+++ head/sys/sys/socketvar.hFri Jun 8 19:35:24 2018(r334853)
@@ -63,6 +63,7 @@ struct vnet;
* private data and error information.
*/
typedefint so_upcall_t(struct socket *, void *, int);
+typedefvoid so_dtor_t(struct socket *);
struct socket;
@@ -99,6 +100,7 @@ struct socket {
/* NB: generation count must not be first. */
so_gen_t so_gencnt; /* (h) generation count */
void*so_emuldata; /* (b) private data for emulators */
+ so_dtor_t *so_dtor; /* (b) optional destructor */
struct osd osd;/* Object Specific extensions */
/*
* so_fibnum, so_user_cookie and friends can be used to attach
@@ -397,6 +399,7 @@ int soconnect2(struct socket *so1, struct socket *so2)
intsocreate(int dom, struct socket **aso, int type, int proto,
struct ucred *cred, struct thread *td);
intsodisconnect(struct socket *so);
+void sodtor_set(struct socket *, so_dtor_t *);
struct sockaddr *sodupsockaddr(const struct sockaddr *sa, int mflags);
void sofree(struct socket *so);
void sohasoutofband(struct socket *so);
___
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: r334817 - in head/usr.sbin/cron: cron crontab lib
On 2018-06-07 22:38:40, Gleb Smirnoff wrote: Author: glebius Date: Thu Jun 7 22:38:40 2018 New Revision: 334817 URL: https://svnweb.freebsd.org/changeset/base/334817 Log: Add new functionality and syntax to cron(1) to allow to run jobs at a given interval, which is counted in seconds since exit of the previous invocation of the job. Example user crontab entry: @25sleep 10 The example will launch 'sleep 10' every 35 seconds. This is a rather useless example above, but clearly explains the functionality. The practical goal here is to avoid overlap of previous job invocation to a new one, or to avoid too short interval(s) for jobs that last long and doesn't have any point of immediate launch soon after previous run. Another useful effect of interval jobs can be noticed when a cluster of machines periodically communicates with a single node. Running the task time based creates too much load on the node. Running interval based spreads invocations across machines in cluster. Note that -j/-J won't help in this case. Sponsored by: Netflix Missing a Relnotes tag, possibly. ___ 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: r334852 - head/sys/mips/atheros
Author: mmacy Date: Fri Jun 8 18:54:47 2018 New Revision: 334852 URL: https://svnweb.freebsd.org/changeset/base/334852 Log: hwpmc: yet another missed fixup Modified: head/sys/mips/atheros/apb.c Modified: head/sys/mips/atheros/apb.c == --- head/sys/mips/atheros/apb.c Fri Jun 8 18:32:26 2018(r334851) +++ head/sys/mips/atheros/apb.c Fri Jun 8 18:54:47 2018(r334852) @@ -388,7 +388,7 @@ apb_filter(void *arg) tf = td->td_intr_frame; if (pmc_intr) - (*pmc_intr)(PCPU_GET(tf); + (*pmc_intr)(tf); continue; } /* Ignore timer interrupts */ ___ 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: r334708 - head/sys/kern
On Fri, Jun 08, 2018 at 02:30:10PM -0400, Mark Johnston wrote: > On Fri, Jun 08, 2018 at 08:37:55PM +0300, Konstantin Belousov wrote: > > On Thu, Jun 07, 2018 at 11:02:29PM -0700, Ryan Libby wrote: > > > On Thu, Jun 7, 2018 at 10:03 PM, Mateusz Guzik wrote: > > > > Checking it without any locks is perfectly valid in this case. It is > > > > done > > > > after v_holdcnt gets bumped from a non-zero value. So at that time it > > > > is at least two. Of course that result is stale as an arbitrary number > > > > of > > > > other threads could have bumped and dropped the ref past that point. > > > > The minimum value is 1 since we hold the ref. But this means the > > > > vnode must not be on the free list and that's what the assertion is > > > > verifying. > > > > > > > > The problem is indeed lack of ordering against the code clearing the > > > > flag for the case where 2 threads to vhold and one does the 0->1 > > > > transition. > > > > > > > > That said, the fence is required for the assertion to work. > > > > > > > > > > Yeah, I agree with this logic. What I mean is that reordering between > > > v_holdcnt 0->1 and v_iflag is normally settled by the release and > > > acquisition of the vnode interlock, which we are supposed to hold for > > > v_*i*flag. A quick scan seems to show all of the checks of VI_FREE that > > > are not asserts do hold the vnode interlock. So, I'm just saying that I > > > don't think the possible reordering affects them. > > But do we know that only VI_FREE checks are affected ? > > > > My concern is that users of _vhold() rely on seeing up to date state of the > > vnode, and VI_FREE is only an example of the problem. Most likely, the > > code which fetched the vnode pointer before _vhold() call, should guarantee > > visibility. > > Wouldn't this be a problem only if we permit lockless accesses of vnode > state outside of _vhold() and other vnode subroutines? The current > protocol requires that the interlock be held, and this synchronizes with > code which performs 0->1 and 1->0 transitions of the hold count. If this > requirement is relaxed in the future, then fences would indeed be > needed. I do not claim that my concern is a real problem. I stated it as a thing to look at when deciding whether the fences should be added (unconditionally ?). If you argument is that the only current lock-less protocol for the struct vnode state is the v_holdcnt transitions for > 1, then I can agree with it. ___ 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: r334851 - head/sys/arm64/arm64
Author: kib Date: Fri Jun 8 18:32:26 2018 New Revision: 334851 URL: https://svnweb.freebsd.org/changeset/base/334851 Log: Restore release semantic for the old thread unlock on arm64. With the introduction of pmap_switch(), the DSB instruction on the address map switch is not necessary executed, which is fixed by changing the unlock store to release. Also remove comment which documented pre-pmap_switch() code. Reviewed by: andrew Sponsored by: The FreeBSD Foundation MFC after:1 week Modified: head/sys/arm64/arm64/swtch.S Modified: head/sys/arm64/arm64/swtch.S == --- head/sys/arm64/arm64/swtch.SFri Jun 8 18:24:46 2018 (r334850) +++ head/sys/arm64/arm64/swtch.SFri Jun 8 18:32:26 2018 (r334851) @@ -165,10 +165,9 @@ ENTRY(cpu_switch) mov x0, x19 /* -* Release the old thread. This doesn't need to be a store-release -* as the above dsb instruction will provide release semantics. +* Release the old thread. */ - str x2, [x0, #TD_LOCK] + stlrx2, [x0, #TD_LOCK] #if defined(SCHED_ULE) && defined(SMP) /* Spin if TD_LOCK points to a blocked_lock */ ldr x2, =_C_LABEL(blocked_lock) ___ 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: r334708 - head/sys/kern
On Fri, Jun 08, 2018 at 08:37:55PM +0300, Konstantin Belousov wrote: > On Thu, Jun 07, 2018 at 11:02:29PM -0700, Ryan Libby wrote: > > On Thu, Jun 7, 2018 at 10:03 PM, Mateusz Guzik wrote: > > > Checking it without any locks is perfectly valid in this case. It is done > > > after v_holdcnt gets bumped from a non-zero value. So at that time it > > > is at least two. Of course that result is stale as an arbitrary number of > > > other threads could have bumped and dropped the ref past that point. > > > The minimum value is 1 since we hold the ref. But this means the > > > vnode must not be on the free list and that's what the assertion is > > > verifying. > > > > > > The problem is indeed lack of ordering against the code clearing the > > > flag for the case where 2 threads to vhold and one does the 0->1 > > > transition. > > > > > > That said, the fence is required for the assertion to work. > > > > > > > Yeah, I agree with this logic. What I mean is that reordering between > > v_holdcnt 0->1 and v_iflag is normally settled by the release and > > acquisition of the vnode interlock, which we are supposed to hold for > > v_*i*flag. A quick scan seems to show all of the checks of VI_FREE that > > are not asserts do hold the vnode interlock. So, I'm just saying that I > > don't think the possible reordering affects them. > But do we know that only VI_FREE checks are affected ? > > My concern is that users of _vhold() rely on seeing up to date state of the > vnode, and VI_FREE is only an example of the problem. Most likely, the > code which fetched the vnode pointer before _vhold() call, should guarantee > visibility. Wouldn't this be a problem only if we permit lockless accesses of vnode state outside of _vhold() and other vnode subroutines? The current protocol requires that the interlock be held, and this synchronizes with code which performs 0->1 and 1->0 transitions of the hold count. If this requirement is relaxed in the future, then fences would indeed be needed. ___ 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: r334850 - head/sys/arm/xscale/ixp425
Author: mmacy Date: Fri Jun 8 18:24:46 2018 New Revision: 334850 URL: https://svnweb.freebsd.org/changeset/base/334850 Log: hwpmc: remove hwpmc_xscale.c from corresponding arm build Modified: head/sys/arm/xscale/ixp425/files.ixp425 Modified: head/sys/arm/xscale/ixp425/files.ixp425 == --- head/sys/arm/xscale/ixp425/files.ixp425 Fri Jun 8 18:21:57 2018 (r334849) +++ head/sys/arm/xscale/ixp425/files.ixp425 Fri Jun 8 18:24:46 2018 (r334850) @@ -13,7 +13,6 @@ arm/xscale/ixp425/uart_bus_ixp425.c optionaluart arm/xscale/ixp425/ixp425_a4x_space.c optionaluart arm/xscale/ixp425/ixp425_a4x_io.S optionaluart dev/cfi/cfi_bus_ixp4xx.c optionalcfi -dev/hwpmc/hwpmc_xscale.c optionalhwpmc dev/uart/uart_dev_ns8250.c optionaluart # # NPE-based Ethernet support (requires qmgr also). ___ 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: r334849 - in head/sys: contrib/dev/ath/ath_hal/ar9300 dev/ath/ath_hal/ar5416
Author: adrian
Date: Fri Jun 8 18:21:57 2018
New Revision: 334849
URL: https://svnweb.freebsd.org/changeset/base/334849
Log:
[ath_hal] Return failure if noise floor calibration fails.
If we fail noise floor calibration then we may end up with a deaf NIC
which we can't recover without a full chip reset.
Earlier chips seem to get less stuck in this condition versus AR9280/later
and AR9300/later, but whilst here just fix up the AR5212 era chips to also
return NF calibration failures.
This HAL routine would only return failure if the channel was not configured.
This is a no-op until the driver side code for doing resets and the HAL
code for being told about the reset type (and then handling it!) is
implemented.
Tested:
* AR9280, STA mode
* AR2425, STA mode
* AR9380, STA mode
Modified:
head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.c
head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.c
head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_reset.c
head/sys/dev/ath/ath_hal/ar5416/ar5416_cal.c
Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.c
==
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.cFri Jun 8
18:15:23 2018(r334848)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.cFri Jun 8
18:21:57 2018(r334849)
@@ -1188,6 +1188,15 @@ ar9300_ani_ar_poll(struct ath_hal *ah, const HAL_NODE_
cck_phy_err_cnt - ani_state->cck_phy_err_count;
ani_state->cck_phy_err_count = cck_phy_err_cnt;
+/*
+ * Note - the ANI code is using the aggregate listen time.
+ * The AR_PHY_CNT1/AR_PHY_CNT2 registers here are also
+ * free running, not clear-on-read and are free-running.
+ *
+ * So, ofdm_phy_err_rate / cck_phy_err_rate are accumulating
+ * the same as listenTime is accumulating.
+ */
+
#if HAL_ANI_DEBUG
HALDEBUG(ah, HAL_DEBUG_ANI,
"%s: Errors: OFDM=0x%08x-0x0=%d CCK=0x%08x-0x0=%d\n",
Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.c
==
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.cFri Jun 8
18:15:23 2018(r334848)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.cFri Jun 8
18:21:57 2018(r334849)
@@ -704,11 +704,16 @@ ar9300_proc_rx_desc_freebsd(struct ath_hal *ah, struct
(void *) ds));
}
+/*
+ * This is the primary way the ANI code gets the node statistics per packet.
+ */
void
ar9300_ani_rxmonitor_freebsd(struct ath_hal *ah, const HAL_NODE_STATS *stats,
const struct ieee80211_channel *chan)
{
+ struct ath_hal_9300 *ahp = AH9300(ah);
+ ahp->ah_stats.ast_nodestats.ns_avgbrssi = stats->ns_avgbrssi;
}
void
Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_reset.c
==
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_reset.c Fri Jun 8
18:15:23 2018(r334848)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_reset.c Fri Jun 8
18:21:57 2018(r334849)
@@ -2493,15 +2493,23 @@ ar9300_calibration(struct ath_hal *ah, struct ieee8021
chan->ic_state &= ~IEEE80211_CHANSTATE_CWINT;
if (nf_done) {
+int ret;
/*
* Load the NF from history buffer of the current channel.
* NF is slow time-variant, so it is OK to use a historical value.
*/
ar9300_get_nf_hist_base(ah, ichan, is_scan, nf_buf);
-ar9300_load_nf(ah, nf_buf);
-
+
+ret = ar9300_load_nf(ah, nf_buf);
/* start NF calibration, without updating BB NF register*/
-ar9300_start_nf_cal(ah);
+ar9300_start_nf_cal(ah);
+
+/*
+ * If we failed the NF cal then tell the upper layer that we
+ * failed so we can do a full reset
+ */
+if (! ret)
+return AH_FALSE;
}
}
return AH_TRUE;
@@ -4479,6 +4487,7 @@ First_NFCal(struct ath_hal *ah, HAL_CHANNEL_INTERNAL *
ar9300_reset_nf_hist_buff(ah, ichan);
ar9300_get_nf_hist_base(ah, ichan, is_scan, nf_buf);
ar9300_load_nf(ah, nf_buf);
+/* XXX TODO: handle failure from load_nf */
stats = 0;
} else {
stats = 1;
@@ -5303,6 +5312,7 @@ ar9300_reset(struct ath_hal *ah, HAL_OPMODE opmode, st
/* XXX FreeBSD is ichan appropariate? It was curchan.. */
ar9300_get_nf_hist_base(ah, ichan, is_scan, nf_buf);
ar9300_load_nf(ah, nf_buf);
+/* XXX TODO: handle NF load failure */
if (nf_hist_buff_reset == 1)
{
nf_hist_buff_reset = 0;
Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_cal.c
==
---
svn commit: r334848 - in head/sys/dev/ath/ath_hal: ar5212 ar5416
Author: adrian Date: Fri Jun 8 18:15:23 2018 New Revision: 334848 URL: https://svnweb.freebsd.org/changeset/base/334848 Log: [ath_hal] Don't do ANI processing if we've reset. If we've reset then we can't trust the current state of the ANI tracking, so just wait until next time. Tested: * AR5424, STA mode (2GHz) Modified: head/sys/dev/ath/ath_hal/ar5212/ar5212_ani.c head/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c Modified: head/sys/dev/ath/ath_hal/ar5212/ar5212_ani.c == --- head/sys/dev/ath/ath_hal/ar5212/ar5212_ani.cFri Jun 8 18:09:19 2018(r334847) +++ head/sys/dev/ath/ath_hal/ar5212/ar5212_ani.cFri Jun 8 18:15:23 2018(r334848) @@ -1000,6 +1000,9 @@ ar5212AniPoll(struct ath_hal *ah, const struct ieee802 ahp->ah_stats.ast_ani_lneg++; /* restart ANI period if listenTime is invalid */ ar5212AniRestart(ah, aniState); + + /* Don't do any further ANI processing here */ + return; } /* XXX beware of overflow? */ aniState->listenTime += listenTime; Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c == --- head/sys/dev/ath/ath_hal/ar5416/ar5416_ani.cFri Jun 8 18:09:19 2018(r334847) +++ head/sys/dev/ath/ath_hal/ar5416/ar5416_ani.cFri Jun 8 18:15:23 2018(r334848) @@ -950,6 +950,9 @@ ar5416AniPoll(struct ath_hal *ah, const struct ieee802 HALDEBUG(ah, HAL_DEBUG_ANI, "%s: invalid listenTime\n", __func__); ar5416AniRestart(ah, aniState); + + /* Don't do any further processing */ + return; } /* XXX beware of overflow? */ aniState->listenTime += listenTime; ___ 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: r334847 - head/sys/dev/hwpmc
Author: mmacy Date: Fri Jun 8 18:09:19 2018 New Revision: 334847 URL: https://svnweb.freebsd.org/changeset/base/334847 Log: hwpmc: retire never completed xscale support hwpmc xscale support is not actually functional and the architecture is well past its shelf life. Deleted: head/sys/dev/hwpmc/hwpmc_xscale.c ___ 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: r334846 - head/share/man/man4
Author: markj Date: Fri Jun 8 17:55:06 2018 New Revision: 334846 URL: https://svnweb.freebsd.org/changeset/base/334846 Log: Correct the list of supported drivers. - bnxt(4) is supported via iflib. - mlx4en(4) support has not yet been committed. Modified: head/share/man/man4/netdump.4 Modified: head/share/man/man4/netdump.4 == --- head/share/man/man4/netdump.4 Fri Jun 8 17:41:49 2018 (r334845) +++ head/share/man/man4/netdump.4 Fri Jun 8 17:55:06 2018 (r334846) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 17, 2018 +.Dd June 8, 2018 .Dt NETDUMP 4 .Os .Sh NAME @@ -99,12 +99,12 @@ message to the server. The following network drivers support netdump: .Xr alc 4 , .Xr bge 4 , +.Xr bnxt 4 , .Xr bxe 4 , .Xr cxgb 4 , .Xr em 4 , .Xr igb 4 , .Xr ix 4 , -.Xr mlx4en 4 , .Xr re 4 , .Xr vtnet 4 . .Sh SYSCTL VARIABLES ___ 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: r334777 - head/sys/compat/linuxkpi/common/include/linux
On 06/08/18 18:51, Ian Lepore wrote: Will this be a problem on i386, where timespec contains a 32-bit time_t? I think it's the only remaining arch with 32-bit time_t. The LinuxKPI has no need for 64-bit time. These defines are currently only used for debug printouts in drm-next-kmod. --HPS ___ 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: r334845 - head/sys/dev/hwpmc
Author: mmacy
Date: Fri Jun 8 17:41:49 2018
New Revision: 334845
URL: https://svnweb.freebsd.org/changeset/base/334845
Log:
hwpmc: update files missed by r334827
Modified:
head/sys/dev/hwpmc/hwpmc_e500.c
head/sys/dev/hwpmc/hwpmc_mips.c
head/sys/dev/hwpmc/hwpmc_mpc7xxx.c
head/sys/dev/hwpmc/hwpmc_ppc970.c
Modified: head/sys/dev/hwpmc/hwpmc_e500.c
==
--- head/sys/dev/hwpmc/hwpmc_e500.c Fri Jun 8 17:38:28 2018
(r334844)
+++ head/sys/dev/hwpmc/hwpmc_e500.c Fri Jun 8 17:41:49 2018
(r334845)
@@ -565,13 +565,14 @@ e500_release_pmc(int cpu, int ri, struct pmc *pmc)
}
static int
-e500_intr(int cpu, struct trapframe *tf)
+e500_intr(struct trapframe *tf)
{
- int i, error, retval;
+ int i, error, retval, cpu;
uint32_t config;
struct pmc *pm;
struct powerpc_cpu *pac;
+ cpu = curcpu;
KASSERT(cpu >= 0 && cpu < pmc_cpu_max(),
("[powerpc,%d] out of range CPU %d", __LINE__, cpu));
@@ -607,8 +608,7 @@ e500_intr(int cpu, struct trapframe *tf)
continue;
/* Stop the counter if logging fails. */
- error = pmc_process_interrupt(cpu, PMC_HR, pm, tf,
- TRAPF_USERMODE(tf));
+ error = pmc_process_interrupt(PMC_HR, pm, tf);
if (error != 0)
e500_stop_pmc(cpu, i);
Modified: head/sys/dev/hwpmc/hwpmc_mips.c
==
--- head/sys/dev/hwpmc/hwpmc_mips.c Fri Jun 8 17:38:28 2018
(r334844)
+++ head/sys/dev/hwpmc/hwpmc_mips.c Fri Jun 8 17:41:49 2018
(r334845)
@@ -252,15 +252,16 @@ mips_release_pmc(int cpu, int ri, struct pmc *pmc)
}
static int
-mips_pmc_intr(int cpu, struct trapframe *tf)
+mips_pmc_intr(struct trapframe *tf)
{
int error;
- int retval, ri;
+ int retval, ri, cpu;
struct pmc *pm;
struct mips_cpu *pc;
uint32_t r0, r2;
pmc_value_t r;
+ cpu = curcpu;
KASSERT(cpu >= 0 && cpu < pmc_cpu_max(),
("[mips,%d] CPU %d out of range", __LINE__, cpu));
Modified: head/sys/dev/hwpmc/hwpmc_mpc7xxx.c
==
--- head/sys/dev/hwpmc/hwpmc_mpc7xxx.c Fri Jun 8 17:38:28 2018
(r334844)
+++ head/sys/dev/hwpmc/hwpmc_mpc7xxx.c Fri Jun 8 17:41:49 2018
(r334845)
@@ -660,13 +660,14 @@ mpc7xxx_release_pmc(int cpu, int ri, struct pmc *pmc)
}
static int
-mpc7xxx_intr(int cpu, struct trapframe *tf)
+mpc7xxx_intr(struct trapframe *tf)
{
- int i, error, retval;
+ int i, error, retval, cpu;
uint32_t config;
struct pmc *pm;
struct powerpc_cpu *pac;
+ cpu = curcpu;
KASSERT(cpu >= 0 && cpu < pmc_cpu_max(),
("[powerpc,%d] out of range CPU %d", __LINE__, cpu));
Modified: head/sys/dev/hwpmc/hwpmc_ppc970.c
==
--- head/sys/dev/hwpmc/hwpmc_ppc970.c Fri Jun 8 17:38:28 2018
(r334844)
+++ head/sys/dev/hwpmc/hwpmc_ppc970.c Fri Jun 8 17:41:49 2018
(r334845)
@@ -479,13 +479,14 @@ ppc970_write_pmc(int cpu, int ri, pmc_value_t v)
}
static int
-ppc970_intr(int cpu, struct trapframe *tf)
+ppc970_intr(struct trapframe *tf)
{
struct pmc *pm;
struct powerpc_cpu *pac;
uint32_t config;
- int i, error, retval;
+ int i, error, retval, cpu;
+ cpu = curcpu;
KASSERT(cpu >= 0 && cpu < pmc_cpu_max(),
("[powerpc,%d] out of range CPU %d", __LINE__, 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: r334844 - in head: cddl/contrib/opensolaris/cmd/zdb cddl/contrib/opensolaris/cmd/zpool cddl/contrib/opensolaris/cmd/ztest cddl/contrib/opensolaris/lib/libzfs/common cddl/contrib/opensol...
Author: sef
Date: Fri Jun 8 17:38:28 2018
New Revision: 334844
URL: https://svnweb.freebsd.org/changeset/base/334844
Log:
This originated from ZFS On Linux, as
https://github.com/zfsonlinux/zfs/commit/d4a72f23863382bdf6d0ae33196f5b5decbc48fd
During scans (scrubs or resilvers), it sorts the blocks in each transaction
group by block offset; the result can be a significant improvement. (On my
test system just now, which I put some effort to introduce fragmentation into
the pool since I set it up yesterday, a scrub went from 1h2m to 33.5m with the
changes.) I've seen similar rations on production systems.
Approved by: Alexander Motin
Obtained from:ZFS On Linux
Relnotes: Yes (improved scrub performance, with tunables)
Differential Revision:https://reviews.freebsd.org/D15562
Modified:
head/cddl/contrib/opensolaris/cmd/zdb/zdb.c
head/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c
head/cddl/contrib/opensolaris/cmd/ztest/ztest.c
head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c
head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
head/cddl/contrib/opensolaris/lib/libzpool/common/taskq.c
head/sys/cddl/compat/opensolaris/kern/opensolaris_taskq.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/range_tree.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/arc.h
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_scan.h
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/range_tree.h
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_disk.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_indirect.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_missing.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_root.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c
head/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h
head/sys/cddl/contrib/opensolaris/uts/common/sys/taskq.h
Modified: head/cddl/contrib/opensolaris/cmd/zdb/zdb.c
==
--- head/cddl/contrib/opensolaris/cmd/zdb/zdb.c Fri Jun 8 17:37:49 2018
(r334843)
+++ head/cddl/contrib/opensolaris/cmd/zdb/zdb.c Fri Jun 8 17:38:28 2018
(r334844)
@@ -2281,14 +2281,14 @@ dump_dir(objset_t *os)
object_count++;
}
- ASSERT3U(object_count, ==, usedobjs);
-
(void) printf("\n");
if (error != ESRCH) {
(void) fprintf(stderr, "dmu_object_next() = %d\n", error);
abort();
}
+
+ ASSERT3U(object_count, ==, usedobjs);
}
static void
@@ -2788,6 +2788,7 @@ zdb_blkptr_done(zio_t *zio)
mutex_enter(>spa_scrub_lock);
spa->spa_scrub_inflight--;
+ spa->spa_load_verify_ios--;
cv_broadcast(>spa_scrub_io_cv);
if (ioerr && !(zio->io_flags & ZIO_FLAG_SPECULATIVE)) {
@@ -2859,9 +2860,10 @@ zdb_blkptr_cb(spa_t *spa, zilog_t *zilog, const blkptr
flags |= ZIO_FLAG_SPECULATIVE;
mutex_enter(>spa_scrub_lock);
- while (spa->spa_scrub_inflight > max_inflight)
+ while (spa->spa_load_verify_ios > max_inflight)
cv_wait(>spa_scrub_io_cv, >spa_scrub_lock);
spa->spa_scrub_inflight++;
+ spa->spa_load_verify_ios++;
mutex_exit(>spa_scrub_lock);
zio_nowait(zio_read(NULL, spa, bp, abd, size,
Modified: head/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c
Re: svn commit: r334708 - head/sys/kern
On Thu, Jun 07, 2018 at 11:02:29PM -0700, Ryan Libby wrote:
> On Thu, Jun 7, 2018 at 10:03 PM, Mateusz Guzik wrote:
> > On Fri, Jun 8, 2018 at 6:29 AM, Ryan Libby wrote:
> >>
> >> On Thu, Jun 7, 2018 at 8:32 PM, Mark Johnston wrote:
> >> > On Wed, Jun 06, 2018 at 05:03:11PM +0300, Konstantin Belousov wrote:
> >> >> On Wed, Jun 06, 2018 at 12:57:12PM +, Justin Hibbits wrote:
> >> >> > Author: jhibbits
> >> >> > Date: Wed Jun 6 12:57:11 2018
> >> >> > New Revision: 334708
> >> >> > URL: https://svnweb.freebsd.org/changeset/base/334708
> >> >> >
> >> >> > Log:
> >> >> > Add a memory barrier after taking a reference on the vnode holdcnt
> >> >> > in _vhold
> >> >> >
> >> >> > This is needed to avoid a race between the VNASSERT() below, and
> >> >> > another
> >> >> > thread updating the VI_FREE flag, on weakly-ordered architectures.
> >> >> >
> >> >> > On a 72-thread POWER9, without this barrier a 'make -j72
> >> >> > buildworld' would
> >> >> > panic on the assert regularly.
> >> >> >
> >> >> > It may be possible to use a weaker barrier, and I'll investigate
> >> >> > that once
> >> >> > all stability issues are worked out on POWER9.
> >> >> >
> >> >> > Modified:
> >> >> > head/sys/kern/vfs_subr.c
> >> >> >
> >> >> > Modified: head/sys/kern/vfs_subr.c
> >> >> >
> >> >> > ==
> >> >> > --- head/sys/kern/vfs_subr.cWed Jun 6 10:46:24 2018
> >> >> > (r334707)
> >> >> > +++ head/sys/kern/vfs_subr.cWed Jun 6 12:57:11 2018
> >> >> > (r334708)
> >> >> > @@ -2807,6 +2807,9 @@ _vhold(struct vnode *vp, bool locked)
> >> >> > CTR2(KTR_VFS, "%s: vp %p", __func__, vp);
> >> >> > if (!locked) {
> >> >> > if (refcount_acquire_if_not_zero(>v_holdcnt)) {
> >> >> > +#if !defined(__amd64__) && !defined(__i386__)
> >> >> > + mb();
> >> >> > +#endif
> >> >> > VNASSERT((vp->v_iflag & VI_FREE) == 0, vp,
> >> >> > ("_vhold: vnode with holdcnt is free"));
> >> >> > return;
> >> >> First, mb() must not be used in the FreeBSD code at all.
> >> >> Look at atomic_thread_fenceXXX(9) KPI.
> >> >>
> >> >> Second, you need the reciprocal fence between clearing of VI_FREE and
> >> >> refcount_acquire(), otherwise the added barrier is nop. Most likely,
> >> >> you got away with it because there is a mutex unlock between clearing
> >> >> of VI_FREE and acquire, which release semantic you abused.
> >> >
> >> > I note that vnlru_free_locked() clears VI_FREE and increments v_holdcnt
> >> > without an intervening release fence. At this point the caller has not
> >> > purged the vnode from the name cache, so it seems possible that the
> >> > panicking thread observed the two stores out of order. In particular, it
> >> > seems to me that the patch below is necessary, but possibly (probably?)
> >> > not sufficient:
> >>
> >> Mark, Justin, and I looked at this.
> >>
> >> I think that the VNASSERT itself is not quite valid, since it is
> >> checking the value of v_iflag without the vnode interlock held (and
> >> without the vop lock also). If the rule is that we normally need the
> >> vnode interlock to check VI_FREE, then I don't think that possible
> >> reordering between the refcount_acquire and VI_FREE clearing in
> >> vnlru_free_locked is necessarily a problem in production.
> >
> >
> > Checking it without any locks is perfectly valid in this case. It is done
> > after v_holdcnt gets bumped from a non-zero value. So at that time it
> > is at least two. Of course that result is stale as an arbitrary number of
> > other threads could have bumped and dropped the ref past that point.
> > The minimum value is 1 since we hold the ref. But this means the
> > vnode must not be on the free list and that's what the assertion is
> > verifying.
> >
> > The problem is indeed lack of ordering against the code clearing the
> > flag for the case where 2 threads to vhold and one does the 0->1
> > transition.
> >
> > That said, the fence is required for the assertion to work.
> >
>
> Yeah, I agree with this logic. What I mean is that reordering between
> v_holdcnt 0->1 and v_iflag is normally settled by the release and
> acquisition of the vnode interlock, which we are supposed to hold for
> v_*i*flag. A quick scan seems to show all of the checks of VI_FREE that
> are not asserts do hold the vnode interlock. So, I'm just saying that I
> don't think the possible reordering affects them.
But do we know that only VI_FREE checks are affected ?
My concern is that users of _vhold() rely on seeing up to date state of the
vnode, and VI_FREE is only an example of the problem. Most likely, the
code which fetched the vnode pointer before _vhold() call, should guarantee
visibility.
>
> >>
> >>
> >> It might just be that unlocked assertions about v_iflag actually need
> >> additional synchronization (although it would be a little unfortunate to
> >> add
svn commit: r334843 - head/sys/netinet
Author: mmacy
Date: Fri Jun 8 17:37:49 2018
New Revision: 334843
URL: https://svnweb.freebsd.org/changeset/base/334843
Log:
avoid 'tcp_outflags defined but not used'
Modified:
head/sys/netinet/tcp_fsm.h
head/sys/netinet/tcp_output.c
Modified: head/sys/netinet/tcp_fsm.h
==
--- head/sys/netinet/tcp_fsm.h Fri Jun 8 17:37:43 2018(r334842)
+++ head/sys/netinet/tcp_fsm.h Fri Jun 8 17:37:49 2018(r334843)
@@ -78,27 +78,8 @@
#defineTCPS_HAVERCVDFIN(s) \
((s) == TCPS_CLOSE_WAIT || ((s) >= TCPS_CLOSING && (s) != TCPS_FIN_WAIT_2))
-#ifdef TCPOUTFLAGS
-/*
- * Flags used when sending segments in tcp_output. Basic flags (TH_RST,
- * TH_ACK,TH_SYN,TH_FIN) are totally determined by state, with the proviso
- * that TH_FIN is sent only if all data queued for output is included in the
- * segment.
- */
-static u_char tcp_outflags[TCP_NSTATES] = {
- TH_RST|TH_ACK, /* 0, CLOSED */
- 0, /* 1, LISTEN */
- TH_SYN, /* 2, SYN_SENT */
- TH_SYN|TH_ACK, /* 3, SYN_RECEIVED */
- TH_ACK, /* 4, ESTABLISHED */
- TH_ACK, /* 5, CLOSE_WAIT */
- TH_FIN|TH_ACK, /* 6, FIN_WAIT_1 */
- TH_FIN|TH_ACK, /* 7, CLOSING */
- TH_FIN|TH_ACK, /* 8, LAST_ACK */
- TH_ACK, /* 9, FIN_WAIT_2 */
- TH_ACK, /* 10, TIME_WAIT */
-};
-#endif
+
+extern u_char tcp_outflags[TCP_NSTATES];
#ifdef KPROF
inttcp_acounts[TCP_NSTATES][PRU_NREQ];
Modified: head/sys/netinet/tcp_output.c
==
--- head/sys/netinet/tcp_output.c Fri Jun 8 17:37:43 2018
(r334842)
+++ head/sys/netinet/tcp_output.c Fri Jun 8 17:37:49 2018
(r334843)
@@ -169,6 +169,26 @@ hhook_run_tcp_est_out(struct tcpcb *tp, struct tcphdr
#endif
/*
+ * Flags used when sending segments in tcp_output. Basic flags (TH_RST,
+ * TH_ACK,TH_SYN,TH_FIN) are totally determined by state, with the proviso
+ * that TH_FIN is sent only if all data queued for output is included in the
+ * segment.
+ */
+u_char tcp_outflags[TCP_NSTATES] = {
+ TH_RST|TH_ACK, /* 0, CLOSED */
+ 0, /* 1, LISTEN */
+ TH_SYN, /* 2, SYN_SENT */
+ TH_SYN|TH_ACK, /* 3, SYN_RECEIVED */
+ TH_ACK, /* 4, ESTABLISHED */
+ TH_ACK, /* 5, CLOSE_WAIT */
+ TH_FIN|TH_ACK, /* 6, FIN_WAIT_1 */
+ TH_FIN|TH_ACK, /* 7, CLOSING */
+ TH_FIN|TH_ACK, /* 8, LAST_ACK */
+ TH_ACK, /* 9, FIN_WAIT_2 */
+ TH_ACK, /* 10, TIME_WAIT */
+};
+
+/*
* CC wrapper hook functions
*/
static void inline
___
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: r334842 - head/sys/netinet
Author: mmacy Date: Fri Jun 8 17:37:43 2018 New Revision: 334842 URL: https://svnweb.freebsd.org/changeset/base/334842 Log: hpts: remove redundant decl breaking gcc build Modified: head/sys/netinet/tcp_hpts.c Modified: head/sys/netinet/tcp_hpts.c == --- head/sys/netinet/tcp_hpts.c Fri Jun 8 15:05:26 2018(r334841) +++ head/sys/netinet/tcp_hpts.c Fri Jun 8 17:37:43 2018(r334842) @@ -198,7 +198,6 @@ static void tcp_init_hptsi(void *st); int32_t tcp_min_hptsi_time = DEFAULT_MIN_SLEEP; static int32_t tcp_hpts_callout_skip_swi = 0; -SYSCTL_DECL(_net_inet_tcp); SYSCTL_NODE(_net_inet_tcp, OID_AUTO, hpts, CTLFLAG_RW, 0, "TCP Hpts controls"); #definetimersub(tvp, uvp, vvp) \ ___ 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: r334804 - in head/sys: kern modules/tcp modules/tcp/rack netinet netinet/tcp_stacks sys
On Fri, Jun 8, 2018 at 12:37 PM, hiren panchasara < hi...@strugglingcoder.info> wrote: > ps: I know we are not killing the default stack as of yet and just > stopping active maintenance of it but just wanted to raise these > (probably obvious) points. We absolutely are not stopping active maintenance of the "default" (soon to be renamed "base") TCP stack. RACK is an alternative which might be useful for some people. But, there is no suggestion that we should in any way change the priority we give to maintaining the base TCP stack anytime in the near future. Jonathan ___ 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: r334777 - head/sys/compat/linuxkpi/common/include/linux
On Thu, 2018-06-07 at 11:41 +, Hans Petter Selasky wrote: > Author: hselasky > Date: Thu Jun 7 11:41:42 2018 > New Revision: 334777 > URL: https://svnweb.freebsd.org/changeset/base/334777 > > Log: > Wrap timespec64 into timespec in the LinuxKPI. > > Submitted by: Johannes Lundberg > MFC after: 1 week > Sponsored by: Mellanox Technologies > Sponsored by: Limelight Networks > > Modified: > head/sys/compat/linuxkpi/common/include/linux/ktime.h > head/sys/compat/linuxkpi/common/include/linux/time.h > > Modified: head/sys/compat/linuxkpi/common/include/linux/ktime.h > = > = > --- head/sys/compat/linuxkpi/common/include/linux/ktime.h Thu > Jun 7 11:40:13 2018 (r334776) > +++ head/sys/compat/linuxkpi/common/include/linux/ktime.h Thu > Jun 7 11:41:42 2018 (r334777) > @@ -159,6 +159,7 @@ timeval_to_ktime(struct timeval tv) > } > > #define ktime_to_timespec(kt) ns_to_timespec(k > t) > +#define ktime_to_timespec64(kt) ns_to_timespec > (kt) > #define ktime_to_timeval(kt)ns_to_timeval(kt) > #define ktime_to_ns(kt) (kt) > > > Modified: head/sys/compat/linuxkpi/common/include/linux/time.h > = > = > --- head/sys/compat/linuxkpi/common/include/linux/time.h Thu > Jun 7 11:40:13 2018 (r334776) > +++ head/sys/compat/linuxkpi/common/include/linux/time.h Thu > Jun 7 11:41:42 2018 (r334777) > @@ -35,6 +35,8 @@ > #define USEC_PER_MSEC 1000L > #define USEC_PER_SEC100L > > +#define timespec64 timespec > + > #include > #include Will this be a problem on i386, where timespec contains a 32-bit time_t? I think it's the only remaining arch with 32-bit time_t. -- Ian ___ 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: r334804 - in head/sys: kern modules/tcp modules/tcp/rack netinet netinet/tcp_stacks sys
On 06/07/18 at 08:07P, Matthew Macy wrote:
> >
> > Okay. I believe there might be situations where we may want to still
> > keep the 'default' stack alive. I know Windows doesn't yet use RACK when
> > rtt is lesser than 10ms (or something like that), as an example.
> >
>
> Is there any reason RACK wouldn't work for tracking 10us RTTs? If we
> know we know the peer doesn't do delack or have enough data in flight
> and the other stack doesn't have broken LRO, could we just use this in
> lieu of high resolution timestamps?
I believe the issue is both ends having fine-grained timers for RACK to
be able to do the right thing. If timer resolution ends up being coarser
than rtt, just depending on rack may be problematic. I know 10ms is
doable on most systems but just using this as an example that we
probably want non-rack ('default') stack to be around a little longer
and possibly with the enhancements that we can easily extract out to be
shared among all the stacks.
Also RACK needing pacing which requires but more CPU so question for us
could be that do we want to keep the 'default' stack around for machines
that can't take that extra CPU hit.
SACK is inefficient in default stack and PRR could be super useful as
"psuedo" pacing mechanism and could help recover faster but at the end
of the day it all depends on someone with time/energy/motivation to
maintain the 'default' stack with all shiny things that appear in
non-default stacks.
cheers,
Hiren
ps: I know we are not killing the default stack as of yet and just
stopping active maintenance of it but just wanted to raise these
(probably obvious) points.
pgpAd9US7XWHW.pgp
Description: PGP signature
Re: svn commit: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys
> The fact that our NMI handler isn't re-entrant can lead to subtle > problems. If while executing the NMI handler we hit a dtrace > probe or DDB breakpoint, the iret executed upon return to the handler > will re-enable NMIs. Then, if a second NMI arrives before the handler > for the first has returned, the trapframe will be clobbered. Did you > rule out an issue like this? No, but it happened instantly on all CPUs an a non-debug kernel 100% of the time after I changed pmc_process_interrupt earlier this week. My voodoo fix now avoids it. What you're describing sounds episodic and doesn't sound like it would be fixed / worked around by my change. -M ___ 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: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys
On Fri, Jun 08, 2018 at 09:07:53AM -0700, Matthew Macy wrote: > On Fri, Jun 8, 2018 at 07:35 Mark Johnston wrote: > > > On Fri, Jun 08, 2018 at 04:58:03AM +, Matt Macy wrote: > > > Author: mmacy > > > Date: Fri Jun 8 04:58:03 2018 > > > New Revision: 334827 > > > URL: https://svnweb.freebsd.org/changeset/base/334827 > > > > > > Log: > > > hwpmc: simplify calling convention for hwpmc interrupt handling > > > > > > pmc_process_interrupt takes 5 arguments when only 3 are needed. > > > cpu is always available in curcpu and inuserspace can always be > > > derived from the passed trapframe. > > > > > > While facially a reasonable cleanup this change was motivated > > > by the need to workaround a compiler bug. > > > > What is the compiler bug? Do you have disassembly of the subroutines in > > question? > > > > We talked about this online. Not in any more detail than is present in the commit message. > How would that help without engaging in a huge > diversion in to the toolchain? If you can provide C code and point to the bug in the disassembly, that should be enough for an LLVM bug report. I don't think that's a huge diversion. > There is nothing wrong with the C code so I > resorted to a voodoo fix to get hwpmc working again. If you're volunteering > mjg or I or you can disassemble the code prior to my change. I'll volunteer to look at the disassembly, sure. "Nothing wrong with the C code" isn't the bar for claiming a compiler bug though. The fact that our NMI handler isn't re-entrant can lead to subtle problems. If while executing the NMI handler we hit a dtrace probe or DDB breakpoint, the iret executed upon return to the handler will re-enable NMIs. Then, if a second NMI arrives before the handler for the first has returned, the trapframe will be clobbered. Did you rule out an issue like this? ___ 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: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys
On Fri, Jun 8, 2018 at 07:35 Mark Johnston wrote: > On Fri, Jun 08, 2018 at 04:58:03AM +, Matt Macy wrote: > > Author: mmacy > > Date: Fri Jun 8 04:58:03 2018 > > New Revision: 334827 > > URL: https://svnweb.freebsd.org/changeset/base/334827 > > > > Log: > > hwpmc: simplify calling convention for hwpmc interrupt handling > > > > pmc_process_interrupt takes 5 arguments when only 3 are needed. > > cpu is always available in curcpu and inuserspace can always be > > derived from the passed trapframe. > > > > While facially a reasonable cleanup this change was motivated > > by the need to workaround a compiler bug. > > What is the compiler bug? Do you have disassembly of the subroutines in > question? > We talked about this online. How would that help without engaging in a huge diversion in to the toolchain? There is nothing wrong with the C code so I resorted to a voodoo fix to get hwpmc working again. If you're volunteering mjg or I or you can disassemble the code prior to my change. > -M > > > > > core2_intr(cpu, tf) -> > > pmc_process_interrupt(cpu, ring, pmc, tf, inuserspace) -> > > pmc_add_sample(cpu, ring, pm, tf, inuserspace) > > > > In the process of optimizing the tail call the tf pointer was getting > > clobbered: > > > > (kgdb) up > > at /storage/mmacy/devel/freebsd/sys/dev/hwpmc/hwpmc_mod.c:4709 > > 4709 > pmc_save_kernel_callchain(ps->ps_pc, > > (kgdb) up > > 1205error = pmc_process_interrupt(cpu, PMC_HR, pm, > tf, > > > > resulting in a crash in pmc_save_kernel_callchain. > ___ 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: r334841 - head/share/skel
Author: brd
Date: Fri Jun 8 15:05:26 2018
New Revision: 334841
URL: https://svnweb.freebsd.org/changeset/base/334841
Log:
Simplify this Makefile.
Approved by: bapt (mentor)
Modified:
head/share/skel/Makefile
Modified: head/share/skel/Makefile
==
--- head/share/skel/MakefileFri Jun 8 14:36:10 2018(r334840)
+++ head/share/skel/MakefileFri Jun 8 15:05:26 2018(r334841)
@@ -1,13 +1,10 @@
# @(#)Makefile8.1 (Berkeley) 6/8/93
# $FreeBSD$
-FILESGROUPS= FILES1 FILES2
-FILES1=dot.cshrc dot.login dot.login_conf dot.mailrc
dot.profile \
- dot.shrc
-FILES2=dot.mail_aliases
-FILES1DIR= ${SHAREDIR}/skel
-FILES2DIR= ${SHAREDIR}/skel
-FILES1MODE=0644
-FILES2MODE=0600
+FILES= dot.cshrc dot.login dot.login_conf dot.mailrc dot.profile \
+ dot.shrc dot.mail_aliases
+FILESDIR= ${SHAREDIR}/skel
+FILESMODE= 0644
+FILESMODE_dot.mail_aliases=0600
.include
___
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: r334814 - head/sbin/dump
On Fri, Jun 08, 2018 at 10:08:25AM -0400, Ed Maste wrote:
> On 7 June 2018 at 16:49, Kirk McKusick wrote:
> > Author: mckusick
> > Date: Thu Jun 7 20:49:01 2018
> > New Revision: 334814
> > URL: https://svnweb.freebsd.org/changeset/base/334814
> >
> > Log:
> > Ensure proper initialization of superblock.
> >
> ...
> > --- head/sbin/dump/main.c Thu Jun 7 19:57:55 2018(r334813)
> > +++ head/sbin/dump/main.c Thu Jun 7 20:49:01 2018(r334814)
> > @@ -433,6 +433,7 @@ main(int argc, char *argv[])
> > msgtail("to %s\n", tape);
> >
> > sync();
> > + sblock = NULL;
> > if ((ret = sbget(diskfd, , -1)) != 0) {
>
> sblock is initialized to NULL at the beginning of ffs_sbget, so I'm
I saw that under lldb when I checked the assembler code.
> not really sure what's happening here.
ditto. But another data point this morning. I ran stock dump
on a spinning rust portable drive I have with me today. It worked fine.
the disk in the laptop is a SSD SATA. Another data point , the
bug failed to manifest until my system had been running a few minutes.
e.g. it did the demo mode failure when I tried to show it to jhibbits...
I will boot from the spinning rust and fsck the ssd again. @dteske
and I thoroughly fsck_ufs fsck_ffs etc. yesterday but I'll try again
today from another root disk. That's an obvious one.
> ___
> svn-src-...@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"
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys
On Fri, Jun 08, 2018 at 04:58:03AM +, Matt Macy wrote: > Author: mmacy > Date: Fri Jun 8 04:58:03 2018 > New Revision: 334827 > URL: https://svnweb.freebsd.org/changeset/base/334827 > > Log: > hwpmc: simplify calling convention for hwpmc interrupt handling > > pmc_process_interrupt takes 5 arguments when only 3 are needed. > cpu is always available in curcpu and inuserspace can always be > derived from the passed trapframe. > > While facially a reasonable cleanup this change was motivated > by the need to workaround a compiler bug. What is the compiler bug? Do you have disassembly of the subroutines in question? > > core2_intr(cpu, tf) -> > pmc_process_interrupt(cpu, ring, pmc, tf, inuserspace) -> > pmc_add_sample(cpu, ring, pm, tf, inuserspace) > > In the process of optimizing the tail call the tf pointer was getting > clobbered: > > (kgdb) up > at /storage/mmacy/devel/freebsd/sys/dev/hwpmc/hwpmc_mod.c:4709 > 4709pmc_save_kernel_callchain(ps->ps_pc, > (kgdb) up > 1205error = pmc_process_interrupt(cpu, PMC_HR, pm, tf, > > resulting in a crash in pmc_save_kernel_callchain. ___ 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: r334814 - head/sbin/dump
On Fri, Jun 8, 2018 at 10:08 AM, Ed Maste wrote:
> On 7 June 2018 at 16:49, Kirk McKusick wrote:
>> Author: mckusick
>> Date: Thu Jun 7 20:49:01 2018
>> New Revision: 334814
>> URL: https://svnweb.freebsd.org/changeset/base/334814
>>
>> Log:
>> Ensure proper initialization of superblock.
>>
> ...
>> --- head/sbin/dump/main.c Thu Jun 7 19:57:55 2018(r334813)
>> +++ head/sbin/dump/main.c Thu Jun 7 20:49:01 2018(r334814)
>> @@ -433,6 +433,7 @@ main(int argc, char *argv[])
>> msgtail("to %s\n", tape);
>>
>> sync();
>> + sblock = NULL;
>> if ((ret = sbget(diskfd, , -1)) != 0) {
>
> sblock is initialized to NULL at the beginning of ffs_sbget, so I'm
> not really sure what's happening here.
>
Diane just found possibly the real cause of the problem. dump.h is
included by almost every .c file, but defines variables, doesn't just
declare them. I think the real solution would be to define them in
main.c, or somewhere else, and just declare them in dump.h. Or if
they're truly only needed on a per-file basis, not as globals, they
could be marked static so there is no chance of conflict, and they're
pre-initialized to 0. The linker "might" merge them into the common
section, or might not, resulting in bizarre conflicts like what she's
seeing. Though, I'm surprised we're not seeing a linker error or
warning anyway.
- Justin
___
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: r334814 - head/sbin/dump
On 7 June 2018 at 16:49, Kirk McKusick wrote:
> Author: mckusick
> Date: Thu Jun 7 20:49:01 2018
> New Revision: 334814
> URL: https://svnweb.freebsd.org/changeset/base/334814
>
> Log:
> Ensure proper initialization of superblock.
>
...
> --- head/sbin/dump/main.c Thu Jun 7 19:57:55 2018(r334813)
> +++ head/sbin/dump/main.c Thu Jun 7 20:49:01 2018(r334814)
> @@ -433,6 +433,7 @@ main(int argc, char *argv[])
> msgtail("to %s\n", tape);
>
> sync();
> + sblock = NULL;
> if ((ret = sbget(diskfd, , -1)) != 0) {
sblock is initialized to NULL at the beginning of ffs_sbget, so I'm
not really sure what's happening here.
___
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: r334837 - head/usr.bin/grep
Author: kevans
Date: Fri Jun 8 12:58:55 2018
New Revision: 334837
URL: https://svnweb.freebsd.org/changeset/base/334837
Log:
bsdgrep(1): Evict character sequence that moved in
Reported by: trasz
Modified:
head/usr.bin/grep/file.c
Modified: head/usr.bin/grep/file.c
==
--- head/usr.bin/grep/file.cFri Jun 8 10:09:30 2018(r334836)
+++ head/usr.bin/grep/file.cFri Jun 8 12:58:55 2018(r334837)
@@ -113,7 +113,7 @@ grep_fgetln(struct file *f, struct parsec *pc)
return (bufpos);
}
- /* Look for a newline in the remaining part of the [6rbuffer */
+ /* Look for a newline in the remaining part of the buffer */
if ((p = memchr(bufpos, fileeol, bufrem)) != NULL) {
++p; /* advance over newline */
ret = bufpos;
___
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: r334617 - in head: . etc
On Thu, Jun 7, 2018, at 10:59 PM, Bryan Drewery wrote: > > > On Jun 4, 2018, at 11:17, Brad Davis wrote: > > > > Author: brd > > Date: Mon Jun 4 15:17:24 2018 > > New Revision: 334617 > > URL: https://svnweb.freebsd.org/changeset/base/334617 > > > > Log: > > Move /sys symlink creating out of etc/Makefile. > > > > This is prep for etc/Makefile going away. > > > > Approved by:bapt (mentor) > > > > Modified: > > head/Makefile.inc1 > > head/etc/Makefile > > > > Aside from other objections, I don’t think /Makefile nor > /Makefile.inc1> should “own” anything on the system and should only drive the > build or> other general targets for users to interact with. Please put this > into> something like /hier or better yet the existing directory > handling that> stuff /etc. (so a revert since simply moving everything to it > via a > rename or rewrite seems silly) I agree, I started creating a hier/ last night. Regards, Brad Davis ___ 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: r334617 - in head: . etc
On Thu, Jun 7, 2018, at 10:38 PM, Bryan Drewery wrote: > > > > On Jun 5, 2018, at 16:43, Brad Davis wrote: > > > > > > On Tue, Jun 5, 2018, at 1:07 PM, Renato Botelho wrote: > > > On 05/06/18 15:26, Konstantin Belousov wrote: > > > > On Tue, Jun 05, 2018 at 12:13:05PM -0600, Brad Davis wrote: > > > >> On Tue, Jun 5, 2018, at 10:46 AM, Konstantin Belousov wrote: > > > >>> I find it often very useful to do > > > >>> (cd src/etc/rc.d && make install) > > > >>> Same for defaults and several other directories which in fact > > > >>> contains> > > >>> non-editable content. Is this planned to keep > > > >>> working ? > > > >> > > > >> The short answer is, no. All rc.d scripts get moved to the src > > > >> of the program they start.> > > >> > > > >> That said, if there is a big need for this, we can see about > > > >> options to keep them working.> > > >> > > > >> What are you trying to accomplish when you do this? Just > > > >> verify the rc.d scripts match your src tree?> > > > > > > > I avoid mergemaster/etcupdate and whatever else. rc.d and > > > > /etc/rc,> > > > /etc/rc.subr /etc/rc.network are not suitable to etc, > > > > they are > > > > binaries> > > > provided by the project not for the user editing. > > > > > > > > When upgrading the host, esp. on HEAD, i usually refresh scripts > > > > by this> > > > procedure and avoid any editing and implied conflict > > > > resolution > > > > for real> > > > configs. > > > > > > > > Not being able to easily install clean copies of these scripts > > > > would> > > > be very inconvenient and time consuming. > > > > > > If I understood what Brad is saying, each rc.d script will be > > > installed> > > by the application it belongs to. So when it's installing > > > SSH it > > > will> > > also install /etc/rc.d/sshd and you will not need to deal with > > > rc.d> > > files on mergemaster anymore. > > > > > > Is it correct, Brad? > > > > Correct. > > > > This makes no sense. Many rc scripts, and other config files, have no> > “owner” outside of etc/... > > Please don’t kill etc/Makefile. This is going to be very > painful to deal> with downstream. I was wrong. We moved startup scripts under sbin/init. So this would be easy to merge. Regards, Brad Davis ___ 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: r334617 - in head: . etc
> On Jun 7, 2018, at 03:29, Alexey Dokuchaev wrote: > >> On Wed, Jun 06, 2018 at 01:02:25PM -0600, Brad Davis wrote: >>> On Wed, Jun 6, 2018, at 12:33 PM, Rodney W. Grimes wrote: >>> ... >>> So each installworld would wipe over the top of any localmod /etc/rc.d/ >>> and other stuff that mght exist? >>> One of the reasons that etc/Makefile is detached from Installword is so >>> that /etc does not get perturbuted unless specifically requested. >> >> Yes, this is by design. >> >> If people need custom tweaks for that stuff they should be upstreamed or >> moved into /usr/local/etc/rc.d as a custom startup script. > > This is rather questionable design to me. I don't consider my scripts > as binaries and like them in /etc/rc.d/ and managed via mergemaster -Fi. > Everything was perfectly fine with it. What exactly the problem you're > trying to solve here? For me the biggest selling point of FreeBSD has always been how configurable and customizable it has been (without modifying src). Especially the rc files and patterns of .local in /etc. > > ./danfe > ___ 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: r334830 - in head/sys: kern net vm
On 8 June 2018 at 01:31, Eitan Adler wrote:
> On 7 June 2018 at 22:40, Mateusz Guzik wrote:
>> Modified: head/sys/vm/uma_core.c
>> ==
>> --- head/sys/vm/uma_core.c Fri Jun 8 05:17:06 2018(r334829)
>> +++ head/sys/vm/uma_core.c Fri Jun 8 05:40:36 2018(r334830)
>> @@ -2257,7 +2257,8 @@ uma_zalloc_arg(uma_zone_t zone, void *udata, int flags
>> KASSERT(curthread->td_critnest == 0 || SCHEDULER_STOPPED(),
>> ("uma_zalloc_arg: called with spinlock or critical section
>> held"));
>> if (zone->uz_flags & UMA_ZONE_PCPU)
>> - MPASS((flags & M_ZERO) == 0);
>> + KASSERT((flags & M_ZERO) == 0, ("allocating from a pcpu zone
>> "
>> + "with M_ZERO passed"));
>
> After this I get a panic (inverted order)
>
> Panic: flags & MZERO @ uma_core.c line 2260
>
> fast_syscall_common
> amd64_syscall
> sys_ioctl
> kern_ioctl
> if_up
> in6_attach
> in6_update_ifa
> rtinit
> rtrequest1_fib
> uma_zalloc_arg
> zone_import
> zone_fetch_slab
> keg_fetch_slab
> keb_alloc_slab
> rtentry_zinit
> counter_u64_alloc
> uma_zalloc_arg
> ...
ofc, kgdb has an internal error trying to open the core.
--
Eitan Adler
___
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: r334830 - in head/sys: kern net vm
On 7 June 2018 at 22:40, Mateusz Guzik wrote:
> Modified: head/sys/vm/uma_core.c
> ==
> --- head/sys/vm/uma_core.c Fri Jun 8 05:17:06 2018(r334829)
> +++ head/sys/vm/uma_core.c Fri Jun 8 05:40:36 2018(r334830)
> @@ -2257,7 +2257,8 @@ uma_zalloc_arg(uma_zone_t zone, void *udata, int flags
> KASSERT(curthread->td_critnest == 0 || SCHEDULER_STOPPED(),
> ("uma_zalloc_arg: called with spinlock or critical section
> held"));
> if (zone->uz_flags & UMA_ZONE_PCPU)
> - MPASS((flags & M_ZERO) == 0);
> + KASSERT((flags & M_ZERO) == 0, ("allocating from a pcpu zone "
> + "with M_ZERO passed"));
After this I get a panic (inverted order)
Panic: flags & MZERO @ uma_core.c line 2260
fast_syscall_common
amd64_syscall
sys_ioctl
kern_ioctl
if_up
in6_attach
in6_update_ifa
rtinit
rtrequest1_fib
uma_zalloc_arg
zone_import
zone_fetch_slab
keg_fetch_slab
keb_alloc_slab
rtentry_zinit
counter_u64_alloc
uma_zalloc_arg
...
--
Eitan Adler
___
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: r334708 - head/sys/kern
On Thu, Jun 7, 2018 at 10:03 PM, Mateusz Guzik wrote:
> On Fri, Jun 8, 2018 at 6:29 AM, Ryan Libby wrote:
>>
>> On Thu, Jun 7, 2018 at 8:32 PM, Mark Johnston wrote:
>> > On Wed, Jun 06, 2018 at 05:03:11PM +0300, Konstantin Belousov wrote:
>> >> On Wed, Jun 06, 2018 at 12:57:12PM +, Justin Hibbits wrote:
>> >> > Author: jhibbits
>> >> > Date: Wed Jun 6 12:57:11 2018
>> >> > New Revision: 334708
>> >> > URL: https://svnweb.freebsd.org/changeset/base/334708
>> >> >
>> >> > Log:
>> >> > Add a memory barrier after taking a reference on the vnode holdcnt
>> >> > in _vhold
>> >> >
>> >> > This is needed to avoid a race between the VNASSERT() below, and
>> >> > another
>> >> > thread updating the VI_FREE flag, on weakly-ordered architectures.
>> >> >
>> >> > On a 72-thread POWER9, without this barrier a 'make -j72
>> >> > buildworld' would
>> >> > panic on the assert regularly.
>> >> >
>> >> > It may be possible to use a weaker barrier, and I'll investigate
>> >> > that once
>> >> > all stability issues are worked out on POWER9.
>> >> >
>> >> > Modified:
>> >> > head/sys/kern/vfs_subr.c
>> >> >
>> >> > Modified: head/sys/kern/vfs_subr.c
>> >> >
>> >> > ==
>> >> > --- head/sys/kern/vfs_subr.cWed Jun 6 10:46:24 2018
>> >> > (r334707)
>> >> > +++ head/sys/kern/vfs_subr.cWed Jun 6 12:57:11 2018
>> >> > (r334708)
>> >> > @@ -2807,6 +2807,9 @@ _vhold(struct vnode *vp, bool locked)
>> >> > CTR2(KTR_VFS, "%s: vp %p", __func__, vp);
>> >> > if (!locked) {
>> >> > if (refcount_acquire_if_not_zero(>v_holdcnt)) {
>> >> > +#if !defined(__amd64__) && !defined(__i386__)
>> >> > + mb();
>> >> > +#endif
>> >> > VNASSERT((vp->v_iflag & VI_FREE) == 0, vp,
>> >> > ("_vhold: vnode with holdcnt is free"));
>> >> > return;
>> >> First, mb() must not be used in the FreeBSD code at all.
>> >> Look at atomic_thread_fenceXXX(9) KPI.
>> >>
>> >> Second, you need the reciprocal fence between clearing of VI_FREE and
>> >> refcount_acquire(), otherwise the added barrier is nop. Most likely,
>> >> you got away with it because there is a mutex unlock between clearing
>> >> of VI_FREE and acquire, which release semantic you abused.
>> >
>> > I note that vnlru_free_locked() clears VI_FREE and increments v_holdcnt
>> > without an intervening release fence. At this point the caller has not
>> > purged the vnode from the name cache, so it seems possible that the
>> > panicking thread observed the two stores out of order. In particular, it
>> > seems to me that the patch below is necessary, but possibly (probably?)
>> > not sufficient:
>>
>> Mark, Justin, and I looked at this.
>>
>> I think that the VNASSERT itself is not quite valid, since it is
>> checking the value of v_iflag without the vnode interlock held (and
>> without the vop lock also). If the rule is that we normally need the
>> vnode interlock to check VI_FREE, then I don't think that possible
>> reordering between the refcount_acquire and VI_FREE clearing in
>> vnlru_free_locked is necessarily a problem in production.
>
>
> Checking it without any locks is perfectly valid in this case. It is done
> after v_holdcnt gets bumped from a non-zero value. So at that time it
> is at least two. Of course that result is stale as an arbitrary number of
> other threads could have bumped and dropped the ref past that point.
> The minimum value is 1 since we hold the ref. But this means the
> vnode must not be on the free list and that's what the assertion is
> verifying.
>
> The problem is indeed lack of ordering against the code clearing the
> flag for the case where 2 threads to vhold and one does the 0->1
> transition.
>
> That said, the fence is required for the assertion to work.
>
Yeah, I agree with this logic. What I mean is that reordering between
v_holdcnt 0->1 and v_iflag is normally settled by the release and
acquisition of the vnode interlock, which we are supposed to hold for
v_*i*flag. A quick scan seems to show all of the checks of VI_FREE that
are not asserts do hold the vnode interlock. So, I'm just saying that I
don't think the possible reordering affects them.
>>
>>
>> It might just be that unlocked assertions about v_iflag actually need
>> additional synchronization (although it would be a little unfortunate to
>> add synchronization only to INVARIANTS builds).
>>
>> >
>> >> Does the fence needed for the non-invariants case ?
>> >>
>> >> Fourth, doesn't v_usecount has the same issues WRT inactivation ?
>> >
>> > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
>> > index 286a871c3631..c97a8ba63612 100644
>> > --- a/sys/kern/vfs_subr.c
>> > +++ b/sys/kern/vfs_subr.c
>> > @@ -1018,6 +1018,7 @@ vnlru_free_locked(int count, struct vfsops
>> > *mnt_op)
>> > */
>> > freevnodes--;
>> > vp->v_iflag &= ~VI_FREE;
