Re: svn commit: r313878 - head/sys/kern

2017-02-20 Thread Andriy Gapon 
On 21/02/2017 02:42, Pedro Giffuni wrote:
> FWIW,
> 
> 
> On 2/20/2017 7:24 PM, Bryan Drewery wrote:
>> On 2/17/2017 7:40 AM, Mateusz Guzik wrote:
>>> Author: mjg
>>> Date: Fri Feb 17 15:40:24 2017
>>> New Revision: 313878
>>> URL: https://svnweb.freebsd.org/changeset/base/313878
>>>
>>> Log:
>>>mtx: get rid of file/line args from slow paths if they are unused
>>>   This denotes changes which went in by accident in r313877.
>> I really wish people would just revert their changes and recommit them
>> properly.  The 'svn blame' on the code in r313877 will never show the
>> commit message here (r313878).  So a person would only find this
>> explanation if they read 'svn log' on the file, which in the case of
>> sys/kern/kern_mutex.c there are 273 commits for.  Are we expected to
>> read 'svn log' (in the future) for all changes in the hopes that a later
>> commit happens to mention it?
>>
>> As someone who so often is 'svn blame'ing code to understand it better
>> and to track regressions, commits like this that explain other commits
>> might as well have never been done.
> 
> As I mentioned in another thread, other svn configurations (ASF, for example)
> permit editing the log message:
> 
> http://help.collab.net/index.jsp?topic=/faq/changelog.html

How well do various svn exporters handle that?
Specifically, svn-> git ?

-- 
Andriy Gapon
___
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: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mateusz Guzik 
On Mon, Feb 20, 2017 at 09:39:32PM -0800, Mark Millard wrote:
> Looks like some kernel binary interface (as seen by
> emulators/virtualbox-ose-addition ) has changed:
> rebuilding emulators/virtualbox-ose-addition removed
> the booting crash but uname -apKU still lists 1200021
> and 2100021 for the kernel and world for -r313999,
> just like for -r313864.
> 

I think this is r313992.

I don't see why __FreeBSD_version would be modified for this. You are
expected to always recompilel your modules while tracking -current.

-- 
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: r314027 - head/sys/cam/ctl

2017-02-20 Thread Alexander Motin 
Author: mav
Date: Tue Feb 21 06:10:11 2017
New Revision: 314027
URL: https://svnweb.freebsd.org/changeset/base/314027

Log:
  Do not blindly free completed ATIOs/INOTs on invalidation.
  
  When LUN is disabled, SIM starts returning queued ATIOs/INOTs.  But at the
  same time there can be some ATIOs/INOTs still carrying real new requests.
  If we free those, SIM may leak some resources, forever expecting for any
  response from us.  So try to be careful, separating ATIOs/INOTs carrying
  requests which still must be processed, from ATIOs/INOTs completed with
  errors which can be freed.
  
  MFC after:2 weeks

Modified:
  head/sys/cam/ctl/scsi_ctl.c

Modified: head/sys/cam/ctl/scsi_ctl.c
==
--- head/sys/cam/ctl/scsi_ctl.c Tue Feb 21 05:13:16 2017(r314026)
+++ head/sys/cam/ctl/scsi_ctl.c Tue Feb 21 06:10:11 2017(r314027)
@@ -1096,6 +1096,7 @@ ctlfedone(struct cam_periph *periph, uni
struct ccb_accept_tio *atio = NULL;
union ctl_io *io = NULL;
struct mtx *mtx;
+   cam_status status;
 
KASSERT((done_ccb->ccb_h.flags & CAM_UNLOCKED) != 0,
("CCB in ctlfedone() without CAM_UNLOCKED flag"));
@@ -1122,30 +1123,15 @@ ctlfedone(struct cam_periph *periph, uni
mtx = cam_periph_mtx(periph);
mtx_lock(mtx);
 
-   /*
-* If the peripheral is invalid, ATIOs and immediate notify CCBs
-* need to be freed.  Most of the ATIOs and INOTs that come back
-* will be CCBs that are being returned from the SIM as a result of
-* our disabling the LUN.
-*
-* Other CCB types are handled in their respective cases below.
-*/
-   if (periph->flags & CAM_PERIPH_INVALID) {
-   switch (done_ccb->ccb_h.func_code) {
-   case XPT_ACCEPT_TARGET_IO:
-   case XPT_IMMEDIATE_NOTIFY:
-   case XPT_NOTIFY_ACKNOWLEDGE:
-   ctlfe_free_ccb(periph, done_ccb);
-   goto out;
-   default:
-   break;
-   }
-
-   }
switch (done_ccb->ccb_h.func_code) {
case XPT_ACCEPT_TARGET_IO: {
 
atio = _ccb->atio;
+   status = atio->ccb_h.status & CAM_STATUS_MASK;
+   if (status != CAM_CDB_RECVD) {
+   ctlfe_free_ccb(periph, done_ccb);
+   goto out;
+   }
 
  resubmit:
/*
@@ -1424,14 +1410,9 @@ ctlfedone(struct cam_periph *periph, uni
case XPT_IMMEDIATE_NOTIFY: {
union ctl_io *io;
struct ccb_immediate_notify *inot;
-   cam_status status;
int send_ctl_io;
 
inot = _ccb->cin1;
-   printf("%s: got XPT_IMMEDIATE_NOTIFY status %#x tag %#x "
-  "seq %#x\n", __func__, inot->ccb_h.status,
-  inot->tag_id, inot->seq_id);
-
io = done_ccb->ccb_h.io_ptr;
ctl_zero_io(io);
 
@@ -1497,40 +1478,22 @@ ctlfedone(struct cam_periph *periph, uni
break;
default:
xpt_print(periph->path,
- "%s: unsupported message 0x%x\n",
- __func__, inot->arg);
+   "%s: unsupported INOT message 0x%x\n",
+   __func__, inot->arg);
send_ctl_io = 0;
break;
}
break;
+   default:
+   xpt_print(periph->path,
+   "%s: unsupported INOT status 0x%x\n",
+   __func__, status);
+   /* FALLTHROUGH */
case CAM_REQ_ABORTED:
-   /*
-* This request was sent back by the driver.
-* XXX KDM what do we do here?
-*/
-   send_ctl_io = 0;
-   break;
case CAM_REQ_INVALID:
+   case CAM_DEV_NOT_THERE:
case CAM_PROVIDE_FAIL:
-   default:
-   /*
-* We should only get here if we're talking
-* to a talking to a SIM that is target
-* capable but supports the old API.  In
-* that case, we need to just free the CCB.
-* If we actually send a notify acknowledge,
-* it will send that back with an error as
-* well.
-*/
-
-   if ((status != CAM_REQ_INVALID)
-&& (status != CAM_PROVIDE_FAIL))
-

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mark Millard 
On 2017-Feb-20, at 6:36 PM, Mark Millard  wrote:

> On 2017-Feb-20, at 3:35 PM, Mateusz Guzik  wrote:
> 
>> On Mon, Feb 20, 2017 at 03:10:44PM -0800, Mark Millard wrote:
>>> On 2017-Feb-20, at 2:58 PM, Mark Millard  wrote:
>>> 
 On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:
 
> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
>> [Note: I experiment with clang based powerpc64 builds,
>> reporting problems that I find. Justin is familiar
>> with this, as is Nathan.]
>> 
>> I tried to update the PowerMac G5 (a so-called "Quad Core")
>> that I have access to from head -r312761 to -r313864 and
>> ended up with random panics and hang ups in fairly short
>> order after booting.
>> 
>> Some approximate bisecting for the kernel lead to:
>> (sometimes getting part way into a buildkernel attempt
>> for a different version before a failure happens)
>> 
>> -r313266: works (just before use of atomic_fcmpset)
>> vs.
>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
>> 
>> (I did not try -r313268 through -r313270 as the use was
>> gradually added.)
>> 
>> So I'm currently running a -r313864 world with a -r313266
>> kernel.
>> 
>> No kernel that I tried that was from before -r313266 had the
>> problems.
>> 
>> Any kernel that I tried that was from after -r313271 had the
>> problems.
>> 
>> Of course I did not try them all in other direction. :)
>> 
> 
> I found that spin mutexes were not properly handling this, fixed in
> r313996.
> 
> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
> fcmpset to simulate failures. Everything works, while it would easily
> fail without the patch.
> 
> That said, I hope this concludes the 'missing check for not-reread value
> of failed fcmpset' saga.
> 
> -- 
> Mateusz Guzik 
 
 I tried to update from -r313864 to -r313999 in my amd64 context
 (a VirtualBox machine under macOS) but it now crashes late in
 the boot sequence (after it processes a dump if I make one but
 before I can log in).
 
 This update was via my usual explicit svnlite update; buildworld
 buildkernel; etc. production style build of world and kernel,
 including use of MALLOC_PRODUCTION.
 
 The window shows:
 
 _vm_map_lock+0xf
 vm_map_wire+0x32
 rtROMemObjNativeLockInMap+0x8c
 rtROMemObjNativeLockUser+0x51
 RTR0MemObjLockUserTag+0x231
 vbglR0HGCMInternalPreprocessCall+0x65d
 vbglR0HGCMInternalCall+0x17c
 vgdrvIoCtl_HGCMCall+0x43f
 VGDrvCommonIoCtl+0x261
 vgdrvFreeBSDIOCtl+0x2cd
 devfs_ioctl+0xae
 VOP_IOCTL_APV+0x88
 vn_ioctl+0x161
 devfs_ioctl_f+0x1f
 kern_ioctl+0x280
 sys_ioctl+0x13f
 amd64_syscall+0x397
 Xfast_syscall+0xfb
>>> 
>>> More detail from booting with the -r313864 kernel.old
>>> and using kgdb on what the dump produced:
>>> 
>>> # kgdb kernel.debug /var/crash/vmcore.
>>> /var/crash/vmcore.0/var/crash/vmcore.last
>>> # kgdb kernel.debug /var/crash/vmcore.0
>>> GNU gdb 6.1.1 [FreeBSD]
>>> Copyright 2004 Free Software Foundation, Inc.
>>> GDB is free software, covered by the GNU General Public License, and you are
>>> welcome to change it and/or distribute copies of it under certain 
>>> conditions.
>>> Type "show copying" to see the conditions.
>>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>>> This GDB was configured as "amd64-marcel-freebsd"...
>>> 
>>> Unread portion of the kernel message buffer:
>>> <118>Starting vboxservice.
>>> <118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
>>> 18:37:45) release log
>>> <118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
>>> <118>00:00:00.000162 main OS Product: FreeBSD
>>> <118>00:00:00.000171 main OS Release: 12.0-CURRENT
>>> <118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
>>> <118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
>>> <118>00:00:00.000194 main Process ID: 609
>>> <118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)
>>> 
>>> 
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 2; apic id = 02
>>> fault virtual address   = 0xd6
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x80d4ebaf
>>> stack pointer   = 0x28:0xfe0122e2bef0
>>> frame pointer   = 0x28:0xfe0122e2bf00
>>> code segment= base 0x0, limit 0xf, type 0x1b
>>>   = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags= interrupt enabled, resume, IOPL = 0
>>> current process = 609 (VBoxService)
>>> 
>> 
>> 
>> 
>>> #9  0x80eb6be1 in calltrap () at 
>>> /usr/src/sys/amd64/amd64/exception.S:236
>>> #10 0x80d4ebaf in _vm_map_lock

svn commit: r314024 - head/sys/powerpc/booke

2017-02-20 Thread Justin Hibbits 
Author: jhibbits
Date: Tue Feb 21 05:08:07 2017
New Revision: 314024
URL: https://svnweb.freebsd.org/changeset/base/314024

Log:
  Correct the return value for pmap_change_attr()
  
  pmap_change_attr() returns an error code, not a paddr.  This function is
  currently unused for powerpc.
  
  MFC after:2 weeks

Modified:
  head/sys/powerpc/booke/pmap.c

Modified: head/sys/powerpc/booke/pmap.c
==
--- head/sys/powerpc/booke/pmap.c   Tue Feb 21 03:50:57 2017
(r314023)
+++ head/sys/powerpc/booke/pmap.c   Tue Feb 21 05:08:07 2017
(r314024)
@@ -2973,7 +2973,7 @@ mmu_booke_change_attr(mmu_t mmu, vm_offs
tlb_miss_unlock();
mtx_unlock_spin(_mutex);
 
-   return (pte_vatopa(mmu, kernel_pmap, va));
+   return (0);
 }
 
 /**/
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mark Millard 
On 2017-Feb-20, at 3:35 PM, Mateusz Guzik  wrote:

> On Mon, Feb 20, 2017 at 03:10:44PM -0800, Mark Millard wrote:
>> On 2017-Feb-20, at 2:58 PM, Mark Millard  wrote:
>> 
>>> On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:
>>> 
 On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
> [Note: I experiment with clang based powerpc64 builds,
> reporting problems that I find. Justin is familiar
> with this, as is Nathan.]
> 
> I tried to update the PowerMac G5 (a so-called "Quad Core")
> that I have access to from head -r312761 to -r313864 and
> ended up with random panics and hang ups in fairly short
> order after booting.
> 
> Some approximate bisecting for the kernel lead to:
> (sometimes getting part way into a buildkernel attempt
> for a different version before a failure happens)
> 
> -r313266: works (just before use of atomic_fcmpset)
> vs.
> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
> 
> (I did not try -r313268 through -r313270 as the use was
> gradually added.)
> 
> So I'm currently running a -r313864 world with a -r313266
> kernel.
> 
> No kernel that I tried that was from before -r313266 had the
> problems.
> 
> Any kernel that I tried that was from after -r313271 had the
> problems.
> 
> Of course I did not try them all in other direction. :)
> 
 
 I found that spin mutexes were not properly handling this, fixed in
 r313996.
 
 Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
 fcmpset to simulate failures. Everything works, while it would easily
 fail without the patch.
 
 That said, I hope this concludes the 'missing check for not-reread value
 of failed fcmpset' saga.
 
 -- 
 Mateusz Guzik 
