svn commit: r355224 - in head/stand/efi: include libefi

2019-11-30 Thread Toomas Soome
Author: tsoome
Date: Sat Nov 30 09:11:28 2019
New Revision: 355224
URL: https://svnweb.freebsd.org/changeset/base/355224

Log:
  loader.efi: efipart needs better support detecting nested partitions
  
  Just as disks can have nested partitions, the same happens with cd devices,
  so we need to detect device paths and make sure we will not mix the handles.
  
  To address this:
  
  we fetch handle array and create linked list of block devices.
  we walk the list and detect parent devices and set children pd_parent.
  for {fd, cd, hd}, we walk device list and pick up our devices and store to
  corresponding list. We make sure we store parent device first.
  
  For sorting we use 3 steps: We check for floppy, we check for cd and then
  everything else must be hd.
  
  In general, it seems the floppy devices have no parent.
  CD can have both parents and children (multiple boot entries, partitions
  from the hybrid disk image).
  
  Tested by: cross+free...@distal.com on Cisco UCS systems, C200 series 
(C220M5, C240M4).
  Also on MBP with UEFI 1.10
  
  Reported by:  Chriss Ross
  MFC after:1w
  Differential Revision:https://reviews.freebsd.org/D22553

Modified:
  head/stand/efi/include/efidevp.h
  head/stand/efi/include/efilib.h
  head/stand/efi/libefi/devpath.c
  head/stand/efi/libefi/efipart.c

Modified: head/stand/efi/include/efidevp.h
==
--- head/stand/efi/include/efidevp.hSat Nov 30 06:02:13 2019
(r355223)
+++ head/stand/efi/include/efidevp.hSat Nov 30 09:11:28 2019
(r355224)
@@ -288,6 +288,14 @@ typedef struct _UART_DEVICE_PATH {
 #define DEVICE_PATH_MESSAGING_VT_UTF8 \
 { 0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d, 
0x88} }
 
+/* Device Logical Unit SubType. */
+#defineMSG_DEVICE_LOGICAL_UNIT_DP  0x11
+typedef struct {
+   EFI_DEVICE_PATH Header;
+   /* Logical Unit Number for the interface. */
+   UINT8   Lun;
+} DEVICE_LOGICAL_UNIT_DEVICE_PATH;
+
 #define MSG_SATA_DP0x12
 typedef struct _SATA_DEVICE_PATH {
EFI_DEVICE_PATH Header;

Modified: head/stand/efi/include/efilib.h
==
--- head/stand/efi/include/efilib.h Sat Nov 30 06:02:13 2019
(r355223)
+++ head/stand/efi/include/efilib.h Sat Nov 30 09:11:28 2019
(r355224)
@@ -84,6 +84,7 @@ int efi_handle_update_dev(EFI_HANDLE, struct devsw *, 
 
 EFI_DEVICE_PATH *efi_lookup_image_devpath(EFI_HANDLE);
 EFI_DEVICE_PATH *efi_lookup_devpath(EFI_HANDLE);
+void efi_close_devpath(EFI_HANDLE);
 EFI_HANDLE efi_devpath_handle(EFI_DEVICE_PATH *);
 EFI_DEVICE_PATH *efi_devpath_last_node(EFI_DEVICE_PATH *);
 EFI_DEVICE_PATH *efi_devpath_trim(EFI_DEVICE_PATH *);

Modified: head/stand/efi/libefi/devpath.c
==
--- head/stand/efi/libefi/devpath.c Sat Nov 30 06:02:13 2019
(r355223)
+++ head/stand/efi/libefi/devpath.c Sat Nov 30 09:11:28 2019
(r355224)
@@ -67,6 +67,16 @@ efi_lookup_devpath(EFI_HANDLE handle)
return (devpath);
 }
 
+void
+efi_close_devpath(EFI_HANDLE handle)
+{
+   EFI_STATUS status;
+
+   status = BS->CloseProtocol(handle, &DevicePathGUID, IH, NULL);
+   if (EFI_ERROR(status))
+   printf("CloseProtocol error: %lu\n", EFI_ERROR_CODE(status));
+}
+
 static char *
 efi_make_tail(char *suffix)
 {

Modified: head/stand/efi/libefi/efipart.c
==
--- head/stand/efi/libefi/efipart.c Sat Nov 30 06:02:13 2019
(r355223)
+++ head/stand/efi/libefi/efipart.c Sat Nov 30 09:11:28 2019
(r355224)
@@ -44,9 +44,11 @@ __FBSDID("$FreeBSD$");
 
 static EFI_GUID blkio_guid = BLOCK_IO_PROTOCOL;
 
+typedef bool (*pd_test_cb_t)(pdinfo_t *, pdinfo_t *);
 static int efipart_initfd(void);
 static int efipart_initcd(void);
 static int efipart_inithd(void);
+static void efipart_cdinfo_add(pdinfo_t *);
 
 static int efipart_strategy(void *, int, daddr_t, size_t, char *, size_t *);
 static int efipart_realstrategy(void *, int, daddr_t, size_t, char *, size_t 
*);
@@ -209,6 +211,123 @@ efiblk_pdinfo_count(pdinfo_list_t *pdi)
return (i);
 }
 
+static pdinfo_t *
+efipart_find_parent(pdinfo_list_t *pdi, EFI_DEVICE_PATH *devpath)
+{
+   pdinfo_t *pd;
+   EFI_DEVICE_PATH *parent;
+
+   /* We want to find direct parent */
+   parent = efi_devpath_trim(devpath);
+   /* We should not get out of memory here but be careful. */
+   if (parent == NULL)
+   return (NULL);
+
+   STAILQ_FOREACH(pd, pdi, pd_link) {
+   /* We must have exact match. */
+   if (efi_devpath_match(pd->pd_devpath, parent))
+   break;
+   }
+   free(parent);
+  

svn commit: r355225 - head/sbin/bectl

2019-11-30 Thread Benedict Reuschling
Author: bcr (doc committer)
Date: Sat Nov 30 14:17:45 2019
New Revision: 355225
URL: https://svnweb.freebsd.org/changeset/base/355225

Log:
  Capitalize some user-visible output messages in
  the bectl utility.
  
  No functional changes.
  
  Approved by:  imp@
  MFC after:7 days
  Differential Revision:https://reviews.freebsd.org/D22330

Modified:
  head/sbin/bectl/bectl.c

Modified: head/sbin/bectl/bectl.c
==
--- head/sbin/bectl/bectl.c Sat Nov 30 09:11:28 2019(r355224)
+++ head/sbin/bectl/bectl.c Sat Nov 30 14:17:45 2019(r355225)
@@ -68,7 +68,7 @@ usage(bool explicit)
 
fp =  explicit ? stdout : stderr;
fprintf(fp, "%s",
-   "usage:\tbectl {-h | -? | subcommand [args...]}\n"
+   "Usage:\tbectl {-h | -? | subcommand [args...]}\n"
 #if SOON
"\tbectl add (path)*\n"
 #endif
@@ -167,10 +167,10 @@ bectl_cmd_activate(int argc, char *argv[])
/* activate logic goes here */
if ((err = be_activate(be, argv[0], temp)) != 0)
/* XXX TODO: more specific error msg based on err */
-   printf("did not successfully activate boot environment %s\n",
+   printf("Did not successfully activate boot environment %s\n",
argv[0]);
else
-   printf("successfully activated boot environment %s\n", argv[0]);
+   printf("Successfully activated boot environment %s\n", argv[0]);
 
if (temp)
printf("for next boot\n");
@@ -250,14 +250,14 @@ bectl_cmd_create(int argc, char *argv[])
default:
if (atpos != NULL)
fprintf(stderr,
-   "failed to create a snapshot '%s' of '%s'\n",
+   "Failed to create a snapshot '%s' of '%s'\n",
atpos, bootenv);
else if (snapname == NULL)
fprintf(stderr,
-   "failed to create bootenv %s\n", bootenv);
+   "Failed to create bootenv %s\n", bootenv);
else
fprintf(stderr,
-   "failed to create bootenv %s from snapshot %s\n",
+   "Failed to create bootenv %s from snapshot %s\n",
bootenv, snapname);
}
 
@@ -424,12 +424,12 @@ bectl_cmd_mount(int argc, char *argv[])
 
switch (err) {
case BE_ERR_SUCCESS:
-   printf("successfully mounted %s at %s\n", bootenv, result_loc);
+   printf("Successfully mounted %s at %s\n", bootenv, result_loc);
break;
default:
fprintf(stderr,
-   (argc == 3) ? "failed to mount bootenv %s at %s\n" :
-   "failed to mount bootenv %s at temporary path %s\n",
+   (argc == 3) ? "Failed to mount bootenv %s at %s\n" :
+   "Failed to mount bootenv %s at temporary path %s\n",
bootenv, mountpoint);
}
 
@@ -462,7 +462,7 @@ bectl_cmd_rename(int argc, char *argv[])
case BE_ERR_SUCCESS:
break;
default:
-   fprintf(stderr, "failed to rename bootenv %s to %s\n",
+   fprintf(stderr, "Failed to rename bootenv %s to %s\n",
src, dest);
}
 
@@ -507,7 +507,7 @@ bectl_cmd_unmount(int argc, char *argv[])
case BE_ERR_SUCCESS:
break;
default:
-   fprintf(stderr, "failed to unmount bootenv %s\n", bootenv);
+   fprintf(stderr, "Failed to unmount bootenv %s\n", bootenv);
}
 
return (err);
@@ -563,7 +563,7 @@ main(int argc, char *argv[])
return (usage(true));
 
if ((cmd = get_cmd_info(command)) == NULL) {
-   fprintf(stderr, "unknown command: %s\n", command);
+   fprintf(stderr, "Unknown command: %s\n", command);
return (usage(false));
}
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355226 - head/sys/sys

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sat Nov 30 16:40:16 2019
New Revision: 355226
URL: https://svnweb.freebsd.org/changeset/base/355226

Log:
  vfs: swap placement between v_type and v_tag
  
  The former is frequently accessed (e.g., in vfs_cache_lookup) and shares the
  cacheline with v_usecount, avoidably adding to cache misses during concurrent
  lookup. The latter is almost unused and probably can get garbage-collected.
  
  The struct does not change in size despite enum vs char * discrepancy.
  On 64-bit archs there used to be 4 bytes padding after v_type giving 480 bytes
  in total.

Modified:
  head/sys/sys/vnode.h

Modified: head/sys/sys/vnode.h
==
--- head/sys/sys/vnode.hSat Nov 30 14:17:45 2019(r355225)
+++ head/sys/sys/vnode.hSat Nov 30 16:40:16 2019(r355226)
@@ -103,7 +103,7 @@ struct vnode {
 * Fields which define the identity of the vnode.  These fields are
 * owned by the filesystem (XXX: and vgone() ?)
 */
-   const char *v_tag;  /* u type of underlying data */
+   enumvtype v_type;   /* u vnode type */
struct  vop_vector *v_op;   /* u vnode operations vector */
void*v_data;/* u private data for fs */
 
@@ -173,7 +173,7 @@ struct vnode {
int v_writecount;   /* I ref count of writers or
   (negative) text users */
u_int   v_hash;
-   enumvtype v_type;   /* u vnode type */
+   const char *v_tag;  /* u type of underlying data */
 };
 
 #endif /* defined(_KERNEL) || defined(_KVM_VNODE) */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355227 - head/sys/fs/tmpfs

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sat Nov 30 16:41:47 2019
New Revision: 355227
URL: https://svnweb.freebsd.org/changeset/base/355227

Log:
  tmpfs: add fast path to tmpfs_access for common case lookup
  
  VEXEC consists of vast majority of all calls and almost all targets have
  at least 0111.

Modified:
  head/sys/fs/tmpfs/tmpfs_vnops.c

Modified: head/sys/fs/tmpfs/tmpfs_vnops.c
==
--- head/sys/fs/tmpfs/tmpfs_vnops.c Sat Nov 30 16:40:16 2019
(r355226)
+++ head/sys/fs/tmpfs/tmpfs_vnops.c Sat Nov 30 16:41:47 2019
(r355227)
@@ -331,6 +331,12 @@ tmpfs_access(struct vop_access_args *v)
 
node = VP_TO_TMPFS_NODE(vp);
 
+   /*
+* Common case path lookup.
+*/
+   if (__predict_true(accmode == VEXEC && (node->tn_mode & 0111) == 0111))
+   return (0);
+
switch (vp->v_type) {
case VDIR:
/* FALLTHROUGH */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355228 - in head/sys: fs/devfs kern

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sat Nov 30 16:46:19 2019
New Revision: 355228
URL: https://svnweb.freebsd.org/changeset/base/355228

Log:
  devfs: introduce a per-dev lock to protect ->si_devsw
  
  This allows bumping threadcount without taking the global devmtx lock.
  
  In particular this eliminates contention on said lock while using bhyve
  with multiple vms.
  
  Reviewed by:  kib
  Tested by:markj
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D22548

Modified:
  head/sys/fs/devfs/devfs_devs.c
  head/sys/fs/devfs/devfs_int.h
  head/sys/kern/kern_conf.c
  head/sys/kern/subr_witness.c

Modified: head/sys/fs/devfs/devfs_devs.c
==
--- head/sys/fs/devfs/devfs_devs.c  Sat Nov 30 16:41:47 2019
(r355227)
+++ head/sys/fs/devfs/devfs_devs.c  Sat Nov 30 16:46:19 2019
(r355228)
@@ -138,6 +138,8 @@ devfs_alloc(int flags)
if (cdp == NULL)
return (NULL);
 
+   mtx_init(&cdp->cdp_threadlock, "devthrd", NULL, MTX_DEF);
+
cdp->cdp_dirents = &cdp->cdp_dirent0;
 
cdev = &cdp->cdp_c;
@@ -180,6 +182,7 @@ devfs_free(struct cdev *cdev)
devfs_free_cdp_inode(cdp->cdp_inode);
if (cdp->cdp_maxdirent > 0) 
free(cdp->cdp_dirents, M_DEVFS2);
+   mtx_destroy(&cdp->cdp_threadlock);
free(cdp, M_CDEVP);
 }
 

Modified: head/sys/fs/devfs/devfs_int.h
==
--- head/sys/fs/devfs/devfs_int.h   Sat Nov 30 16:41:47 2019
(r355227)
+++ head/sys/fs/devfs/devfs_int.h   Sat Nov 30 16:46:19 2019
(r355228)
@@ -70,6 +70,8 @@ struct cdev_priv {
void*cdp_dtr_cb_arg;
 
LIST_HEAD(, cdev_privdata) cdp_fdpriv;
+
+   struct mtx  cdp_threadlock;
 };
 
 #definecdev2priv(c)__containerof(c, struct cdev_priv, cdp_c)

Modified: head/sys/kern/kern_conf.c
==
--- head/sys/kern/kern_conf.c   Sat Nov 30 16:41:47 2019(r355227)
+++ head/sys/kern/kern_conf.c   Sat Nov 30 16:46:19 2019(r355228)
@@ -186,16 +186,16 @@ dev_refthread(struct cdev *dev, int *ref)
*ref = 0;
return (dev->si_devsw);
}
-   dev_lock();
+   cdp = cdev2priv(dev);
+   mtx_lock(&cdp->cdp_threadlock);
csw = dev->si_devsw;
if (csw != NULL) {
-   cdp = cdev2priv(dev);
if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0)
atomic_add_long(&dev->si_threadcount, 1);
else
csw = NULL;
}
-   dev_unlock();
+   mtx_unlock(&cdp->cdp_threadlock);
if (csw != NULL)
*ref = 1;
return (csw);
@@ -223,19 +223,21 @@ devvn_refthread(struct vnode *vp, struct cdev **devp, 
}
 
