Re: svn commit: r364038 - head/sys/dev/pci

[Kubilay Kocak]

On 8/08/2020 4:40 am, Alexander Motin wrote:

Author: mav
Date: Fri Aug  7 18:40:56 2020
New Revision: 364038
URL: https://svnweb.freebsd.org/changeset/base/364038

Log:
   Enable hw.pci.enable_aspm tunable by default.
   
   While effects on power saving is only a guess, effects on hot-plug are

   clearly visible.  Lets try to enable it and see what happen.
   
   MFC after:	3 months


Modified:
   head/sys/dev/pci/pci.c

Modified: head/sys/dev/pci/pci.c
==
--- head/sys/dev/pci/pci.c  Fri Aug  7 18:38:10 2020(r364037)
+++ head/sys/dev/pci/pci.c  Fri Aug  7 18:40:56 2020(r364038)
@@ -408,7 +408,7 @@ static int pci_enable_ari = 1;
  SYSCTL_INT(_hw_pci, OID_AUTO, enable_ari, CTLFLAG_RDTUN, _enable_ari,
  0, "Enable support for PCIe Alternative RID Interpretation");
  
-int pci_enable_aspm;

+int pci_enable_aspm = 1;
  SYSCTL_INT(_hw_pci, OID_AUTO, enable_aspm, CTLFLAG_RDTUN, _enable_aspm,
  0, "Enable support for PCIe Active State Power Management");
  
___

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"



relnotes: Yes?
___
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: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Kubilay Kocak]

On 16/01/2020 7:27 pm, Colin Percival wrote:

On 2020-01-15 21:07, Philip Paeps wrote:

On 2020-01-16 04:57:28 (+1000), Oliver Pinter wrote:

On Wednesday, January 15, 2020, Ben Woods  wrote:

   bsdinstall: Change "default" (first) Partitioning method to ZFS



Plus I miss from here the relontes tag.


I'm not sure if this merits a release notes entry but ... sure.

There is not actually a functional change here.  It's just a defaults change.


I'd say that a change in defaults is far more deserving of being mentioned
in the release notes than, say, adding a new feature.  Nobody will trip over
new features by mistake, but there's probably someone out there who is used
to holding down the Enter key in the installer and expects to get UFS.



+1 on changing the default. This doesn't preclude UFS systems or reduce 
choice (we value choice).


+0 on tweaking it or setting exceptions if and where necessary, as long 
as it doesn't result in more than minimal fragmentation between 
versions/archs/install types: this is also a POLA issue. I don't oin its 
own consider "4gb systems" as necessary.


+1 RELNOTES, we value POLA.

More things in RELNOTES not less
___
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: r356240 - head/sys/netinet

[Kubilay Kocak]

On 1/01/2020 5:58 am, Alexander Motin wrote:

Author: mav
Date: Tue Dec 31 18:58:29 2019
New Revision: 356240
URL: https://svnweb.freebsd.org/changeset/base/356240

Log:
   Relax locking of carp_forus().
   
   This fixes deadlock between CARP and bridge.  Bridge calls this function

   taking CARP lock while holding bridge lock.  Same time CARP tries to send
   its announcements via the bridge while holding CARP lock.
   
   Use of CARP_LOCK() here does not solve anything, since sc_addr is constant

   while race on sc_state is harmless and use of the lock does not close it.
   
   Reviewed by:	glebius

   MFC after:   2 weeks
   Sponsored by:iXsystems, Inc.

Modified:
   head/sys/netinet/ip_carp.c

Modified: head/sys/netinet/ip_carp.c
==
--- head/sys/netinet/ip_carp.c  Tue Dec 31 18:28:25 2019(r356239)
+++ head/sys/netinet/ip_carp.c  Tue Dec 31 18:58:29 2019(r356240)
@@ -1230,14 +1230,15 @@ carp_forus(struct ifnet *ifp, u_char *dhost)
  
  	CIF_LOCK(ifp->if_carp);

IFNET_FOREACH_CARP(ifp, sc) {
-   CARP_LOCK(sc);
+   /*
+* CARP_LOCK() is not here, since would protect nothing, but
+* cause deadlock with if_bridge, calling this under its lock.
+*/
if (sc->sc_state == MASTER && !bcmp(dhost, LLADDR(>sc_addr),
ETHER_ADDR_LEN)) {
-   CARP_UNLOCK(sc);
CIF_UNLOCK(ifp->if_carp);
return (1);
}
-   CARP_UNLOCK(sc);
}
CIF_UNLOCK(ifp->if_carp);
  
___

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"



Hi Alexander,

Is this a only-head-impacted fix, or does the issue impact stable/12,11 
too, warranting MFC ?

___
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: r355407 - head/sys/fs/tmpfs

[Kubilay Kocak]

On 5/12/2019 11:03 am, Konstantin Belousov wrote:

Author: kib
Date: Thu Dec  5 00:03:17 2019
New Revision: 355407
URL: https://svnweb.freebsd.org/changeset/base/355407


Could you elaborate on the why/rationale?

Is there memory wastage/duplication, bug(s), performance or 
development/maintenance benefit?


The review summary doesnt appear to include this information either


Log:
   Stop using per-mount tmpfs zones.
   
   Requested and reviewed by:	jeff

   Sponsored by:The FreeBSD Foundation
   MFC after:   1 week
   Differential revision:   https://reviews.freebsd.org/D22643

Modified:
   head/sys/fs/tmpfs/tmpfs.h
   head/sys/fs/tmpfs/tmpfs_subr.c
   head/sys/fs/tmpfs/tmpfs_vfsops.c