>>> 
>>> I tried to update from -r313864 to -r313999 in my amd64 context
>>> (a VirtualBox machine under macOS) but it now crashes late in
>>> the boot sequence (after it processes a dump if I make one but
>>> before I can log in).
>>> 
>>> This update was via my usual explicit svnlite update; buildworld
>>> buildkernel; etc. production style build of world and kernel,
>>> including use of MALLOC_PRODUCTION.
>>> 
>>> The window shows:
>>> 
>>> _vm_map_lock+0xf
>>> vm_map_wire+0x32
>>> rtROMemObjNativeLockInMap+0x8c
>>> rtROMemObjNativeLockUser+0x51
>>> RTR0MemObjLockUserTag+0x231
>>> vbglR0HGCMInternalPreprocessCall+0x65d
>>> vbglR0HGCMInternalCall+0x17c
>>> vgdrvIoCtl_HGCMCall+0x43f
>>> VGDrvCommonIoCtl+0x261
>>> vgdrvFreeBSDIOCtl+0x2cd
>>> devfs_ioctl+0xae
>>> VOP_IOCTL_APV+0x88
>>> vn_ioctl+0x161
>>> devfs_ioctl_f+0x1f
>>> kern_ioctl+0x280
>>> sys_ioctl+0x13f
>>> amd64_syscall+0x397
>>> Xfast_syscall+0xfb
>> 
>> More detail from booting with the -r313864 kernel.old
>> and using kgdb on what the dump produced:
>> 
>> # kgdb kernel.debug /var/crash/vmcore.
>> /var/crash/vmcore.0/var/crash/vmcore.last
>> # kgdb kernel.debug /var/crash/vmcore.0
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> This GDB was configured as "amd64-marcel-freebsd"...
>> 
>> Unread portion of the kernel message buffer:
>> <118>Starting vboxservice.
>> <118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
>> 18:37:45) release log
>> <118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
>> <118>00:00:00.000162 main OS Product: FreeBSD
>> <118>00:00:00.000171 main OS Release: 12.0-CURRENT
>> <118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
>> <118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
>> <118>00:00:00.000194 main Process ID: 609
>> <118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)
>> 
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 2; apic id = 02
>> fault virtual address   = 0xd6
>> fault code  = supervisor read data, page not present
>> instruction pointer = 0x20:0x80d4ebaf
>> stack pointer   = 0x28:0xfe0122e2bef0
>> frame pointer   = 0x28:0xfe0122e2bf00
>> code segment= base 0x0, limit 0xf, type 0x1b
>>= DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags= interrupt enabled, resume, IOPL = 0
>> current process = 609 (VBoxService)
>> 
> 
> 
> 
>> #9  0x80eb6be1 in calltrap () at 
>> /usr/src/sys/amd64/amd64/exception.S:236
>> #10 0x80d4ebaf in _vm_map_lock (map=0x1, file=0x0, line=0) at 
>> /usr/src/sys/vm/vm_map.c:501
> 
> The function is:
> void
> _vm_map_lock(vm_map_t map, const char *file, int line)
> {
> 
>if

Re: svn commit: r313859 - in head/sys: kern sys

2017-02-20 Thread Mateusz Guzik 
On Fri, Feb 17, 2017 at 09:15:00PM +1100, Bruce Evans wrote:
> On Fri, 17 Feb 2017, Hans Petter Selasky wrote:
> 
> >>Log:
> >>  Introduce SCHEDULER_STOPPED_TD for use when the thread pointer
> >>was already read
> >>
> >>  Sprinkle in few places.
> >>
> >>Modified:
> >>  head/sys/kern/kern_condvar.c
> >>  head/sys/kern/kern_synch.c
> >>  head/sys/sys/systm.h
> >
> >Do these checks also cover panics? Or only shutdown?
> 
> This is just an optimization.
> 
> I don't like it because it moves further from moving the stopped flag
> back out of the thread to a global.
> 

I only did this to make it more feasible to remove the tid argument from
primitives which I may or may not end up doing, undecided yet.

As for changing the conditon to testing a global, I don't think this
change affects feasibilitly. It onlly requires some more churn by hand
which I'm happy to do if said change is implemented.

-- 
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: r314001 - head/usr.bin/timeout

2017-02-20 Thread Bryan Drewery 
Author: bdrewery
Date: Tue Feb 21 01:11:18 2017
New Revision: 314001
URL: https://svnweb.freebsd.org/changeset/base/314001

Log:
  Make it more clear that -k sends SIGKILL, not the -s signal.
  
  MFC after:1 week

Modified:
  head/usr.bin/timeout/timeout.1

Modified: head/usr.bin/timeout/timeout.1
==
--- head/usr.bin/timeout/timeout.1  Mon Feb 20 23:48:50 2017
(r314000)
+++ head/usr.bin/timeout/timeout.1  Tue Feb 21 01:11:18 2017
(r314001)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd February 17, 2017
+.Dd February 20, 2017
 .Dt TIMEOUT 1
 .Os
 .Sh NAME
@@ -68,7 +68,9 @@ By default,
 .Ar SIGTERM .
 is sent.
 .It Fl k Ar time , Fl -kill-after Ar time
-Send a second kill signal if
+Send a
+.Ar SIGKILL
+signal if
 .Ar command
 is still running after
 .Ar time
___
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: r313878 - head/sys/kern

2017-02-20 Thread Mateusz Guzik 
On Mon, Feb 20, 2017 at 04:24:50PM -0800, Bryan Drewery wrote:
> On 2/17/2017 7:40 AM, Mateusz Guzik wrote:
> > Author: mjg
> > Date: Fri Feb 17 15:40:24 2017
> > New Revision: 313878
> > URL: https://svnweb.freebsd.org/changeset/base/313878
> > 
> > Log:
> >   mtx: get rid of file/line args from slow paths if they are unused
> >   
> >   This denotes changes which went in by accident in r313877.
> 
> I really wish people would just revert their changes and recommit them
> properly.  The 'svn blame' on the code in r313877 will never show the
> commit message here (r313878).  So a person would only find this
> explanation if they read 'svn log' on the file, which in the case of
> sys/kern/kern_mutex.c there are 273 commits for.  Are we expected to
> read 'svn log' (in the future) for all changes in the hopes that a later
> commit happens to mention it?
> 
> As someone who so often is 'svn blame'ing code to understand it better
> and to track regressions, commits like this that explain other commits
> might as well have never been done.
> 

In general I agree, but also don't think the change was worth any
additional churn. It only removed 2 args when not under LOCK_DEBUG. The
commit message above is only to note KBI is covered as this could be of
concern for a casual reader.

I would not do this if the change was doing anything non-trivial.

> >   
> >   On most production kernels both said parameters are zeroed and have 
> > nothing
> >   reading them in either __mtx_lock_sleep or __mtx_unlock_sleep. Thus this 
> > change
> >   stops passing them by internal consumers which this is the case.
> >   
> >   Kernel modules use _flags variants which are not affected kbi-wise.
> > 
> > Modified:
> >   head/sys/kern/kern_mutex.c
> > 
> > Modified: head/sys/kern/kern_mutex.c
> > ==
> > --- head/sys/kern/kern_mutex.c  Fri Feb 17 15:34:40 2017
> > (r313877)
> > +++ head/sys/kern/kern_mutex.c  Fri Feb 17 15:40:24 2017
> > (r313878)
> > @@ -622,7 +622,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, 
> > LOCKSTAT_RECORD1(adaptive__block, m, sleep_time);
> >  
> > /*
> > -* Only record the loops spinning and not sleeping. 
> > +* Only record the loops spinning and not sleeping.
> >  */
> > if (lda.spin_cnt > sleep_cnt)
> > LOCKSTAT_RECORD1(adaptive__spin, m, all_time - sleep_time);
> > 
> 
> 
> -- 
> Regards,
> Bryan Drewery
> 




-- 
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: r313878 - head/sys/kern

2017-02-20 Thread Pedro Giffuni 

FWIW,


On 2/20/2017 7:24 PM, Bryan Drewery wrote:

On 2/17/2017 7:40 AM, Mateusz Guzik wrote:

Author: mjg
Date: Fri Feb 17 15:40:24 2017
New Revision: 313878
URL: https://svnweb.freebsd.org/changeset/base/313878

Log:
   mtx: get rid of file/line args from slow paths if they are unused
   
   This denotes changes which went in by accident in r313877.

I really wish people would just revert their changes and recommit them
properly.  The 'svn blame' on the code in r313877 will never show the
commit message here (r313878).  So a person would only find this
explanation if they read 'svn log' on the file, which in the case of
sys/kern/kern_mutex.c there are 273 commits for.  Are we expected to
read 'svn log' (in the future) for all changes in the hopes that a later
commit happens to mention it?

As someone who so often is 'svn blame'ing code to understand it better
and to track regressions, commits like this that explain other commits
might as well have never been done.


As I mentioned in another thread, other svn configurations (ASF, for 
example) permit editing the log message:


http://help.collab.net/index.jsp?topic=/faq/changelog.html

Cheers,

Pedro.

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

Re: svn commit: r313878 - head/sys/kern

2017-02-20 Thread Bryan Drewery 
On 2/20/2017 4:24 PM, Bryan Drewery wrote:
> On 2/17/2017 7:40 AM, Mateusz Guzik wrote:
>> Author: mjg
>> Date: Fri Feb 17 15:40:24 2017
>> New Revision: 313878
>> URL: https://svnweb.freebsd.org/changeset/base/313878
>>
>> Log:
>>   mtx: get rid of file/line args from slow paths if they are unused
>>   
>>   This denotes changes which went in by accident in r313877.
> 
> I really wish people would just revert their changes and recommit them
> properly.  The 'svn blame' on the code in r313877 will never show the
> commit message here (r313878).  So a person would only find this
> explanation if they read 'svn log' on the file, which in the case of
> sys/kern/kern_mutex.c there are 273 commits for.  Are we expected to
> read 'svn log' (in the future) for all changes in the hopes that a later
> commit happens to mention it?
> 
> As someone who so often is 'svn blame'ing code to understand it better
> and to track regressions, commits like this that explain other commits
> might as well have never been done.

https://lists.freebsd.org/pipermail/svn-src-all/2017-February/139904.html
is a case just now that is similar here.  Personally I do look in the
list archives for svn-src-all for additional discussion on commits.  In
the case of r313982, the discussion and author's admission that the
commit message wasn't quite right are documented along with the commit
at least on lists.freebsd.org and our own archives.

> 
>>   
>>   On most production kernels both said parameters are zeroed and have nothing
>>   reading them in either __mtx_lock_sleep or __mtx_unlock_sleep. Thus this 
>> change
>>   stops passing them by internal consumers which this is the case.
>>   
>>   Kernel modules use _flags variants which are not affected kbi-wise.
>>
>> Modified:
>>   head/sys/kern/kern_mutex.c
>>
>> Modified: head/sys/kern/kern_mutex.c
>> ==
>> --- head/sys/kern/kern_mutex.c   Fri Feb 17 15:34:40 2017
>> (r313877)
>> +++ head/sys/kern/kern_mutex.c   Fri Feb 17 15:40:24 2017
>> (r313878)
>> @@ -622,7 +622,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, 
>>  LOCKSTAT_RECORD1(adaptive__block, m, sleep_time);
>>  
>>  /*
>> - * Only record the loops spinning and not sleeping. 
>> + * Only record the loops spinning and not sleeping.
>>   */
>>  if (lda.spin_cnt > sleep_cnt)
>>  LOCKSTAT_RECORD1(adaptive__spin, m, all_time - sleep_time);
>>
> 
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r313982 - in head/sys/dev: agp al_eth an arcmsr bce beri/virtio bhnd/cores/usb buslogic ce cm cp ctau cx de ed fatm fe firewire hptiop hptmv iicbus isp le md ncr netmap ofw patm pccard

2017-02-20 Thread Pedro Giffuni 

Hello;

Just been discussing the same issue in private as well ...

On 2/20/2017 6:40 PM, Conrad Meyer wrote:

On Sun, Feb 19, 2017 at 7:43 PM, Pedro F. Giffuni  wrote:

Author: pfg
Date: Mon Feb 20 03:43:12 2017
New Revision: 313982
URL: https://svnweb.freebsd.org/changeset/base/313982

Log:
   sys/dev: Replace zero with NULL for pointers.

   Makes things easier to read, plus architectures may set NULL to something
   different than zero.

Hi Pedro,

I like the change for style reasons.

The comment about architectures with non-zero NULL is a little
misleading, though.  This change has no impact on non-zero bit pattern
NULL architectures.  The zero pointer value in C is NULL and NULL is
the zero pointer value in C.  It may have a bit pattern other than
zero (i.e., printf("%p", NULL) may be non-zero and memset(, 0,
sizeof(p)) is bogus in portable code) but assigning the logical zero
value is always legitimate.


Grrr ... yes the comment is/was misleading: I would undo it if I didn't 
have to revert the commit with it. Other project have SVN configured to 
permit changing the log message BTW.



After all, NULL is just a casted zero value:

#define NULL((void *)0)


The compiler is pretty good at detecting when the value is a pointer though.
The change has few (if any) effect on real life but coming  from the 
days where most computer languages were somewhat stronger typed I really 
like to be able to distinguish between a zero valued pointer and a zero 
valued int.




Maybe this is moot.  I don't believe any architecture FreeBSD actually
supports has non-zero bitpattern NULL, but something weird like CHERI
might.


Such "weird" platforms are starting to appear:

https://reviews.llvm.org/D26196
Regards,

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

Re: svn commit: r313878 - head/sys/kern

2017-02-20 Thread Bryan Drewery 
On 2/17/2017 7:40 AM, Mateusz Guzik wrote:
> Author: mjg
> Date: Fri Feb 17 15:40:24 2017
> New Revision: 313878
> URL: https://svnweb.freebsd.org/changeset/base/313878
> 
> Log:
>   mtx: get rid of file/line args from slow paths if they are unused
>   
>   This denotes changes which went in by accident in r313877.

I really wish people would just revert their changes and recommit them
properly.  The 'svn blame' on the code in r313877 will never show the
commit message here (r313878).  So a person would only find this
explanation if they read 'svn log' on the file, which in the case of
sys/kern/kern_mutex.c there are 273 commits for.  Are we expected to
read 'svn log' (in the future) for all changes in the hopes that a later
commit happens to mention it?

As someone who so often is 'svn blame'ing code to understand it better
and to track regressions, commits like this that explain other commits
might as well have never been done.

>   
>   On most production kernels both said parameters are zeroed and have nothing
>   reading them in either __mtx_lock_sleep or __mtx_unlock_sleep. Thus this 
> change
>   stops passing them by internal consumers which this is the case.
>   
>   Kernel modules use _flags variants which are not affected kbi-wise.
> 
> Modified:
>   head/sys/kern/kern_mutex.c
> 
> Modified: head/sys/kern/kern_mutex.c
> ==
> --- head/sys/kern/kern_mutex.cFri Feb 17 15:34:40 2017
> (r313877)
> +++ head/sys/kern/kern_mutex.cFri Feb 17 15:40:24 2017
> (r313878)
> @@ -622,7 +622,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, 
>   LOCKSTAT_RECORD1(adaptive__block, m, sleep_time);
>  
>   /*
> -  * Only record the loops spinning and not sleeping. 
> +  * Only record the loops spinning and not sleeping.
>*/
>   if (lda.spin_cnt > sleep_cnt)
>   LOCKSTAT_RECORD1(adaptive__spin, m, all_time - sleep_time);
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r313975 - in head: contrib/openpam contrib/openpam/bin contrib/openpam/bin/openpam_dump_policy contrib/openpam/bin/pamtest contrib/openpam/bin/su contrib/openpam/doc contrib/openpam/do

2017-02-20 Thread Bryan Drewery 
On 2/19/2017 4:56 PM, Dag-Erling Smørgrav wrote:
> Author: des
> Date: Mon Feb 20 00:56:46 2017
> New Revision: 313975
> URL: https://svnweb.freebsd.org/changeset/base/313975
> 
> Log:
>   Upgrade to OpenPAM Radula.
> 
> Added:
>   head/contrib/openpam/m4/
>  - copied from r313968, vendor/openpam/dist/m4/
>   head/contrib/openpam/misc/Makefile.am
>  - copied unchanged from r313968, vendor/openpam/dist/misc/Makefile.am
>   head/contrib/openpam/misc/Makefile.in
>  - copied unchanged from r313968, vendor/openpam/dist/misc/Makefile.in
>   head/contrib/openpam/misc/coverage.sh.in
>  - copied unchanged from r313968, vendor/openpam/dist/misc/coverage.sh.in
>   head/contrib/openpam/misc/coverity.sh.in
>  - copied unchanged from r313968, vendor/openpam/dist/misc/coverity.sh.in
>   head/contrib/openpam/modules/pam_return/
>  - copied from r313968, vendor/openpam/dist/modules/pam_return/
>   head/contrib/openpam/t/t_openpam_dispatch.c
>  - copied unchanged from r313968, 
> vendor/openpam/dist/t/t_openpam_dispatch.c
>   head/contrib/openpam/t/t_pam_conv.c
>  - copied unchanged from r313968, vendor/openpam/dist/t/t_pam_conv.c
>   head/contrib/openpam/t/t_pam_conv.h
>  - copied unchanged from r313968, vendor/openpam/dist/t/t_pam_conv.h
> Deleted:
>   head/contrib/openpam/pamgdb.in
>   head/contrib/openpam/t/t.h
>   head/contrib/openpam/t/t_file.c
>   head/contrib/openpam/t/t_main.c
>   head/lib/libpam/libpam/tests/


Did you intend to delete the tests?

lib/libpam/libpam/tests/Makefile:
.for test in t_openpam_ctype t_openpam_readlinev t_openpam_readword

I still see these in the tree and modified by this update:

>   head/contrib/openpam/t/Makefile.am
>   head/contrib/openpam/t/Makefile.in
>   head/contrib/openpam/t/t_openpam_ctype.c
>   head/contrib/openpam/t/t_openpam_readlinev.c
>   head/contrib/openpam/t/t_openpam_readword.c



-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r313982 - in head/sys/dev: agp al_eth an arcmsr bce beri/virtio bhnd/cores/usb buslogic ce cm cp ctau cx de ed fatm fe firewire hptiop hptmv iicbus isp le md ncr netmap ofw patm pccard

2017-02-20 Thread Conrad Meyer 
On Sun, Feb 19, 2017 at 7:43 PM, Pedro F. Giffuni  wrote:
> Author: pfg
> Date: Mon Feb 20 03:43:12 2017
> New Revision: 313982
> URL: https://svnweb.freebsd.org/changeset/base/313982
>
> Log:
>   sys/dev: Replace zero with NULL for pointers.
>
>   Makes things easier to read, plus architectures may set NULL to something
>   different than zero.

Hi Pedro,

I like the change for style reasons.

The comment about architectures with non-zero NULL is a little
misleading, though.  This change has no impact on non-zero bit pattern
NULL architectures.  The zero pointer value in C is NULL and NULL is
the zero pointer value in C.  It may have a bit pattern other than
zero (i.e., printf("%p", NULL) may be non-zero and memset(, 0,
sizeof(p)) is bogus in portable code) but assigning the logical zero
value is always legitimate.

After all, NULL is just a casted zero value:

#define NULL((void *)0)

Maybe this is moot.  I don't believe any architecture FreeBSD actually
supports has non-zero bitpattern NULL, but something weird like CHERI
might.

Best,
Conrad
___
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: r314000 - in head: contrib/traceroute usr.sbin/traceroute

2017-02-20 Thread Mariusz Zaborski 
Author: oshogbo
Date: Mon Feb 20 23:48:50 2017
New Revision: 314000
URL: https://svnweb.freebsd.org/changeset/base/314000

Log:
  Capsicumize traceroute.
  
  PR:193973
  Submitted by:  Mikhail 
  Reviewed by:   pjd, bapt, emaste, AllanJude
  Differential Revision:https://reviews.freebsd.org/D9303

Modified:
  head/contrib/traceroute/traceroute.c
  head/usr.sbin/traceroute/Makefile

Modified: head/contrib/traceroute/traceroute.c
==
--- head/contrib/traceroute/traceroute.cMon Feb 20 20:37:25 2017
(r313999)
+++ head/contrib/traceroute/traceroute.cMon Feb 20 23:48:50 2017
(r314000)
@@ -203,6 +203,7 @@ static const char rcsid[] =
  */
 
 #include 
+#include 
 #include 
 #include 
 #ifdef HAVE_SYS_SELECT_H
@@ -226,6 +227,11 @@ static const char rcsid[] =
 
 #include 
 
+#ifdef HAVE_LIBCASPER
+#include 
+#include 
+#endif
+
 #ifdef IPSEC
 #include 
 #include /* XXX */
@@ -362,6 +368,10 @@ extern int optind;
 extern int opterr;
 extern char *optarg;
 
+#ifdef HAVE_LIBCASPER
+static cap_channel_t *capdns;
+#endif
+
 /* Forwards */
 double deltaT(struct timeval *, struct timeval *);
 void   freehostinfo(struct hostinfo *);
@@ -510,6 +520,13 @@ main(int argc, char **argv)
int requestPort = -1;
int sump = 0;
int sockerrno;
+#ifdef HAVE_LIBCASPER
+   const char *types[] = { "NAME", "ADDR" };
+   int families[1];
+   cap_channel_t *casper;
+#endif
+   cap_rights_t rights;
+   bool cansandbox;
 
/* Insure the socket fds won't be 0, 1 or 2 */
if (open(devnull, O_RDONLY) < 0 ||
@@ -538,6 +555,20 @@ main(int argc, char **argv)
exit(1);
}
 
+#ifdef HAVE_LIBCASPER
+   casper = cap_init();
+   if (casper == NULL)
+   errx(1, "unable to create casper process");
+   capdns = cap_service_open(casper, "system.dns");
+   if (capdns == NULL)
+   errx(1, "unable to open system.dns service");
+   if (cap_dns_type_limit(capdns, types, 2) < 0)
+   errx(1, "unable to limit access to system.dns service");
+   families[0] = AF_INET;
+   if (cap_dns_family_limit(capdns, families, 1) < 0)
+   errx(1, "unable to limit access to system.dns service");
+#endif /* HAVE_LIBCASPER */
+
 #ifdef IPCTL_DEFTTL
{
int mib[4] = { CTL_NET, PF_INET, IPPROTO_IP, IPCTL_DEFTTL };
@@ -548,10 +579,14 @@ main(int argc, char **argv)
exit(1);
}
}
-#else
+#else /* !IPCTL_DEFTTL */
max_ttl = 30;
 #endif
 
