NET_LOCK and pf_consistency_lock removal

Hi, this removes the pf_consistency_lock and protects the users with NET_LOCK() I ran into a crash when using pfctl -k, and mpi suggested this change (and likes the diff). pf hackers: ok? diff --git sys/net/pf.c sys/net/pf.c index 2ae434e405d..a8ade533484 100644 --- sys/net/pf.c +++

Re: NET_LOCK and pf_consistency_lock removal

On 25/01/17(Wed) 09:53, Sebastian Benoit wrote: > Hi, > > this removes the pf_consistency_lock and protects the users with NET_LOCK() > > I ran into a crash when using pfctl -k, and mpi suggested this change (and > likes the diff). The reason I suggested this diff is that pfioctl() will need

Re: Special rules for early-open fd's in pledge

On Wed, Jan 25, 2017 at 12:41:26AM -0700, Theo de Raadt wrote: > > On Wed, Jan 25, 2017 at 12:33:36AM -0700, Theo de Raadt wrote: > > > > 2. vmd calls openpty() in the pledged parent whenever a new VM is > > > > started - effectively doing ioctls on post-pledge fds. I will > > > > probably solve

preliminary diff to add BFD support to OpenBGPD

Here is the inital support for OpenBGPD to understand BFD messages. With this, when BFD detects failure, it sets the nexthop for that neighbor to Invalid. Conversely, when BFD sets the state to up, it removes that flag, setting the nexthop to Valid. # when BFD state to 203.0.113.9 is Up $

Re: socket splicing sleeps in task thread

On 25 January 2017 at 13:12, Alexander Bluhm wrote: > Hi, > > I ran the regression tests with netlock and kern.splassert=2. > > panic: sleep: sosplice failed insomnia > Stopped at Debugger+0x7: leave > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND >

Re: socket splicing sleeps in task thread

Hi, I ran the regression tests with netlock and kern.splassert=2. panic: sleep: sosplice failed insomnia Stopped at Debugger+0x7: leave TIDPIDUID PRFLAGS PFLAGS CPU COMMAND 165128 1277 0 0x2 01 relayd * 72837 53210 0 0x14000

Re: pfctl: Kill states within a rdomain

Hi, On 2017-01-24 07:26 PM, Sebastian Benoit wrote: > but your diff does not seem to be against -current, you started from 6.0 > > But even with 6.0 i get rejects, maybe you mail client messes this up. My patch is based on current I suppose problem came from my mail client. > Can you please

Re: Help with the NET_LOCK() - socreate

On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to

Re: Help with the NET_LOCK()

On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to

Re: Help with the NET_LOCK()

On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to

Re: Help with the NET_LOCK() - socreate

On 25/01/17(Wed) 15:52, Theo de Raadt wrote: > I have the same diff. > > It does not help the pr_usrreq path though. Sure but, let's do baby step. :) > >On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote: > >> splassert: yield: want 0 have 1 > >> Starting stack trace... > >> yield() at

Re: pfctl: Kill states within a rdomain

Hi, Based on feedback from jmc and florian here a new version of the patch - Add -V in usage() && __dead usage() - Change man (I hope this time my mail client is well configure) Regards, -- Bertrand Provost Index: pfctl.8 ===

Re: Help with the NET_LOCK()

On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to

Re: Help with the NET_LOCK() - socreate

On 25/01/17(Wed) 19:04, Alexander Bluhm wrote: > On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote: > > splassert: yield: want 0 have 1 > > Starting stack trace... > > yield() at yield+0xac > > pool_get() at pool_get+0x1ca > > socreate() at socreate+0xba > > sys_socket() at

pr_ctlinput void

Hi, This is the next step in merging protosw and ip6protosw. The IPv4 pr_ctlinput functions return a void pointer that is always NULL and never used. Make all functions void like in the IPv6 case. ok? bluhm Index: netinet/ip_icmp.c

Re: Help with the NET_LOCK() - socreate