csw = NULL;
-   dev_lock();
+   VI_LOCK(vp);
dev = vp->v_rdev;
if (dev == NULL) {
-   dev_unlock();
+   VI_UNLOCK(vp);
return (NULL);
}
cdp = cdev2priv(dev);
+   mtx_lock(&cdp->cdp_threadlock);
if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0) {
csw = dev->si_devsw;
if (csw != NULL)
atomic_add_long(&dev->si_threadcount, 1);
}
-   dev_unlock();
+   mtx_unlock(&cdp->cdp_threadlock);
+   VI_UNLOCK(vp);
if (csw != NULL) {
*devp = dev;
*ref = 1;
@@ -1136,20 +1138,26 @@ destroy_devl(struct cdev *dev)
dev->si_flags &= ~SI_CLONELIST;
}
 
+   mtx_lock(&cdp->cdp_threadlock);
csw = dev->si_devsw;
dev->si_devsw = NULL;   /* already NULL for SI_ALIAS */
while (csw != NULL && csw->d_purge != NULL && dev->si_threadcount) {
csw->d_purge(dev);
+   mtx_unlock(&cdp->cdp_threadlock);
msleep(csw, &devmtx, PRIBIO, "devprg", hz/10);
+   mtx_lock(&cdp->cdp_threadlock);
if (dev->si_threadcount)
printf("Still %lu threads in %s\n",
dev->si_threadcount, devtoname(dev));
}
while (dev->si_threadcount != 0) {
/* Use unique dummy wait ident */
+   mtx_unlock(&cdp->cdp_threadlock);
msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
+   mtx_lock(&cdp->cdp_threadlock);
}
 