+#ifdef HAVE_LIBCASPER
+   cap_close(casper);
+#endif
+
if (argv[0] == NULL)
prog = "traceroute";
else if ((cp = strrchr(argv[0], '/')) != NULL)
@@ -964,6 +999,45 @@ main(int argc, char **argv)
}
}
 
+   if (connect(sndsock, (struct sockaddr *),
+   sizeof(whereto)) != 0) {
+   Fprintf(stderr, "%s: connect: %s\n", prog, strerror(errno));
+   exit(1);
+   }
+
+#ifdef HAVE_LIBCASPER
+   cansandbox = true;
+#else
+   if (nflag)
+   cansandbox = true;
+   else
+   cansandbox = false;
+#endif
+
+   /*
+* Here we enter capability mode. Further down access to global
+* namespaces (e.g filesystem) is restricted (see capsicum(4)).
+* We must connect(2) our socket before this point.
+*/
+   if (cansandbox && cap_enter() < 0) {
+   Fprintf(stderr, "%s: cap_enter: %s\n", prog, strerror(errno));
+   exit(1);
+   }
+
+   cap_rights_init(, CAP_SEND, CAP_SETSOCKOPT);
+   if (cansandbox && cap_rights_limit(sndsock, ) < 0) {
+   Fprintf(stderr, "%s: cap_rights_limit sndsock: %s\n", prog,
+   strerror(errno));
+   exit(1);
+   }
+
+   cap_rights_init(, CAP_RECV, CAP_EVENT);
+   if (cansandbox && cap_rights_limit(s, ) < 0) {
+   Fprintf(stderr, "%s: cap_rights_limit s: %s\n", prog,
+   strerror(errno));
+   exit(1);
+   }
+
 #ifdefined(IPSEC) && defined(IPSEC_POLICY_IPSEC)
