Re: svn commit: r324620 - head/sys/fs/fuse

2017-10-14 Thread Stefan Esser 
Am 14.10.17 um 21:02 schrieb Fedor Uporov:
> Author: fsu
> Date: Sat Oct 14 19:02:52 2017
> New Revision: 324620
> URL: https://svnweb.freebsd.org/changeset/base/324620
> 
> Log:
>   Add extended attributes support to fuse kernel module.
>   
>   Author: kem
>   Reviewed by:cem, pfg (mentor)
>   Approved by:pfg (mentor)
>   MFC after:  2 weeks
>   
>   Differential Revision: https://reviews.freebsd.org/D12485

Should any of these defines have been updated?

/sys/fuse/fs/fuse.h:
#define FUSE_FREEBSD_VERSION"0.4.4"

/sys/fuse/fs/fuse_kernel.h:
#define FUSE_KERNEL_VERSION 7
#define FUSE_KERNEL_MINOR_VERSION 8

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

Re: svn commit: r324541 - in head: share/man/man9 sys/kern sys/sys

2017-10-14 Thread Matt Joras 
On 10/14/2017 11:03, Mark Johnston wrote:
> TAILQ_FOREACH_SAFE just fetches the next element at the beginning of
> each loop iteration rather than at the end, same as the current
> implementation of clear_unrhdr() does. There's no change to the code
> generated by clang when I replace your loop with:
>
>   TAILQ_FOREACH_SAFE(up, >head, list, uq) {
>   if (up->ptr != uh) {
>   Free(up->ptr);
>   }
>   Free(up);
>   }

Ah, that's a fair point... I was assuming Ngie was suggesting doing a
TAILQ_REMOVE during each iteration, since that's probably the typical
reason to do TAILQ_FOREACH_SAFE. That loop looks better. It would
probably be good to change the queue(3) manpage to suggest that for
deletion.

Matt

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

svn commit: r324622 - head/include

2017-10-14 Thread Cy Schubert 
Author: cy
Date: Sun Oct 15 02:40:13 2017
New Revision: 324622
URL: https://svnweb.freebsd.org/changeset/base/324622

Log:
  Sync (make same) the offsetof macro definition in include/ with the
  definition of the same in sys/sys/. The problem was discovered while
  working on implementing a new C11 gets_s() for libc. (The new gets_s()
  requires rsize_t found in include/stddef.h.) The solution to sync the two
  definitions was suggested by ed@ while discussing D12667.
  
  Suggested by: ed
  MFC after:2 weeks

Modified:
  head/include/stddef.h

Modified: head/include/stddef.h
==
--- head/include/stddef.h   Sat Oct 14 23:25:44 2017(r324621)
+++ head/include/stddef.h   Sun Oct 15 02:40:13 2017(r324622)
@@ -70,7 +70,7 @@ typedef   __max_align_t   max_align_t;
 #endif
 #endif
 
-#defineoffsetof(type, member)  __offsetof(type, member)
+#defineoffsetof(type, field)   __offsetof(type, field)
 
 #if __EXT1_VISIBLE
 /* ISO/IEC 9899:2011 K.3.3.2 */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r324620 - head/sys/fs/fuse

2017-10-14 Thread Alan Somers 
On Sat, Oct 14, 2017 at 1:02 PM, Fedor Uporov  wrote:
> Author: fsu
> Date: Sat Oct 14 19:02:52 2017
> New Revision: 324620
> URL: https://svnweb.freebsd.org/changeset/base/324620
>
> Log:
>   Add extended attributes support to fuse kernel module.
>
>   Author: kem
>   Reviewed by:cem, pfg (mentor)
>   Approved by:pfg (mentor)
>   MFC after:  2 weeks
>
>   Differential Revision: https://reviews.freebsd.org/D12485

+1

Also, this should be mentioned in the release notes.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r324621 - head/sys/dev/mlx4/mlx4_en

2017-10-14 Thread Ryan Libby 
Author: rlibby
Date: Sat Oct 14 23:25:44 2017
New Revision: 324621
URL: https://svnweb.freebsd.org/changeset/base/324621

Log:
  mlx4: use enum constants instead of const vars for case exprs
  
  Follow up from r324201 to fix compilation with gcc, which complains
  about non-ICE case expressions.
  
  Reviewed by:  hselasky
  Differential Revision:https://reviews.freebsd.org/D12675

Modified:
  head/sys/dev/mlx4/mlx4_en/mlx4_en_rx.c