+   mtx_unlock(&cdp->cdp_threadlock);
dev_unlock();
if ((cdp->cdp_flags & CDP_UNREF_DTR) == 0) {
/* avoid out of order notify events */

Modified: head/sys/kern/subr_witness.c
==
--- head/sys/kern/subr_witness.cSat Nov 30 16:41:47 2019
(r

svn commit: r355230 - in head/sys: kern sys

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sat Nov 30 17:22:10 2019
New Revision: 355230
URL: https://svnweb.freebsd.org/changeset/base/355230

Log:
  Add a way to inject fences using IPIs
  
  A variant of this facility was already used by rmlocks where IPIs would
  enforce ordering.
  
  This allows to elide fences where they are rarely needed and the cost of
  IPI (should it be necessary) is cheaper.
  
  Reviewed by:  kib, jeff (previous version)
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D21740

Modified:
  head/sys/kern/subr_smp.c
  head/sys/sys/smp.h

Modified: head/sys/kern/subr_smp.c
==
--- head/sys/kern/subr_smp.cSat Nov 30 16:59:29 2019(r355229)
+++ head/sys/kern/subr_smp.cSat Nov 30 17:22:10 2019(r355230)
@@ -929,6 +929,66 @@ quiesce_all_cpus(const char *wmesg, int prio)
return quiesce_cpus(all_cpus, wmesg, prio);
 }
 
+/*
+ * Observe all CPUs not executing in critical section.
+ * We are not in one so the check for us is safe. If the found
+ * thread changes to something else we know the section was
+ * exited as well.
+ */
+void
+quiesce_all_critical(void)
+{
+   struct thread *td, *newtd;
+   struct pcpu *pcpu;
+   int cpu;
+
+   MPASS(curthread->td_critnest == 0);
+
+   CPU_FOREACH(cpu) {
+   pcpu = cpuid_to_pcpu[cpu];
+   td = pcpu->pc_curthread;
+   for (;;) {
+   if (td->td_critnest == 0)
+   break;
+   cpu_spinwait();
+   newtd = (struct thread *)
+   atomic_load_acq_ptr((u_long *)pcpu->pc_curthread);
+   if (td != newtd)
+   break;
+   }
+   }
+}
+
+static void
+cpus_fence_seq_cst_issue(void *arg __unused)
+{
+
+   atomic_thread_fence_seq_cst();
+}
+
+/*
+ * Send an IPI forcing a sequentially consistent fence.
+ *
+ * Allows replacement of an explicitly fence with a compiler barrier.
+ * Trades speed up during normal execution for a significant slowdown when
+ * the barrier is needed.
+ */
+void
+cpus_fence_seq_cst(void)
+{
+
+#ifdef SMP
+   smp_rendezvous(
+   smp_no_rendezvous_barrier,
+   cpus_fence_seq_cst_issue,
+   smp_no_rendezvous_barrier,
+   NULL
+   );
+#else
+   cpus_fence_seq_cst_issue(NULL);
+#endif
+}
+
 /* Extra care is taken with this sysctl because the data type is volatile */
 static int
 sysctl_kern_smp_active(SYSCTL_HANDLER_ARGS)

Modified: head/sys/sys/smp.h
==
--- head/sys/sys/smp.h  Sat Nov 30 16:59:29 2019(r355229)
+++ head/sys/sys/smp.h  Sat Nov 30 17:22:10 2019(r355230)
@@ -264,6 +264,8 @@ extern  struct mtx smp_ipi_mtx;
 
 intquiesce_all_cpus(const char *, int);
 intquiesce_cpus(cpuset_t, const char *, int);
+void   quiesce_all_critical(void);
+void   cpus_fence_seq_cst(void);
 void   smp_no_rendezvous_barrier(void *);
 void   smp_rendezvous(void (*)(void *), 
   void (*)(void *),
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355231 - head/sys/kern

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sat Nov 30 17:24:42 2019
New Revision: 355231
URL: https://svnweb.freebsd.org/changeset/base/355231

Log:
  lockprof: use IPI-injecetd fences to fix hangs on stat dump and reset
  
  The previously used quiesce_all_cpus walks all CPUs and waits until curthread
  can run on them. Even on contemporary machines this becomes a significant
  problem under load when it can literally take minutes for the operation to
  complete. With the patch the stall is normally less than 1 second.
  
  Reviewed by:  kib, jeff (previous version)
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D21740

Modified:
  head/sys/kern/subr_lock.c

Modified: head/sys/kern/subr_lock.c
==
--- head/sys/kern/subr_lock.c   Sat Nov 30 17:22:10 2019(r355230)
+++ head/sys/kern/subr_lock.c   Sat Nov 30 17:24:42 2019(r355231)
@@ -324,8 +324,14 @@ lock_prof_reset(void)
atomic_store_rel_int(&lock_prof_resetting, 1);
enabled = lock_prof_enable;
lock_prof_enable = 0;
-   quiesce_all_cpus("profreset", 0);
/*
+* This both publishes lock_prof_enable as disabled and makes sure
+* everyone else reads it if they are not far enough. We wait for the
+* rest down below.
+*/
+   cpus_fence_seq_cst();
+   quiesce_all_critical();
+   /*
 * Some objects may have migrated between CPUs.  Clear all links
 * before we zero the structures.  Some items may still be linked
 * into per-thread lists as well.
@@ -343,6 +349,9 @@ lock_prof_reset(void)
lock_prof_init_type(&lpc->lpc_types[0]);
lock_prof_init_type(&lpc->lpc_types[1]);
}
+   /*
+* Paired with the fence from cpus_fence_seq_cst()
+*/
atomic_store_rel_int(&lock_prof_resetting, 0);
lock_prof_enable = enabled;
 }
@@ -433,12 +442,17 @@ dump_lock_prof_stats(SYSCTL_HANDLER_ARGS)
"max", "wait_max", "total", "wait_total", "count", "avg", 
"wait_avg", "cnt_hold", "cnt_lock", "name");
enabled = lock_prof_enable;
lock_prof_enable = 0;
-   quiesce_all_cpus("profstat", 0);
+   /*
+* See the comment in lock_prof_reset
+*/
+   cpus_fence_seq_cst();
+   quiesce_all_critical();
t = ticks;
CPU_FOREACH(cpu) {
lock_prof_type_stats(&LP_CPU(cpu)->lpc_types[0], sb, 0, t);
lock_prof_type_stats(&LP_CPU(cpu)->lpc_types[1], sb, 1, t);
}
+   atomic_thread_fence_rel();
lock_prof_enable = enabled;
 
error = sbuf_finish(sb);
@@ -591,6 +605,10 @@ lock_profile_obtain_lock_success(struct lock_object *l
else
l->lpo_waittime = 0;
 out:
+   /*
+* Paired with cpus_fence_seq_cst().
+*/
+   atomic_thread_fence_rel();
critical_exit();
 }
 
@@ -677,6 +695,10 @@ release:
type = &LP_CPU_SELF->lpc_types[spin];
LIST_INSERT_HEAD(&type->lpt_lpoalloc, l, lpo_link);
 out:
+   /*
+* Paired with cpus_fence_seq_cst().
+*/
+   atomic_thread_fence_rel();
critical_exit();
 }
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355232 - head/libexec/rc/rc.d

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sat Nov 30 17:30:01 2019
New Revision: 355232
URL: https://svnweb.freebsd.org/changeset/base/355232

Log:
  ldconfig: fetch hw.machine_arch only once
  
  This happens to be of significance with poudriere which runs the script a lot
  when installing packages.

Modified:
  head/libexec/rc/rc.d/ldconfig

Modified: head/libexec/rc/rc.d/ldconfig
==
--- head/libexec/rc/rc.d/ldconfig   Sat Nov 30 17:24:42 2019
(r355231)
+++ head/libexec/rc/rc.d/ldconfig   Sat Nov 30 17:30:01 2019
(r355232)
@@ -40,7 +40,9 @@ ldconfig_start()
check_startmsgs && echo 'ELF ldconfig path:' ${_LDC}
${ldconfig} -elf ${_ins} ${_LDC}
 
-   case `sysctl -n hw.machine_arch` in
+   machine_arch=$(sysctl -n hw.machine_arch)
+
+   case ${machine_arch} in
amd64|mips64|powerpc64)
for i in ${ldconfig_local32_dirs}; do
if [ -d "${i}" ]; then
@@ -62,7 +64,7 @@ ldconfig_start()
;;
esac
 
-   case `sysctl -n hw.machine_arch` in
+   case ${machine_arch} in
armv[67])
for i in ${ldconfig_localsoft_dirs}; do
if [ -d "${i}" ]; then
@@ -85,7 +87,7 @@ ldconfig_start()
esac
 
# Legacy aout support for i386 only
-   case `sysctl -n hw.machine_arch` in
+   case ${machine_arch} in
i386)
# Default the a.out ldconfig path.
: ${ldconfig_paths_aout=${ldconfig_paths}}
___
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: r355164 - in head: . share/man/man4 sys/amd64/conf sys/conf sys/dev/trm sys/i386/conf sys/modules sys/modules/trm

2019-11-30 Thread Enji Cooper

> On Nov 27, 2019, at 6:32 PM, Scott Long  wrote:
> 
> Author: scottl
> Date: Thu Nov 28 02:32:17 2019
> New Revision: 355164
> URL: https://svnweb.freebsd.org/changeset/base/355164
> 
> Log:
>  Remove the trm(4) driver
> 
>  Differential Revision:   https://reviews.freebsd.org/D22575

Hi Scott,
I believe this driver was removed because it was impacts the CAM GIANT 
lock removal effort — is that true (I’m asking because the “why” behind the 
removal is unclear)?
Thanks!
-Enji
___
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: r355164 - in head: . share/man/man4 sys/amd64/conf sys/conf sys/dev/trm sys/i386/conf sys/modules sys/modules/trm

2019-11-30 Thread Warner Losh
On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper  wrote:

>
> > On Nov 27, 2019, at 6:32 PM, Scott Long  wrote:
> >
> > Author: scottl
> > Date: Thu Nov 28 02:32:17 2019
> > New Revision: 355164
> > URL: https://svnweb.freebsd.org/changeset/base/355164
> >
> > Log:
> >  Remove the trm(4) driver
> >
> >  Differential Revision:   https://reviews.freebsd.org/D22575
>
> Hi Scott,
> I believe this driver was removed because it was impacts the CAM
> GIANT lock removal effort — is that true (I’m asking because the “why”
> behind the removal is unclear)?
>

Hi Enji,