if (setpolicy(sndsock, "in bypass") < 0)
errx(1, "%s", ipsec_strerror());
@@ -1251,8 +1325,7 @@ send_probe(int seq, int ttl)
}
 #endif
 
-   cc = sendto(sndsock, (char *)outip,
-   packlen, 0, , sizeof(whereto));
+   cc = send(sndsock, (char *)outip, packlen, 0);
if (cc < 0 || cc != packlen)  {
if (cc < 0)
Fprintf(stderr, "%s: sendto: %s\n",
@@ -1770,7 +1843,12 @@ inetname(struct in_addr in)
else {
cp = strchr(domain, '.');
if (cp == NULL) {
-   hp = gethostbyname(domain);
+#ifdef HAVE_LIBCASPER
+   if (capdns !=

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mateusz Guzik 
On Mon, Feb 20, 2017 at 03:10:44PM -0800, Mark Millard wrote:
> On 2017-Feb-20, at 2:58 PM, Mark Millard  wrote:
> 
> > On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:
> > 
> >> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
> >>> [Note: I experiment with clang based powerpc64 builds,
> >>> reporting problems that I find. Justin is familiar
> >>> with this, as is Nathan.]
> >>> 
> >>> I tried to update the PowerMac G5 (a so-called "Quad Core")
> >>> that I have access to from head -r312761 to -r313864 and
> >>> ended up with random panics and hang ups in fairly short
> >>> order after booting.
> >>> 
> >>> Some approximate bisecting for the kernel lead to:
> >>> (sometimes getting part way into a buildkernel attempt
> >>> for a different version before a failure happens)
> >>> 
> >>> -r313266: works (just before use of atomic_fcmpset)
> >>> vs.
> >>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
> >>> 
> >>> (I did not try -r313268 through -r313270 as the use was
> >>> gradually added.)
> >>> 
> >>> So I'm currently running a -r313864 world with a -r313266
> >>> kernel.
> >>> 
> >>> No kernel that I tried that was from before -r313266 had the
> >>> problems.
> >>> 
> >>> Any kernel that I tried that was from after -r313271 had the
> >>> problems.
> >>> 
> >>> Of course I did not try them all in other direction. :)
> >>> 
> >> 
> >> I found that spin mutexes were not properly handling this, fixed in
> >> r313996.
> >> 
> >> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
> >> fcmpset to simulate failures. Everything works, while it would easily
> >> fail without the patch.
> >> 
> >> That said, I hope this concludes the 'missing check for not-reread value
> >> of failed fcmpset' saga.
> >> 
> >> -- 
> >> Mateusz Guzik 
> > 
> > I tried to update from -r313864 to -r313999 in my amd64 context
> > (a VirtualBox machine under macOS) but it now crashes late in
> > the boot sequence (after it processes a dump if I make one but
> > before I can log in).
> > 
> > This update was via my usual explicit svnlite update; buildworld
> > buildkernel; etc. production style build of world and kernel,
> > including use of MALLOC_PRODUCTION.
> > 
> > The window shows:
> > 
> > _vm_map_lock+0xf
> > vm_map_wire+0x32
> > rtROMemObjNativeLockInMap+0x8c
> > rtROMemObjNativeLockUser+0x51
> > RTR0MemObjLockUserTag+0x231
> > vbglR0HGCMInternalPreprocessCall+0x65d
> > vbglR0HGCMInternalCall+0x17c
> > vgdrvIoCtl_HGCMCall+0x43f
> > VGDrvCommonIoCtl+0x261
> > vgdrvFreeBSDIOCtl+0x2cd
> > devfs_ioctl+0xae
> > VOP_IOCTL_APV+0x88
> > vn_ioctl+0x161
> > devfs_ioctl_f+0x1f
> > kern_ioctl+0x280
> > sys_ioctl+0x13f
> > amd64_syscall+0x397
> > Xfast_syscall+0xfb
> 
> More detail from booting with the -r313864 kernel.old
> and using kgdb on what the dump produced:
> 
> # kgdb kernel.debug /var/crash/vmcore.
> /var/crash/vmcore.0/var/crash/vmcore.last
> # kgdb kernel.debug /var/crash/vmcore.0
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> <118>Starting vboxservice.
> <118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
> 18:37:45) release log
> <118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
> <118>00:00:00.000162 main OS Product: FreeBSD
> <118>00:00:00.000171 main OS Release: 12.0-CURRENT
> <118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
> <118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
> <118>00:00:00.000194 main Process ID: 609
> <118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0xd6
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80d4ebaf
> stack pointer   = 0x28:0xfe0122e2bef0
> frame pointer   = 0x28:0xfe0122e2bf00
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 609 (VBoxService)
> 



> #9  0x80eb6be1 in calltrap () at 
> /usr/src/sys/amd64/amd64/exception.S:236
> #10 0x80d4ebaf in _vm_map_lock (map=0x1, file=0x0, line=0) at 
> /usr/src/sys/vm/vm_map.c:501

The function is:
void
_vm_map_lock(vm_map_t map, const char *file, int line)
{

if (map->system_map)
mtx_lock_flags_(>system_mtx, 0, file, line);
else

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mark Millard 
On 2017-Feb-20, at 2:58 PM, Mark Millard  wrote:

> On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:
> 
>> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
>>> [Note: I experiment with clang based powerpc64 builds,
>>> reporting problems that I find. Justin is familiar
>>> with this, as is Nathan.]
>>> 
>>> I tried to update the PowerMac G5 (a so-called "Quad Core")
>>> that I have access to from head -r312761 to -r313864 and
>>> ended up with random panics and hang ups in fairly short
>>> order after booting.
>>> 
>>> Some approximate bisecting for the kernel lead to:
>>> (sometimes getting part way into a buildkernel attempt
>>> for a different version before a failure happens)
>>> 
>>> -r313266: works (just before use of atomic_fcmpset)
>>> vs.
>>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
>>> 
>>> (I did not try -r313268 through -r313270 as the use was
>>> gradually added.)
>>> 
>>> So I'm currently running a -r313864 world with a -r313266
>>> kernel.
>>> 
>>> No kernel that I tried that was from before -r313266 had the
>>> problems.
>>> 
>>> Any kernel that I tried that was from after -r313271 had the
>>> problems.
>>> 
>>> Of course I did not try them all in other direction. :)
>>> 
>> 
>> I found that spin mutexes were not properly handling this, fixed in
>> r313996.
>> 
>> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
>> fcmpset to simulate failures. Everything works, while it would easily
>> fail without the patch.
>> 
>> That said, I hope this concludes the 'missing check for not-reread value
>> of failed fcmpset' saga.
>> 
>> -- 
>> Mateusz Guzik 
> 
> I tried to update from -r313864 to -r313999 in my amd64 context
> (a VirtualBox machine under macOS) but it now crashes late in
> the boot sequence (after it processes a dump if I make one but
> before I can log in).
> 
> This update was via my usual explicit svnlite update; buildworld
> buildkernel; etc. production style build of world and kernel,
> including use of MALLOC_PRODUCTION.
> 
> The window shows:
> 
> _vm_map_lock+0xf
> vm_map_wire+0x32
> rtROMemObjNativeLockInMap+0x8c
> rtROMemObjNativeLockUser+0x51
> RTR0MemObjLockUserTag+0x231
> vbglR0HGCMInternalPreprocessCall+0x65d
> vbglR0HGCMInternalCall+0x17c
> vgdrvIoCtl_HGCMCall+0x43f
> VGDrvCommonIoCtl+0x261
> vgdrvFreeBSDIOCtl+0x2cd
> devfs_ioctl+0xae
> VOP_IOCTL_APV+0x88
> vn_ioctl+0x161
> devfs_ioctl_f+0x1f
> kern_ioctl+0x280
> sys_ioctl+0x13f
> amd64_syscall+0x397
> Xfast_syscall+0xfb

More detail from booting with the -r313864 kernel.old
and using kgdb on what the dump produced:

# kgdb kernel.debug /var/crash/vmcore.
/var/crash/vmcore.0/var/crash/vmcore.last
# kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
<118>Starting vboxservice.
<118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
18:37:45) release log
<118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
<118>00:00:00.000162 main OS Product: FreeBSD
<118>00:00:00.000171 main OS Release: 12.0-CURRENT
<118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
<118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
<118>00:00:00.000194 main Process ID: 609
<118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0xd6
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80d4ebaf
stack pointer   = 0x28:0xfe0122e2bef0
frame pointer   = 0x28:0xfe0122e2bf00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 609 (VBoxService)

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/modules/vboxguest.ko...done.
Loaded symbols for /boot/modules/vboxguest.ko
#0  doadump (textdump=0) at pcpu.h:232
232 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0  doadump (textdump=0) at pcpu.h:232
#1  0x8039dd0b in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at 
/usr/src/sys/ddb/db_command.c:546
#2

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mark Millard 
On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:

> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
>> [Note: I experiment with clang based powerpc64 builds,
>> reporting problems that I find. Justin is familiar
>> with this, as is Nathan.]
>> 
>> I tried to update the PowerMac G5 (a so-called "Quad Core")
>> that I have access to from head -r312761 to -r313864 and
>> ended up with random panics and hang ups in fairly short
>> order after booting.
>> 
>> Some approximate bisecting for the kernel lead to:
>> (sometimes getting part way into a buildkernel attempt
>> for a different version before a failure happens)
>> 
>> -r313266: works (just before use of atomic_fcmpset)
>> vs.
>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
>> 
>> (I did not try -r313268 through -r313270 as the use was
>> gradually added.)
>> 
>> So I'm currently running a -r313864 world with a -r313266
>> kernel.
>> 
>> No kernel that I tried that was from before -r313266 had the
>> problems.
>> 
>> Any kernel that I tried that was from after -r313271 had the
>> problems.
>> 
>> Of course I did not try them all in other direction. :)
>> 
> 
> I found that spin mutexes were not properly handling this, fixed in
> r313996.
> 
> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
> fcmpset to simulate failures. Everything works, while it would easily
> fail without the patch.
> 
> That said, I hope this concludes the 'missing check for not-reread value
> of failed fcmpset' saga.
> 
> -- 
> Mateusz Guzik 

I tried to update from -r313864 to -r313999 in my amd64 context
(a VirtualBox machine under macOS) but it now crashes late in
the boot sequence (after it processes a dump if I make one but
before I can log in).

This update was via my usual explicit svnlite update; buildworld
buildkernel; etc. production style build of world and kernel,
including use of MALLOC_PRODUCTION.

The window shows:

_vm_map_lock+0xf
vm_map_wire+0x32
rtROMemObjNativeLockInMap+0x8c
rtROMemObjNativeLockUser+0x51
RTR0MemObjLockUserTag+0x231
vbglR0HGCMInternalPreprocessCall+0x65d
vbglR0HGCMInternalCall+0x17c
vgdrvIoCtl_HGCMCall+0x43f
VGDrvCommonIoCtl+0x261
vgdrvFreeBSDIOCtl+0x2cd
devfs_ioctl+0xae
VOP_IOCTL_APV+0x88
vn_ioctl+0x161
devfs_ioctl_f+0x1f
kern_ioctl+0x280
sys_ioctl+0x13f
amd64_syscall+0x397
Xfast_syscall+0xfb


===
Mark Millard
markmi at dsl-only.net

___
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: r313999 - head/sys/kern

2017-02-20 Thread John Baldwin 
Author: jhb
Date: Mon Feb 20 20:37:25 2017
New Revision: 313999
URL: https://svnweb.freebsd.org/changeset/base/313999

Log:
  Consolidate statements to initialize files.
  
  Previously, the first lines of various generated files from system call
  tables were generated in two sections.  Some of the initialization was
  done in BEGIN, and the rest was done when the first line was encountered.
  The main reason for this split before r313564 was that most of the
  initialization done in the second section depended on the $FreeBSD$ tag
  extracted from the system call table.  Now that the $FreeBSD$ tag is no
  longer used, consolidate all of the file initialization in the BEGIN
  section.
  
  This change was tested by confirming that the content of generated files
  did not change.

Modified:
  head/sys/kern/makesyscalls.sh

Modified: head/sys/kern/makesyscalls.sh
==
--- head/sys/kern/makesyscalls.sh   Mon Feb 20 20:16:11 2017
(r313998)
+++ head/sys/kern/makesyscalls.sh   Mon Feb 20 20:37:25 2017
(r313999)
@@ -116,6 +116,9 @@ sed -e '
 
split(capenabled_string, capenabled, ",");
 
+   printf "\n/* The casts are bogus but will do for now. */\n" > 
sysent
+   printf "struct sysent %s[] = {\n",switchname > sysent
+
printf "/*\n * System call switch table.\n *\n" > syssw
printf " * DO NOT EDIT-- this file is automatically 
generated.\n" > syssw
printf " * $%s$\n", "FreeBSD" > syssw
@@ -125,35 +128,6 @@ sed -e '
printf " * DO NOT EDIT-- this file is automatically 
generated.\n" > sysarg
printf " * $%s$\n", "FreeBSD" > sysarg
printf " */\n\n" > sysarg
-
-   printf "\n#ifdef %s\n\n", compat > syscompat
-   printf "\n#ifdef %s\n\n", compat4 > syscompat4
-   printf "\n#ifdef %s\n\n", compat6 > syscompat6
-   printf "\n#ifdef %s\n\n", compat7 > syscompat7
-   printf "\n#ifdef %s\n\n", compat10 > syscompat10
-
-   printf "/*\n * System call names.\n *\n" > sysnames
-   printf " * DO NOT EDIT-- this file is automatically 
generated.\n" > sysnames
-   printf " * $%s$\n", "FreeBSD" > sysnames
-   printf " */\n\n" > sysnames
-
-   printf "/*\n * System call numbers.\n *\n" > syshdr
-   printf " * DO NOT EDIT-- this file is automatically 
generated.\n" > syshdr
-   printf " * $%s$\n", "FreeBSD" > syshdr
-   printf " */\n\n" > syshdr
-
-   printf "# FreeBSD system call object files.\n" > sysmk
-   printf "# DO NOT EDIT-- this file is automatically 
generated.\n" > sysmk
-   printf "# $%s$\n", "FreeBSD" > sysmk
-
-   printf "/*\n * System call argument to DTrace register array 
converstion.\n *\n" > systrace
-   printf " * DO NOT EDIT-- this file is automatically 
generated.\n" > systrace
-   printf " * $%s$\n", "FreeBSD" > systrace
-   }
-   NR == 1 {
-   printf "\n/* The casts are bogus but will do for now. */\n" > 
sysent
-   printf "struct sysent %s[] = {\n",switchname > sysent
-
printf "#ifndef %s\n", sysproto_h > sysarg
printf "#define\t%s\n\n", sysproto_h > sysarg
printf "#include \n" > sysarg
@@ -176,10 +150,31 @@ sed -e '
printf "#define\tPADR_(t)\t0\n" > sysarg
printf "#endif\n\n" > sysarg
 
+   printf "\n#ifdef %s\n\n", compat > syscompat
+   printf "\n#ifdef %s\n\n", compat4 > syscompat4
+   printf "\n#ifdef %s\n\n", compat6 > syscompat6
+   printf "\n#ifdef %s\n\n", compat7 > syscompat7
+   printf "\n#ifdef %s\n\n", compat10 > syscompat10
+
+   printf "/*\n * System call names.\n *\n" > sysnames
+   printf " * DO NOT EDIT-- this file is automatically 
generated.\n" > sysnames
+   printf " * $%s$\n", "FreeBSD" > sysnames
+   printf " */\n\n" > sysnames
printf "const char *%s[] = {\n", namesname > sysnames
 
+   printf "/*\n * System call numbers.\n *\n" > syshdr
+   printf " * DO NOT EDIT-- this file is automatically 
generated.\n" > syshdr
+   printf " * $%s$\n", "FreeBSD" > syshdr
+   printf " */\n\n" > syshdr
+
+   printf "# FreeBSD system call object files.\n" > sysmk
+   printf "# DO NOT EDIT-- this file is automatically 
generated.\n" > sysmk
+   printf "# $%s$\n", "FreeBSD" > sysmk
printf "MIASM = " > sysmk
 
+   printf "/*\n * System call argument to DTrace register array 
converstion.\n *\n" > systrace
+   printf " * DO NOT EDIT-- this file is automatically 
generated.\n" > systrace
+

Re: svn commit: r299182 - head/sys/dev/e1000

2017-02-20 Thread Kenneth D. Merry 
On Fri, May 06, 2016 at 15:41:38 +, Sean Bruno wrote:
> Author: sbruno
> Date: Fri May  6 15:41:38 2016
> New Revision: 299182
> URL: https://svnweb.freebsd.org/changeset/base/299182
> 
> Log:
>   If ALTQ is defined in the kern conf, switch to Legacy Mode.
>   
>   PR: 208409
>   Submitted by:   free...@mcwest.org
>   MFC after:  2 weeks
> 
> Modified:
>   head/sys/dev/e1000/if_igb.h

Just for the mail archives (and hopefully for someone who is interested in
fixing it), IGB_LEGACY_TX is broken.  (It leads to panics.)

See:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213257
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212413

And some comments about it in this particular bug as well:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208409

This bit me last night on 10-stable.  I have ALTQ in my kernel
configuration, but I'm only using it on em(4) interfaces, not igb(4)
interfaces.  (I bought an em(4) NIC in mid-2015 because of this particular
problem.)

Some folks have been able to get around the problem by rate-limiting
traffic on the igb(4) interfaces, but that is fairly kludgy.

IMO, we shouldn't enable IGB_LEGACY_TX automatically when ALTQ is enabled
when it can lead to crashes.

There are several possible ways to fix things:

1. Actually fix IGB_LEGACY_TX so that it doesn't cause crashes.
2. If ALTQ is actually in use with igb(4), switch igb(4) into single queue
   mode.  (Not sure how feasible that is.)
3. Come up with a way for ALTQ to generically and easily work on top of
   multiqueue interfaces.

I'm sure other folks more well versed in the network stack will have
additional ideas.

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

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mateusz Guzik 
On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
> [Note: I experiment with clang based powerpc64 builds,
> reporting problems that I find. Justin is familiar
> with this, as is Nathan.]
> 
> I tried to update the PowerMac G5 (a so-called "Quad Core")
> that I have access to from head -r312761 to -r313864 and
> ended up with random panics and hang ups in fairly short
> order after booting.
> 
> Some approximate bisecting for the kernel lead to:
> (sometimes getting part way into a buildkernel attempt
> for a different version before a failure happens)
> 
> -r313266: works (just before use of atomic_fcmpset)
> vs.
> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
> 
> (I did not try -r313268 through -r313270 as the use was
> gradually added.)
> 
> So I'm currently running a -r313864 world with a -r313266
> kernel.
> 
> No kernel that I tried that was from before -r313266 had the
> problems.
> 
> Any kernel that I tried that was from after -r313271 had the
> problems.
> 
> Of course I did not try them all in other direction. :)
> 