Modified: head/sys/fs/tmpfs/tmpfs.h
==
--- head/sys/fs/tmpfs/tmpfs.h   Wed Dec  4 23:24:40 2019(r355406)
+++ head/sys/fs/tmpfs/tmpfs.h   Thu Dec  5 00:03:17 2019(r355407)
@@ -378,10 +378,6 @@ struct tmpfs_mount {
/* All node lock to protect the node list and tmp_pages_used. */
struct mtx  tm_allnode_lock;
  
-	/* Zones used to store file system meta data, per tmpfs mount. */

-   uma_zone_t  tm_dirent_pool;
-   uma_zone_t  tm_node_pool;
-
/* Read-only status. */
booltm_ronly;
/* Do not use namecache. */
@@ -493,8 +489,9 @@ struct tmpfs_dirent *tmpfs_dir_next(struct tmpfs_node
  #endif
  
  size_t tmpfs_mem_avail(void);

-
  size_t tmpfs_pages_used(struct tmpfs_mount *tmp);
+void tmpfs_subr_init(void);
+void tmpfs_subr_uninit(void);
  
  #endif
  


Modified: head/sys/fs/tmpfs/tmpfs_subr.c
==
--- head/sys/fs/tmpfs/tmpfs_subr.c  Wed Dec  4 23:24:40 2019
(r355406)
+++ head/sys/fs/tmpfs/tmpfs_subr.c  Thu Dec  5 00:03:17 2019
(r355407)
@@ -72,7 +72,74 @@ SYSCTL_NODE(_vfs, OID_AUTO, tmpfs, CTLFLAG_RW, 0, "tmp
  
  static long tmpfs_pages_reserved = TMPFS_PAGES_MINRESERVED;
  
+static uma_zone_t tmpfs_dirent_pool;

+static uma_zone_t tmpfs_node_pool;
+
  static int
+tmpfs_node_ctor(void *mem, int size, void *arg, int flags)
+{
+   struct tmpfs_node *node;
+
+   node = mem;
+   node->tn_gen++;
+   node->tn_size = 0;
+   node->tn_status = 0;
+   node->tn_flags = 0;
+   node->tn_links = 0;
+   node->tn_vnode = NULL;
+   node->tn_vpstate = 0;
+   return (0);
+}
+
+static void
+tmpfs_node_dtor(void *mem, int size, void *arg)
+{
+   struct tmpfs_node *node;
+
+   node = mem;
+   node->tn_type = VNON;
+}
+
+static int
+tmpfs_node_init(void *mem, int size, int flags)
+{
+   struct tmpfs_node *node;
+
+   node = mem;
+   node->tn_id = 0;
+   mtx_init(>tn_interlock, "tmpfsni", NULL, MTX_DEF);
+   node->tn_gen = arc4random();
+   return (0);
+}
+
+static void
+tmpfs_node_fini(void *mem, int size)
+{
+   struct tmpfs_node *node;
+
+   node = mem;
+   mtx_destroy(>tn_interlock);
+}
+
+void
+tmpfs_subr_init(void)
+{
+   tmpfs_dirent_pool = uma_zcreate("TMPFS dirent",
+   sizeof(struct tmpfs_dirent), NULL, NULL, NULL, NULL,
+   UMA_ALIGN_PTR, 0);
+   tmpfs_node_pool = uma_zcreate("TMPFS node",
+   sizeof(struct tmpfs_node), tmpfs_node_ctor, tmpfs_node_dtor,
+   tmpfs_node_init, tmpfs_node_fini, UMA_ALIGN_PTR, 0);
+}
+
+void
+tmpfs_subr_uninit(void)
+{
+   uma_zdestroy(tmpfs_node_pool);
+   uma_zdestroy(tmpfs_dirent_pool);
+}
+
+static int
  sysctl_mem_reserved(SYSCTL_HANDLER_ARGS)
  {
int error;
@@ -219,8 +286,7 @@ tmpfs_alloc_node(struct mount *mp, struct tmpfs_mount
if ((mp->mnt_kern_flag & MNT_RDONLY) != 0)
return (EROFS);
  
-	nnode = (struct tmpfs_node *)uma_zalloc_arg(tmp->tm_node_pool, tmp,

-   M_WAITOK);
+   nnode = uma_zalloc_arg(tmpfs_node_pool, tmp, M_WAITOK);
  
  	/* Generic initialization. */

nnode->tn_type = type;
@@ -367,7 +433,7 @@ tmpfs_free_node_locked(struct tmpfs_mount *tmp, struct
panic("tmpfs_free_node: type %p %d", node, (int)node->tn_type);
}
  
-	uma_zfree(tmp->tm_node_pool, node);

+   uma_zfree(tmpfs_node_pool, node);
TMPFS_LOCK(tmp);
tmpfs_free_tmp(tmp);
return (true);
@@ -434,7 +500,7 @@ tmpfs_alloc_dirent(struct tmpfs_mount *tmp, struct tmp
  {
struct tmpfs_dirent *nde;
  
-	nde = uma_zalloc(tmp->tm_dirent_pool, M_WAITOK);

+   nde = uma_zalloc(tmpfs_dirent_pool, M_WAITOK);
nde->td_node = node;
if (name != NULL) {
nde->ud.td_name = malloc(len, M_TMPFSNAME, M_WAITOK);
@@ -470,7 +536,7 @@ tmpfs_free_dirent(struct tmpfs_mount *tmp, struct tmpf
}
if (!tmpfs_dirent_duphead(de) && de->ud.td_name != NULL)
free(de->ud.td_name, M_TMPFSNAME);
-   uma_zfree(tmp->tm_dirent_pool, de);
+   

Re: svn commit: r354708 - head/sys/netinet/cc

[Kubilay Kocak]

On 15/11/2019 3:28 am, Michael Tuexen wrote:

Author: tuexen
Date: Thu Nov 14 16:28:02 2019
New Revision: 354708
URL: https://svnweb.freebsd.org/changeset/base/354708

Log:
   For idle TCP sessions using the CUBIC congestio control, reset ssthresh
   to the higher of the previous ssthresh or 3/4 of the prior cwnd.
   
   Submitted by:		Richard Scheffenegger

   Reviewed by: Cheng Cui
   Differential Revision:   https://reviews.freebsd.org/D18982

Modified:
   head/sys/netinet/cc/cc_cubic.c


Are stable/12,11 affected by this too?


Modified: head/sys/netinet/cc/cc_cubic.c
==
--- head/sys/netinet/cc/cc_cubic.c  Thu Nov 14 15:10:01 2019
(r354707)
+++ head/sys/netinet/cc/cc_cubic.c  Thu Nov 14 16:28:02 2019
(r354708)
@@ -78,6 +78,7 @@ static intcubic_mod_init(void);
  static void   cubic_post_recovery(struct cc_var *ccv);
  static void   cubic_record_rtt(struct cc_var *ccv);
  static void   cubic_ssthresh_update(struct cc_var *ccv);
+static voidcubic_after_idle(struct cc_var *ccv);
  
  struct cubic {

/* Cubic K in fixed point form with CUBIC_SHIFT worth of precision. */
@@ -112,6 +113,7 @@ struct cc_algo cubic_cc_algo = {
.conn_init = cubic_conn_init,
.mod_init = cubic_mod_init,
.post_recovery = cubic_post_recovery,
+   .after_idle = cubic_after_idle,
  };
  
  static void

@@ -192,7 +194,24 @@ cubic_ack_received(struct cc_var *ccv, uint16_t type)
}
  }
  
+/*

+ * This is a Cubic specific implementation of after_idle.
+ *   - Reset cwnd by calling New Reno implementation of after_idle.
+ *   - Reset t_last_cong.
+ */
  static void
+cubic_after_idle(struct cc_var *ccv)
+{
+   struct cubic *cubic_data;
+
+   cubic_data = ccv->cc_data;
+
+   newreno_cc_algo.after_idle(ccv);
+   cubic_data->t_last_cong = ticks;
+}
+
+
+static void
  cubic_cb_destroy(struct cc_var *ccv)
  {
free(ccv->cc_data, M_CUBIC);
@@ -287,9 +306,6 @@ cubic_conn_init(struct cc_var *ccv)
  static int
  cubic_mod_init(void)
  {
-
-   cubic_cc_algo.after_idle = newreno_cc_algo.after_idle;
-
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-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: r352953 - in head/usr.bin: killall split

[Kubilay Kocak]

On 2/10/2019 9:59 pm, Kyle Evans wrote:

Sorry for the crap formatting, mobile.

We can perhaps also fix this class with a proper modelling file. koobs was
going to send out an email about it, but I haven't seen anything.


Thanks for the public reminder Kyle :]

I'll flick it out soon


On Wed, Oct 2, 2019, 02:03 Conrad Meyer  wrote:


Hi Alexander,

Coverity has millions of spurious warnings of this class and they're
basically all false positives.  I think we should instead try to
figure out how to disable this class of warning on our codebase, since
it is largely incorrect.

I would encourage reverting this change, because it uglies up the code
for no functional benefit.  The code was correct before the change;
only Coverity was wrong.

Best,
Conrad

On Tue, Oct 1, 2019 at 11:15 PM Alexander Kabaev  wrote:


Author: kan
Date: Wed Oct  2 06:15:30 2019
New Revision: 352953
URL: https://svnweb.freebsd.org/changeset/base/352953

Log:
   Convert pnmatch to single element array in regexec calls

   The regexec function is declared as taking an array of regmatch_t
   elements, and passing in the pointer to singleton element, while
   correct, triggers a Coverity warning. Convert the singleton into
   an array of one to silence the warning.

   Reported by:  Coverity
   Coverity CID: 1009732, 1009733
   MFC after:2 weeks

Modified:
   head/usr.bin/killall/killall.c
   head/usr.bin/split/split.c

Modified: head/usr.bin/killall/killall.c


==

--- head/usr.bin/killall/killall.c  Wed Oct  2 02:37:34 2019

(r352952)

+++ head/usr.bin/killall/killall.c  Wed Oct  2 06:15:30 2019

(r352953)

@@ -98,7 +98,7 @@ main(int ac, char **av)
 struct stat sb;
 struct passwd   *pw;
 regex_t rgx;
-   regmatch_t  pmatch;
+   regmatch_t  pmatch[1];
 int i, j, ch;
 charbuf[256];
 charfirst;
@@ -361,9 +361,9 @@ main(int ac, char **av)
 }
 }
 if (mflag) {
-   pmatch.rm_so = 0;
-   pmatch.rm_eo = strlen(thiscmd);
-   if (regexec(, thiscmd, 0, ,
+   pmatch[0].rm_so = 0;
+   pmatch[0].rm_eo = strlen(thiscmd);
+   if (regexec(, thiscmd, 0, pmatch,
 REG_STARTEND) != 0)
 matched = 0;
 regfree();
@@ -387,9 +387,9 @@ main(int ac, char **av)
 }
 }
 if (mflag) {
-   pmatch.rm_so = 0;
-   pmatch.rm_eo = strlen(thiscmd);
-   if (regexec(, thiscmd, 0, ,
+   pmatch[0].rm_so = 0;
+   pmatch[0].rm_eo = strlen(thiscmd);
+   if (regexec(, thiscmd, 0, pmatch,
 REG_STARTEND) == 0)
 matched = 1;
 regfree();

Modified: head/usr.bin/split/split.c


==

--- head/usr.bin/split/split.c  Wed Oct  2 02:37:34 2019(r352952)
+++ head/usr.bin/split/split.c  Wed Oct  2 06:15:30 2019(r352953)
@@ -281,11 +281,11 @@ split2(void)

 /* Check if we need to start a new file */
 if (pflag) {
-   regmatch_t pmatch;
+   regmatch_t pmatch[1];

-   pmatch.rm_so = 0;
-   pmatch.rm_eo = len - 1;
-   if (regexec(, bfr, 0, , REG_STARTEND)

== 0)

+   pmatch[0].rm_so = 0;
+   pmatch[0].rm_eo = len - 1;
+   if (regexec(, bfr, 0, pmatch, REG_STARTEND)

== 0)

 newfile();
 } else if (lcnt++ == numlines) {
 newfile();






___
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: r352707 - in head/sys: conf kern net sys

[Kubilay Kocak]

On 27/09/2019 12:48 am, Charlie Li via svn-src-head wrote:

Gleb Smirnoff wrote:

Modified: head/sys/conf/options
==
--- head/sys/conf/options   Wed Sep 25 18:09:19 2019(r352706)
+++ head/sys/conf/options   Wed Sep 25 18:26:31 2019(r352707)
@@ -712,6 +712,8 @@ WITNESS_SKIPSPINopt_witness.h
  WITNESS_COUNT opt_witness.h
  OPENSOLARIS_WITNESS   opt_global.h
  
+EPOCH_TRACE		opt_epoch.h

+
  # options for ACPI support
  ACPI_DEBUGopt_acpi.h
  ACPI_MAX_TASKSopt_acpi.h

Modified: head/sys/sys/epoch.h
==
--- head/sys/sys/epoch.hWed Sep 25 18:09:19 2019(r352706)
+++ head/sys/sys/epoch.hWed Sep 25 18:26:31 2019(r352707)
@@ -41,6 +41,8 @@ typedef struct epoch_context *epoch_context_t;
  #include 
  #include 
  
+#include "opt_epoch.h"

+
  struct epoch;
  typedef struct epoch *epoch_t;
  

This breaks building the drm-kmod ports, as the build cannot find
opt_epoch.h (drm-devel-kmod example shown, drm-current-kmod dies the
exact same way):


I started to get pkg-fallout emails in net/aquantia-atlantic-kmod with 
the same build failure


https://github.com/Aquantia/aqtion-freebsd/issues/4


--- linux_anon_inodes.o ---
cc  -O2 -pipe -fno-strict-aliasing -include
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/drivers/gpu/drm/drm_os_config.h
'-DKBUILD_MODNAME="linuxkpi_gplv2"'  -Werror -D_KERNEL -DKLD_MODULE
-nostdinc
-I/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/include 
-I/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/dummy/include
-I/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include
-I/usr/src/sys/compat/linuxkpi/common/include -I. -I/usr/src/sys
-I/usr/src/sys/contrib/ck/include -fno-common  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-fdebug-prefix-map=./machine=/usr/src/sys/amd64/include
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include -MD
-MF.depend.linux_anon_inodes.o -MTlinux_anon_inodes.o -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-address-of-packed-member -Wno-format-zero-length -Wno-pointer-arith
   -mno-aes -mno-avx  -std=iso9899:1999 -c
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/src/linux_anon_inodes.c
-o linux_anon_inodes.o
In file included from
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/src/linux_anon_inodes.c:12:
In file included from
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/anon_inodes.h:4:
In file included from
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/fs.h:6:
In file included from
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/shrinker.h:5:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/list.h:56:
In file included from /usr/src/sys/net/if_var.h:83:
/usr/src/sys/sys/epoch.h:44:10: fatal error: 'opt_epoch.h' file not found
#include "opt_epoch.h"
  ^
--- linux_anon_inodefs.o ---
In file included from
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/src/linux_anon_inodefs.c:45:
In file included from
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/debugfs.h:18:
In file included from
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/fs.h:6:
In file included from
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/shrinker.h:5:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/list.h:56:
In file included from /usr/src/sys/net/if_var.h:83:
/usr/src/sys/sys/epoch.h:44:10: fatal error: 'opt_epoch.h' file not found
#include "opt_epoch.h"
  ^
--- linux_anon_inodes.o ---
1 error generated.
*** [linux_anon_inodes.o] Error code 1

make[2]: stopped in
/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi
--- linux_anon_inodefs.o ---
1 error generated.
*** [linux_anon_inodefs.o] Error code 1

Interestingly enough, does not happen when drm-current-kmod is built as
part of buildkernel (using an existing installed package with SOURCE on).




___

Re: svn commit: r352662 - head/usr.sbin/freebsd-update

[Kubilay Kocak]

On 25/09/2019 6:49 am, Michael Gmelin wrote:

Author: grembo (ports committer)
Date: Tue Sep 24 20:49:33 2019
New Revision: 352662
URL: https://svnweb.freebsd.org/changeset/base/352662

Log:
   freebsd-update: Add `updatesready' and `showconfig' commands
   
   `freebsd-update updatesready' can be used to check if there are any pending

   fetched updates that can be installed.
   
   `freebsd-update showconfig' writes freebsd-update's configuration to

   stdout.
   
   This also changes the exit code of `freebsd-update install' to 2 in case

   there are no updates pending to be installed and there wasn't a fetch phase
   in the same invocation. This allows scripts to tell apart these error
   conditions without breaking existing jail managers.
   
   See freebsd-update(8) for details.
   
   PR:		240757, 240177, 229346

   Reviewed by: manpages (bcr), sectam (emaste), yuripv
   Differential Revision:   https://reviews.freebsd.org/D21473


Would love to see these MFC'd. Consistency between freebsd-update on all 
our supported versions for one of our major user features would be awesome.



Modified:
   head/usr.sbin/freebsd-update/freebsd-update.8
   head/usr.sbin/freebsd-update/freebsd-update.sh

Modified: head/usr.sbin/freebsd-update/freebsd-update.8
==
--- head/usr.sbin/freebsd-update/freebsd-update.8   Tue Sep 24 20:36:43 
2019(r352661)
+++ head/usr.sbin/freebsd-update/freebsd-update.8   Tue Sep 24 20:49:33 
2019(r352662)
@@ -25,7 +25,7 @@
  .\"
  .\" $FreeBSD$
  .\"
-.Dd June 14, 2017
+.Dd September 24, 2019
  .Dt FREEBSD-UPDATE 8
  .Os
  .Sh NAME
@@ -155,13 +155,24 @@ Note that this command may require up to 500 MB of spa
  depending on which components of the
  .Fx
  base system are installed.
+.It Cm updatesready
+Check if there are fetched updates ready to install.
+Returns exit code 2 if there are no updates to install.
  .It Cm install
  Install the most recently fetched updates or upgrade.
+Returns exit code 2 if there are no updates to install
+and the
+.Cm fetch
+command wasn't passed as an earlier argument in the same
+invocation.
  .It Cm rollback
  Uninstall the most recently installed updates.
  .It Cm IDS
  Compare the system against a "known good" index of the
  installed release.
+.It Cm showconfig
+Show configuration options after parsing conffile and command
+line options.
  .El
  .Sh TIPS
  .Bl -bullet

Modified: head/usr.sbin/freebsd-update/freebsd-update.sh
==
--- head/usr.sbin/freebsd-update/freebsd-update.sh  Tue Sep 24 20:36:43 
2019(r352661)
+++ head/usr.sbin/freebsd-update/freebsd-update.sh  Tue Sep 24 20:49:33 
2019(r352662)
@@ -62,9 +62,11 @@ Commands:
cron -- Sleep rand(3600) seconds, fetch updates, and send an
email if updates were found
upgrade  -- Fetch upgrades to FreeBSD version specified via -r option
+  updatesready -- Check if there are fetched updates ready to install
install  -- Install downloaded updates or upgrades
rollback -- Uninstall most recently installed updates
IDS  -- Compare the system against an index of "known good" files
+  showconfig   -- Show configuration
  EOF
exit 0
  }
@@ -503,7 +505,8 @@ parse_cmdline () {
;;
  
  		# Commands

-   cron | fetch | upgrade | install | rollback | IDS)
+   cron | fetch | upgrade | updatesready | install | rollback |\
+   IDS | showconfig)
COMMANDS="${COMMANDS} $1"
;;
  
@@ -827,7 +830,7 @@ install_check_params () {

echo "No updates are available to install."
if [ $ISFETCHED -eq 0 ]; then
echo "Run '$0 fetch' first."
-   exit 1
+   exit 2
fi
exit 0
fi
@@ -,6 +3336,21 @@ cmd_upgrade () {
upgrade_run || exit 1
  }
  
+# Check if there are fetched updates ready to install

+cmd_updatesready () {
+   # Construct a unique name from ${BASEDIR}
+   BDHASH=`echo ${BASEDIR} | sha256 -q`
+
+   # Check that we have updates ready to install
+   if ! [ -L ${BDHASH}-install ]; then
+   echo "No updates are available to install."
+   exit 2
+   fi
+
+   echo "There are updates available to install."
+   echo "Run '$0 install' to proceed."
+}
+
  # Install downloaded updates.
  cmd_install () {
install_check_params
@@ -3349,6 +3367,13 @@ cmd_rollback () {
  cmd_IDS () {
IDS_check_params
IDS_run || exit 1
+}
+
+# Output configuration.
+cmd_showconfig () {
+   for X in ${CONFIGOPTIONS}; do
+   echo $X=$(eval echo \$${X})
+   done
  }
  
   Entry point

___

Re: svn commit: r349505 - head/contrib/bzip2

[Kubilay Kocak]

On 28/06/2019 3:11 pm, Xin LI wrote:

Author: delphij
Date: Fri Jun 28 05:11:02 2019
New Revision: 349505
URL: https://svnweb.freebsd.org/changeset/base/349505

Log:
   Upgrade to Bzip2 version 1.0.7.


PR: 238843


   MFC after:   3 days

Modified:
   head/contrib/bzip2/CHANGES
   head/contrib/bzip2/LICENSE
   head/contrib/bzip2/README
   head/contrib/bzip2/README.COMPILATION.PROBLEMS
   head/contrib/bzip2/blocksort.c
   head/contrib/bzip2/bzip2.1
   head/contrib/bzip2/bzip2.c
   head/contrib/bzip2/bzip2recover.c
   head/contrib/bzip2/bzlib.c
   head/contrib/bzip2/bzlib.h
   head/contrib/bzip2/bzlib_private.h
   head/contrib/bzip2/compress.c
   head/contrib/bzip2/crctable.c
   head/contrib/bzip2/decompress.c
   head/contrib/bzip2/huffman.c
   head/contrib/bzip2/randtable.c
   head/contrib/bzip2/spewG.c
   head/contrib/bzip2/unzcrash.c
   head/contrib/bzip2/words2
Directory Properties:
   head/contrib/bzip2/   (props changed)

Modified: head/contrib/bzip2/CHANGES
==
--- head/contrib/bzip2/CHANGES  Fri Jun 28 04:52:24 2019(r349504)
+++ head/contrib/bzip2/CHANGES  Fri Jun 28 05:11:02 2019(r349505)
@@ -2,8 +2,8 @@
   This file is part of bzip2/libbzip2, a program and library for
   lossless, block-sorting data compression.
  
- bzip2/libbzip2 version 1.0.6 of 6 September 2010

- Copyright (C) 1996-2010 Julian Seward 
+ bzip2/libbzip2 version 1.0.7 of 27 June 2019
+ Copyright (C) 1996-2010 Julian Seward 
  
   Please read the WARNING, DISCLAIMER and PATENTS sections in the

   README file.
@@ -325,3 +325,16 @@ Security fix only.  Fixes CERT-FI 20469 as it applies
Izdebski.
  
  * Make the documentation build on Ubuntu 10.04

+
+1.0.7 (27 Jun 19)
+~
+
+* Fix undefined behavior in the macros SET_BH, CLEAR_BH, & ISSET_BH
+
+* bzip2: Fix return value when combining --test,-t and -q.
+
+* bzip2recover: Fix buffer overflow for large argv[0]
+
+* bzip2recover: Fix use after free issue with outFile (CVE-2016-3189)
+
+* Make sure nSelectors is not out of range (CVE-2019-12900)

Modified: head/contrib/bzip2/LICENSE
==
--- head/contrib/bzip2/LICENSE  Fri Jun 28 04:52:24 2019(r349504)
+++ head/contrib/bzip2/LICENSE  Fri Jun 28 05:11:02 2019(r349505)
@@ -36,7 +36,7 @@ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUD
  NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
  SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
-Julian Seward, jsew...@bzip.org

-bzip2/libbzip2 version 1.0.6 of 6 September 2010
+Julian Seward, jsew...@acm.org
+bzip2/libbzip2 version 1.0.7 of 27 June 2019
  
  --


Modified: head/contrib/bzip2/README
==
--- head/contrib/bzip2/README   Fri Jun 28 04:52:24 2019(r349504)
+++ head/contrib/bzip2/README   Fri Jun 28 05:11:02 2019(r349505)
@@ -6,8 +6,8 @@ This version is fully compatible with the previous pub
  This file is part of bzip2/libbzip2, a program and library for
  lossless, block-sorting data compression.
  
-bzip2/libbzip2 version 1.0.6 of 6 September 2010

-Copyright (C) 1996-2010 Julian Seward 
+bzip2/libbzip2 version 1.0.7 of 27 June 2019
+Copyright (C) 1996-2010 Julian Seward 
  
  Please read the WARNING, DISCLAIMER and PATENTS sections in this file.
  
@@ -73,7 +73,7 @@ HOW TO BUILD -- Windows 95, NT, DOS, Mac, etc.
  
  It's difficult for me to support compilation on all these platforms.

  My approach is to collect binaries for these platforms, and put them
-on the master web site (http://www.bzip.org).  Look there.  However
+on the master web site (https://sourceware.org/bzip2/).  Look there.  However
  (FWIW), bzip2-1.0.X is very standard ANSI C and should compile
  unmodified with MS Visual C.  If you have difficulties building, you
  might want to read README.COMPILATION.PROBLEMS.
@@ -161,43 +161,22 @@ WHAT'S NEW IN 0.9.5 ?
 * Many small improvements in file and flag handling.
 * A Y2K statement.
  
-WHAT'S NEW IN 1.0.0 ?

+WHAT'S NEW IN 1.0.x ?
  
 See the CHANGES file.
  
-WHAT'S NEW IN 1.0.2 ?

-
-   See the CHANGES file.
-
-WHAT'S NEW IN 1.0.3 ?
-
-   See the CHANGES file.
-
-WHAT'S NEW IN 1.0.4 ?
-
-   See the CHANGES file.
-
-WHAT'S NEW IN 1.0.5 ?
-
-   See the CHANGES file.
-
-WHAT'S NEW IN 1.0.6 ?
-
-   See the CHANGES file.
-
-
  I hope you find bzip2 useful.  Feel free to contact me at
-   jsew...@bzip.org
+   jsew...@acm.org
  if you have any suggestions or queries.  Many people mailed me with
  comments, suggestions and patches after the releases of bzip-0.15,
  bzip-0.21, and bzip2 versions 0.1pl2, 0.9.0, 0.9.5, 1.0.0, 1.0.1,
  1.0.2 and 1.0.3, and the changes in bzip2 are largely a result of this
  feedback.  I thank you for your comments.
  
-bzip2's "home" 

Re: svn commit: r348484 - head/sys/vm

[Kubilay Kocak]

On 1/06/2019 7:02 am, Doug Moore wrote:

Author: dougm
Date: Fri May 31 21:02:42 2019
New Revision: 348484
URL: https://svnweb.freebsd.org/changeset/base/348484

Log:
   The function vm_phys_free_contig invokes vm_phys_free_pages for every
   power-of-two page block it frees, launching an unsuccessful search for
   a buddy to pair up with each time.  The only possible buddy-up mergers
   are across the boundaries of the freed region, so change
   vm_phys_free_contig simply to enqueue the freed interior blocks, via a
   new function vm_phys_enqueue_contig, and then call vm_phys_free_pages
   on the bounding blocks to create as big a cross-boundary block as
   possible after buddy-merging.
   
   The only callers of vm_phys_free_contig at the moment call it in

   situations where merging blocks across the boundary is clearly
   impossible, so just call vm_phys_enqueue_contig in those places and
   avoid trying to buddy-up at all.
   
   One beneficiary of this change is in breaking reservations.  For the

   case where memory is freed in breaking a reservation with only the
   first and last pages allocated, the number of cycles consumed by the
   operation drops about 11% with this change.
   
   Suggested by: alc

   Reviewed by: alc
   Approved by: kib, markj (mentors)
   Differential Revision: https://reviews.freebsd.org/D16901


Can this be an MFC candidate?



Modified:
   head/sys/vm/vm_page.c
   head/sys/vm/vm_phys.c
   head/sys/vm/vm_phys.h
   head/sys/vm/vm_reserv.c

Modified: head/sys/vm/vm_page.c
==
--- head/sys/vm/vm_page.c   Fri May 31 20:36:32 2019(r348483)
+++ head/sys/vm/vm_page.c   Fri May 31 21:02:42 2019(r348484)
@@ -833,7 +833,7 @@ vm_page_startup(vm_offset_t vaddr)
  
  			vmd = VM_DOMAIN(seg->domain);

vm_domain_free_lock(vmd);
-   vm_phys_free_contig(m, pagecount);
+   vm_phys_enqueue_contig(m, pagecount);
vm_domain_free_unlock(vmd);
vm_domain_freecnt_inc(vmd, pagecount);
vm_cnt.v_page_count += (u_int)pagecount;

Modified: head/sys/vm/vm_phys.c
==
--- head/sys/vm/vm_phys.c   Fri May 31 20:36:32 2019(r348483)
+++ head/sys/vm/vm_phys.c   Fri May 31 21:02:42 2019(r348484)
@@ -1095,14 +1095,35 @@ vm_phys_free_pages(vm_page_t m, int order)
  }
  
  /*

- * Free a contiguous, arbitrarily sized set of physical pages.
+ * Return the largest possible order of a set of pages starting at m.
+ */
+static int
+max_order(vm_page_t m)
+{
+
+   /*
+* Unsigned "min" is used here so that "order" is assigned
+* "VM_NFREEORDER - 1" when "m"'s physical address is zero
+* or the low-order bits of its physical address are zero
+* because the size of a physical address exceeds the size of
+* a long.
+*/
+   return (min(ffsl(VM_PAGE_TO_PHYS(m) >> PAGE_SHIFT) - 1,
+   VM_NFREEORDER - 1));
+}
+
+/*
+ * Free a contiguous, arbitrarily sized set of physical pages, without
+ * merging across set boundaries.
   *
   * The free page queues must be locked.
   */
  void
-vm_phys_free_contig(vm_page_t m, u_long npages)
+vm_phys_enqueue_contig(vm_page_t m, u_long npages)
  {
-   u_int n;
+   struct vm_freelist *fl;
+   struct vm_phys_seg *seg;
+   vm_page_t m_end;
int order;
  
  	/*

@@ -1110,29 +1131,68 @@ vm_phys_free_contig(vm_page_t m, u_long npages)
 * possible power-of-two-sized subsets.
 */
vm_domain_free_assert_locked(vm_pagequeue_domain(m));
-   for (;; npages -= n) {
-   /*
-* Unsigned "min" is used here so that "order" is assigned
-* "VM_NFREEORDER - 1" when "m"'s physical address is zero
-* or the low-order bits of its physical address are zero
-* because the size of a physical address exceeds the size of
-* a long.
-*/
-   order = min(ffsl(VM_PAGE_TO_PHYS(m) >> PAGE_SHIFT) - 1,
-   VM_NFREEORDER - 1);
-   n = 1 << order;
-   if (npages < n)
-   break;
-   vm_phys_free_pages(m, order);
-   m += n;
+   seg = _phys_segs[m->segind];
+   fl = (*seg->free_queues)[m->pool];
+   m_end = m + npages;
+   /* Free blocks of increasing size. */
+   while ((order = max_order(m)) < VM_NFREEORDER - 1 &&
+   m + (1 << order) <= m_end) {
+   KASSERT(seg == _phys_segs[m->segind],
+   ("%s: page range [%p,%p) spans multiple segments",
+   __func__, m_end - npages, m));
+   vm_freelist_add(fl, m, order, 1);
+   m += 1 << order;
}
-   /* The residual "npages" is less than "1 

Re: svn commit: r344368 - head/sys/netinet

[Kubilay Kocak]

On 21/02/2019 5:03 am, Michael Tuexen wrote:

Author: tuexen
Date: Wed Feb 20 18:03:43 2019
New Revision: 344368
URL: https://svnweb.freebsd.org/changeset/base/344368

Log:
   Reduce the TCP initial retransmission timeout from 3 seconds to
   1 second as allowed by RFC 6298.
   
   Reviewed by:		kbowling@, Richard Scheffenegger

   Sponsored by:Netflix, Inc.
   Differential Revision:   https://reviews.freebsd.org/D18941

Modified:
   head/sys/netinet/tcp_syncache.c
   head/sys/netinet/tcp_timer.h

Modified: head/sys/netinet/tcp_syncache.c
==
--- head/sys/netinet/tcp_syncache.c Wed Feb 20 17:56:38 2019
(r344367)
+++ head/sys/netinet/tcp_syncache.c Wed Feb 20 18:03:43 2019
(r344368)
@@ -159,7 +159,7 @@ static int   syncookie_cmp(struct in_conninfo *inc, str
   *  tcp_backoff[1] +
   *  tcp_backoff[2] +
   *  tcp_backoff[3]) + 3 * tcp_rexmit_slop,
- * 3000 ms * (1 + 2 + 4 + 8) +  3 * 200 ms = 45600 ms,
+ * 1000 ms * (1 + 2 + 4 + 8) +  3 * 200 ms = 15600 ms,
   * the odds are that the user has given up attempting to connect by then.
   */
  #define SYNCACHE_MAXREXMTS3

Modified: head/sys/netinet/tcp_timer.h
==
--- head/sys/netinet/tcp_timer.hWed Feb 20 17:56:38 2019
(r344367)
+++ head/sys/netinet/tcp_timer.hWed Feb 20 18:03:43 2019
(r344368)
@@ -77,7 +77,7 @@
  #define   TCPTV_MSL   ( 30*hz)/* max seg lifetime 
(hah!) */
  #define   TCPTV_SRTTBASE  0   /* base roundtrip time;
   if 0, no idea yet */
-#defineTCPTV_RTOBASE   (  3*hz)/* assumed RTO if no 
info */
+#defineTCPTV_RTOBASE   (  1*hz)/* assumed RTO if no 
info */
  
  #define	TCPTV_PERSMIN	(  5*hz)		/* minimum persist interval */

  #define   TCPTV_PERSMAX   ( 60*hz)/* maximum persist 
interval */
___


Any way this can be a run-time tunable?

___
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: r342057 - head/crypto/openssl/crypto/engine

[Kubilay Kocak]

On 14/12/2018 12:06 pm, Jung-uk Kim wrote:

Author: jkim
Date: Fri Dec 14 01:06:34 2018
New Revision: 342057
URL: https://svnweb.freebsd.org/changeset/base/342057

Log:
   Do not complain when /dev/crypto does not exist.
   
   Now the new devcrypto engine is enabled since r342009, many users started

   seeing "Could not open /dev/crypto: No such file or directory".  Disable
   the annoying error message as it is not very useful anyway.
   
   Note the patch was submitted upstream.
   
   https://github.com/openssl/openssl/pull/7896


Modified:
   head/crypto/openssl/crypto/engine/eng_devcrypto.c

Modified: head/crypto/openssl/crypto/engine/eng_devcrypto.c
==
--- head/crypto/openssl/crypto/engine/eng_devcrypto.c   Fri Dec 14 00:40:38 
2018(r342056)
+++ head/crypto/openssl/crypto/engine/eng_devcrypto.c   Fri Dec 14 01:06:34 
2018(r342057)
@@ -24,6 +24,8 @@
  
  #include "internal/engine.h"
  
+/* #define ENGINE_DEVCRYPTO_DEBUG */

+
  #ifdef CRYPTO_ALGORITHM_MIN
  # define CHECK_BSD_STYLE_MACROS
  #endif
@@ -615,6 +617,9 @@ void engine_load_devcrypto_int()
  ENGINE *e = NULL;
  
  if ((cfd = open("/dev/crypto", O_RDWR, 0)) < 0) {

+#ifndef ENGINE_DEVCRYPTO_DEBUG
+if (errno != ENOENT)
+#endif
  fprintf(stderr, "Could not open /dev/crypto: %s\n", strerror(errno));
  return;
  }


How trivially could devcrypto_debug  be modified to be a runtime 
configuration (say sysctl) setting?

___
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: r341505 - head/share/man/man5

[Kubilay Kocak]

On 5/12/2018 9:51 am, Pedro F. Giffuni wrote:

Starting with FreeBSD 12 we fully support writing ext4 filesystems


Can we remove '2' from the module/man/etc name if (since) it supports 
multiple extXfs versions? Is there anything serious preventing it?


Seems minor but I think worth it for discovery/pola/obviousness, and a 
good time (early in the 13.0 cycle).


We get a lot of user questions about ext*fs support on FreeBSD and 
pointing to an ext2fs man page also feels a bit weird.


Happy to get/organise a !committer contributor to take care of this if 
no-one wants to pick it up.


./koobs
___
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: r337709 - head/sys/net

[Kubilay Kocak]

On 14/08/2018 12:13 am, Andrew Gallatin wrote:
> Author: gallatin
> Date: Mon Aug 13 14:13:25 2018
> New Revision: 337709
> URL: https://svnweb.freebsd.org/changeset/base/337709
> 
> Log:
>   lagg: allow lacp to manage the link state
>   
>   Lacp needs to manage the link state itself. Unlike other
>   lagg protocols, the ability of lacp to pass traffic
>   depends not only on the lagg members having link, but also
>   on the lacp protocol converging to a distributing state with the
>   link partner.
>   
>   If we prematurely mark the link as up, then we will send a
>   gratuitous arp (via arp_handle_ifllchange()) before the lacp
>   interface is capable of passing traffic. When this happens,
>   the gratuitous arp is lost, and our link partner may cache
>   a stale mac address (eg, when the base mac address for the
>   lagg bundle changes, due to a BIOS change re-ordering NIC
>   unit numbers)

Hi Andrew

Can this be MFC'd?

>   Reviewed by: jtl, hselasky
>   Sponsored by: Netflix
> 
> Modified:
>   head/sys/net/ieee8023ad_lacp.c
>   head/sys/net/if_lagg.c
> 
> Modified: head/sys/net/ieee8023ad_lacp.c
> ==
> --- head/sys/net/ieee8023ad_lacp.cMon Aug 13 13:58:45 2018
> (r337708)
> +++ head/sys/net/ieee8023ad_lacp.cMon Aug 13 14:13:25 2018
> (r337709)
> @@ -711,6 +711,8 @@ lacp_disable_distributing(struct lacp_port *lp)
>   }
>  
>   lp->lp_state &= ~LACP_STATE_DISTRIBUTING;
> + if_link_state_change(sc->sc_ifp,
> + sc->sc_active ? LINK_STATE_UP : LINK_STATE_DOWN);
>  }
>  
>  static void
> @@ -745,6 +747,9 @@ lacp_enable_distributing(struct lacp_port *lp)
>   } else
>   /* try to become the active aggregator */
>   lacp_select_active_aggregator(lsc);
> +
> + if_link_state_change(sc->sc_ifp,
> + sc->sc_active ? LINK_STATE_UP : LINK_STATE_DOWN);
>  }
>  
>  static void
> 
> Modified: head/sys/net/if_lagg.c
> ==
> --- head/sys/net/if_lagg.cMon Aug 13 13:58:45 2018(r337708)
> +++ head/sys/net/if_lagg.cMon Aug 13 14:13:25 2018(r337709)
> @@ -1737,6 +1737,10 @@ lagg_linkstate(struct lagg_softc *sc)
>  
>   LAGG_XLOCK_ASSERT(sc);
>  
> + /* LACP handles link state itself */
> + if (sc->sc_proto == LAGG_PROTO_LACP)
> + return;
> +
>   /* Our link is considered up if at least one of our ports is active */
>   LAGG_RLOCK();
>   CK_SLIST_FOREACH(lp, >sc_ports, lp_entries) {
> ___
> 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-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

[Kubilay Kocak]

On 8/06/2018 10:15 am, Gleb Smirnoff wrote:
> Author: glebius
> Date: Fri Jun  8 00:15:08 2018
> New Revision: 334819
> URL: https://svnweb.freebsd.org/changeset/base/334819
> 
> Log:
>   UMA memory debugging enabled with INVARIANTS consists of two things:
>   trashing freed memory and checking that allocated memory is properly
>   trashed, and also of keeping a bitset of freed items. Trashing/checking
>   creates a lot of CPU cache poisoning, while keeping debugging bitsets
>   consistent creates a lot of contention on UMA zone lock(s). The performance
>   difference between INVARIANTS kernel and normal one is mostly attributed
>   to UMA debugging, rather than to all KASSERT checks in the kernel.
>   
>   Add loader tunable vm.debug.divisor that allows either to turn off UMA

Is 'sample interval' a standard/common enough term for this kind of
mechanism to name the sysctl with it rather than the implementation?

Or 'sample frequency'

>   debugging completely, or turn it on only for a fraction of allocations,
>   while still running all KASSERTs in kernel. That allows to run INVARIANTS
>   kernels in production environments without reducing load by orders of
>   magnitude, but still doing useful extra checks.
>   
>   Default value is 1, meaning debug every allocation. Value of 0 would
>   disable UMA debugging completely. Values above 1 enable debugging only
>   for every N-th item. It isn't possible to strictly follow the number,
>   but still amount of debugging is reduced roughly by (N-1)/N percent.
>   
>   Sponsored by:   Netflix
>   Differential Revision:  https://reviews.freebsd.org/D15199
> 

> +static u_int dbg_divisor = 1;
> +SYSCTL_UINT(_vm_debug, OID_AUTO, divisor,
> +CTLFLAG_RDTUN | CTLFLAG_NOFETCH, _divisor, 0,
> +"Debug & thrash every this item in memory allocator");

Might "Nth" be better (more explicit) here ---^ ?

> +static counter_u64_t uma_dbg_cnt = EARLY_COUNTER;
> +static counter_u64_t uma_skip_cnt = EARLY_COUNTER;
> +SYSCTL_COUNTER_U64(_vm_debug, OID_AUTO, trashed, CTLFLAG_RD,
> +_dbg_cnt, "memory items debugged");
> +SYSCTL_COUNTER_U64(_vm_debug, OID_AUTO, skipped, CTLFLAG_RD,
> +_skip_cnt, "memory items skipped, not debugged");
>  #endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r332645 - head/sbin/ifconfig

[Kubilay Kocak]

On 17/04/2018 10:54 pm, Andrew Gallatin wrote:
> Author: gallatin
> Date: Tue Apr 17 12:54:58 2018
> New Revision: 332645
> URL: https://svnweb.freebsd.org/changeset/base/332645
> 
> Log:
>   Make lagg creation more fault tolerant
>   
>   - Warn, don't exit, when SIOCSLAGGPORT returns an error.
>   
>   When we exit with an error during lagg creation, a single
>   failed NIC (which no longer attaches) can prevent lagg
>   creation and other configuration, such as adding an IPv4
>   address, and thus leave a machine unreachable.
>   
>   - Preserve non-EEXISTS errors for exit status from SIOCSLAGGPORT,
> in case scripts are looking for it. Hopefully this can be
> extended if other parts of ifconfig can allow a "soft" failure.
>   
>   - Improve the warning message to mention what lagg and what
> member are problematic.
>   
>   Reviewed by: jtl, glebius
>   Sponsored by: Netflix
>   Differential Revision:  https://reviews.freebsd.org/D15046


MFC please?

> Modified:
>   head/sbin/ifconfig/ifclone.c
>   head/sbin/ifconfig/ifconfig.c
>   head/sbin/ifconfig/ifconfig.h
>   head/sbin/ifconfig/ifgroup.c
>   head/sbin/ifconfig/iflagg.c
> 
> Modified: head/sbin/ifconfig/ifclone.c
> ==
> --- head/sbin/ifconfig/ifclone.c  Tue Apr 17 12:52:30 2018
> (r332644)
> +++ head/sbin/ifconfig/ifclone.c  Tue Apr 17 12:54:58 2018
> (r332645)
> @@ -181,7 +181,7 @@ static void
>  clone_Copt_cb(const char *optarg __unused)
>  {
>   list_cloners();
> - exit(0);
> + exit(exit_code);
>  }
>  static struct option clone_Copt = { .opt = "C", .opt_usage = "[-C]", .cb = 
> clone_Copt_cb };
>  
> 
> Modified: head/sbin/ifconfig/ifconfig.c
> ==
> --- head/sbin/ifconfig/ifconfig.c Tue Apr 17 12:52:30 2018
> (r332644)
> +++ head/sbin/ifconfig/ifconfig.c Tue Apr 17 12:54:58 2018
> (r332645)
> @@ -99,6 +99,7 @@ int printifname = 0;
>  
>  int  supmedia = 0;
>  int  printkeys = 0;  /* Print keying material for interfaces. */
> +int  exit_code = 0;
>  
>  /* Formatter Strings */
>  char *f_inet, *f_inet6, *f_ether, *f_addr;
> @@ -485,7 +486,7 @@ main(int argc, char *argv[])
>   errx(1, "%s: cloning name too long",
>   ifname);
>   ifconfig(argc, argv, 1, NULL);
> - exit(0);
> + exit(exit_code);
>   }
>  #ifdef JAIL
>   /*
> @@ -499,7 +500,7 @@ main(int argc, char *argv[])
>   errx(1, "%s: interface name too long",
>   ifname);
>   ifconfig(argc, argv, 0, NULL);
> - exit(0);
> + exit(exit_code);
>   }
>  #endif
>   errx(1, "interface %s does not exist", ifname);
> @@ -597,7 +598,7 @@ main(int argc, char *argv[])
>   freeifaddrs(ifap);
>  
>   freeformat();
> - exit(0);
> + exit(exit_code);
>  }
>  
>  static struct afswtch *afs = NULL;
> 
> Modified: head/sbin/ifconfig/ifconfig.h
> ==
> --- head/sbin/ifconfig/ifconfig.h Tue Apr 17 12:52:30 2018
> (r332644)
> +++ head/sbin/ifconfig/ifconfig.h Tue Apr 17 12:54:58 2018
> (r332645)
> @@ -136,6 +136,7 @@ externint printkeys;
>  extern   int newaddr;
>  extern   int verbose;
>  extern   int printifname;
> +extern   int exit_code;
>  
>  void setifcap(const char *, int value, int s, const struct afswtch *);
>  
> 
> Modified: head/sbin/ifconfig/ifgroup.c
> ==
> --- head/sbin/ifconfig/ifgroup.c  Tue Apr 17 12:52:30 2018
> (r332644)
> +++ head/sbin/ifconfig/ifgroup.c  Tue Apr 17 12:54:58 2018
> (r332645)
> @@ -140,7 +140,7 @@ printgroup(const char *groupname)
>   if (ioctl(s, SIOCGIFGMEMB, (caddr_t)) == -1) {
>   if (errno == EINVAL || errno == ENOTTY ||
>   errno == ENOENT)
> - exit(0);
> + exit(exit_code);
>   else
>   err(1, "SIOCGIFGMEMB");
>   }
> @@ -159,7 +159,7 @@ printgroup(const char *groupname)
>   }
>   free(ifgr.ifgr_groups);
>  
> - exit(0);
> + exit(exit_code);
>  }
>  
>  static struct cmd group_cmds[] = {
> 
> Modified: head/sbin/ifconfig/iflagg.c
> ==
> --- head/sbin/ifconfig/iflagg.c   Tue Apr 17 12:52:30 2018
> (r332644)
> +++ head/sbin/ifconfig/iflagg.c   Tue Apr 17 12:54:58 2018
> (r332645)
> @@ -41,9 +41,17 

Re: svn commit: r328011 - in head/sys/amd64/vmm: amd intel

[Kubilay Kocak]

On 9/03/2018 8:57 am, Ed Maste wrote:
> On 15 January 2018 at 13:37, Tycho Nightingale  wrote:
>> Author: tychon
>> Date: Mon Jan 15 18:37:03 2018
>> New Revision: 328011
>> URL: https://svnweb.freebsd.org/changeset/base/328011
>>
>> Log:
>>   Provide some mitigation against CVE-2017-5715 by clearing registers
>>   upon returning from the guest which aren't immediately clobbered by
>>   the host.  This eradicates any remaining guest contents limiting their
>>   usefulness in an exploit gadget.
> 
> Will you MFC this to stable/11?

Mitigations and related MFC's and SA's, etc for vulnerabilities, are
presumably all being coordinated and handled by secteam, with associated
(explicit) messaging when fixes don't apply to particular
branches/versions, no?
___
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: r329874 - in head: etc/mtree tests/sys/net

[Kubilay Kocak]

On 2/24/18 5:18 AM, Alan Somers wrote:
>   Unfortunately, most of the tests are disabled because they fairly frequently
>   trigger panics.

Do the atf_skip annotations/reasons show up in the output even though
they're not run?

Somewhat related, do the test machines use debug bits and produce good
debug output/backtraces in these situations?

./koobs


___
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: r309109 - head/lib/libutil

[Kubilay Kocak]

On 25/11/2016 1:50 AM, Dag-Erling Smørgrav wrote:
> +/* + * Reliably open and lock a file. + * + * DO NOT, UNDER PAIN OF
> DEATH, modify this code without first reading the + * revision
> history and discussing your changes with . + * Don't
> be fooled by the code's apparent simplicity; there would be no + *
> need for this function if it was as easy to get right as you think. +
> */

This comes as close to obvious territoriality in FreeBSD as I've seen to
date and it's especially disappointing to see coming from someone many
look up to and consider a senior project developer.

While we all may understand the frustration associated with people
changing code they don't understand, I believe we need less fear
associated with contributing to FreeBSD and that this is a big step in
the wrong direction.

Please choose a better way to resolve the perceived problem.

--
Respectfully,

./koobs
___
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: r306577 - head/sys/netinet

[Kubilay Kocak]

On 2/10/2016 12:42 PM, Eric van Gyzen wrote:
> Author: vangyzen Date: Sun Oct  2 01:42:45 2016 New Revision: 306577 
> URL: https://svnweb.freebsd.org/changeset/base/306577
> 
> Log: Add GARP retransmit capability
> 
> A single gratuitous ARP (GARP) is always transmitted when an IPv4 
> address is added to an interface, and that is usually sufficient. 
> However, in some circumstances, such as when a shared address is 
> passed between cluster nodes, this single GARP may occasionally be 
> dropped or lost.  This can lead to neighbors on the network link 
> working with a stale ARP cache and sending packets destined for that
> address to the node that previously owned the address, which may not
> respond.
> 
> To avoid this situation, GARP retransmissions can be enabled by
> setting the net.link.ether.inet.garp_rexmit_count sysctl to a value
> greater than zero.  The setting represents the maximum number of
> retransmissions. The interval between retransmissions is calculated
> using an exponential backoff algorithm, doubling each time, so the
> retransmission intervals are: {1, 2, 4, 8, 16, ...} (seconds).
> 
> Due to the exponential backoff algorithm used for the interval 
> between GARP retransmissions, the maximum number of retransmissions 
> is limited to 16 for sanity.  This limit corresponds to a maximum 
> interval between retransmissions of 2^16 seconds ~= 18 hours. 
> Increasing this limit is possible, but sending out GARPs spaced days
> apart would be of little use.
> 

Thanks for this David & Eric

I presume this is (or would be) quite complementary to D4111 [1]
(Gratuitous ARP's for lagg(4) failover) when it lands? I'm thinking
particularly given the various states upstream switch ports can have
during topology changes.

[1] https://reviews.freebsd.org/D4111

./koobs


___
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: r304435 - head/sys/netinet

[Kubilay Kocak]

On 19/08/2016 8:59 AM, Ryan Stone wrote:
> Author: rstone
> Date: Thu Aug 18 22:59:00 2016
> New Revision: 304435
> URL: https://svnweb.freebsd.org/changeset/base/304435
> 
> Log:
>   Don't iterate over the ifnet addr list in ip_output()
>   
>   For almost every packet that is transmitted through ip_output(),
>   a call to in_broadcast() was made to decide if the destination
>   IP was a broadcast address.  in_broadcast() iterates over the
>   ifnet's address to find a source IP matching the subnet of the
>   destination IP, and then checks if the IP is a broadcast in that
>   subnet.
>   
>   This is completely redundant as we have already performed the
>   route lookup, so the source IP is already known.  Just use that
>   address to directly check whether the destination IP is a
>   broadcast address or not.

Hi Ryan,

Could you elaborate on any of the potential performance implications of
this?

>   MFC after:  2 months
>   Sponsored By:   EMC / Isilon Storage Division
>   Differential Revision: https://reviews.freebsd.org/D7266
> 
> Modified:
>   head/sys/netinet/in.c
>   head/sys/netinet/in.h
>   head/sys/netinet/ip_output.c
> 
> Modified: head/sys/netinet/in.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"

Re: svn commit: r304072 - head/etc

[Kubilay Kocak]

On 14/08/2016 3:18 PM, Xin LI wrote:
> Author: delphij Date: Sun Aug 14 05:18:38 2016 New Revision: 304072 
> URL: https://svnweb.freebsd.org/changeset/base/304072
> 
> Log: Now that the portsnap buildbox is generating the raw bits for
> INDEX-12, add it to the set of INDEX files built by portsnap.

Thank you!

> Switch to INDEX-12 for head/.
> 
> Modified: head/etc/portsnap.conf
> 
> Modified: head/etc/portsnap.conf 
> ==
>
> 
--- head/etc/portsnap.conf  Sun Aug 14 05:10:26 2016(r304071)
> +++ head/etc/portsnap.confSun Aug 14 05:18:38 2016(r304072) @@
> -32,4 +32,5 @@ # List of INDEX files to build and the DESCRIBE file
> to use for each #INDEX INDEX-9 DESCRIBE.9 #INDEX INDEX-10
> DESCRIBE.10 -INDEX INDEX-11 DESCRIBE.11 +#INDEX INDEX-11 DESCRIBE.11 
> +INDEX INDEX-12 DESCRIBE.12 
> ___ 
> 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-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: r303043 - in head: share/man/man4 sys/dev/vt sys/dev/vt/hw/fb

[Kubilay Kocak]

On 21/07/2016 5:07 AM, Bryan Drewery wrote:
> On 7/20/16 8:20 AM, Conrad Meyer wrote:
>> On Wed, Jul 20, 2016 at 12:44 AM, Kubilay Kocak <ko...@freebsd.org> wrote:
>>> On 20/07/2016 5:20 AM, Conrad E. Meyer wrote:
>>>> Author: cem
>>>> Date: Tue Jul 19 19:20:47 2016
>>>> New Revision: 303043
>>>> URL: https://svnweb.freebsd.org/changeset/base/303043
>>>>
>>>> Log:
>>>>   Increase vt(4) framebuffer maximum size
>>>>
>>>>   And rename "DEFAULT" constants to the more accurate "MAX."
>>>>
>>>>   PR: 210382
>>>>   Submitted by:   Felix 
>>>>   Reviewed by:wblock, cem
>>>>   Tested by:  Dave Cottlehuber 
>>>
>>> Can MFC?
>>>
>>> There are high hopes for this coming out in 11.0 / next 10.x
>>>
>>> re is cc'd on the original bugzilla issue
>>
>> If you would like to do so, please go ahead.
>>
>> Best,
>> Conrad
>>
> 
> I'll handle it after it's been in for a week.
> 

Thank you Bryan

./koobs
___
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: r303043 - in head: share/man/man4 sys/dev/vt sys/dev/vt/hw/fb

[Kubilay Kocak]

On 20/07/2016 5:20 AM, Conrad E. Meyer wrote:
> Author: cem
> Date: Tue Jul 19 19:20:47 2016
> New Revision: 303043
> URL: https://svnweb.freebsd.org/changeset/base/303043
> 
> Log:
>   Increase vt(4) framebuffer maximum size
>   
>   And rename "DEFAULT" constants to the more accurate "MAX."
>   
>   PR: 210382
>   Submitted by:   Felix 
>   Reviewed by:wblock, cem
>   Tested by:  Dave Cottlehuber 

Can MFC?

There are high hopes for this coming out in 11.0 / next 10.x

re is cc'd on the original bugzilla issue

> Modified:
>   head/share/man/man4/vt.4
>   head/sys/dev/vt/hw/fb/vt_fb.c
>   head/sys/dev/vt/vt.h
>   head/sys/dev/vt/vt_core.c
> 
> Modified: head/share/man/man4/vt.4
> ==
> --- head/share/man/man4/vt.4  Tue Jul 19 19:19:03 2016(r303042)
> +++ head/share/man/man4/vt.4  Tue Jul 19 19:20:47 2016(r303043)
> @@ -24,7 +24,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd June 21, 2016
> +.Dd July 19, 2016
>  .Dt "VIRTUAL TERMINALS" 4
>  .Os
>  .Sh NAME
> @@ -36,8 +36,8 @@
>  .Cd "options VT_MAXWINDOWS=N"
>  .Cd "options VT_ALT_TO_ESC_HACK=1"
>  .Cd "options VT_TWOBUTTON_MOUSE"
> -.Cd "options VT_FB_DEFAULT_WIDTH=X"
> -.Cd "options VT_FB_DEFAULT_HEIGHT=Y"
> +.Cd "options VT_FB_MAX_WIDTH=X"
> +.Cd "options VT_FB_MAX_HEIGHT=Y"
>  .Cd "options SC_NO_CUTPASTE"
>  .Cd "device vt"
>  .Pp
> 
> Modified: head/sys/dev/vt/hw/fb/vt_fb.c
> ==
> --- head/sys/dev/vt/hw/fb/vt_fb.c Tue Jul 19 19:19:03 2016
> (r303042)
> +++ head/sys/dev/vt/hw/fb/vt_fb.c Tue Jul 19 19:20:47 2016
> (r303043)
> @@ -416,10 +416,10 @@ vt_fb_init(struct vt_device *vd)
>   int err;
>  
>   info = vd->vd_softc;
> - vd->vd_height = MIN(VT_FB_DEFAULT_HEIGHT, info->fb_height);
> + vd->vd_height = MIN(VT_FB_MAX_HEIGHT, info->fb_height);
>   margin = (info->fb_height - vd->vd_height) >> 1;
>   vd->vd_transpose = margin * info->fb_stride;
> - vd->vd_width = MIN(VT_FB_DEFAULT_WIDTH, info->fb_width);
> + vd->vd_width = MIN(VT_FB_MAX_WIDTH, info->fb_width);
>   margin = (info->fb_width - vd->vd_width) >> 1;
>   vd->vd_transpose += margin * (info->fb_bpp / NBBY);
>   vd->vd_video_dev = info->fb_video_dev;
> 
> Modified: head/sys/dev/vt/vt.h
> ==
> --- head/sys/dev/vt/vt.h  Tue Jul 19 19:19:03 2016(r303042)
> +++ head/sys/dev/vt/vt.h  Tue Jul 19 19:20:47 2016(r303043)
> @@ -377,11 +377,11 @@ void vt_upgrade(struct vt_device *vd);
>  #define  PIXEL_WIDTH(w)  ((w) / 8)
>  #define  PIXEL_HEIGHT(h) ((h) / 16)
>  
> -#ifndef VT_FB_DEFAULT_WIDTH
> -#define  VT_FB_DEFAULT_WIDTH 2048
> +#ifndef VT_FB_MAX_WIDTH
> +#define  VT_FB_MAX_WIDTH 4096
>  #endif
> -#ifndef VT_FB_DEFAULT_HEIGHT
> -#define  VT_FB_DEFAULT_HEIGHT1200
> +#ifndef VT_FB_MAX_HEIGHT
> +#define  VT_FB_MAX_HEIGHT2400
>  #endif
>  
>  /* name argument is not used yet. */
> 
> Modified: head/sys/dev/vt/vt_core.c
> ==
> --- head/sys/dev/vt/vt_core.c Tue Jul 19 19:19:03 2016(r303042)
> +++ head/sys/dev/vt/vt_core.c Tue Jul 19 19:20:47 2016(r303043)
> @@ -181,8 +181,8 @@ static void vt_resume_handler(void *priv
>  
>  SET_DECLARE(vt_drv_set, struct vt_driver);
>  
> -#define  _VTDEFH MAX(100, PIXEL_HEIGHT(VT_FB_DEFAULT_HEIGHT))
> -#define  _VTDEFW MAX(200, PIXEL_WIDTH(VT_FB_DEFAULT_WIDTH))
> +#define  _VTDEFH MAX(100, PIXEL_HEIGHT(VT_FB_MAX_HEIGHT))
> +#define  _VTDEFW MAX(200, PIXEL_WIDTH(VT_FB_MAX_WIDTH))
>  
>  struct terminal  vt_consterm;
>  static struct vt_window  vt_conswindow;
> ___
> 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-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: r302324 - head/lib/libc/locale

[Kubilay Kocak]

On 15/07/2016 4:19 PM, Jung-uk Kim wrote:
> On 07/03/16 11:00 AM, Baptiste Daroussin wrote:
>> Author: bapt
>> Date: Sun Jul  3 15:00:12 2016
>> New Revision: 302324
>> URL: https://svnweb.freebsd.org/changeset/base/302324
>>
>> Log:
>>   Fix a bad test resulting in a segfault with ISO-8859-5 locales
>>   
>>   Reported by:   Lauri Tirkkonen from Illumos
>>   Approved by:   re@ (gjb)
>>
>> Modified:
>>   head/lib/libc/locale/collate.c
>>
>> Modified: head/lib/libc/locale/collate.c
>> ==
>> --- head/lib/libc/locale/collate.c   Sun Jul  3 11:45:54 2016
>> (r302323)
>> +++ head/lib/libc/locale/collate.c   Sun Jul  3 15:00:12 2016
>> (r302324)
>> @@ -310,7 +310,7 @@ _collate_lookup(struct xlocale_collate *
>>  if ((sptr = *state) != NULL) {
>>  *pri = *sptr;
>>  sptr++;
>> -if ((sptr == *state) || (sptr == NULL))
>> +if ((sptr == *state) || (*sptr == 0))
>>  *state = NULL;
>>  else
>>  *state = sptr;
> 
> I had a serious regression with ko_KR.UTF-8 locale after this commit.
> MATE is unusable because mate-panel is busy looping and eating 100% CPU.
>  GNOME 3 does not start at all, i.e., nothing but mouse cursor on black
> screen.  After reverting this commit, everything is back to normal.
> Please investigate.  IMHO, this must be fixed before 11.0-BETA2 build.
> 
> Thanks,
> 
> Jung-uk Kim
> 

Please report a bug so it can be tracked and not forgotten:

Add re@ and original committer to cc
Set mfc-stable11 to ?
Add keyword: regression

___
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: r295768 - head/usr.sbin/iostat

[Kubilay Kocak]

On 22/02/2016 8:56 PM, David Chisnall wrote:
> On 19 Feb 2016, at 23:23, Dimitry Andric  wrote:
>> 
>> This warning is only produced when you use -Wall -W, and then
>> initialize structs partially, i.e. you initialize some fields but
>> not others.  I think this is a quite reasonable warning for a high
>> warning level.
> 
> The warning is annoying in many ways.  You ought to be able to zero
> initialise any struct with {0}, but clang objects if you do this and
> requires every field to be filled in.  This warning really shouldn’t
> be enabled with -Wall, because it has too hight a false positive
> rate.

For the lay persons among us (I'm genuinely interested), what are the
the downsides to requiring initialization of all fields?

And in addition, the upsides, if any, of 'deferred' field initialization?

Is there a proper term for the above?

> With regard to Bruce’s comment about padding, this is a known issue
> in C11.  There is an open DR about it and it’s scheduled for
> discussion at the WG14 meeting in London in April.
> 
> David
> 

Koobs
___
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: r295796 - head/sys/net

[Kubilay Kocak]

On 19/02/2016 6:07 PM, Marcelo Araujo wrote:
> 
> 
> 2016-02-19 15:03 GMT+08:00 Kubilay Kocak <ko...@freebsd.org
> <mailto:ko...@freebsd.org>>:
> 
> On 19/02/2016 5:35 PM, Marcelo Araujo wrote:
> > Author: araujo
> > Date: Fri Feb 19 06:35:53 2016
> > New Revision: 295796
> > URL: https://svnweb.freebsd.org/changeset/base/295796
> >
> > Log:
> >   Fix regression introduced on 272446r.
> >
> >   lagg(4) supports the protocol none, where it disables any traffic 
> without
> >   disabling the lagg(4) interface itself.
> >
> >   PR: 206921
> >   Submitted by:   Pushkar Kothavade <pushka...@gmail.com 
> <mailto:pushka...@gmail.com>>
> >   Reviewed by:rpokala
> >   Approved by:bapt (mentor)
> >   MFC after:  3 weeks
> >   Sponsored by:   gandi.net <http://gandi.net>
> >   Differential Revision:  https://reviews.freebsd.org/D5076
> >
> 
> 10.3-R candidate?
> 
> 
> Yes, it is!
> 
> But the patch for 10-Stable is different than the one for HEAD, because
> lagg(4) code change between releases.
> 
> Patch for 10-Stable here:
> https://reviews.freebsd.org/D5226
> 
> I have contacted re@ already! I will do again.
> 
> 
> Best,
> -- 
> 
> -- 
> Marcelo Araujo(__)
> ara...@freebsd.org <mailto:ara...@freebsd.org> \\\'',)
> http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
> Power To Server. .\. /_)
> 

Much love, thank you Marcelo!

Might help marking these as such in the original head commit to prevent
annoying people (me) from pinging about it :)

For example, I'm also interested in all the recent PVS fixes, none of
which were marked for MFC, but appear to be very good at least
stable/10,9 candidates, if not 10.3-R.

./koobs
___
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: r295796 - head/sys/net

[Kubilay Kocak]

On 19/02/2016 5:35 PM, Marcelo Araujo wrote:
> Author: araujo
> Date: Fri Feb 19 06:35:53 2016
> New Revision: 295796
> URL: https://svnweb.freebsd.org/changeset/base/295796
> 
> Log:
>   Fix regression introduced on 272446r.
>   
>   lagg(4) supports the protocol none, where it disables any traffic without
>   disabling the lagg(4) interface itself.
>   
>   PR: 206921
>   Submitted by:   Pushkar Kothavade 
>   Reviewed by:rpokala
>   Approved by:bapt (mentor)
>   MFC after:  3 weeks
>   Sponsored by:   gandi.net
>   Differential Revision:  https://reviews.freebsd.org/D5076
> 

10.3-R candidate?

___
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: r295529 - in head/sys: net netinet netinet6

[Kubilay Kocak]

On 12/02/2016 4:07 AM, Devin Teske wrote:
> Author: dteske
> Date: Thu Feb 11 17:07:19 2016
> New Revision: 295529
> URL: https://svnweb.freebsd.org/changeset/base/295529
> 
> Log:
>   Merge SVN r295220 (bz) from projects/vnet/
>   
>   Fix a panic that occurs when a vnet interface is unavailable at the time the
>   vnet jail referencing said interface is stopped.
>   
>   Sponsored by:   FIS Global, Inc.


Was/is there a bugzilla issue for this?

Also, MFC and/or re (10.3-R) candidate?

> Modified:
>   head/sys/net/route.c
>   head/sys/netinet/in_rmx.c
>   head/sys/netinet6/in6_rmx.c
> Directory Properties:
>   head/   (props changed)
>   head/sys/   (props changed)
> 
> Modified: head/sys/net/route.c
> ==
> --- head/sys/net/route.c  Thu Feb 11 16:54:23 2016(r295528)
> +++ head/sys/net/route.c  Thu Feb 11 17:07:19 2016(r295529)
> @@ -353,10 +353,24 @@ rt_table_init(int offset)
>   return (rh);
>  }
>  
> +static int
> +rt_freeentry(struct radix_node *rn, void *arg)
> +{
> + struct radix_head * const rnh = arg;
> + struct radix_node *x;
> +
> + x = (struct radix_node *)rn_delete(rn + 2, NULL, rnh);
> + if (x != NULL)
> + R_Free(x);
> + return (0);
> +}
> +
>  void
>  rt_table_destroy(struct rib_head *rh)
>  {
>  
> + rn_walktree(>rmhead.head, rt_freeentry, >rmhead.head);
> +
>   /* Assume table is already empty */
>   rw_destroy(>rib_lock);
>   free(rh, M_RTABLE);
> 
> Modified: head/sys/netinet/in_rmx.c
> ==
> --- head/sys/netinet/in_rmx.c Thu Feb 11 16:54:23 2016(r295528)
> +++ head/sys/netinet/in_rmx.c Thu Feb 11 17:07:19 2016(r295529)
> @@ -133,7 +133,8 @@ int
>  in_detachhead(void **head, int off)
>  {
>  
> - return (rn_detachhead(head));
> + rt_table_destroy((struct rib_head *)(*head));
> + return (1);
>  }
>  #endif
>  
> 
> Modified: head/sys/netinet6/in6_rmx.c
> ==
> --- head/sys/netinet6/in6_rmx.c   Thu Feb 11 16:54:23 2016
> (r295528)
> +++ head/sys/netinet6/in6_rmx.c   Thu Feb 11 17:07:19 2016
> (r295529)
> @@ -237,7 +237,9 @@ in6_detachhead(void **head, int off)
>  {
>  
>   callout_drain(_rtq_mtutimer);
> - return (rn_detachhead(head));
> + rt_table_destroy((struct rib_head *)(*head));
> +
> + return (1);
>  }
>  #endif
>  
> ___
> svn-src-head@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
> 

___
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: r295385 - in head: sys/kern tools/regression/sysvsem

[Kubilay Kocak]

On 8/02/2016 9:12 AM, Jilles Tjoelker wrote:
> Author: jilles
> Date: Sun Feb  7 22:12:39 2016
> New Revision: 295385
> URL: https://svnweb.freebsd.org/changeset/base/295385
> 
> Log:
>   semget(): Check for [EEXIST] error first.
>   
>   Although POSIX literally permits failing with [EINVAL] if IPC_CREAT and
>   IPC_EXCL were both passed, the semaphore set already exists and has fewer
>   semaphores than nsems, this does not allow an application to retry safely:
>   if the [EINVAL] is actually because of the semmsl limit, an infinite loop
>   would result.
>   
>   PR: 206927
> 
> Modified:
>   head/sys/kern/sysv_sem.c
>   head/tools/regression/sysvsem/semtest.c


+infinity for bugfix & issue reference & regression test.

Thank you Jilles!

> Modified: head/sys/kern/sysv_sem.c
> ==
> --- head/sys/kern/sysv_sem.c  Sun Feb  7 21:25:08 2016(r295384)
> +++ head/sys/kern/sysv_sem.c  Sun Feb  7 22:12:39 2016(r295385)
> @@ -867,6 +867,11 @@ sys_semget(struct thread *td, struct sem
>   }
>   if (semid < seminfo.semmni) {
>   DPRINTF(("found public key\n"));
> + if ((semflg & IPC_CREAT) && (semflg & IPC_EXCL)) {
> + DPRINTF(("not exclusive\n"));
> + error = EEXIST;
> + goto done2;
> + }
>   if ((error = ipcperm(td, [semid].u.sem_perm,
>   semflg & 0700))) {
>   goto done2;
> @@ -876,11 +881,6 @@ sys_semget(struct thread *td, struct sem
>   error = EINVAL;
>   goto done2;
>   }
> - if ((semflg & IPC_CREAT) && (semflg & IPC_EXCL)) {
> - DPRINTF(("not exclusive\n"));
> - error = EEXIST;
> - goto done2;
> - }
>  #ifdef MAC
>   error = mac_sysvsem_check_semget(cred, [semid]);
>   if (error != 0)
> 
> Modified: head/tools/regression/sysvsem/semtest.c
> ==
> --- head/tools/regression/sysvsem/semtest.c   Sun Feb  7 21:25:08 2016
> (r295384)
> +++ head/tools/regression/sysvsem/semtest.c   Sun Feb  7 22:12:39 2016
> (r295385)
> @@ -152,6 +152,15 @@ main(int argc, char *argv[])
>  
>   print_semid_ds(_ds, 0600);
>  
> + errno = 0;
> + if (semget(semkey, 1, IPC_CREAT | IPC_EXCL | 0600) != -1 ||
> + errno != EEXIST)
> + err(1, "semget IPC_EXCL 1 did not fail with [EEXIST]");
> + errno = 0;
> + if (semget(semkey, 2, IPC_CREAT | IPC_EXCL | 0600) != -1 ||
> + errno != EEXIST)
> + err(1, "semget IPC_EXCL 2 did not fail with [EEXIST]");
> +
>   for (child_count = 0; child_count < 5; child_count++) {
>   switch ((child_pid = fork())) {
>   case -1:


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r294778 - in head: lib/libc/sys sys/kern

[Kubilay Kocak]

On 26/01/2016 10:38 PM, Bruce Evans wrote:
> On Tue, 26 Jan 2016, Kubilay Kocak wrote:
> 
>>> Log:
>>>   Restore flushing of output for revoke(2) again.  Document revoke()'s
>>>   intended behaviour in its man page.  Simplify tty_drain() to match.
>>>   Don't call ttydevsw methods in tty_flush() if the device is gone
>>>   since we now sometimes call it then.
>>> ...
>>>   This was first broken then fixed in 1995.  I changed only the tty
>>> ...
>>
>> Seems like
>>
>>>   This was next broken in 1997 then fixed in 1998.  Importing Lite2 made
>>> ...
>>
>> A fantastic
>>
>>>   This was next broken in 2008 by replacing everything in tty.c and not
>>> ...
>>
>> Regression test candidate :)
>>
>>>   It is now possible to fix this better using the new FREVOKE flag.
> 
> Regression tests for devices are difficult to write and more difficult
> to run.  Simpler for ttys than for networking or disks, but you still
> need at least 2 generic tty ports just to test things that are not
> very related to hardware.

Of course, though perhaps mocking external subsystems/components is
something we could do, as is relatively standard for testing only the
code you want to cover, rather than (requiring) the entire integration.

> Bugs in flushing and draining are sometimes obvious by observing if
> echo 123 >/dev/ttyXx works when it should fail or fails when it should
> work.
> 
> For more arcane bugs, I use the old NIST POSIX test suite.  This is
> badly written and hard to use and not very complete, but it finds about
> 30 regressions between FreeBSD-5 and FreeBSD-9.  30 over-counts for error
> cascades but undercounts for blocking and some other timing bugs, and
> of course strict POSIX tests don't get near FreeBSD features like
> revoke() or bidrectional devices.
> 
> Bruce

___
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: r294778 - in head: lib/libc/sys sys/kern

[Kubilay Kocak]

On 26/01/2016 6:57 PM, Konstantin Belousov wrote:
> Author: kib
> Date: Tue Jan 26 07:57:44 2016
> New Revision: 294778
> URL: https://svnweb.freebsd.org/changeset/base/294778
> 
> Log:
>   Restore flushing of output for revoke(2) again.  Document revoke()'s
>   intended behaviour in its man page.  Simplify tty_drain() to match.
>   Don't call ttydevsw methods in tty_flush() if the device is gone
>   since we now sometimes call it then.
>   
>   The flushing was supposed to be implemented by passing the FNONBLOCK
>   flag to VOP_CLOSE() for revoke().  The tty driver is one of the few
>   that can block in close and was one of the fewer that knew about this.
>   
>   This almost worked in FreeBSD-1 and similarly in Net/2.  These
>   versions only almost worked because there was and is considerable
>   confusion between IO_NDELAY and FNONBLOCK (aka O_NONBLOCK).  IO_NDELAY
>   is only valid for VOP_READ() and VOP_WRITE().  For other VOPs it has
>   the same value as O_SHLOCK.  But since vfs_subr.c and tty.c
>   consistently used the wrong flag and the O_SHLOCK flag is rarely set,
>   this mostly worked.  It also gave the feature than applications could
>   get the non-blocking close by abusing O_SHLOCK.
>   
>   This was first broken then fixed in 1995.  I changed only the tty
>   driver to use FNONBLOCK, as a hack to get non-blocking via the normal
>   flag FNONBLOCK for last closes.  I didn't know about revoke()'s use
>   of IO_NDELAY or change it to be consistent, so revoke() was broken.
>   Then I changed revoke() to match.

Seems like

>   This was next broken in 1997 then fixed in 1998.  Importing Lite2 made
>   the flags inconsistent again by undoing the fix only in vfs_subr.c.

A fantastic

>   This was next broken in 2008 by replacing everything in tty.c and not
>   checking any flags in last close.  Other bugs in draining limited the
>   resulting unbounded waits to drain in some cases.

Regression test candidate :)

>   It is now possible to fix this better using the new FREVOKE flag.
>   Just restore flushing for revoke() for now.  Don't restore or undo any
>   hacks for ordinary last closes yet.  But remove dead code in the
>   1-second relative timeout (r272789).  This did extra work to extend
>   the buggy draining for revoke() for as long as possible.  The 1-second
>   timeout made this not very long by usually flushing after 1 second.
>   
>   Submitted by:   bde
>   MFC after:  2 weeks
> 
> Modified:
>   head/lib/libc/sys/revoke.2
>   head/sys/kern/tty.c
> 
> Modified: head/lib/libc/sys/revoke.2
> ==
> --- head/lib/libc/sys/revoke.2Tue Jan 26 07:49:11 2016
> (r294777)
> +++ head/lib/libc/sys/revoke.2Tue Jan 26 07:57:44 2016
> (r294778)
> @@ -31,7 +31,7 @@
>  .\" @(#)revoke.2 8.1 (Berkeley) 6/4/93
>  .\" $FreeBSD$
>  .\"
> -.Dd June 4, 1993
> +.Dd Jan 25, 2016
>  .Dt REVOKE 2
>  .Os
>  .Sh NAME
> @@ -59,7 +59,8 @@ and a
>  system call will succeed.
>  If the file is a special file for a device which is open,
>  the device close function
> -is called as if all open references to the file had been closed.
> +is called as if all open references to the file had been closed
> +using a special close method which does not block.
>  .Pp
>  Access to a file may be revoked only by its owner or the super user.
>  The
> @@ -104,3 +105,6 @@ The
>  .Fn revoke
>  system call first appeared in
>  .Bx 4.3 Reno .
> +.Sh BUGS
> +The non-blocking close method is only correctly implemented for
> +terminal devices.
> 
> Modified: head/sys/kern/tty.c
> ==
> --- head/sys/kern/tty.c   Tue Jan 26 07:49:11 2016(r294777)
> +++ head/sys/kern/tty.c   Tue Jan 26 07:57:44 2016(r294778)
> @@ -126,7 +126,7 @@ static int
>  tty_drain(struct tty *tp, int leaving)
>  {
>   size_t bytesused;
> - int error, revokecnt;
> + int error;
>  
>   if (ttyhook_hashook(tp, getc_inject))
>   /* buffer is inaccessible */
> @@ -141,18 +141,10 @@ tty_drain(struct tty *tp, int leaving)
>  
>   /* Wait for data to be drained. */
>   if (leaving) {
> - revokecnt = tp->t_revokecnt;
>   error = tty_timedwait(tp, >t_outwait, hz);
> - switch (error) {
> - case ERESTART:
> - if (revokecnt != tp->t_revokecnt)
> - error = 0;
> - break;
> - case EWOULDBLOCK:
> - if (ttyoutq_bytesused(>t_outq) < bytesused)
> - error = 0;
> - break;
> - }
> + if (error == EWOULDBLOCK &&
> + ttyoutq_bytesused(>t_outq) < bytesused)
> + error 

Re: svn commit: r294627 - head/share/man/man5

[Kubilay Kocak]

On 23/01/2016 11:25 PM, Edward Tomasz Napierala wrote:
> Author: trasz
> Date: Sat Jan 23 12:25:24 2016
> New Revision: 294627
> URL: https://svnweb.freebsd.org/changeset/base/294627
> 
> Log:
>   Advertise support for ext3 and ext4.
>   
>   MFC after:  1 month
>   Sponsored by:   The FreeBSD Foundation
> 
> Modified:
>   head/share/man/man5/ext2fs.5
> 
> Modified: head/share/man/man5/ext2fs.5
> ==
> --- head/share/man/man5/ext2fs.5  Sat Jan 23 12:19:37 2016
> (r294626)
> +++ head/share/man/man5/ext2fs.5  Sat Jan 23 12:25:24 2016
> (r294627)
> @@ -26,12 +26,12 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd October 1, 2013
> +.Dd January 23, 2016
>  .Dt EXT2FS 5
>  .Os
>  .Sh NAME
>  .Nm ext2fs
> -.Nd "Ext2fs file system"
> +.Nd "ext2/ext3/ext4 file system"
>  .Sh SYNOPSIS
>  To link into the kernel:
>  .Bd -ragged -offset indent
> @@ -47,8 +47,14 @@ The
>  driver will permit the
>  .Fx
>  kernel to access
> -.Tn Ext2
> +.Tn ext2 ,
> +.Tn ext3 ,
> +and
> +.Tn ext4
>  file systems.
> +The
> +.Tn ext4
> +support is read-only.
>  .Sh EXAMPLES
>  To mount a
>  .Nm

Thanks for this :)

Thoughts on renaming the module to something less specific than ext2,
like extfs? Does anyone remember this question coming up before?

If I had a dollar for every user I've helped find this, that has replied
'oh! I thought that was only ext2', I'd have like $43.

Also, any reason why we don't have a mount_extfs(8) command? Can we also
have (man,mount) aliases for each of extN that is supported?

Asking for a friend (the community)

./koobs
___
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: r293854 - head/sys/dev/e1000

[Kubilay Kocak]

On 14/01/2016 8:47 AM, Marius Strobl wrote:
> Author: marius
> Date: Wed Jan 13 21:47:27 2016
> New Revision: 293854
> URL: https://svnweb.freebsd.org/changeset/base/293854
> 
> Log:
>   Given that em(4), lem(4) and igb(4) hardware doesn't require the
>   alignment guarantees provided by m_defrag(9), use m_collapse(9)
>   instead for performance reasons.
>   While at it, sanitize the statistics softc members, i. e. retire
>   unused ones and add SYSCTL nodes missing for actually used ones.
>   
>   Differential Revision:  https://reviews.freebsd.org/D4717
> 
> Modified:
>   head/sys/dev/e1000/if_em.c
>   head/sys/dev/e1000/if_em.h
>   head/sys/dev/e1000/if_igb.c
>   head/sys/dev/e1000/if_igb.h
>   head/sys/dev/e1000/if_lem.c
>   head/sys/dev/e1000/if_lem.h

What kind of performance / overhead delta can be expected for this change?

Is this worth MFC and/or Relnotes ?
___
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: r293739 - head/release

[Kubilay Kocak]

On 12/01/2016 8:42 PM, Colin Percival wrote:
> Author: cperciva
> Date: Tue Jan 12 09:42:21 2016
> New Revision: 293739
> URL: https://svnweb.freebsd.org/changeset/base/293739
> 
> Log:
>   Enable "EC2 Enhanced Networking" (aka. SR-IOV networking) when creating
>   EC2 images.
>   
>   X-MFC after:if/when the driver fixes get MFCed

Is there a Bugzilla issue reference for this (or the head changeset)?

>   Relnotes:   FreeBSD now supports EC2 Enhanced Networking
> 
> Modified:
>   head/release/Makefile.ec2
> 
> Modified: head/release/Makefile.ec2
> ==
> --- head/release/Makefile.ec2 Tue Jan 12 09:27:01 2016(r293738)
> +++ head/release/Makefile.ec2 Tue Jan 12 09:42:21 2016(r293739)
> @@ -51,7 +51,7 @@ ec2ami: cw-ec2 ${CW_EC2_PORTINSTALL}
>   @echo "--"
>   @false
>  .endif
> - /usr/local/bin/bsdec2-image-upload ${PUBLISH} \
> + /usr/local/bin/bsdec2-image-upload ${PUBLISH} --sriov \
>   ${.OBJDIR}/ec2.raw \
>   "${TYPE} ${REVISION}-${BRANCH}-${TARGET}${AMINAMESUFFIX}" \
>   "${TYPE} ${REVISION}-${BRANCH}-${TARGET}" \
> ___
> 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-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: r292379 - in head/sys: netinet netinet6

[Kubilay Kocak]

On 18/12/2015 9:55 AM, Steven Hartland wrote:
> On 17/12/2015 19:20, Gleb Smirnoff wrote:
>>Steven,
>>
>> another feasible solution for the design described in the 156226
>> would be to run STP on the switches, and if_bridge(4) instead of
>> if_lagg(4) on FreeBSD, also with STP enabled. Would work perfectly.
>>
>> Of course, if switches are dumb and cheap, and can't do STP,
>> then a tiny bpf-writer is the right solution.
>>
>> P.S. When I was running network in my university dormitory, we
>> used a lot of cheap solutions, and a lot of dirty workarounds,
>> but none of the latter made its way to FreeBSD kernel. You can
>> also ask Eugene Grosbein, he also has huge experience of living
>> on not so pleasant workarounds, but not pushing them agrressively
>> into the kernel.
>>
> Last time I heard STP is a bad word in networking, so I'm sure they
> network team
> would have me crucified for even suggesting it and start shouting MLAG
> for the
> rest of the day ;-)
> 
> Regards
> Steve

FWIW, during my testing at $lastjob, STP-enabled switches didn't provide
optimial failback times, even with portfast enabled.

This was for two FreeBSD machines providing HA network management
services for multiple backends configured with dual-port bge/em NIC's
configured with lagg(4) (bge0/em0, bge1,em1) in failover mode (no
aggregation), with multiple carp(4) interfaces for public service IP's
on top.

___
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: r292379 - in head/sys: netinet netinet6

[Kubilay Kocak]

On 17/12/2015 11:38 AM, Gleb Smirnoff wrote:
>   I'm sorry that wasn't able to review D4111 in time, but I have
> very strong concerns against r292275. And r292379 doesn't
> improve situation. I am asking you to back out both patches,
> and then we can get together back to the problem. The 156226
> bug was sitting for 2 years in the bugzilla for a reason. It
> is a not "low hanging fruit" like koobs@ says.

To clarify my comment on the review, I intended to refer to the *value*,
and concrete *definition* of the desired feature (ie the problem space),
not the triviality of any solution or implementation.

I do my best not to presume where I don't have knowledge :)

./koobs
___
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: r291460 - head/sys/kern

[Kubilay Kocak]

On 30/11/2015 8:42 AM, Kirk McKusick wrote:
> Author: mckusick
> Date: Sun Nov 29 21:42:26 2015
> New Revision: 291460
> URL: https://svnweb.freebsd.org/changeset/base/291460
> 
> Log:
>   As the kernel allocates and frees vnodes, it fully initializes them
>   on every allocation and fully releases them on every free.  These
>   are not trivial costs: it starts by zeroing a large structure then
>   initializes a mutex, a lock manager lock, an rw lock, four lists,
>   and six pointers. And looking at vfs.vnodes_created, these operations
>   are being done millions of times an hour on a busy machine.
>   
>   As a performance optimization, this code update uses the uma_init
>   and uma_fini routines to do these initializations and cleanups only
>   as the vnodes enter and leave the vnode_zone. With this change the
>   initializations are only done kern.maxvnodes times at system startup
>   and then only rarely again. The frees are done only if the vnode_zone
>   shrinks which never happens in practice. For those curious about the
>   avoided work, look at the vnode_init() and vnode_fini() functions in
>   kern/vfs_subr.c to see the code that has been removed from the main
>   vnode allocation/free path.
>   
>   Reviewed by: kib
>   Tested by:   Peter Holm
> 
> Modified:
>   head/sys/kern/vfs_subr.c
> 

Kirk,

Very interesting.

Any estimation / expectation on the performance impact^W benefit of
this, and in what scenario's / use-cases it might be particularly
beneficial? Any benchmarks or tests you can share?

./koobs

___
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: r290433 - in head: share/mk sys/conf tools/build/options

[Kubilay Kocak]

On 6/11/2015 4:52 PM, Dmitry Sivachenko wrote:
> 
> 
>> 6 нояб. 2015 г., в 8:00, Bryan Drewery  написал(а):
>>
>>> On 11/5/15 8:59 PM, Dmitry Sivachenko wrote:
>>>
 On 06 Nov 2015, at 07:45, Bryan Drewery  wrote:

 Author: bdrewery
 Date: Fri Nov  6 04:45:29 2015
 New Revision: 290433
 URL: https://svnweb.freebsd.org/changeset/base/290433

 Log:
 Add a FAST_DEPEND option, off by default, which speeds up the build 
 significantly.
>>>
>>>
>>> Well, if it just a speedup, what is the reason to introduce a new option 
>>> for that?
>>
>> "Enabling this by default, for src or out-of-src, can be done once more
>> testing has been done, such as a ports exp-run, and with more compilers."
> 
> 
> Well, this is what -current is for. Just let it settle longer before MFC.
> 

Having an option in the first instance is also quite considerate, as it
ensures that this work doesn't block/frustrate people dogfooding CURRENT
if it ends up having issues that can't quickly be fixed without a revert.




___
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: r290387 - head/sys/cam/scsi

[Kubilay Kocak]

On 5/11/2015 8:07 PM, Alexander Motin wrote:
> Author: mav
> Date: Thu Nov  5 09:07:53 2015
> New Revision: 290387
> URL: https://svnweb.freebsd.org/changeset/base/290387
> 
> Log:
>   Extend mask of VMware virtual disks.
> 
> Modified:
>   head/sys/cam/scsi/scsi_da.c
> 
> Modified: head/sys/cam/scsi/scsi_da.c
> ==
> --- head/sys/cam/scsi/scsi_da.c   Thu Nov  5 08:27:45 2015
> (r290386)
> +++ head/sys/cam/scsi/scsi_da.c   Thu Nov  5 09:07:53 2015
> (r290387)
> @@ -368,7 +368,7 @@ static struct da_quirk_entry da_quirk_ta
>* VMware returns BUSY status when storage has transient
>* connectivity problems, so better wait.
>*/
> - {T_DIRECT, SIP_MEDIA_FIXED, "VMware", "Virtual disk", "*"},
> + {T_DIRECT, SIP_MEDIA_FIXED, "VMware*", "*", "*"},
>   /*quirks*/ DA_Q_RETRY_BUSY
>   },
>   /* USB mass storage devices supported by umass(4) */
> ___
> 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"
> 


Ooo, thank you! I forgot to test your patch :)
___
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: r284198 - head/bin/ls

[Kubilay Kocak]

On 15/06/2015 5:19 AM, Garrett Cooper wrote:
 
 Next time someone else converts ANYTHING to libxo -- write tests
 FIRST to make sure you're not breaking legacy behavior. If you need
 help figuring out how to do that, I'll be more than happy to document
 it on a wiki page, with simple, concise directions.
 
 

Please do so anyway, these kinds of things are great (simple) ways for
people inside and outside the project to start contributing to.

*Then* perhaps we can hook in some code coverage checks into our CI,
publish the numbers and go from there.

Koobs
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r280308 - head/sys/fs/devfs

[Kubilay Kocak]

On 22/03/2015 1:27 AM, Konstantin Belousov wrote:
 On Sat, Mar 21, 2015 at 11:00:09PM +1100, Kubilay Kocak wrote:
 On 21/03/2015 12:14 PM, Xin LI wrote:
 Author: delphij
 Date: Sat Mar 21 01:14:11 2015
 New Revision: 280308
 URL: https://svnweb.freebsd.org/changeset/base/280308

 Log:
   Disable timestamping on devfs read/write operations by default.
   
   Currently we update timestamps unconditionally when doing read or
   write operations.  This may slow things down on hardware where
   reading timestamps is expensive (e.g. HPET, because of the default
   vfs.timestamp_precision setting is nanosecond now) with limited
   benefit.
   
   A new sysctl variable, vfs.devfs.dotimes is added, which can be
   set to non-zero value when the old behavior is desirable.

 Perhaps *devfs_timestamp_update* is a better name. thoughts?

 If something shorter is desired: devfs_ts_update might be ok, though I
 prefer the former.

 Let's not forget these are user visible system control knobs, not just
 code variables, though I do understand the desire to shorten them, and
 that we do have descriptions for them ... mostly :)
 
 should it be
 vfs.devfs.devfs_ts_devfs_ts_devfs_update_devfs
 so that user is _absolutely_ sure that it is devfs related, if 'devfs'
 used only one time in the MIB prevents him from realizing this ?
 

s/_/.

devfs.timestamp_update

sorry. :)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r280308 - head/sys/fs/devfs

[Kubilay Kocak]

On 21/03/2015 12:14 PM, Xin LI wrote:
 Author: delphij
 Date: Sat Mar 21 01:14:11 2015
 New Revision: 280308
 URL: https://svnweb.freebsd.org/changeset/base/280308
 
 Log:
   Disable timestamping on devfs read/write operations by default.
   
   Currently we update timestamps unconditionally when doing read or
   write operations.  This may slow things down on hardware where
   reading timestamps is expensive (e.g. HPET, because of the default
   vfs.timestamp_precision setting is nanosecond now) with limited
   benefit.
   
   A new sysctl variable, vfs.devfs.dotimes is added, which can be
   set to non-zero value when the old behavior is desirable.

Perhaps *devfs_timestamp_update* is a better name. thoughts?

If something shorter is desired: devfs_ts_update might be ok, though I
prefer the former.

Let's not forget these are user visible system control knobs, not just
code variables, though I do understand the desire to shorten them, and
that we do have descriptions for them ... mostly :)

koobs
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r270417 - head/release/arm

[Kubilay Kocak]

On 24/08/2014 1:59 AM, Glen Barber wrote:
 Author: gjb
 Date: Sat Aug 23 15:59:31 2014
 New Revision: 270417
 URL: http://svnweb.freebsd.org/changeset/base/270417
 
 Log:
   Fix arm build breakage when building stable/10 on
   head/.
   
   MFC after:  3 days
   Sponsored by:   The FreeBSD Foundation
 
 Modified:
   head/release/arm/release.sh
 
 Modified: head/release/arm/release.sh
 ==
 --- head/release/arm/release.sh   Sat Aug 23 15:54:22 2014
 (r270416)
 +++ head/release/arm/release.sh   Sat Aug 23 15:59:31 2014
 (r270417)
 @@ -92,6 +92,10 @@ install_uboot() {
  }
  
  main() {
 + # Fix broken ports that use kern.osreldate.
 + OSVERSION=$(chroot ${CHROOTDIR} /usr/bin/uname -U)
 + export OSVERSION
 +
   # Build the 'xdev' target for crochet.
   eval chroot ${CHROOTDIR} make -C /usr/src \
   ${XDEV_FLAGS} XDEV=${XDEV} XDEV_ARCH=${XDEV_ARCH} \
 ___
 svn-src-head@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-head
 To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
 

Is this an individual port issue, or a ports framework issue?

What should broken ports use?
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: Phabric IDs / URLs in commits

[Kubilay Kocak]

On 16/07/2014 1:12 AM, John Baldwin wrote:
 On Friday, July 11, 2014 1:54:42 pm Baptiste Daroussin wrote:
 On Fri, Jul 11, 2014 at 12:38:23PM -0400, John Baldwin wrote:
 On Friday, July 11, 2014 12:16:26 pm John Baldwin wrote:
 Author: jhb
 Date: Fri Jul 11 16:16:26 2014
 New Revision: 268531
 URL: http://svnweb.freebsd.org/changeset/base/268531

 Log:
   Fix some edge cases with rewinddir():
   - In the unionfs case, opendir() and fdopendir() read the directory's 
 full
 contents and cache it.  This cache is not refreshed when rewinddir() is
 called, so rewinddir() will not notice updates to a directory.  Fix 
 this
 by splitting the code to fetch a directory's contents out of
 __opendir_common() into a new _filldir() function and call this from
 rewinddir() when operating on a unionfs directory.
   - If rewinddir() is called on a directory opened with fdopendir() before
 any directory entries are fetched, rewinddir() will not adjust the seek
 location of the backing file descriptor.  If the file descriptor passed
 to fdopendir() had a non-zero offset, the rewinddir() will not rewind 
 to
 the beginning.  Fix this by always seeking back to 0 in rewinddir().
 This means the dd_rewind hack can also be removed.
   
   While here, add missing locking to rewinddir().
   
   CR:  https://phabric.freebsd.org/D312
   Reviewed by: jilles
   MFC after:   1 week

 Just picking my own commit here as a sample case.

 I think we should be annotating commits with phabricator code reviews in 
 some 
 way when a change has gone through that review.  It is very useful to get 
 back
 to the review details from the commit log message in svnweb, etc.

 I can see a number of different ways to do this, but I do think it would be
 nice to pick a consistent way to do it.

 Things to consider:

 1) The tag (CR: is what I used above).  I don't care, just pick one.  I
chose CR since Warner used it previously.  Whatever we decide, we should
add it to the template.

 2) ID vs full URL.  For PRs we just list the bug ID and not the full URL
(same for Coverity).  I would be fine with that so long as someone hacks
up svnweb to convert the IDs into links (the way it handles PR bug
numbers).  OTOH, if you use the full URL you get that for free in svnweb,
and you also get it in mail clients, etc.  It helps that the URL isn't 
 but
so long.

 for bugs we could use http://bugs.FreeBSD.org/number that also works and 
 it is
 short :)
 
 Ok, so Bryan said ports uses 'Phabric: Dxxx' and I read Baptiste's e-mail as a
 preference for the URL itself (no preference on the prefix though?)  Any other
 thoughts?  I probably lean towards the full URL personally since it requires 
 less
 work (no hacking on svnweb) and works out-of-the-box in more forums (e-mail, 
 etc.)
 

+100 on CR: ID-including-D-prefix without URL's to keep them decoupled
and forever valid in the (probably very likely) case we change
hostnames/urls.

I'm liking phabric so far, but would opt for a more concrete
review.freebsd.org if I had the choice (and when it's ready). This way
our review processes and workflows can be extended or modified
orthogonal to the tool in use.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver

[Kubilay Kocak]

On 10/04/2014 12:01 AM, Dag-Erling Smørgrav wrote:
 Bryan Drewery bdrew...@freebsd.org writes:
 Also, that this was a partial release of 1.0.1g is confusing a LOT of
 users. They think they are still vulnerable. They expect to see 1.0.1g
 in 'openssl version'. We could have our own version string in 'openssl
 version' to remedy this.
 
 This is no different from what other OSes do, e.g. RHEL6.5:
 
 % cat /etc/redhat-release 
 Red Hat Enterprise Linux Workstation release 6.5 (Santiago)
 % openssl version
 OpenSSL 1.0.1e-fips 11 Feb 2013
 % TZ=UTC rpm -qi openssl
 Name: openssl  Relocations: (not relocatable)
 Version : 1.0.1eVendor: Red Hat, Inc.
 Release : 16.el6_5.7Build Date: Mon 07 Apr 2014 
 11:34:45 AM UTC
 Install Date: Tue 08 Apr 2014 05:18:52 AM UTC  Build Host: 
 x86-027.build.eng.bos.redhat.com
 [...]
 
 which despite the version number and date is *not* vulnerable.
 
 DES
 

More precisely, users expect *not* to see 1.0.1e

That expectation is orthogonal to whether we or other projects do it one
way or another. RHEL users may well be as confused as ours (whether of
not ours are). It may be relevant as a data point, but not for decision
making.

Whether its just 1.0.1e, a full 1.0.1g, e+foo, or additional meta
obviously matters, but it's not as important as distinguishing 'what we
want' with how we're going to do it and why.

I'll give it a crack:

Our users can quickly and clearly see and know, on the system, when a
vendored library or piece of software in base is patched, or partially
updated to account for bugs or security vulnerabilities in a supported
version of FreeBSD

./koobs
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r263978 - head/sys/cam/ctl

[Kubilay Kocak]

On 1/04/2014 7:49 AM, Edward Tomasz Napierala wrote:
 Author: trasz
 Date: Mon Mar 31 20:49:33 2014
 New Revision: 263978
 URL: http://svnweb.freebsd.org/changeset/base/263978
 
 Log:
   Make it possible to have multiple CTL worker threads.  Leave the default
   of 1 for now.
   
   Sponsored by:   The FreeBSD Foundation
 
 Modified:
   head/sys/cam/ctl/ctl.c
 
 Modified: head/sys/cam/ctl/ctl.c
 ==
 --- head/sys/cam/ctl/ctl.cMon Mar 31 19:58:08 2014(r263977)
 +++ head/sys/cam/ctl/ctl.cMon Mar 31 20:49:33 2014(r263978)
 @@ -60,6 +60,7 @@ __FBSDID($FreeBSD$);
  #include sys/ioccom.h
  #include sys/queue.h
  #include sys/sbuf.h
 +#include sys/smp.h
  #include sys/endian.h
  #include sys/sysctl.h
  
 @@ -320,6 +321,10 @@ static int ctl_is_single = 1;
  static int index_to_aps_page;
  
  SYSCTL_NODE(_kern_cam, OID_AUTO, ctl, CTLFLAG_RD, 0, CAM Target Layer);
 +static int worker_threads = 1;
 +TUNABLE_INT(kern.cam.ctl.worker_threads, worker_threads);
 +SYSCTL_INT(_kern_cam_ctl, OID_AUTO, worker_threads, CTLFLAG_RDTUN,
 +worker_threads, 1, Number of worker threads);
  
  /*
   * Serial number (0x80), device id (0x83), and supported pages (0x00)
 @@ -950,10 +955,7 @@ ctl_init(void)
   struct ctl_frontend *fe;
   struct ctl_lun *lun;
  uint8_t sc_id =0;
 -#if 0
 - int i;
 -#endif
 - int error, retval;
 + int i, error, retval;
   //int isc_retval;
  
   retval = 0;
 @@ -1085,17 +1087,35 @@ ctl_init(void)
   mtx_unlock(softc-ctl_lock);
  #endif
  
 - error = kproc_create(ctl_work_thread, softc, softc-work_thread, 0, 0,
 -  ctl_thrd);
 - if (error != 0) {
 - printf(error creating CTL work thread!\n);
 - mtx_lock(softc-ctl_lock);
 - ctl_free_lun(lun);
 - mtx_unlock(softc-ctl_lock);
 - ctl_pool_free(internal_pool);
 - ctl_pool_free(emergency_pool);
 - ctl_pool_free(other_pool);
 - return (error);
 + if (worker_threads  MAXCPU || worker_threads == 0) {
 + printf(invalid kern.cam.ctl.worker_threads value; 
 + setting to 1);
 + worker_threads = 1;
 + } else if (worker_threads  0) {

Why is it that the  0 case is special enough that it gets the mp_ncpus
check below, but the == 0 and  MAXCPU cases don't?

 + if (mp_ncpus  2) {
 + /*
 +  * Using more than two worker threads actually hurts
 +  * performance due to lock contention.
 +  */

 + worker_threads = 2;
 + } else {
 + worker_threads = 1;
 + }

Are printf(Setting to N)'s worthwhile here as well given
worker_threads is set to a value that wasn't specified by the user, as
above?

 + }
 +
 + for (i = 0; i  worker_threads; i++) {
 + error = kproc_create(ctl_work_thread, softc, 
 softc-work_thread, 0, 0,
 + ctl_thrd%d, i);
 + if (error != 0) {
 + printf(error creating CTL work thread!\n);
 + mtx_lock(softc-ctl_lock);
 + ctl_free_lun(lun);
 + mtx_unlock(softc-ctl_lock);
 + ctl_pool_free(internal_pool);
 + ctl_pool_free(emergency_pool);
 + ctl_pool_free(other_pool);
 + return (error);
 + }
   }
   if (bootverbose)
   printf(ctl: CAM Target Layer loaded\n);
 @@ -12991,7 +13011,11 @@ ctl_work_thread(void *arg)
   if (io != NULL) {
   STAILQ_REMOVE_HEAD(softc-rtr_queue, links);
   mtx_unlock(softc-ctl_lock);
 - goto execute;
 + retval = ctl_scsiio(io-scsiio);
 + if (retval != CTL_RETVAL_COMPLETE)
 + CTL_DEBUG_PRINT((ctl_scsiio 
 failed\n));
 + mtx_lock(softc-ctl_lock);
 + continue;
   }
   }
   io = (union ctl_io *)STAILQ_FIRST(softc-incoming_queue);
 @@ -13022,19 +13046,6 @@ ctl_work_thread(void *arg)
  
   /* Back to the top of the loop to see what woke us up. */
   continue;
 -
 -execute:
 - retval = ctl_scsiio(io-scsiio);
 - switch (retval) {
 - case CTL_RETVAL_COMPLETE:
 - break;
 - default:
 - /*
 -  * Probably need to make sure this doesn't happen.
 -  */
 - break;
 - }
 - mtx_lock(softc-ctl_lock);
   }
  }
  
 ___
 

Re: svn commit: r256066 - head/sys/dev/virtio/network

[Kubilay Kocak]

On 6/10/2013 5:07 AM, Bryan Venteicher wrote:
 Author: bryanv
 Date: Sat Oct  5 18:07:24 2013
 New Revision: 256066
 URL: http://svnweb.freebsd.org/changeset/base/256066
 
 Log:
   Do not hold the vtnet Rx queue lock when calling up into the stack
   
   This matches other similar drivers and avoids various LOR warnings.
   
   Approved by:re (marius)
 
 Modified:
   head/sys/dev/virtio/network/if_vtnet.c
 
 Modified: head/sys/dev/virtio/network/if_vtnet.c
 ==
 --- head/sys/dev/virtio/network/if_vtnet.cSat Oct  5 16:22:33 2013
 (r256065)
 +++ head/sys/dev/virtio/network/if_vtnet.cSat Oct  5 18:07:24 2013
 (r256066)
 @@ -1700,9 +1700,9 @@ vtnet_rxq_input(struct vtnet_rxq *rxq, s
   rxq-vtnrx_stats.vrxs_ipackets++;
   rxq-vtnrx_stats.vrxs_ibytes += m-m_pkthdr.len;
  
 - /* VTNET_RXQ_UNLOCK(rxq); */
 + VTNET_RXQ_UNLOCK(rxq);
   (*ifp-if_input)(ifp, m);
 - /* VTNET_RXQ_LOCK(rxq); */
 + VTNET_RXQ_LOCK(rxq);
  }
  
  static int
 @@ -1782,6 +1782,10 @@ vtnet_rxq_eof(struct vtnet_rxq *rxq)
   m_adj(m, adjsz);
  
   vtnet_rxq_input(rxq, m, hdr);
 +
 + /* Must recheck after dropping the Rx lock. */
 + if ((ifp-if_drv_flags  IFF_DRV_RUNNING) == 0)
 + break;
   }
  
   if (deq  0)
 ___
 svn-src-head@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-head
 To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
 

Thanks Bryan, confirming no more LOR apparent after this commit :)

Is this a good MFC candidate?



___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org