We're trying hard to get rid of all Giant-locked drivers in the tree,
either by updating or removal. Since sym(4) provides a super-set of trm(4)
and we have recent-ish reports of sym(4) working, it makes sense to trim
this driver from the tree. The specific cards it supports aren't all that
popular, the couple-extra features that trm(4) gave over sym(4) aren't
really that relevant today, and it's been years since trm has had good
testing and maintenance.

Warner
___
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: r355164 - in head: . share/man/man4 sys/amd64/conf sys/conf sys/dev/trm sys/i386/conf sys/modules sys/modules/trm

2019-11-30 Thread Enji Cooper

> On Nov 30, 2019, at 10:03 AM, Warner Losh  wrote:
> 
> 
> 
> On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper  > wrote:
> 
> > On Nov 27, 2019, at 6:32 PM, Scott Long  wrote:
> > 
> > Author: scottl
> > Date: Thu Nov 28 02:32:17 2019
> > New Revision: 355164
> > URL: https://svnweb.freebsd.org/changeset/base/355164 
> > 
> > 
> > Log:
> >  Remove the trm(4) driver
> > 
> >  Differential Revision:   https://reviews.freebsd.org/D22575 
> > 
> 
> Hi Scott,
> I believe this driver was removed because it was impacts the CAM 
> GIANT lock removal effort — is that true (I’m asking because the “why” behind 
> the removal is unclear)?
> 
> Hi Enji,
> 
> We're trying hard to get rid of all Giant-locked drivers in the tree, either 
> by updating or removal. Since sym(4) provides a super-set of trm(4) and we 
> have recent-ish reports of sym(4) working, it makes sense to trim this driver 
> from the tree. The specific cards it supports aren't all that popular, the 
> couple-extra features that trm(4) gave over sym(4) aren't really that 
> relevant today, and it's been years since trm has had good testing and 
> maintenance.

Warner,
Thanks so very much for the info :). Glad to see this effort taking 
place, since it’s very needed to modernize FreeBSD and improve concurrency in 
the kernel, as well as reduce the overall maintenance burden.
Keep up the good work :)!
Cheers!
-Enji
___
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: r355164 - in head: . share/man/man4 sys/amd64/conf sys/conf sys/dev/trm sys/i386/conf sys/modules sys/modules/trm

2019-11-30 Thread Warner Losh
On Sat, Nov 30, 2019 at 11:58 AM Enji Cooper  wrote:

>
> On Nov 30, 2019, at 10:03 AM, Warner Losh  wrote:
>
>
>
> On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper 
> wrote:
>
>>
>> > On Nov 27, 2019, at 6:32 PM, Scott Long  wrote:
>> >
>> > Author: scottl
>> > Date: Thu Nov 28 02:32:17 2019
>> > New Revision: 355164
>> > URL: https://svnweb.freebsd.org/changeset/base/355164
>> >
>> > Log:
>> >  Remove the trm(4) driver
>> >
>> >  Differential Revision:   https://reviews.freebsd.org/D22575
>>
>> Hi Scott,
>> I believe this driver was removed because it was impacts the CAM
>> GIANT lock removal effort — is that true (I’m asking because the “why”
>> behind the removal is unclear)?
>>
>
> Hi Enji,
>
> We're trying hard to get rid of all Giant-locked drivers in the tree,
> either by updating or removal. Since sym(4) provides a super-set of trm(4)
> and we have recent-ish reports of sym(4) working, it makes sense to trim
> this driver from the tree. The specific cards it supports aren't all that
> popular, the couple-extra features that trm(4) gave over sym(4) aren't
> really that relevant today, and it's been years since trm has had good
> testing and maintenance.
>
>
> Warner,
> Thanks so very much for the info :). Glad to see this effort taking place,
> since it’s very needed to modernize FreeBSD and improve concurrency in the
> kernel, as well as reduce the overall maintenance burden.
>

Giant isn't contending, but it's getting in the way of a cleanup of the
console / kbd system, as well as there being newbus issues in highly
dynamic systems. With TB and USB4 support on the horizon, we need to
finally clean that mess up.. I'll post a longer summary of what's left. I
have a 'doodle' tree that I'm separating out the Giant usage to 'driver
lock', kbd/console/ddb, newbus, sysctl, and WTF is that protecting... I'm
tempted to create wtf_lock() and wtf_unlock(), but I'm not sure how well
that would go over :)

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


svn commit: r355239 - head/sys/dev/ofw

2019-11-30 Thread Ian Lepore
Author: ian
Date: Sat Nov 30 19:16:44 2019
New Revision: 355239
URL: https://svnweb.freebsd.org/changeset/base/355239

Log:
  Add an OFWBUS_PNP_INFO() macro for devices that hang directly off the root
  ofwbus.  Also, apply some style(9) whitespace fixing to the
  SIMPLEBUS_PNP_INFO() macro (no functional change).

Modified:
  head/sys/dev/ofw/ofw_bus_subr.h

Modified: head/sys/dev/ofw/ofw_bus_subr.h
==
--- head/sys/dev/ofw/ofw_bus_subr.h Sat Nov 30 18:55:50 2019
(r355238)
+++ head/sys/dev/ofw/ofw_bus_subr.h Sat Nov 30 19:16:44 2019
(r355239)
@@ -69,7 +69,8 @@ struct intr_map_data_fdt {
 #define FDTCOMPAT_PNP_INFO(t, busname) \
MODULE_PNP_INFO(FDTCOMPAT_PNP_DESCR, busname, t, t, sizeof(t) / 
sizeof(t[0]));
 
-#define SIMPLEBUS_PNP_INFO(t) FDTCOMPAT_PNP_INFO(t, simplebus)
+#defineOFWBUS_PNP_INFO(t)  FDTCOMPAT_PNP_INFO(t, ofwbus)
+#defineSIMPLEBUS_PNP_INFO(t)   FDTCOMPAT_PNP_INFO(t, simplebus)
 
 /* Generic implementation of ofw_bus_if.m methods and helper routines */
 intofw_bus_gen_setup_devinfo(struct ofw_bus_devinfo *, phandle_t);
___
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: r355164 - in head: . share/man/man4 sys/amd64/conf sys/conf sys/dev/trm sys/i386/conf sys/modules sys/modules/trm

2019-11-30 Thread Enji Cooper

> On Nov 30, 2019, at 11:01 AM, Warner Losh  wrote:
> 
> On Sat, Nov 30, 2019 at 11:58 AM Enji Cooper  > wrote:
> 
>> On Nov 30, 2019, at 10:03 AM, Warner Losh > > wrote:
>> 
>> 
>> 
>> On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper > > wrote:
>> 
>> > On Nov 27, 2019, at 6:32 PM, Scott Long > > > wrote:
>> > 
>> > Author: scottl
>> > Date: Thu Nov 28 02:32:17 2019
>> > New Revision: 355164
>> > URL: https://svnweb.freebsd.org/changeset/base/355164 
>> > 
>> > 
>> > Log:
>> >  Remove the trm(4) driver
>> > 
>> >  Differential Revision:   https://reviews.freebsd.org/D22575 
>> > 
>> 
>> Hi Scott,
>> I believe this driver was removed because it was impacts the CAM 
>> GIANT lock removal effort — is that true (I’m asking because the “why” 
>> behind the removal is unclear)?
>> 
>> Hi Enji,
>> 
>> We're trying hard to get rid of all Giant-locked drivers in the tree, either 
>> by updating or removal. Since sym(4) provides a super-set of trm(4) and we 
>> have recent-ish reports of sym(4) working, it makes sense to trim this 
>> driver from the tree. The specific cards it supports aren't all that 
>> popular, the couple-extra features that trm(4) gave over sym(4) aren't 
>> really that relevant today, and it's been years since trm has had good 
>> testing and maintenance.
> 
> Warner,
>   Thanks so very much for the info :). Glad to see this effort taking 
> place, since it’s very needed to modernize FreeBSD and improve concurrency in 
> the kernel, as well as reduce the overall maintenance burden.
> 
> Giant isn't contending, but it's getting in the way of a cleanup of the 
> console / kbd system, as well as there being newbus issues in highly dynamic 
> systems. With TB and USB4 support on the horizon, we need to finally clean 
> that mess up.. I'll post a longer summary of what's left. I have a 'doodle' 
> tree that I'm separating out the Giant usage to 'driver lock', 
> kbd/console/ddb, newbus, sysctl, and WTF is that protecting... I'm tempted to 
> create wtf_lock() and wtf_unlock(), but I'm not sure how well that would go 
> over :)

Sounds great :D…
-Enji

PS wtf_lock() would be amusing, but probably less of a good idea these days 
:D...
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355241 - head/sys/kern

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sat Nov 30 19:33:02 2019
New Revision: 355241
URL: https://svnweb.freebsd.org/changeset/base/355241

Log:
  smp: cast the read in quiesce_all_critical through void *
  
  Fixes compilation on some 32-bit arm platforms.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/kern/subr_smp.c

Modified: head/sys/kern/subr_smp.c
==
--- head/sys/kern/subr_smp.cSat Nov 30 19:21:29 2019(r355240)
+++ head/sys/kern/subr_smp.cSat Nov 30 19:33:02 2019(r355241)
@@ -952,7 +952,7 @@ quiesce_all_critical(void)
break;
cpu_spinwait();
newtd = (struct thread *)
-   atomic_load_acq_ptr((u_long *)pcpu->pc_curthread);
+   atomic_load_acq_ptr((void *)pcpu->pc_curthread);
if (td != newtd)
break;
}
___
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: r355164 - in head: . share/man/man4 sys/amd64/conf sys/conf sys/dev/trm sys/i386/conf sys/modules sys/modules/trm