I found that spin mutexes were not properly handling this, fixed in
r313996.

Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
fcmpset to simulate failures. Everything works, while it would easily
fail without the patch.

That said, I hope this concludes the 'missing check for not-reread value
of failed fcmpset' saga.

-- 
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: r313996 - in head/sys: kern sys

2017-02-20 Thread Mateusz Guzik 
Author: mjg
Date: Mon Feb 20 19:08:36 2017
New Revision: 313996
URL: https://svnweb.freebsd.org/changeset/base/313996

Log:
  mtx: fix spin mutexes interaction with failed fcmpset
  
  While doing so move recursion support down to the fallback routine.

Modified:
  head/sys/kern/kern_mutex.c
  head/sys/sys/mutex.h

Modified: head/sys/kern/kern_mutex.c
==
--- head/sys/kern/kern_mutex.c  Mon Feb 20 17:33:25 2017(r313995)
+++ head/sys/kern/kern_mutex.c  Mon Feb 20 19:08:36 2017(r313996)
@@ -696,6 +696,14 @@ _mtx_lock_spin_cookie(volatile uintptr_t
lock_delay_arg_init(, _spin_delay);
m = mtxlock2mtx(c);
 
+   if (__predict_false(v == MTX_UNOWNED))
+   v = MTX_READ_VALUE(m);
+
+   if (__predict_false(v == tid)) {
+   m->mtx_recurse++;
+   return;
+   }
+
if (LOCK_LOG_TEST(>lock_object, opts))
CTR1(KTR_LOCK, "_mtx_lock_spin: %p spinning", m);
KTR_STATE1(KTR_SCHED, "thread", sched_tdname((struct thread *)tid),

Modified: head/sys/sys/mutex.h
==
--- head/sys/sys/mutex.hMon Feb 20 17:33:25 2017(r313995)
+++ head/sys/sys/mutex.hMon Feb 20 19:08:36 2017(r313996)
@@ -223,12 +223,9 @@ void   thread_lock_flags_(struct thread *,
uintptr_t _v = MTX_UNOWNED; \
\
spinlock_enter();   \
-   if (!_mtx_obtain_lock_fetch((mp), &_v, _tid)) { \
-   if (_v == _tid) \
-   (mp)->mtx_recurse++;\
-   else\
-   _mtx_lock_spin((mp), _v, _tid, (opts), (file), (line));\
-   } else  \
+   if (!_mtx_obtain_lock_fetch((mp), &_v, _tid))   \
+   _mtx_lock_spin((mp), _v, _tid, (opts), (file), (line)); \
+   else\
LOCKSTAT_PROFILE_OBTAIN_LOCK_SUCCESS(spin__acquire, \
mp, 0, 0, file, line);  \
 } while (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: r313995 - head/sys/compat/linprocfs

2017-02-20 Thread Edward Tomasz Napierala 
Author: trasz
Date: Mon Feb 20 17:33:25 2017
New Revision: 313995
URL: https://svnweb.freebsd.org/changeset/base/313995

Log:
  Add /proc/self/mounts to linprocfs; some linux binaries need it.
  
  MFC after:2 weeks
  Sponsored by: DARPA, AFRL

Modified:
  head/sys/compat/linprocfs/linprocfs.c

Modified: head/sys/compat/linprocfs/linprocfs.c
==
--- head/sys/compat/linprocfs/linprocfs.c   Mon Feb 20 16:18:33 2017
(r313994)
+++ head/sys/compat/linprocfs/linprocfs.c   Mon Feb 20 17:33:25 2017
(r313995)
@@ -1543,6 +1543,8 @@ linprocfs_init(PFS_INIT_ARGS)
NULL, NULL, NULL, PFS_RD);
pfs_create_file(dir, "mem", _doprocmem,
_attr, _candebug, NULL, PFS_RDWR|PFS_RAW);
+   pfs_create_file(dir, "mounts", _domtab,
+   NULL, NULL, NULL, PFS_RD);
pfs_create_link(dir, "root", _doprocroot,
NULL, NULL, NULL, 0);
pfs_create_file(dir, "stat", _doprocstat,
___
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: r313994 - head/sys/fs/devfs

2017-02-20 Thread Edward Tomasz Napierala 
Author: trasz
Date: Mon Feb 20 16:18:33 2017
New Revision: 313994
URL: https://svnweb.freebsd.org/changeset/base/313994

Log:
  Simplify devfs_fsync() by removing it. This might also be a minor
  optimization, as vn_isdisk() needs to lock a global mutex.
  
  Reviewed by:  imp
  Tested by:pho
  MFC after:2 weeks
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D9628

Modified:
  head/sys/fs/devfs/devfs_vnops.c

Modified: head/sys/fs/devfs/devfs_vnops.c
==
--- head/sys/fs/devfs/devfs_vnops.c Mon Feb 20 16:13:40 2017
(r313993)
+++ head/sys/fs/devfs/devfs_vnops.c Mon Feb 20 16:18:33 2017
(r313994)
@@ -677,32 +677,6 @@ devfs_close_f(struct file *fp, struct th
 }
 
 static int
-devfs_fsync(struct vop_fsync_args *ap)
-{
-   int error;
-   struct bufobj *bo;
-   struct devfs_dirent *de;
-
-   if (!vn_isdisk(ap->a_vp, )) {
-   bo = >a_vp->v_bufobj;
-   de = ap->a_vp->v_data;
-   if (error == ENXIO && bo->bo_dirty.bv_cnt > 0) {
-   printf("Device %s went missing before all of the data "
-   "could be written to it; expect data loss.\n",
-   de->de_dirent->d_name);
-
-   error = vop_stdfsync(ap);
-   if (bo->bo_dirty.bv_cnt != 0 || error != 0)
-   printf("devfs_fsync: vop_stdfsync failed.");
-   }
-
-   return (0);
-   }
-
-   return (vop_stdfsync(ap));
-}
-
-static int
 devfs_getattr(struct vop_getattr_args *ap)
 {
struct vnode *vp = ap->a_vp;
@@ -1912,7 +1886,7 @@ static struct vop_vector devfs_specops =
.vop_bmap = VOP_PANIC,
.vop_close =devfs_close,
.vop_create =   VOP_PANIC,
-   .vop_fsync =devfs_fsync,
+   .vop_fsync =vop_stdfsync,
.vop_getattr =  devfs_getattr,
.vop_ioctl =devfs_ioctl,
.vop_link = VOP_PANIC,
___
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: r313993 - head/sys/amd64/linux

2017-02-20 Thread Edward Tomasz Napierala 
Author: trasz
Date: Mon Feb 20 16:13:40 2017
New Revision: 313993
URL: https://svnweb.freebsd.org/changeset/base/313993

Log:
  Reimplement linux_arch_prctl() as a wrapper around sysarch(2).
  This also adds support for LINUX_ARCH_SET_GS.
  
  Reviewed by:  dchagin
  MFC after:2 weeks
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D9372

Modified:
  head/sys/amd64/linux/linux_machdep.c

Modified: head/sys/amd64/linux/linux_machdep.c
==
--- head/sys/amd64/linux/linux_machdep.cMon Feb 20 15:53:16 2017
(r313992)
+++ head/sys/amd64/linux/linux_machdep.cMon Feb 20 16:13:40 2017
(r313993)
@@ -88,6 +88,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
 
 int
 linux_execve(struct thread *td, struct linux_execve_args *args)
@@ -226,28 +227,34 @@ int
 linux_arch_prctl(struct thread *td, struct linux_arch_prctl_args *args)
 {
int error;
-   struct pcb *pcb;
+   struct sysarch_args bsd_args;
 
LINUX_CTR2(arch_prctl, "0x%x, %p", args->code, args->addr);
 
-   error = ENOTSUP;
-   pcb = td->td_pcb;
-
switch (args->code) {
-   case LINUX_ARCH_GET_GS:
-   error = copyout(>pcb_gsbase, (unsigned long *)args->addr,
-   sizeof(args->addr));
-   break;
case LINUX_ARCH_SET_GS:
-   if (args->addr >= VM_MAXUSER_ADDRESS)
-   return(EPERM);
+   bsd_args.op = AMD64_SET_GSBASE;
+   bsd_args.parms = (void *)args->addr;
+   error = sysarch(td, _args);
+   if (error == EINVAL)
+   error = EPERM;
+   break;
+   case LINUX_ARCH_SET_FS:
+   bsd_args.op = AMD64_SET_FSBASE;
+   bsd_args.parms = (void *)args->addr;
+   error = sysarch(td, _args);
+   if (error == EINVAL)
+   error = EPERM;
break;
case LINUX_ARCH_GET_FS:
-   error = copyout(>pcb_fsbase, (unsigned long *)args->addr,
-   sizeof(args->addr));
+   bsd_args.op = AMD64_GET_FSBASE;
+   bsd_args.parms = (void *)args->addr;
+   error = sysarch(td, _args);
break;
-   case LINUX_ARCH_SET_FS:
-   error = linux_set_cloned_tls(td, (void *)args->addr);
+   case LINUX_ARCH_GET_GS:
+   bsd_args.op = AMD64_GET_GSBASE;
+   bsd_args.parms = (void *)args->addr;
+   error = sysarch(td, _args);
break;
default:
error = EINVAL;
___
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: r313992 - in head: sys/kern sys/sys tests/sys/kern

2017-02-20 Thread Eric Badger 
Author: badger
Date: Mon Feb 20 15:53:16 2017
New Revision: 313992
URL: https://svnweb.freebsd.org/changeset/base/313992

Log:
  Defer ptracestop() signals that cannot be delivered immediately
  
  When a thread is stopped in ptracestop(), the ptrace(2) user may request
  a signal be delivered upon resumption of the thread. Heretofore, those signals
  were discarded unless ptracestop()'s caller was issignal(). Fix this by
  modifying ptracestop() to queue up signals requested by the ptrace user that
  will be delivered when possible. Take special care when the signal is SIGKILL
  (usually generated from a PT_KILL request); no new stop events should be
  triggered after a PT_KILL.
  
  Add a number of tests for the new functionality. Several tests were authored
  by jhb.
  
  PR:   212607
  Reviewed by:  kib
  Approved by:  kib (mentor)
  MFC after:2 weeks
  Sponsored by: Dell EMC
  In collaboration with:jhb
  Differential Revision:https://reviews.freebsd.org/D9260

Modified:
  head/sys/kern/kern_fork.c
  head/sys/kern/kern_sig.c
  head/sys/kern/kern_thr.c
  head/sys/kern/subr_syscall.c
  head/sys/kern/sys_process.c
  head/sys/sys/signalvar.h
  head/tests/sys/kern/Makefile
  head/tests/sys/kern/ptrace_test.c

Modified: head/sys/kern/kern_fork.c
==
--- head/sys/kern/kern_fork.c   Mon Feb 20 10:51:46 2017(r313991)
+++ head/sys/kern/kern_fork.c   Mon Feb 20 15:53:16 2017(r313992)
@@ -1081,7 +1081,7 @@ fork_return(struct thread *td, struct tr
proc_reparent(p, dbg);
sx_xunlock(_lock);
td->td_dbgflags |= TDB_CHILD | TDB_SCX | TDB_FSTP;
-   ptracestop(td, SIGSTOP);
+   ptracestop(td, SIGSTOP, NULL);
td->td_dbgflags &= ~(TDB_CHILD | TDB_SCX);
} else {
/*
@@ -1102,7 +1102,7 @@ fork_return(struct thread *td, struct tr
_STOPEVENT(p, S_SCX, td->td_dbg_sc_code);
if ((p->p_ptevents & PTRACE_SCX) != 0 ||
(td->td_dbgflags & TDB_BORN) != 0)
-   ptracestop(td, SIGTRAP);
+   ptracestop(td, SIGTRAP, NULL);
td->td_dbgflags &= ~(TDB_SCX | TDB_BORN);
PROC_UNLOCK(p);
}

Modified: head/sys/kern/kern_sig.c
==
--- head/sys/kern/kern_sig.cMon Feb 20 10:51:46 2017(r313991)
+++ head/sys/kern/kern_sig.cMon Feb 20 15:53:16 2017(r313992)
@@ -278,6 +278,7 @@ sigqueue_init(sigqueue_t *list, struct p
 {
SIGEMPTYSET(list->sq_signals);
SIGEMPTYSET(list->sq_kill);
+   SIGEMPTYSET(list->sq_ptrace);
TAILQ_INIT(>sq_list);
list->sq_proc = p;
list->sq_flags = SQ_INIT;
@@ -301,9 +302,15 @@ sigqueue_get(sigqueue_t *sq, int signo, 
if (!SIGISMEMBER(sq->sq_signals, signo))
return (0);
 
+   if (SIGISMEMBER(sq->sq_ptrace, signo)) {
+   count++;
+   SIGDELSET(sq->sq_ptrace, signo);
+   si->ksi_flags |= KSI_PTRACE;
+   }
if (SIGISMEMBER(sq->sq_kill, signo)) {
count++;
-   SIGDELSET(sq->sq_kill, signo);
+   if (count == 1)
+   SIGDELSET(sq->sq_kill, signo);
}
 
TAILQ_FOREACH_SAFE(ksi, >sq_list, ksi_link, next) {
@@ -347,7 +354,8 @@ sigqueue_take(ksiginfo_t *ksi)
if (kp->ksi_signo == ksi->ksi_signo)
break;
}
-   if (kp == NULL && !SIGISMEMBER(sq->sq_kill, ksi->ksi_signo))
+   if (kp == NULL && !SIGISMEMBER(sq->sq_kill, ksi->ksi_signo) &&
+   !SIGISMEMBER(sq->sq_ptrace, ksi->ksi_signo))
SIGDELSET(sq->sq_signals, ksi->ksi_signo);
 }
 
@@ -360,6 +368,10 @@ sigqueue_add(sigqueue_t *sq, int signo, 
 
KASSERT(sq->sq_flags & SQ_INIT, ("sigqueue not inited"));
 
+   /*
+* SIGKILL/SIGSTOP cannot be caught or masked, so take the fast path
+* for these signals.
+*/
if (signo == SIGKILL || signo == SIGSTOP || si == NULL) {
SIGADDSET(sq->sq_kill, signo);
goto out_set_bit;
@@ -398,16 +410,19 @@ sigqueue_add(sigqueue_t *sq, int signo, 
ksi->ksi_sigq = sq;
}
 
-   if ((si->ksi_flags & KSI_TRAP) != 0 ||
-   (si->ksi_flags & KSI_SIGQ) == 0) {
-   if (ret != 0)
+   if (ret != 0) {
+   if ((si->ksi_flags & KSI_PTRACE) != 0) {
+   SIGADDSET(sq->sq_ptrace, signo);
+   ret = 0;
+   goto out_set_bit;
+   } else if ((si->ksi_flags & KSI_TRAP) != 0 ||
+   (si->ksi_flags & KSI_SIGQ) == 0) {
SIGADDSET(sq->sq_kill, signo);
-   ret = 0;
-

svn commit: r313988 - head/sys/dev/etherswitch/mtkswitch

2017-02-20 Thread Stanislav Galabov 
Author: sgalabov
Date: Mon Feb 20 08:10:41 2017
New Revision: 313988
URL: https://svnweb.freebsd.org/changeset/base/313988

Log:
  etherswitch: Fix RT305x vlan group operation
  
  Fix an issue which prevents proper operation (addition/removal of members)
  of RT305x vlan groups.
  
  Tested by:yamori...@yahoo.co.jp
  
  Submitted by: yamori...@yahoo.co.jp (initial version)
  Reviewed by:  adrian
  Differential Revision:https://reviews.freebsd.org/D9607

Modified:
  head/sys/dev/etherswitch/mtkswitch/mtkswitch_rt3050.c

Modified: head/sys/dev/etherswitch/mtkswitch/mtkswitch_rt3050.c
==
--- head/sys/dev/etherswitch/mtkswitch/mtkswitch_rt3050.c   Mon Feb 20 
08:04:06 2017(r313987)
+++ head/sys/dev/etherswitch/mtkswitch/mtkswitch_rt3050.c   Mon Feb 20 
08:10:41 2017(r313988)
@@ -405,11 +405,38 @@ mtkswitch_vlan_setvgroup(struct mtkswitc
MTKSWITCH_LOCK(sc);
/* First, see if we can accomodate the request at all */
val = MTKSWITCH_READ(sc, MTKSWITCH_POC2);
-   if ((val & POC2_UNTAG_VLAN) == 0 ||
-   sc->sc_switchtype == MTK_SWITCH_RT3050) {
+   if (sc->sc_switchtype == MTK_SWITCH_RT3050 ||
+   (val & POC2_UNTAG_VLAN) == 0) {
+   /*
+* There are 2 things we can't support in per-port untagging
+* mode:
+* 1. Adding a port as an untagged member if the port is not
+*set up to do untagging.
+* 2. Adding a port as a tagged member if the port is set up
+*to do untagging.
+*/
val &= VUB_MASK;
+
+   /* get all untagged members from the member list */
tmp = v->es_untagged_ports & v->es_member_ports;
-   if (val != tmp) {
+   /* fail if untagged members are not a subset of all members */
+   if (tmp != v->es_untagged_ports) {
+   /* Cannot accomodate request */
+   MTKSWITCH_UNLOCK(sc);
+   return (ENOTSUP);
+   }
+
+   /* fail if any untagged member is set up to do tagging */
+   if ((tmp & val) != tmp) {
+   /* Cannot accomodate request */
+   MTKSWITCH_UNLOCK(sc);
+   return (ENOTSUP);
+   }
+
+   /* now, get the list of all tagged members */
+   tmp = v->es_member_ports & ~tmp;
+   /* fail if any tagged member is set up to do untagging */
+   if ((tmp & val) != 0) {
/* Cannot accomodate request */
MTKSWITCH_UNLOCK(sc);
return (ENOTSUP);
___
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: r313987 - head/tools/tools/net80211/wlanstats

2017-02-20 Thread Adrian Chadd 
Author: adrian
Date: Mon Feb 20 08:04:06 2017
New Revision: 313987
URL: https://svnweb.freebsd.org/changeset/base/313987

Log:
  [wlanstats] We actually /do/ support per-STA stats!

Modified:
  head/tools/tools/net80211/wlanstats/main.c

Modified: head/tools/tools/net80211/wlanstats/main.c
==
--- head/tools/tools/net80211/wlanstats/main.c  Mon Feb 20 04:04:59 2017
(r313986)
+++ head/tools/tools/net80211/wlanstats/main.c  Mon Feb 20 08:04:06 2017
(r313987)
@@ -158,7 +158,7 @@ print_sta_stats(FILE *fd, const u_int8_t
 
 void
 usage(void) {
-   printf("wlanstats: [-ah] [-i ifname] [-l] [-o fmt] [interval]\n");
+   printf("wlanstats: [-ah] [-i ifname] [-l] [-m station MAC address] [-o 
fmt] [interval]\n");
 }
 
 int
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"