Modified: head/sys/dev/mlx4/mlx4_en/mlx4_en_rx.c
==
--- head/sys/dev/mlx4/mlx4_en/mlx4_en_rx.c  Sat Oct 14 19:02:52 2017
(r324620)
+++ head/sys/dev/mlx4/mlx4_en/mlx4_en_rx.c  Sat Oct 14 23:25:44 2017
(r324621)
@@ -558,26 +558,28 @@ mlx4_en_rx_mb(struct mlx4_en_priv *priv, struct mlx4_e
 static __inline int
 mlx4_en_rss_hash(__be16 status, int udp_rss)
 {
-   const __be16 status_all = cpu_to_be16(
+   enum {
+   status_all = cpu_to_be16(
MLX4_CQE_STATUS_IPV4|
MLX4_CQE_STATUS_IPV4F   |
MLX4_CQE_STATUS_IPV6|
MLX4_CQE_STATUS_TCP |
-   MLX4_CQE_STATUS_UDP);
-   const __be16 status_ipv4_tcp = cpu_to_be16(
+   MLX4_CQE_STATUS_UDP),
+   status_ipv4_tcp = cpu_to_be16(
MLX4_CQE_STATUS_IPV4|
-   MLX4_CQE_STATUS_TCP);
-   const __be16 status_ipv6_tcp = cpu_to_be16(
+   MLX4_CQE_STATUS_TCP),
+   status_ipv6_tcp = cpu_to_be16(
MLX4_CQE_STATUS_IPV6|
-   MLX4_CQE_STATUS_TCP);
-   const __be16 status_ipv4_udp = cpu_to_be16(
+   MLX4_CQE_STATUS_TCP),
+   status_ipv4_udp = cpu_to_be16(
MLX4_CQE_STATUS_IPV4|
-   MLX4_CQE_STATUS_UDP);
-   const __be16 status_ipv6_udp = cpu_to_be16(
+   MLX4_CQE_STATUS_UDP),
+   status_ipv6_udp = cpu_to_be16(
MLX4_CQE_STATUS_IPV6|
-   MLX4_CQE_STATUS_UDP);
-   const __be16 status_ipv4 = cpu_to_be16(MLX4_CQE_STATUS_IPV4);
-   const __be16 status_ipv6 = cpu_to_be16(MLX4_CQE_STATUS_IPV6);
+   MLX4_CQE_STATUS_UDP),
+   status_ipv4 = cpu_to_be16(MLX4_CQE_STATUS_IPV4),
+   status_ipv6 = cpu_to_be16(MLX4_CQE_STATUS_IPV6)
+   };
 
status &= status_all;
switch (status) {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r324620 - head/sys/fs/fuse

2017-10-14 Thread Fedor Uporov 
Author: fsu
Date: Sat Oct 14 19:02:52 2017
New Revision: 324620
URL: https://svnweb.freebsd.org/changeset/base/324620

Log:
  Add extended attributes support to fuse kernel module.
  
  Author: kem
  Reviewed by:cem, pfg (mentor)
  Approved by:pfg (mentor)
  MFC after:  2 weeks
  
  Differential Revision: https://reviews.freebsd.org/D12485

Modified:
  head/sys/fs/fuse/fuse_ipc.c
  head/sys/fs/fuse/fuse_vnops.c

Modified: head/sys/fs/fuse/fuse_ipc.c
==
--- head/sys/fs/fuse/fuse_ipc.c Sat Oct 14 18:38:36 2017(r324619)
+++ head/sys/fs/fuse/fuse_ipc.c Sat Oct 14 19:02:52 2017(r324620)
@@ -636,23 +636,20 @@ fuse_body_audit(struct fuse_ticket *ftick, size_t blen
break;
 
case FUSE_SETXATTR:
-   panic("FUSE_SETXATTR implementor has forgotten to define a"
- " response body format check");
+   err = (blen == 0) ? 0 : EINVAL;
break;
 
case FUSE_GETXATTR:
-   panic("FUSE_GETXATTR implementor has forgotten to define a"
- " response body format check");
-   break;
-
case FUSE_LISTXATTR:
-   panic("FUSE_LISTXATTR implementor has forgotten to define a"
- " response body format check");
+   /*
+* These can have varying response lengths, and 0 length
+* isn't necessarily invalid.
+*/
+   err = 0;
break;
 
case FUSE_REMOVEXATTR:
-   panic("FUSE_REMOVEXATTR implementor has forgotten to define a"
- " response body format check");
+   err = (blen == 0) ? 0 : EINVAL;
break;
 
case FUSE_FLUSH:

Modified: head/sys/fs/fuse/fuse_vnops.c
==
--- head/sys/fs/fuse/fuse_vnops.c   Sat Oct 14 18:38:36 2017
(r324619)
+++ head/sys/fs/fuse/fuse_vnops.c   Sat Oct 14 19:02:52 2017
(r324620)
@@ -73,6 +73,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -112,10 +113,13 @@ __FBSDID("$FreeBSD$");
 static vop_access_t fuse_vnop_access;
 static vop_close_t fuse_vnop_close;
 static vop_create_t fuse_vnop_create;
+static vop_deleteextattr_t fuse_vnop_deleteextattr;
 static vop_fsync_t fuse_vnop_fsync;
 static vop_getattr_t fuse_vnop_getattr;
+static vop_getextattr_t fuse_vnop_getextattr;
 static vop_inactive_t fuse_vnop_inactive;
 static vop_link_t fuse_vnop_link;
+static vop_listextattr_t fuse_vnop_listextattr;
 static vop_lookup_t fuse_vnop_lookup;
 static vop_mkdir_t fuse_vnop_mkdir;
 static vop_mknod_t fuse_vnop_mknod;
@@ -128,6 +132,7 @@ static vop_remove_t fuse_vnop_remove;
 static vop_rename_t fuse_vnop_rename;
 static vop_rmdir_t fuse_vnop_rmdir;
 static vop_setattr_t fuse_vnop_setattr;
+static vop_setextattr_t fuse_vnop_setextattr;
 static vop_strategy_t fuse_vnop_strategy;
 static vop_symlink_t fuse_vnop_symlink;
 static vop_write_t fuse_vnop_write;
@@ -140,10 +145,13 @@ struct vop_vector fuse_vnops = {
.vop_access = fuse_vnop_access,
.vop_close = fuse_vnop_close,
.vop_create = fuse_vnop_create,
+   .vop_deleteextattr = fuse_vnop_deleteextattr,
.vop_fsync = fuse_vnop_fsync,
.vop_getattr = fuse_vnop_getattr,
+   .vop_getextattr = fuse_vnop_getextattr,
.vop_inactive = fuse_vnop_inactive,
.vop_link = fuse_vnop_link,
+   .vop_listextattr = fuse_vnop_listextattr,
.vop_lookup = fuse_vnop_lookup,
.vop_mkdir = fuse_vnop_mkdir,
.vop_mknod = fuse_vnop_mknod,
@@ -157,6 +165,7 @@ struct vop_vector fuse_vnops = {
.vop_rename = fuse_vnop_rename,
.vop_rmdir = fuse_vnop_rmdir,
.vop_setattr = fuse_vnop_setattr,
+   .vop_setextattr = fuse_vnop_setextattr,
.vop_strategy = fuse_vnop_strategy,
.vop_symlink = fuse_vnop_symlink,
.vop_write = fuse_vnop_write,
@@ -1956,6 +1965,383 @@ fuse_vnop_putpages(struct vop_putpages_args *ap)
}
}
return rtvals[0];
+}
+
+static const char extattr_namespace_separator = '.';
+
+/*
+struct vop_getextattr_args {
+struct vop_generic_args a_gen;
+struct vnode *a_vp;
+int a_attrnamespace;
+const char *a_name;
+struct uio *a_uio;
+size_t *a_size;
+struct ucred *a_cred;
+struct thread *a_td;
+};
+*/
+static int
+fuse_vnop_getextattr(struct vop_getextattr_args *ap)
+{
+   struct vnode *vp = ap->a_vp;
+   struct uio *uio = ap->a_uio;
+   struct fuse_dispatcher fdi = {0};
+   struct fuse_getxattr_in *get_xattr_in;
+   struct fuse_getxattr_out *get_xattr_out;
+   struct mount *mp = vnode_mount(vp);
+   char *prefix;
+   size_t len;
+   char *attr_str;
+

svn commit: r324619 - in head/usr.bin/procstat: . tests

2017-10-14 Thread Brooks Davis 
Author: brooks
Date: Sat Oct 14 18:38:36 2017
New Revision: 324619
URL: https://svnweb.freebsd.org/changeset/base/324619

Log:
  Switch procstat from subcommand flags to verbs
  
  - Use an enumerated value instead of separate flags for commands
  - Look for a verb if no command flag is set
  - Lookup the "xocontainer" value based on the command
  - Document the new command verbs in the man-page
  
  Submitted by: kdrak...@zoho.com
  Differential Revision:https://reviews.freebsd.org/D10916

Modified:
  head/usr.bin/procstat/procstat.1
  head/usr.bin/procstat/procstat.c
  head/usr.bin/procstat/procstat.h
  head/usr.bin/procstat/procstat_args.c
  head/usr.bin/procstat/procstat_auxv.c
  head/usr.bin/procstat/procstat_basic.c
  head/usr.bin/procstat/procstat_bin.c
  head/usr.bin/procstat/procstat_cred.c
  head/usr.bin/procstat/procstat_cs.c
  head/usr.bin/procstat/procstat_files.c
  head/usr.bin/procstat/procstat_kstack.c
  head/usr.bin/procstat/procstat_ptlwpinfo.c
  head/usr.bin/procstat/procstat_rlimit.c
  head/usr.bin/procstat/procstat_rusage.c
  head/usr.bin/procstat/procstat_sigs.c
  head/usr.bin/procstat/procstat_threads.c
  head/usr.bin/procstat/procstat_vm.c
  head/usr.bin/procstat/tests/procstat_test.sh

Modified: head/usr.bin/procstat/procstat.1
==
--- head/usr.bin/procstat/procstat.1Sat Oct 14 17:51:25 2017
(r324618)
+++ head/usr.bin/procstat/procstat.1Sat Oct 14 18:38:36 2017
(r324619)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 3, 2017
+.Dd October 14, 2017
 .Dt PROCSTAT 1
 .Os
 .Sh NAME
@@ -34,14 +34,75 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl -libxo
-.Op Fl CHhn
+.Op Fl h
 .Op Fl M Ar core
 .Op Fl N Ar system
 .Op Fl w Ar interval
-.Op Fl b | c | e | f | i | j | k | l | L | r | s | S | t | v | x
-.Op Fl a | Ar pid | Ar core ...
+.Ar command
+.Op Ar pid ... | Ar core ...
+.Nm
+.Op Fl -libxo
+.Fl a
+.Op Fl h
+.Op Fl M Ar core
+.Op Fl N Ar system
+.Op Fl w Ar interval
+.Ar command
+.Nm
+.Op Fl -libxo
+.Op Fl h
+.Op Fl M Ar core
+.Op Fl N Ar system
+.Op Fl w Ar interval
+.Oo
+.Fl b |
+.Fl c |
+.Fl e |
+.Fl f Oo Fl C Oc |
+.Fl i Oo Fl n Oc |
+.Fl j Oo Fl n Oc |
+.Fl k Oo Fl k Oc |
+.Fl l |
+.Fl r Oo Fl H Oc |
+.Fl s |
+.Fl S |
+.Fl t |
+.Fl v |
+.Fl x
+.Oc
+.Op Ar pid ... | Ar core ...
+.Nm
+.Op Fl -libxo
+.Fl a
+.Op Fl h
+.Op Fl M Ar core
+.Op Fl N Ar system
+.Op Fl w Ar interval
+.Oo
+.Fl b |
+.Fl c |
+.Fl e |
+.Fl f Oo Fl C Oc |
+.Fl i Oo Fl n Oc |
+.Fl j Oo Fl n Oc |
+.Fl k Oo Fl k Oc |
+.Fl l |
+.Fl r Oo Fl H Oc |
+.Fl s |
+.Fl S |
+.Fl t |
+.Fl v |
+.Fl x
+.Oc
+.Nm
+.Op Fl -libxo
+.Fl L
+.Op Fl h
+.Op Fl M Ar core
+.Op Fl N Ar system
+.Op Fl w Ar interval
+.Ar core ...
 .Sh DESCRIPTION
-The
 .Nm
 utility displays detailed information about the processes identified by the
 .Ar pid
@@ -51,49 +112,89 @@ flag is used, all processes.
 It can also display information extracted from a process core file, if
 the core file is specified as the argument.
 .Pp
-By default, basic process statistics are printed; one of the following
-options may be specified in order to select more detailed process information
-for printing:
-.Bl -tag -width indent
-.It Fl -libxo
-Generate output via
+If the
+.Fl -libxo
+flag is specified the output is generated via
 .Xr libxo 3
 in a selection of different human and machine readable formats.
 See
 .Xr xo_parse_args 3
 for details on command line arguments.
-.It Fl b
+.Pp
+The following commands are available:
+.Bl -tag -width indent
+.It Ar basic
+Print basic process statistics (this is the default).
+.It Ar binary | Fl b
 Display binary information for the process.
-.It Fl c
+.Pp
+Substring commands are accepted.
+.It Ar argument(s) | Fl c
 Display command line arguments for the process.
-.It Fl e
+.Pp
+Substring commands are accepted.
+.It Ar environment | Fl e
 Display environment variables for the process.
-.It Fl f
+.Pp
+Substring commands are accepted.
+.It Ar file(s) | Ar fd(s) | Fl f
 Display file descriptor information for the process.
-.It Fl i
+.Pp
+If the
+.Fl C
+subcommand flag is used then additional capability information is printed.
+.It Ar signal(s) | Fl i
 Display signal pending and disposition information for the process.
-.It Fl j
+.Pp
+If the
+.Fl n
+subcommand option is used, the signal numbers are shown instead of signal
+names.
+.Pp
+Substring commands are accepted.
+.It Ar tsignal(s) | Fl j
 Display signal pending and blocked information for the process's threads.
-.It Fl k
+.Pp
+If the
+.Fl n
+subcommand option is used, the signal numbers are shown instead of signal
+names.
+.Pp
+Substring commands are accepted.
+.It Ar kstack | Fl k
 Display the stacks of kernel threads in the process, excluding stacks of
 threads currently running on a CPU and threads with stacks swapped to disk.
-If the flag is repeated, function offsets as well as function names are
-printed.
-.It Fl l
+.Pp
+If the
+.Fl v
+subcommand option is used (or the command flag

Re: svn commit: r324541 - in head: share/man/man9 sys/kern sys/sys

2017-10-14 Thread Mark Johnston 
On Fri, Oct 13, 2017 at 10:36:26PM -0700, Matt Joras wrote:
> On 10/13/2017 22:12, Ngie Cooper (yaneurabeya) wrote:
> >> Modified: head/sys/kern/subr_unit.c
> >> ==
> >> --- head/sys/kern/subr_unit.c  Wed Oct 11 20:36:22 2017
> >> (r324540)
> >> +++ head/sys/kern/subr_unit.c  Wed Oct 11 21:53:50 2017
> >> (r324541)
> >> @@ -366,6 +366,27 @@ delete_unrhdr(struct unrhdr *uh)
> >>Free(uh);
> >> }
> >>
> >> +void
> >> +clear_unrhdr(struct unrhdr *uh)
> >> +{
> >> +  struct unr *up, *uq;
> >> +
> >> +  KASSERT(TAILQ_EMPTY(>ppfree),
> >> +  ("unrhdr has postponed item for free"));
> >> +  up = TAILQ_FIRST(>head);
> >> +  while (up != NULL) {
> > Could this be done with TAILQ_FOREACH_SAFE?
> > -Ngie
> 
> 
> Yes but it is arguably inferior to do so. This while loop is
> theoretically faster since there is no need to individually remove the
> elements when you intend to delete every element.

TAILQ_FOREACH_SAFE just fetches the next element at the beginning of
each loop iteration rather than at the end, same as the current
implementation of clear_unrhdr() does. There's no change to the code
generated by clang when I replace your loop with:

TAILQ_FOREACH_SAFE(up, >head, list, uq) {
if (up->ptr != uh) {
Free(up->ptr);
}
Free(up);
}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r324618 - stable/11/sys/kern

2017-10-14 Thread Mark Johnston 
Author: markj
Date: Sat Oct 14 17:51:25 2017
New Revision: 324618
URL: https://svnweb.freebsd.org/changeset/base/324618

Log:
  MFC r324146:
  Have uiomove_object_page() keep accessed pages in the active queue.

Modified:
  stable/11/sys/kern/uipc_shm.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/kern/uipc_shm.c
==
--- stable/11/sys/kern/uipc_shm.c   Sat Oct 14 16:49:39 2017
(r324617)
+++ stable/11/sys/kern/uipc_shm.c   Sat Oct 14 17:51:25 2017
(r324618)
@@ -203,12 +203,10 @@ uiomove_object_page(vm_object_t obj, size_t len, struc
}
vm_page_lock(m);
vm_page_hold(m);
-   if (m->queue == PQ_NONE) {
-   vm_page_deactivate(m);
-   } else {
-   /* Requeue to maintain LRU ordering. */
-   vm_page_requeue(m);
-   }
+   if (m->queue != PQ_ACTIVE)
+   vm_page_activate(m);
+   else
+   vm_page_reference(m);
vm_page_unlock(m);
VM_OBJECT_WUNLOCK(obj);
error = uiomove_fromphys(, offset, tlen, uio);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r324617 - stable/10/lib/libc/gen

2017-10-14 Thread Brooks Davis 
Author: brooks
Date: Sat Oct 14 16:49:39 2017
New Revision: 324617
URL: https://svnweb.freebsd.org/changeset/base/324617

Log:
  MFC r324243:
  
  Remove an unneeded and incorrect memset().
  
  On Variant I TLS architectures (aarch64, arm, mips, powerpc, and riscv)
  the __libc_allocate_tls function allocates thread local storage memory
  with calloc(). It then copies initialization data over the portions with
  non-zero initial values. Before this change it would then pointlessly
  zero the already zeroed remainder of the storage. Unfortunately the
  calculation was wrong and it would zero TLS_TCB_SIZE (2*sizeof(void *))
  additional bytes.
  
  In practice, this overflow only matters if the TLS segment is sized such
  that calloc() allocates less than TLS_TCB_SIZE extra memory. Even
  then, the likely result will be zeroing part of the next bucket. This
  coupled with the impact being confined to Tier II platforms means there
  will be no security advisory for this issue.
  
  Reviewed by:  kib, dfr
  Discussed with:   security-officer (delphij)
  Found by: CHERI
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D12547

Modified:
  stable/10/lib/libc/gen/tls.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/lib/libc/gen/tls.c
==
--- stable/10/lib/libc/gen/tls.cSat Oct 14 16:23:25 2017
(r324616)
+++ stable/10/lib/libc/gen/tls.cSat Oct 14 16:49:39 2017
(r324617)
@@ -161,9 +161,6 @@ __libc_allocate_tls(void *oldtcb, size_t tcbsize, size
 
if (tls_init_size > 0)
memcpy((void*)dtv[2], tls_init, tls_init_size);
-   if (tls_static_space > tls_init_size)
-   memset((void*)(dtv[2] + tls_init_size), 0,
-   tls_static_space - tls_init_size);
}
 
return(tcb); 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r324616 - stable/11/lib/libc/gen

2017-10-14 Thread Brooks Davis 
Author: brooks
Date: Sat Oct 14 16:23:25 2017
New Revision: 324616
URL: https://svnweb.freebsd.org/changeset/base/324616

Log:
  MFC r324243:
  
  Remove an unneeded and incorrect memset().
  
  On Variant I TLS architectures (aarch64, arm, mips, powerpc, and riscv)
  the __libc_allocate_tls function allocates thread local storage memory
  with calloc(). It then copies initialization data over the portions with
  non-zero initial values. Before this change it would then pointlessly
  zero the already zeroed remainder of the storage. Unfortunately the
  calculation was wrong and it would zero TLS_TCB_SIZE (2*sizeof(void *))
  additional bytes.
  
  In practice, this overflow only matters if the TLS segment is sized such
  that calloc() allocates less than TLS_TCB_SIZE extra memory. Even
  then, the likely result will be zeroing part of the next bucket. This
  coupled with the impact being confined to Tier II platforms means there
  will be no security advisory for this issue.
  
  Reviewed by:  kib, dfr
  Discussed with:   security-officer (delphij)
  Found by: CHERI
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D12547

Modified:
  stable/11/lib/libc/gen/tls.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/lib/libc/gen/tls.c
==
--- stable/11/lib/libc/gen/tls.cSat Oct 14 10:02:59 2017
(r324615)
+++ stable/11/lib/libc/gen/tls.cSat Oct 14 16:23:25 2017
(r324616)
@@ -160,9 +160,6 @@ __libc_allocate_tls(void *oldtcb, size_t tcbsize, size
 
if (tls_init_size > 0)
memcpy((void*)dtv[2], tls_init, tls_init_size);
-   if (tls_static_space > tls_init_size)
-   memset((void*)(dtv[2] + tls_init_size), 0,
-   tls_static_space - tls_init_size);
}
 
return(tcb); 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r324609 - head/sys/sys

2017-10-14 Thread Mateusz Guzik 
On Sat, Oct 14, 2017 at 11:23 AM, Svatopluk Kraus  wrote:

> On Sat, Oct 14, 2017 at 2:48 AM, Mateusz Guzik  wrote:
> > Justification for the change was provided in the commit message: it makes
> > .text smaller on amd64 and probably all architectures.
> >
>
> I did not lack an explanation why you did it, but why it's possible
> and safe. Something like this:
> -
> (1) MTX_UNOWNED even if defined like a flag was never used like a
> flag. It was used like a value set for unowned mutex and test
> accordingly. There is no logical operation (AND, OR, ...) done with
> MTX_UNOWNED in code. There are only assignments and checks for
> equality there. Thus, we can change its value and do not pretend that
> it's a flag anymore. As mutex owner thread pointer and mutex flags are
> kept in one variable together, setting MTX_UNOWNED value to 0 is more
> appropriate and brings some benefits. However, MTX_DESTROYED flag must
> be distinguish from MTX_CONTESTED one now, so there is no savings
> considering mutex flags.
> (2) MTX_UNONWED value is used only internally within mutex
> implemention, thus this change should be quite safe.
> -
>

I guess that's a fair point, I figured some people may be wondering why
switching to 0 makes any difference. On the other hand anyone worried
about var usage can easily grep.

Next time I'll be more verbose.


>
> However, I suggest to do something with MTX_UNOWNED leak in
> sys/dev/syscons/syscons.c. i.e. to make mtx_unowned() public and use
> it instead. Further, MTX_DESTROYED is not used like a flag too. So,
> was its redefinition really needed? In other words, isn't
> MTX_CONTESTED flag without owner thread pointer set enough? Also, I
> would prefer to have some explanation to be in mutex.h about all of
> this. At least to not mess flags with values in definitions without
> explanation.
>
>
The code in syscons looks extremely fishy, I don't know what to do with
it yet. Testing for ownership should be avoidable with trylock.

What you are proposing is an equivalent to the previous trick, but
requires reading the lock owner. All places testing for MTX_DESTROYED
would have to be updated which is an avoidable churn right now.

Not employing the hack makes the flags self-explanatory.

If a need for a new flag arises there are still 2 free bits and if
that's not enough we can alter the current code.

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

svn commit: r324615 - head/sys/netinet

2017-10-14 Thread Michael Tuexen 
Author: tuexen
Date: Sat Oct 14 10:02:59 2017
New Revision: 324615
URL: https://svnweb.freebsd.org/changeset/base/324615

Log:
  Code cleanup, not functional change.
  
  This avoids taking a pointer of a packed structure which allows simpler
  compilation of the userland stack.
  
  MFC after:1 week

Modified:
  head/sys/netinet/sctp_constants.h
  head/sys/netinet/sctp_indata.c
  head/sys/netinet/sctp_input.c
  head/sys/netinet/sctp_output.c
  head/sys/netinet/sctputil.c
  head/sys/netinet/sctputil.h

Modified: head/sys/netinet/sctp_constants.h
==
--- head/sys/netinet/sctp_constants.h   Sat Oct 14 04:27:58 2017
(r324614)
+++ head/sys/netinet/sctp_constants.h   Sat Oct 14 10:02:59 2017
(r324615)
@@ -97,10 +97,6 @@ __FBSDID("$FreeBSD$");
  */
 #define SCTP_DEFAULT_VRF_SIZE 4
 
-/* constants for rto calc */
-#define sctp_align_safe_nocopy 0
-#define sctp_align_unsafe_makecopy 1
-
 /* JRS - Values defined for the HTCP algorithm */
 #define ALPHA_BASE (1<<7)  /* 1.0 with shift << 7 */
 #define BETA_MIN   (1<<6)  /* 0.5 with shift << 7 */

Modified: head/sys/netinet/sctp_indata.c
==
--- head/sys/netinet/sctp_indata.c  Sat Oct 14 04:27:58 2017
(r324614)
+++ head/sys/netinet/sctp_indata.c  Sat Oct 14 10:02:59 2017
(r324615)
@@ -3058,7 +3058,6 @@ sctp_process_segment_range(struct sctp_tcb *stcb, stru

>asoc,

tp1->whoTo,

>sent_rcv_time,
-   
sctp_align_safe_nocopy,

SCTP_RTT_FROM_DATA);
*rto_ok 
= 0;
}
@@ -4030,7 +4029,6 @@ sctp_express_handle_sack(struct sctp_tcb *stcb, uint32

sctp_calculate_rto(stcb,
asoc, 
tp1->whoTo,

>sent_rcv_time,
-   
sctp_align_safe_nocopy,

SCTP_RTT_FROM_DATA);
rto_ok = 0;
}
@@ -4636,7 +4634,6 @@ hopeless_peer:

sctp_calculate_rto(stcb,
asoc, 
tp1->whoTo,

>sent_rcv_time,
-   
sctp_align_safe_nocopy,

SCTP_RTT_FROM_DATA);
rto_ok = 0;
}

Modified: head/sys/netinet/sctp_input.c
==
--- head/sys/netinet/sctp_input.c   Sat Oct 14 04:27:58 2017
(r324614)
+++ head/sys/netinet/sctp_input.c   Sat Oct 14 10:02:59 2017
(r324615)
@@ -517,7 +517,7 @@ sctp_process_init_ack(struct mbuf *m, int iphlen, int 
asoc->primary_destination, SCTP_FROM_SCTP_INPUT + SCTP_LOC_3);
 
/* calculate the RTO */
-   net->RTO = sctp_calculate_rto(stcb, asoc, net, >time_entered, 
sctp_align_safe_nocopy,
+   net->RTO = sctp_calculate_rto(stcb, asoc, net, >time_entered,
SCTP_RTT_FROM_NON_DATA);
retval = sctp_send_cookie_echo(m, offset, stcb, net);
if (retval < 0) {
@@ -639,7 +639,7 @@ sctp_handle_heartbeat_ack(struct sctp_heartbeat_chunk 
tv.tv_sec = cp->heartbeat.hb_info.time_value_1;
tv.tv_usec = cp->heartbeat.hb_info.time_value_2;
/* Now lets do a RTO with this */
-   r_net->RTO = sctp_calculate_rto(stcb, >asoc, r_net, , 
sctp_align_safe_nocopy,
+   r_net->RTO = sctp_calculate_rto(stcb, >asoc, r_net, ,
SCTP_RTT_FROM_NON_DATA);
if (!(r_net->dest_state & SCTP_ADDR_REACHABLE)) {
r_net->dest_state |= SCTP_ADDR_REACHABLE;
@@ -1487,6 +1487,7 @@ sctp_process_cookie_existing(struct mbuf *m, int iphle
struct sctp_init_ack_chunk *initack_cp, initack_buf;
struct sctp_nets *net;
struct mbuf *op_err;
+   struct timeval old;
int init_offset, initack_offset, i;
int retval;

Re: svn commit: r324609 - head/sys/sys

2017-10-14 Thread Svatopluk Kraus 
On Sat, Oct 14, 2017 at 2:48 AM, Mateusz Guzik  wrote:
> On Sat, Oct 14, 2017 at 2:30 AM, Ian Lepore  wrote:
>>
>> On Fri, 2017-10-13 at 23:38 +0200, Svatopluk Kraus wrote:
>> > MTX_UNOWNED is a flag. You did not change its value from 4 to 0, you
>> > removed it actually. I have very bad feeling about it. But maybe, it's
>> > really possible and in that case, a very good explanation should be
>> > provided.
>> >
>> > Svata
>> >
>>
>> The part that scares me is that DESTROYED may have been defined as
>> CONTESTED|UNOWNED for subtle and clever reasons lost in the mists of
>> time.  Any of the places that are testing the MTX_CONTESTED bit may
>> have been relying somehow on the fact that a destroyed mutex has that
>> bit set.
>>
>> Then again, maybe Mateusz has carefully analyzed all this stuff, and we
>> should just relax. :)
>>
>
> I highly doubt there was anything clever going on. Rather, someone wanted
> to somehow denote a destroyed mutex, but did not want to introduce an
> additional flag - they are not free since the field shares the value with
> the
> address of the owner. That is, adding flags requires increasing alignment
> of struct thread and that adds to memory usage. Thus they combined the
> flags in a way which can never happen under normal circumstances.
>
> mtx_destroy explicitly sets the value to MTX_DESTROYED, so there is no
> change here.
>
> MTX_UNOWNED is *not* used as a flag. If you grep the tree you will see
> it is only used in direct comparisons.
>
> That said, I reviewed all users again and a minor bug was introduced in
> owner_mtx (only used by dtrace). For some reason it grabs the owner,
> but the instead of checking if it grabbed anything it checks the flag
> (fixed in r324613). So that's my bad.
>
> Justification for the change was provided in the commit message: it makes
> .text smaller on amd64 and probably all architectures.
>
> --
> Mateusz Guzik 

I did not lack an explanation why you did it, but why it's possible
and safe. Something like this:
-
(1) MTX_UNOWNED even if defined like a flag was never used like a
flag. It was used like a value set for unowned mutex and test
accordingly. There is no logical operation (AND, OR, ...) done with
MTX_UNOWNED in code. There are only assignments and checks for
equality there. Thus, we can change its value and do not pretend that
it's a flag anymore. As mutex owner thread pointer and mutex flags are
kept in one variable together, setting MTX_UNOWNED value to 0 is more
appropriate and brings some benefits. However, MTX_DESTROYED flag must
be distinguish from MTX_CONTESTED one now, so there is no savings
considering mutex flags.
(2) MTX_UNONWED value is used only internally within mutex
implemention, thus this change should be quite safe.
-

However, I suggest to do something with MTX_UNOWNED leak in
sys/dev/syscons/syscons.c. i.e. to make mtx_unowned() public and use
it instead. Further, MTX_DESTROYED is not used like a flag too. So,
was its redefinition really needed? In other words, isn't
MTX_CONTESTED flag without owner thread pointer set enough? Also, I
would prefer to have some explanation to be in mutex.h about all of
this. At least to not mess flags with values in definitions without
explanation.

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

Re: svn commit: r324541 - in head: share/man/man9 sys/kern sys/sys

2017-10-14 Thread Matt Joras 
On 10/13/2017 22:12, Ngie Cooper (yaneurabeya) wrote:
>> Modified: head/sys/kern/subr_unit.c
>> ==
>> --- head/sys/kern/subr_unit.cWed Oct 11 20:36:22 2017
>> (r324540)
>> +++ head/sys/kern/subr_unit.cWed Oct 11 21:53:50 2017
>> (r324541)
>> @@ -366,6 +366,27 @@ delete_unrhdr(struct unrhdr *uh)
>>  Free(uh);
>> }
>>
>> +void
>> +clear_unrhdr(struct unrhdr *uh)
>> +{
>> +struct unr *up, *uq;
>> +
>> +KASSERT(TAILQ_EMPTY(>ppfree),
>> +("unrhdr has postponed item for free"));
>> +up = TAILQ_FIRST(>head);
>> +while (up != NULL) {
> Could this be done with TAILQ_FOREACH_SAFE?
> -Ngie


Yes but it is arguably inferior to do so. This while loop is
theoretically faster since there is no need to individually remove the
elements when you intend to delete every element.

Matt

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