2019-11-30 Thread Ian Lepore
On Sat, 2019-11-30 at 11:25 -0800, Enji Cooper wrote:
> > On Nov 30, 2019, at 11:01 AM, Warner Losh  wrote:
> > 
> > On Sat, Nov 30, 2019 at 11:58 AM Enji Cooper  >  > wrote:
> > 
> > > On Nov 30, 2019, at 10:03 AM, Warner Losh  > > > wrote:
> > > 
> > > 
> > > 
> > > On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper <
> > > yaneurab...@gmail.com > wrote:
> > > 
> > > > On Nov 27, 2019, at 6:32 PM, Scott Long  > > > > wrote:
> > > > 
> > > > Author: scottl
> > > > Date: Thu Nov 28 02:32:17 2019
> > > > New Revision: 355164
> > > > URL: https://svnweb.freebsd.org/changeset/base/355164 <
> > > > https://svnweb.freebsd.org/changeset/base/355164>
> > > > 
> > > > Log:
> > > >  Remove the trm(4) driver
> > > > 
> > > >  Differential Revision:   
> > > > https://reviews.freebsd.org/D22575 <
> > > > https://reviews.freebsd.org/D22575>
> > > 
> > > Hi Scott,
> > > I believe this driver was removed because it was impacts
> > > the CAM GIANT lock removal effort — is that true (I’m asking
> > > because the “why” behind the removal is unclear)?
> > > 
> > > Hi Enji,
> > > 
> > > We're trying hard to get rid of all Giant-locked drivers in the
> > > tree, either by updating or removal. Since sym(4) provides a
> > > super-set of trm(4) and we have recent-ish reports of sym(4)
> > > working, it makes sense to trim this driver from the tree. The
> > > specific cards it supports aren't all that popular, the couple-
> > > extra features that trm(4) gave over sym(4) aren't really that
> > > relevant today, and it's been years since trm has had good
> > > testing and maintenance.
> > 
> > Warner,
> > Thanks so very much for the info :). Glad to see this effort
> > taking place, since it’s very needed to modernize FreeBSD and
> > improve concurrency in the kernel, as well as reduce the overall
> > maintenance burden.
> > 
> > Giant isn't contending, but it's getting in the way of a cleanup of
> > the console / kbd system, as well as there being newbus issues in
> > highly dynamic systems. With TB and USB4 support on the horizon, we
> > need to finally clean that mess up.. I'll post a longer summary of
> > what's left. I have a 'doodle' tree that I'm separating out the
> > Giant usage to 'driver lock', kbd/console/ddb, newbus, sysctl, and
> > WTF is that protecting... I'm tempted to create wtf_lock() and
> > wtf_unlock(), but I'm not sure how well that would go over :)
> 
> Sounds great :D…
> -Enji
> 
> PS wtf_lock() would be amusing, but probably less of a good idea
> these days :D...

But naming is important... I was wondering the other day whether Giant
would have been misused and overused less if it had been named
splhigh_lock.

-- Ian

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


svn commit: r355247 - head/libexec/save-entropy

2019-11-30 Thread Xin LI
Author: delphij
Date: Sat Nov 30 20:06:53 2019
New Revision: 355247
URL: https://svnweb.freebsd.org/changeset/base/355247

Log:
  Reduce disk write load in /usr/libexec/save-entropy.
  
  Before this commit, the save-entropy script rotates entropy files
  like logs. This involves creating a new file that holds the entropy
  and renaming of all existing entropy files. However, the entropy
  data do not really need to be kept in a particular order, and
  replacing the oldest file is sufficient.
  
  This commit replaces the rotation with a scan in the
  [1..entropy_save_num] space that finds the first empty slot, or
  the slot of the oldest file, and writes entropy into that slot.
  
  This also fixes an issue that prevents save-entropy from saving
  any entropy when there is one non-regular file in any slot as a
  side effect.
  
  Based on an earlier patch from peterj@.
  
  PR:   134225
  Reported by:  peterj
  Reviewed by:  csprng (cem, markm)
  MFC after:2 weeks
  Differential Revision:https://reviews.freebsd.org/D22612

Modified:
  head/libexec/save-entropy/save-entropy.sh

