Re: bpf(4), csignal() and selwakup()

On Mon, 15 Aug 2016, Martin Pieuchot wrote: > I'd like to make sure that bpf_tap(9) does not grab the KERNEL_LOCK(). > The reason is to reduce the potential lock ordering problems within PF. > > I'm currently using a mutex to serialize buffer changes, but since > bpf_wakeup() will still need the

Re: IP_SENDSRCADDR [2/2] : add cmsg support

On Thu, 11 Aug 2016 16:57:27 +0100 Stuart Henderson wrote: > On 2016/06/27 13:00, Jérémie Courrèges-Anglas wrote: > > Stuart Henderson writes: > > [...] > > > > > > Basically yes but one observation. > > > > I also gave my ok to vgross by IM. >

Re: ral(4) support RT5390 and RT5392

On 8/16/16, Stefan Sperling wrote: > > Your patch can't be applied with patch(1) because directory > components are missing on the Index: lines even though modified > files are spread across several directories. Could you please > send a patch which uses paths relative to /usr/src

Re: [PATCH] [0/11] pf checksum modification / refactoring

On Tue, 9 Aug 2016, Richard Procter wrote: > > Here is the first step in the pf checksum modification / refactoring > series. > > The complete series is available at http://203.79.107.124/. It differs > from what I presented at the hackathon only by a small optimisation [0]. Change of

sshd: log connections at level info

It seems a bit odd that while disconnections are logged the corresponding connections are not unless we're verbose. This restores my sense of balance. Regards, -- Ant Index: usr.bin/ssh/sshd.c === RCS file:

smtpd: log ip/hostname for failed-command events

As -r1.285 does for authentication events, log address and host for failed-command events too. Regards, -- Ant Index: usr.sbin/smtpd/smtp_session.c === RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v retrieving revision 1.285

Re: fuse cache shenanigans

On Mon, Aug 15, 2016 at 02:11:38PM -0600, Bob Beck wrote: > Note - NFS has similar behaviour ;) > > at least within a directory. - so this isn't tht "unusual" for non-local NFS is much smarter than that. It verifies the results returned by cache_lookup() with some "clever" voodoo that checks

Re: Add / Amend history info for some utilities in /bin

Hi Sevan, > Index: bin/echo/echo.1 > Index: bin/kill/kill.1 > Index: bin/pax/pax.1,v > Index: bin/sleep/sleep.1 > Index: bin/sync/sync.8 > Index: bin/test/test.1bin/chio/chio.1 Committed, thanks. > Index: bin/dd/dd.1 > === > RCS

nsd 4.1.11

OK? diff --git buffer.h buffer.h index bee7d8b..9e17bc9 100644 --- buffer.h +++ buffer.h @@ -315,6 +315,20 @@ buffer_write_u32(buffer_type *buffer, uint32_t data) } static inline void +buffer_write_u64_at(buffer_type *buffer, size_t at, uint64_t data) +{ +

Re: cvs(1): default to a)bort for empty commit log

On Mon, Aug 15, 2016 at 12:46:23PM +0200, Theo Buehler wrote: > This is one of the quirks of cvs that I have a hard time getting used to: > > $ cvs commit > > Log message unchanged or not specified > a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs > Action: (continue)

Re: nitems not from param.h

Ok.

Re: nitems not from param.h

Heh, you bet me to it - at least in my daemons. vmd and a few others might need it as well (relayd already defines it locally). ok reyk@ > Am 16.08.2016 um 19:53 schrieb Ted Unangst : > > should not be using secret kernel interfaces in userland. > > > Index:

nitems not from param.h

should not be using secret kernel interfaces in userland. Index: httpd/httpd.c === RCS file: /cvs/src/usr.sbin/httpd/httpd.c,v retrieving revision 1.56 diff -u -p -r1.56 httpd.c --- httpd/httpd.c 10 Jun 2016 12:09:48 -

bgpd.conf: make it clear what "announce IPv6 unicast" does

The man page is a bit confusing for how we can control which address families we support during the capabilities negotiation. Slightly reorganize the man page to be more clear, and explicitly state what the default is. OK? Index: bgpd.conf.5

Re: ksh: "l.beg may be used uninitialized"

You might want to make "XPtrV l;" local to the "if (i == nwords)" block. OK millert@ either way. - todd

Re: ksh: "l.beg may be used uninitialized"

Theo Buehler wrote: > Theo mentioned on icb yesterday that when compiling ksh for instbin, a > warning similar to this one is emitted: > > /usr/src/bin/ksh/edit.c: In function 'x_print_expansions': > /usr/src/bin/ksh/edit.c:303: warning: 'l.beg' may be used uninitialized in > this function > >

iwm_tx() ignores the USEPROT flag

If the stack demands protection by setting the USEPROT flag then set the corresponding bit in the Tx command regardless of frame length. Index: if_iwm.c === RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v retrieving revision 1.98 diff -u

Re: cvs(1): default to a)bort for empty commit log

I agree, the default should be to abort in thise case. - todd

Re: 5GHz vs 2GHz APs

On Tue, Aug 16, 2016 at 11:31:07AM +0100, Stuart Henderson wrote: > On 2016/08/15 14:46, Stefan Sperling wrote: > > The wireless stack usually runs its scanning loop once per frequency band. > > It begins with 5GHz so that APs on this band are preferred. Within a band, > > an AP with the best RSSI

ksh: "l.beg may be used uninitialized"

Theo mentioned on icb yesterday that when compiling ksh for instbin, a warning similar to this one is emitted: /usr/src/bin/ksh/edit.c: In function 'x_print_expansions': /usr/src/bin/ksh/edit.c:303: warning: 'l.beg' may be used uninitialized in this function This warning is only seen when using

Re: rtalloc(9) micro optimization

On Tue, Aug 16, 2016 at 11:53:40AM +0200, Martin Pieuchot wrote: > No need to zeroize the struct rt_addrinfo in the hot path, ok? OK bluhm@ > > Index: net/route.c > === > RCS file: /cvs/src/sys/net/route.c,v > retrieving revision

Re: 5GHz vs 2GHz APs

On 2016/08/15 14:46, Stefan Sperling wrote: > The wireless stack usually runs its scanning loop once per frequency band. > It begins with 5GHz so that APs on this band are preferred. Within a band, > an AP with the best RSSI (receive signal strength indicator) is chosen, > after matching all other

Re: ral(4) support RT5390 and RT5392

On Mon, Aug 08, 2016 at 11:45:10PM -0400, James Hastings wrote: > Hi all, > > The following patch adds RT5390/RT5392 support to ral(4). Your patch can't be applied with patch(1) because directory components are missing on the Index: lines even though modified files are spread across several