I have the same diff. It does not help the pr_usrreq path though. >On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote: >> splassert: yield: want 0 have 1 >> Starting stack trace... >> yield() at yield+0xac >> pool_get() at pool_get+0x1ca >> socreate() at socreate+0xba >> sys_socket() at

Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)

[moving to tech@] On 26/01/17(Thu) 00:15, Adam Wolk wrote: > One of the diff from testing had this guard in place: [...] > Index: if_athn_usb.c > === > RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v > retrieving revision 1.42 > diff

Re: pfctl: Kill states within a rdomain

OK florian@ On Wed, Jan 25, 2017 at 07:12:14PM -0500, Bertrand Provost wrote: > Hi, > > Based on feedback from jmc and florian here a new version of the patch > - Add -V in usage() && __dead usage() > - Change man > > (I hope this time my mail client is well configure) > > Regards, > > -- >

Re: Help with the NET_LOCK()

On 25.1.2017. 7:32, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to the NET_LOCK() > just

Re: 11n support for athn(4)

On 17 January 2017 at 12:25, Stefan Sperling wrote: > On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote: >> Without more details, all I can do is guess. >> I made one guess already (antennas) and sadly I guessed wrong. > > Another thing where your setup differs from

iwn: Centrino Ultimate-N 6300 scans, doesn't dhcp?

I've got a ThinkPad x220 with a Centrino Ultimate-N 6300, and I'm trying to get it to connect to a WPA1 WiFi network. Network has a password. Steps taken thus far: Tested WiFi on Linux Update WiFi drivers with fw_update via ethernet Verified /etc/firmware/iwn-6000 exists (it does) dmesg:

Re: Help with the NET_LOCK()

On 25/01/17(Wed) 20:12, David Hill wrote: > > splassert: yield: want 0 have 1 > > Starting stack trace... > > yield() at yield+0xac > > malloc() at malloc+0x406 > > ip6_setmoptions() at ip6_setmoptions+0x65 > > ip6_ctloutput() at ip6_ctloutput+0x6d9 > > sosetopt() at sosetopt+0x8e > >

Re: iwn: Centrino Ultimate-N 6300 scans, doesn't dhcp?

Interesting. It seems that on OpenBSD the reception is quite weak. I've connected, HOWEVER, I have to be in the same room as my router! On Linux I can be anywhere in my house. I tried disabling powersave (-powersave), and still I have to be very close to my router. My phone can connect to it no

Re: Help with the NET_LOCK()

On 25/01/17(Wed) 20:04, David Hill wrote: > [...] > Allocate the mbuf beforehand. Also, move the setting of nflag closer > to where its value is used. ok mpi@ > Index: uipc_syscalls.c > === > RCS file:

Re: Help with the NET_LOCK()

On Wed, Jan 25, 2017 at 11:11:03AM -0500, David Hill wrote: > On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote: > > I just enabled the NET_LOCK() again and I'm looking for test reports. > > Please go build a kernel from sources or wait for the next snapshot, > > run it and report

Re: Help with the NET_LOCK() - socreate

On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote: > splassert: yield: want 0 have 1 > Starting stack trace... > yield() at yield+0xac > pool_get() at pool_get+0x1ca > socreate() at socreate+0xba > sys_socket() at sys_socket+0x135 > syscall() at syscall+0x27b > --- syscall (number 97) ---

Re: Help with the NET_LOCK() - socreate

On Wed, Jan 25, 2017 at 07:04:19PM +0100, Alexander Bluhm wrote: > On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote: > > splassert: yield: want 0 have 1 > > Starting stack trace... > > yield() at yield+0xac > > pool_get() at pool_get+0x1ca > > socreate() at socreate+0xba > > sys_socket()

Re: Help with the NET_LOCK()

On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to

Re: pfctl: Kill states within a rdomain

On Wed, Jan 25, 2017 at 10:45:55AM -0500, Bertrand Provost wrote: > Hi, > > On 2017-01-24 07:26 PM, Sebastian Benoit wrote: > > but your diff does not seem to be against -current, you started from 6.0 > > > > But even with 6.0 i get rejects, maybe you mail client messes this up. > My patch is