Modified: head/libexec/save-entropy/save-entropy.sh
==
--- head/libexec/save-entropy/save-entropy.sh   Sat Nov 30 20:04:40 2019
(r355246)
+++ head/libexec/save-entropy/save-entropy.sh   Sat Nov 30 20:06:53 2019
(r355247)
@@ -71,26 +71,63 @@ cd "${entropy_dir}" || {
 
 for f in saved-entropy.*; do
case "${f}" in saved-entropy.\*) continue ;; esac   # No files match
-   [ ${f#saved-entropy\.} -ge ${entropy_save_num} ] && unlink ${f}
+   [ ${f#saved-entropy\.} -gt ${entropy_save_num} ] && unlink ${f}
 done
 
-umask 377
+umask 177
 
-n=$(( ${entropy_save_num} - 1 ))
-while [ ${n} -ge 1 ]; do
-   if [ -f "saved-entropy.${n}" ]; then
-   mv "saved-entropy.${n}" "saved-entropy.$(( ${n} + 1 ))"
-   elif [ -e "saved-entropy.${n}" -o -L "saved-entropy.${n}" ]; then
+# Scan slots [1..$entropy_save_num), picking an empty slot or the oldest
+# existing file if no empty slot was available.
+#
+# 1. Find out the first regular file or empty slot (and its serial number)
+#
+n=1
+while [ ${n} -le ${entropy_save_num} ]; do
+   save_file="saved-entropy.${n}"
+   if [ ! -e "${save_file}" -o -f "${save_file}" ]; then
+   break
+   else
logger -is -t "$0" \
-   "${entropy_dir}/saved-entropy.${n}" is not a regular file, and so \
-   it will not be rotated. Entropy file rotation is aborted.
-   exit 1
+   "${save_file}" is not a regular file, skipped.
fi
-   n=$(( ${n} - 1 ))
+   n=$(( ${n} + 1 ))
 done
+#
+# 2. Start from (serial number + 1), and check if the slot is empty
+#or is an older regular file, update save_file pointer in either
+#case, and break early if we found an empty slot.
+#
+if [ -f ${save_file} ]; then
+   n=$(( ${n} + 1 ))
+   while [ ${n} -le ${entropy_save_num} ]; do
+   next_file=saved-entropy.${n}
+   if [ -f "${next_file}" ]; then
+   [ "${next_file}" -ot "${save_file}" ] && \
+   save_file="${next_file}"
+   elif [ ! -e "${next_file}" ]; then
+   save_file="${next_file}"
+   break
+   else
+   logger -is -t "$0" \
+   "${next_file}" is not a regular file, skipped.
+   fi
+   n=$(( ${n} + 1 ))
+   done
+fi
+#
+# 3. Check if the pointer we have in hand is really a regular file or
+#an empty slot, and bail out as that means there is no available slot.
+#
+if [ -e "${save_file}" -a ! -f "${save_file}" ]; then
+   logger -is -t "$0" \
+   No available slot in "${entropy_dir}", save entropy is aborted.
+   exit 1
+fi
 
-dd if=/dev/random of=saved-entropy.1 bs=${entropy_save_sz} count=1 2>/dev/null
-chflags nodump saved-entropy.1 2>/dev/null || :
-fsync saved-entropy.1 "."
+# Save entropy to the selected slot.
+chmod 600 "${save_file}" 2>/dev/null || :
+dd if=/dev/random of="${save_file}" bs=${entropy_save_sz} count=1 2>/dev/null
+chflags nodump "${save_file}" 2>/dev/null || :
+fsync "${save_file}" "."
 
 exit 0
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355248 - in head: share/man/man4 sys/fs/devfs sys/kern

2019-11-30 Thread Kyle Evans
Author: kevans
Date: Sat Nov 30 20:10:50 2019
New Revision: 355248
URL: https://svnweb.freebsd.org/changeset/base/355248

Log:
  tty: implement TIOCNOTTY
  
  Generally, it's preferred that an application fork/setsid if it doesn't want
  to keep its controlling TTY, but it could be that a debugger is trying to
  steal it instead -- so it would hook in, drop the controlling TTY, then do
  some magic to set things up again. In this case, TIOCNOTTY is quite handy
  and still respected by at least OpenBSD, NetBSD, and Linux as far as I can
  tell.
  
  I've dropped the note about obsoletion, as I intend to support TIOCNOTTY as
  long as it doesn't impose a major burden.
  
  Reviewed by:  bcr (manpages), kib
  Differential Revision:https://reviews.freebsd.org/D22572

Modified:
  head/share/man/man4/tty.4
  head/sys/fs/devfs/devfs_vnops.c
  head/sys/kern/tty.c

Modified: head/share/man/man4/tty.4
==
--- head/share/man/man4/tty.4   Sat Nov 30 20:06:53 2019(r355247)
+++ head/share/man/man4/tty.4   Sat Nov 30 20:10:50 2019(r355248)
@@ -28,7 +28,7 @@
 .\" @(#)tty.4  8.3 (Berkeley) 4/19/94
 .\" $FreeBSD$
 .\"
-.Dd January 11, 2017
+.Dd November 27, 2019
 .Dt TTY 4
 .Os
 .Sh NAME
@@ -194,7 +194,6 @@ Simulate typed input.
 Pretend as if the terminal received the character pointed to by
 .Fa cp .
 .It Dv TIOCNOTTY Fa void
-This call is obsolete but left for compatibility.
 In the past, when a process that did not have a controlling terminal (see
 .Em The Controlling Terminal
 in
@@ -203,7 +202,7 @@ first opened a terminal device, it acquired that termi
 controlling terminal.
 For some programs this was a hazard as they
 did not want a controlling terminal in the first place, and this
-provided a mechanism to disassociate the controlling terminal from
+provides a mechanism to disassociate the controlling terminal from
 the calling process.
 It
 .Em must
@@ -228,6 +227,14 @@ system call which will place the process into its own 
 has the effect of disassociating it from the controlling terminal.
 This is the new and preferred method for programs to lose their controlling
 terminal.
+.Pp
+However, environmental restrictions may prohibit the process from being able to
+.Fn fork
+and call the
+.Fn setsid
+system call to disassociate it from the controlling terminal.
+In this case, it must use
+.Dv TIOCNOTTY .
 .It Dv TIOCSTOP Fa void
 Stop output on the terminal (like typing ^S at the keyboard).
 .It Dv TIOCSTART Fa void

Modified: head/sys/fs/devfs/devfs_vnops.c
==
--- head/sys/fs/devfs/devfs_vnops.c Sat Nov 30 20:06:53 2019
(r355247)
+++ head/sys/fs/devfs/devfs_vnops.c Sat Nov 30 20:10:50 2019
(r355248)
@@ -829,9 +829,16 @@ devfs_ioctl(struct vop_ioctl_args *ap)
error = ENOTTY;
 
if (error == 0 && com == TIOCSCTTY) {
-   /* Do nothing if reassigning same control tty */
+   /*
+* Do nothing if reassigning same control tty, or if the
+* control tty has already disappeared.  If it disappeared,
+* it's because we were racing with TIOCNOTTY.  TIOCNOTTY
+* already took care of releasing the old vnode and we have
+* nothing left to do.
+*/
sx_slock(&proctree_lock);
-   if (td->td_proc->p_session->s_ttyvp == vp) {
+   if (td->td_proc->p_session->s_ttyvp == vp ||
+   td->td_proc->p_session->s_ttyp == NULL) {
sx_sunlock(&proctree_lock);
return (0);
}

Modified: head/sys/kern/tty.c
==
--- head/sys/kern/tty.c Sat Nov 30 20:06:53 2019(r355247)
+++ head/sys/kern/tty.c Sat Nov 30 20:10:50 2019(r355248)
@@ -1195,6 +1195,71 @@ tty_rel_gone(struct tty *tp)
tty_rel_free(tp);
 }
 
+static int
+tty_drop_ctty(struct tty *tp, struct proc *p)
+{
+   struct session *session;
+   struct vnode *vp;
+
+   /*
+* This looks terrible, but it's generally safe as long as the tty
+* hasn't gone away while we had the lock dropped.  All of our sanity
+* checking that this operation is OK happens after we've picked it back
+* up, so other state changes are generally not fatal and the potential
+* for this particular operation to happen out-of-order in a
+* multithreaded scenario is likely a non-issue.
+*/
+   tty_unlock(tp);
+   sx_xlock(&proctree_lock);
+   tty_lock(tp);
+   if (tty_gone(tp)) {
+   sx_xunlock(&proctree_lock);
+   return (ENODEV);
+   }
+
+   /*
+* If the session doesn't have a controlling TTY, or if we weren't
+* invoked on the controlling TTY, we'll

Re: svn commit: r355227 - head/sys/fs/tmpfs

2019-11-30 Thread Konstantin Belousov
On Sat, Nov 30, 2019 at 04:41:48PM +, Mateusz Guzik wrote:
> Author: mjg
> Date: Sat Nov 30 16:41:47 2019
> New Revision: 355227
> URL: https://svnweb.freebsd.org/changeset/base/355227
> 
> Log:
>   tmpfs: add fast path to tmpfs_access for common case lookup
>   
>   VEXEC consists of vast majority of all calls and almost all targets have
>   at least 0111.
On what load VEXEC is the dominant access check ?

> 
> Modified:
>   head/sys/fs/tmpfs/tmpfs_vnops.c
> 
> Modified: head/sys/fs/tmpfs/tmpfs_vnops.c
> ==
> --- head/sys/fs/tmpfs/tmpfs_vnops.c   Sat Nov 30 16:40:16 2019
> (r355226)
> +++ head/sys/fs/tmpfs/tmpfs_vnops.c   Sat Nov 30 16:41:47 2019
> (r355227)
> @@ -331,6 +331,12 @@ tmpfs_access(struct vop_access_args *v)
>  
>   node = VP_TO_TMPFS_NODE(vp);
>  
> + /*
> +  * Common case path lookup.
> +  */
> + if (__predict_true(accmode == VEXEC && (node->tn_mode & 0111) == 0111))
The 0111 must be spelled as (S_IXUSR | S_IXGRP | S_IXOTH).

> + return (0);
> +
>   switch (vp->v_type) {
>   case VDIR:
>   /* FALLTHROUGH */
___
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: r355227 - head/sys/fs/tmpfs

2019-11-30 Thread Mateusz Guzik
On 12/1/19, Konstantin Belousov  wrote:
> On Sat, Nov 30, 2019 at 04:41:48PM +, Mateusz Guzik wrote:
>> Author: mjg
>> Date: Sat Nov 30 16:41:47 2019
>> New Revision: 355227
>> URL: https://svnweb.freebsd.org/changeset/base/355227
>>
>> Log:
>>   tmpfs: add fast path to tmpfs_access for common case lookup
>>
>>   VEXEC consists of vast majority of all calls and almost all targets
>> have
>>   at least 0111.
> On what load VEXEC is the dominant access check ?
>

Note this is called for every directory to be traversed dooring lookup,
so for instance looking up "foo/bar/baz" performs 2 VEXEC checks.

Sample result from buildkernel. 64 is VEXEC.

dtrace -n 'fbt::tmpfs_access:entry { @[args[0]->a_accmode, ((struct
tmpfs_node *)args[0]->a_vp->v_data)->tn_mode & 0111] = count(); }'
dtrace: description 'fbt::tmpfs_access:entry ' matched 1 probe


  384   731
1651202
  1280   68
  3840  877
 40960 1049
  320   73 5965
 4096   7332471
  128   73   145115
  256   73   160569
  2560   999827
   64   73 32320731

>>
>> Modified:
>>   head/sys/fs/tmpfs/tmpfs_vnops.c
>>
>> Modified: head/sys/fs/tmpfs/tmpfs_vnops.c
>> ==
>> --- head/sys/fs/tmpfs/tmpfs_vnops.c  Sat Nov 30 16:40:16 2019
>> (r355226)
>> +++ head/sys/fs/tmpfs/tmpfs_vnops.c  Sat Nov 30 16:41:47 2019
>> (r355227)
>> @@ -331,6 +331,12 @@ tmpfs_access(struct vop_access_args *v)
>>
>>  node = VP_TO_TMPFS_NODE(vp);
>>
>> +/*
>> + * Common case path lookup.
>> + */
>> +if (__predict_true(accmode == VEXEC && (node->tn_mode & 0111) == 0111))
> The 0111 must be spelled as (S_IXUSR | S_IXGRP | S_IXOTH).
>

Ok.

>> +return (0);
>> +
>>  switch (vp->v_type) {
>>  case VDIR:
>>  /* FALLTHROUGH */
>


-- 
Mateusz Guzik 
___
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: r355227 - head/sys/fs/tmpfs

2019-11-30 Thread Konstantin Belousov
On Sun, Dec 01, 2019 at 12:15:06AM +0100, Mateusz Guzik wrote:
> On 12/1/19, Konstantin Belousov  wrote:
> > On Sat, Nov 30, 2019 at 04:41:48PM +, Mateusz Guzik wrote:
> >> Author: mjg
> >> Date: Sat Nov 30 16:41:47 2019
> >> New Revision: 355227
> >> URL: https://svnweb.freebsd.org/changeset/base/355227
> >>
> >> Log:
> >>   tmpfs: add fast path to tmpfs_access for common case lookup
> >>
> >>   VEXEC consists of vast majority of all calls and almost all targets
> >> have
> >>   at least 0111.
> > On what load VEXEC is the dominant access check ?
> >
> 
> Note this is called for every directory to be traversed dooring lookup,
> so for instance looking up "foo/bar/baz" performs 2 VEXEC checks.
So it is for directory components traversal during lookup.
Does it make sense to add something similar at the start of
ufs_accessx() when neither kind of ACLs is enabled for mp ?

> 
> Sample result from buildkernel. 64 is VEXEC.
> 
> dtrace -n 'fbt::tmpfs_access:entry { @[args[0]->a_accmode, ((struct
> tmpfs_node *)args[0]->a_vp->v_data)->tn_mode & 0111] = count(); }'
> dtrace: description 'fbt::tmpfs_access:entry ' matched 1 probe
> 
> 
>   384   731
> 1651202
>   1280   68
>   3840  877
>  40960 1049
>   320   73 5965
>  4096   7332471
>   128   73   145115
>   256   73   160569
>   2560   999827
>64   73 32320731
> 
> >>
> >> Modified:
> >>   head/sys/fs/tmpfs/tmpfs_vnops.c
> >>
> >> Modified: head/sys/fs/tmpfs/tmpfs_vnops.c
> >> ==
> >> --- head/sys/fs/tmpfs/tmpfs_vnops.cSat Nov 30 16:40:16 2019
> >> (r355226)
> >> +++ head/sys/fs/tmpfs/tmpfs_vnops.cSat Nov 30 16:41:47 2019
> >> (r355227)
> >> @@ -331,6 +331,12 @@ tmpfs_access(struct vop_access_args *v)
> >>
> >>node = VP_TO_TMPFS_NODE(vp);
> >>
> >> +  /*
> >> +   * Common case path lookup.
> >> +   */
> >> +  if (__predict_true(accmode == VEXEC && (node->tn_mode & 0111) == 0111))
> > The 0111 must be spelled as (S_IXUSR | S_IXGRP | S_IXOTH).
> >
> 
> Ok.
> 
> >> +  return (0);
> >> +
> >>switch (vp->v_type) {
> >>case VDIR:
> >>/* FALLTHROUGH */
> >
> 
> 
> -- 
> Mateusz Guzik 
___
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: r355227 - head/sys/fs/tmpfs

2019-11-30 Thread Mateusz Guzik
On 12/1/19, Konstantin Belousov  wrote:
> On Sun, Dec 01, 2019 at 12:15:06AM +0100, Mateusz Guzik wrote:
>> On 12/1/19, Konstantin Belousov  wrote:
>> > On Sat, Nov 30, 2019 at 04:41:48PM +, Mateusz Guzik wrote:
>> >> Author: mjg
>> >> Date: Sat Nov 30 16:41:47 2019
>> >> New Revision: 355227
>> >> URL: https://svnweb.freebsd.org/changeset/base/355227
>> >>
>> >> Log:
>> >>   tmpfs: add fast path to tmpfs_access for common case lookup
>> >>
>> >>   VEXEC consists of vast majority of all calls and almost all targets
>> >> have
>> >>   at least 0111.
>> > On what load VEXEC is the dominant access check ?
>> >
>>
>> Note this is called for every directory to be traversed dooring lookup,
>> so for instance looking up "foo/bar/baz" performs 2 VEXEC checks.
> So it is for directory components traversal during lookup.
> Does it make sense to add something similar at the start of
> ufs_accessx() when neither kind of ACLs is enabled for mp ?
>

All filesystems should short-circuit it if they can. I have a review
of the sort for zfs which internally was using a step forward in this
idea by checking if any exec perms are denied:
https://reviews.freebsd.org/D4

However, if talking about ufs performance, I think the bigger fish
to fry is ufs_need_inactive. While I have not benchmarked, if
tmpfs and zfs are of any help, concurrent path lookup will keep
contending on vputx relocking the vnode in exclusive manner.
This not only slows things down as it is, It is a hard blocker
for using adaptive spinning in lockmgr for this fs.

I may get around to providing both much later, but I suspect
you are much more familiar with the fs than I am and could
do it significantly faster.

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


svn commit: r355254 - in head/sys: netinet netinet6 netipsec

2019-11-30 Thread Bjoern A. Zeeb
Author: bz
Date: Sun Dec  1 00:22:04 2019
New Revision: 355254
URL: https://svnweb.freebsd.org/changeset/base/355254

Log:
  Fix m_pullup() problem after removing PULLDOWN_TESTs and KAME EXT_*macros.
  
  r354748-354750 replaced the KAME macros with m_pulldown() calls.
  Contrary to the rest of the network stack m_len checks before m_pulldown()
  were not put in placed (see r354748).
  Put these m_len checks in place for now (to go along with the style of the
  network stack since the initial commits).  These are not put in for
  performance but to avoid an error scenario (even though it also will help
  performance at the moment as it avoid allocating an extra mbuf; not because
  of the unconditional function call).
  
  The observed error case went like this:
  (1) an mbuf with M_EXT arrives and we call m_pullup() unconditionally on it.
  (2) m_pullup() will call m_get() unless the requested length is larger than
  MHLEN (in which case it'll m_freem() the perfectly fine mbuf) and migrate the
  requested length of data and pkthdr into the new mbuf.
  (3) If m_get() succeeds, a further m_pullup() call going over MHLEN will fail.
  This was observed with failing auto-configuration as an RA packet of
  200 bytes exceeded MHLEN and the m_pullup() called from nd6_ra_input()
  dropped the mbuf.
  (Re-)adding the m_len checks before m_pullup() calls avoids this problems
  with mbufs using external storage for now.
  
  MFC after:3 weeks
  Sponsored by: Netflix

Modified:
  head/sys/netinet/ip_carp.c
  head/sys/netinet/tcp_input.c
  head/sys/netinet6/dest6.c
  head/sys/netinet6/frag6.c
  head/sys/netinet6/icmp6.c
  head/sys/netinet6/ip6_input.c
  head/sys/netinet6/ip6_mroute.c
  head/sys/netinet6/mld6.c
  head/sys/netinet6/nd6_nbr.c
  head/sys/netinet6/nd6_rtr.c
  head/sys/netinet6/route6.c
  head/sys/netinet6/sctp6_usrreq.c
  head/sys/netinet6/udp6_usrreq.c
  head/sys/netipsec/xform_ah.c
  head/sys/netipsec/xform_esp.c

Modified: head/sys/netinet/ip_carp.c
==
--- head/sys/netinet/ip_carp.c  Sat Nov 30 21:11:17 2019(r355253)
+++ head/sys/netinet/ip_carp.c  Sun Dec  1 00:22:04 2019(r355254)
@@ -566,12 +566,14 @@ carp6_input(struct mbuf **mp, int *offp, int proto)
}
 
/* verify that we have a complete carp packet */
-   len = m->m_len;
-   m = m_pullup(m, *offp + sizeof(*ch));
-   if (m == NULL) {
-   CARPSTATS_INC(carps_badlen);
-   CARP_DEBUG("%s: packet size %u too small\n", __func__, len);
-   return (IPPROTO_DONE);
+   if (m->m_len < *offp + sizeof(*ch)) {
+   len = m->m_len;
+   m = m_pullup(m, *offp + sizeof(*ch));
+   if (m == NULL) {
+   CARPSTATS_INC(carps_badlen);
+   CARP_DEBUG("%s: packet size %u too small\n", __func__, 
len);
+   return (IPPROTO_DONE);
+   }
}
ch = (struct carp_header *)(mtod(m, caddr_t) + *offp);
 

Modified: head/sys/netinet/tcp_input.c
==
--- head/sys/netinet/tcp_input.cSat Nov 30 21:11:17 2019
(r355253)
+++ head/sys/netinet/tcp_input.cSun Dec  1 00:22:04 2019
(r355254)
@@ -517,11 +517,13 @@ tcp6_input(struct mbuf **mp, int *offp, int proto)
struct ip6_hdr *ip6;
 
m = *mp;
-   m = m_pullup(m, *offp + sizeof(struct tcphdr));
-   if (m == NULL) {
-   *mp = m;
-   TCPSTAT_INC(tcps_rcvshort);
-   return (IPPROTO_DONE);
+   if (m->m_len < *offp + sizeof(struct tcphdr)) {
+   m = m_pullup(m, *offp + sizeof(struct tcphdr));
+   if (m == NULL) {
+   *mp = m;
+   TCPSTAT_INC(tcps_rcvshort);
+   return (IPPROTO_DONE);
+   }
}
 
/*
@@ -708,10 +710,12 @@ tcp_input(struct mbuf **mp, int *offp, int proto)
if (off > sizeof (struct tcphdr)) {
 #ifdef INET6
if (isipv6) {
-   m = m_pullup(m, off0 + off);
-   if (m == NULL) {
-   TCPSTAT_INC(tcps_rcvshort);
-   return (IPPROTO_DONE);
+   if (m->m_len < off0 + off) {
+   m = m_pullup(m, off0 + off);
+   if (m == NULL) {
+   TCPSTAT_INC(tcps_rcvshort);
+   return (IPPROTO_DONE);
+   }
}
ip6 = mtod(m, struct ip6_hdr *);
th = (struct tcphdr *)((caddr_t)ip6 + off0);

Modified: head/sys/netinet6/dest6.c
==
--- head/sys/netinet6/dest6.c   Sat Nov 30 21:11:17 20

svn commit: r355255 - head/sys/fs/tmpfs

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sun Dec  1 00:34:49 2019
New Revision: 355255
URL: https://svnweb.freebsd.org/changeset/base/355255

Log:
  tmpfs: use proper macros for permission values in tmpfs_access
  
  While here group them in one var to prevent overy long lines. Perhaps a
  general macro of the same sort should be introduced.
  
  Requested by: kib

Modified:
  head/sys/fs/tmpfs/tmpfs_vnops.c

Modified: head/sys/fs/tmpfs/tmpfs_vnops.c
==
--- head/sys/fs/tmpfs/tmpfs_vnops.c Sun Dec  1 00:22:04 2019
(r355254)
+++ head/sys/fs/tmpfs/tmpfs_vnops.c Sun Dec  1 00:34:49 2019
(r355255)
@@ -323,7 +323,7 @@ tmpfs_access(struct vop_access_args *v)
struct vnode *vp = v->a_vp;
accmode_t accmode = v->a_accmode;
struct ucred *cred = v->a_cred;
-
+   mode_t all_x = S_IXUSR | S_IXGRP | S_IXOTH;
int error;
struct tmpfs_node *node;
 
@@ -334,7 +334,7 @@ tmpfs_access(struct vop_access_args *v)
/*
 * Common case path lookup.
 */
-   if (__predict_true(accmode == VEXEC && (node->tn_mode & 0111) == 0111))
+   if (__predict_true(accmode == VEXEC && (node->tn_mode & all_x) == 
all_x))
return (0);
 
switch (vp->v_type) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355256 - in head/sys: kern sys

2019-11-30 Thread Mateusz Guzik
Author: mjg
Date: Sun Dec  1 00:35:08 2019
New Revision: 355256
URL: https://svnweb.freebsd.org/changeset/base/355256

Log:
  lockmgr: remove more remnants of adaptive spinning
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/kern/kern_lock.c
  head/sys/sys/lockmgr.h

Modified: head/sys/kern/kern_lock.c
==
--- head/sys/kern/kern_lock.c   Sun Dec  1 00:34:49 2019(r355255)
+++ head/sys/kern/kern_lock.c   Sun Dec  1 00:35:08 2019(r355256)
@@ -61,8 +61,6 @@ __FBSDID("$FreeBSD$");
 PMC_SOFT_DECLARE( , , lock, failed);
 #endif
 
-CTASSERT(((LK_ADAPTIVE | LK_NOSHARE) & LO_CLASSFLAGS) ==
-(LK_ADAPTIVE | LK_NOSHARE));
 CTASSERT(LK_UNLOCKED == (LK_UNLOCKED &
 ~(LK_ALL_WAITERS | LK_EXCLUSIVE_SPINNERS)));
 
@@ -136,10 +134,6 @@ LK_CAN_SHARE(uintptr_t x, int flags, bool fp)
 #defineLK_TRYWIT(x)
\
(LK_TRYOP(x) ? LOP_TRYLOCK : 0)
 
-#defineLK_CAN_ADAPT(lk, f) 
\
-   (((lk)->lock_object.lo_flags & LK_ADAPTIVE) != 0 && \
-   ((f) & LK_SLEEPFAIL) == 0)
-
 #definelockmgr_disowned(lk)
\
(((lk)->lk_lock & ~(LK_FLAGMASK & ~LK_SHARE)) == LK_KERNPROC)
 
@@ -453,7 +447,7 @@ lockinit(struct lock *lk, int pri, const char *wmesg, 
iflags |= LO_IS_VNODE;
if (flags & LK_NEW)
iflags |= LO_NEW;
-   iflags |= flags & (LK_ADAPTIVE | LK_NOSHARE);
+   iflags |= flags & LK_NOSHARE;
 
lock_init(&lk->lock_object, &lock_class_lockmgr, wmesg, NULL, iflags);
lk->lk_lock = LK_UNLOCKED;

Modified: head/sys/sys/lockmgr.h
==
--- head/sys/sys/lockmgr.h  Sun Dec  1 00:34:49 2019(r355255)
+++ head/sys/sys/lockmgr.h  Sun Dec  1 00:35:08 2019(r355256)
@@ -150,7 +150,7 @@ _lockmgr_args_rw(struct lock *lk, u_int flags, struct 
 #defineLK_NOSHARE  0x08
 #defineLK_NOWITNESS0x10
 #defineLK_QUIET0x20
-#defineLK_ADAPTIVE 0x40
+#defineLK_UNUSED0  0x40/* Was LK_ADAPTIVE */
 #defineLK_IS_VNODE 0x80/* Tell WITNESS about a VNODE 
lock */
 #defineLK_NEW  0x000100
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355257 - head/sys/dev/usb/input

2019-11-30 Thread Kyle Evans
Author: kevans
Date: Sun Dec  1 03:56:18 2019
New Revision: 355257
URL: https://svnweb.freebsd.org/changeset/base/355257

Log:
  usb: remove some extraneous tty.h includes

Modified:
  head/sys/dev/usb/input/uep.c
  head/sys/dev/usb/input/ukbd.c
  head/sys/dev/usb/input/ums.c

Modified: head/sys/dev/usb/input/uep.c
==
--- head/sys/dev/usb/input/uep.cSun Dec  1 00:35:08 2019
(r355256)
+++ head/sys/dev/usb/input/uep.cSun Dec  1 03:56:18 2019
(r355257)
@@ -57,7 +57,6 @@
 #else
 #include 
 #include 
-#include 
 #endif
 
 #define USB_DEBUG_VAR uep_debug

Modified: head/sys/dev/usb/input/ukbd.c
==
--- head/sys/dev/usb/input/ukbd.c   Sun Dec  1 00:35:08 2019
(r355256)
+++ head/sys/dev/usb/input/ukbd.c   Sun Dec  1 03:56:18 2019
(r355257)
@@ -80,7 +80,6 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
-#include 
 #include 
 
 #include 

Modified: head/sys/dev/usb/input/ums.c
==
--- head/sys/dev/usb/input/ums.cSun Dec  1 00:35:08 2019
(r355256)
+++ head/sys/dev/usb/input/ums.cSun Dec  1 03:56:18 2019
(r355257)
@@ -79,7 +79,6 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
-#include 
 #include 
 
 #ifdef USB_DEBUG
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r355258 - head/sys/amd64/vmm/amd

2019-11-30 Thread Anish Gupta
Author: anish
Date: Sun Dec  1 04:00:08 2019
New Revision: 355258
URL: https://svnweb.freebsd.org/changeset/base/355258

Log:
  bhyve amd: amdvi_dump_cmds() log the command for which the command completion 
failed.  Completion is checked in poll mode although it can be done using 
interrupts.
  No need to log all the commands in command ring but only the last one for 
which completion failed.
  
  Reported by: n...@freebsd.org
  Reviewed by: np, markj
  MFC after: 2 weeks
  Differential Revision: https://reviews.freebsd.org/D22566

Modified:
  head/sys/amd64/vmm/amd/amdvi_hw.c

Modified: head/sys/amd64/vmm/amd/amdvi_hw.c
==
--- head/sys/amd64/vmm/amd/amdvi_hw.c   Sun Dec  1 03:56:18 2019
(r355257)
+++ head/sys/amd64/vmm/amd/amdvi_hw.c   Sun Dec  1 04:00:08 2019
(r355258)
@@ -66,7 +66,7 @@ SYSCTL_NODE(_hw_vmm, OID_AUTO, amdvi, CTLFLAG_RW, NULL
 /* Print RID or device ID in PCI string format. */
 #define RID2PCI_STR(d) PCI_RID2BUS(d), PCI_RID2SLOT(d), PCI_RID2FUNC(d)
 
-static void amdvi_dump_cmds(struct amdvi_softc *softc);
+static void amdvi_dump_cmds(struct amdvi_softc *softc, int count);
 static void amdvi_print_dev_cap(struct amdvi_softc *softc);
 
 MALLOC_DEFINE(M_AMDVI, "amdvi", "amdvi");
@@ -321,9 +321,7 @@ amdvi_cmd_cmp(struct amdvi_softc *softc, const uint64_
 
pa = vtophys(&softc->cmp_data);
cmd->opcode = AMDVI_CMP_WAIT_OPCODE;
-   cmd->word0 = (pa & 0xFFF8) |
-   (AMDVI_CMP_WAIT_STORE);
-   //(AMDVI_CMP_WAIT_FLUSH | AMDVI_CMP_WAIT_STORE);
+   cmd->word0 = (pa & 0xFFF8) | AMDVI_CMP_WAIT_STORE;
cmd->word1 = (pa >> 32) & 0xF;
cmd->addr = data;
 
@@ -492,26 +490,26 @@ amdvi_wait(struct amdvi_softc *softc)
device_printf(softc->dev, "Error: completion failed"
  " tail:0x%x, head:0x%x.\n",
  ctrl->cmd_tail, ctrl->cmd_head);
-   amdvi_dump_cmds(softc);
+   /* Dump the last command. */
+   amdvi_dump_cmds(softc, 1);
 }
 
 static void
-amdvi_dump_cmds(struct amdvi_softc *softc)
+amdvi_dump_cmds(struct amdvi_softc *softc, int count)
 {
struct amdvi_ctrl *ctrl;
struct amdvi_cmd *cmd;
int off, i;
 
ctrl = softc->ctrl;
-   device_printf(softc->dev, "Dump all the commands:\n");
+   device_printf(softc->dev, "Dump last %d command(s):\n", count);
/*
 * If h/w is stuck in completion, it is the previous command,
 * start dumping from previous command onward.
 */
off = MOD_DEC(ctrl->cmd_head, sizeof(struct amdvi_cmd),
softc->cmd_max);
-   for (i = 0; off != ctrl->cmd_tail &&
-   i < softc->cmd_max; i++) {
+   for (i = 0; off != ctrl->cmd_tail && i < count; i++) {
cmd = (struct amdvi_cmd *)((uint8_t *)softc->cmd + off);
printf("  [CMD%d, off:0x%x] opcode= 0x%x 0x%x"
" 0x%x 0x%lx\n", i, off, cmd->opcode,
___
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"