Re: pair(4) + pf(4): reset all state on "reinjected" packets

On Fri, Oct 30, 2015 at 12:19 +0100, Reyk Floeter wrote: > On Fri, Oct 30, 2015 at 11:30:56AM +0100, Alexander Bluhm wrote: > > On Fri, Oct 30, 2015 at 10:43:21AM +0100, Reyk Floeter wrote: > > > Question: > > > > How does pair(4) interact with pf? If a packet crosses a pair > > > > does it create

Re: pair(4) + pf(4): reset all state on "reinjected" packets

On Fri, Oct 30, 2015 at 13:25 +0100, Reyk Floeter wrote: > On Fri, Oct 30, 2015 at 12:45:31PM +0100, Mike Belopuhov wrote: > > On Fri, Oct 30, 2015 at 12:56 +0100, Reyk Floeter wrote: > > > On Fri, Oct 30, 2015 at 12:29:27PM +0100, Mike Belopuhov wrote: > > > > On Fr

Re: pair(4) + pf(4): reset all state on "reinjected" packets

On Fri, Oct 30, 2015 at 18:16 +0100, Sebastian Benoit wrote: > > i think it should be documented ;) > > otherwise ok > > Index: mbuf.9 > === > RCS file: /cvs/src/share/man/man9/mbuf.9,v > retrieving revision 1.91 > diff -u -p -u

Re: pair(4) + pf(4): reset all state on "reinjected" packets

On Fri, Oct 30, 2015 at 19:05 +0100, Alexander Bluhm wrote: > On Fri, Oct 30, 2015 at 06:48:16PM +0100, Mike Belopuhov wrote: > > On Fri, Oct 30, 2015 at 18:27 +0100, Alexander Bluhm wrote: > > > On Fri, Oct 30, 2015 at 02:04:52PM +0100, Reyk Floeter wrote: > > > > &

Re: pair(4) + pf(4): reset all state on "reinjected" packets

On Fri, Oct 30, 2015 at 18:27 +0100, Alexander Bluhm wrote: > On Fri, Oct 30, 2015 at 02:04:52PM +0100, Reyk Floeter wrote: > > > Socket splicing somove() does the same thing. I will change it to > > > use m_resethdr() after that got commited. > > I just compared code in somove() with

Re: preparing pfi_kif to MP world

On Thu, Oct 29, 2015 at 11:58 +0100, Martin Pieuchot wrote: > On 29/10/15(Thu) 02:49, Mike Belopuhov wrote: > > On 28 October 2015 at 18:41, Alexandr Nedvedicky > > <alexandr.nedvedi...@oracle.com> wrote: > > > Hello Mike, > > > > > > just a q

Re: preparing pfi_kif to MP world

On 28 October 2015 at 18:41, Alexandr Nedvedicky wrote: > Hello Mike, > > just a quick question: > > are you going to commit your pfi_kif_find() et. al.? > or more work is needed there? > I need OKs > thanks a lot > regards > sasha > >> >> Turns

Re: ChachaPoly-03: Chacha20-Poly1305 AEAD construction as per RFC7634

On Mon, Oct 26, 2015 at 18:29 +0100, Mike Belopuhov wrote: > OK? > Update due to poly1305.{c,h} changes. --- sys/crypto/chachapoly.c | 108 sys/crypto/chachapoly.h | 62 +++ 2 files changed, 170 insertions(+)

Re: ChachaPoly-02: import Poly1305 implementation by Andrew-Moon

On Mon, Oct 26, 2015 at 18:28 +0100, Mike Belopuhov wrote: > OK? > A few people asked me to use style(9)'ed version from libressl and cut down on my own changes. Here we go with an updated version. This will require an update to the next diff as well. OK? --- sys/crypto/poly1305.c

Re: ChachaPoly-03: Chacha20-Poly1305 AEAD construction as per RFC7634

On 26 October 2015 at 23:52, Damien Miller <d...@mindrot.org> wrote: > On Mon, 26 Oct 2015, Mike Belopuhov wrote: > >> OK? > > Will this get the nonce right on BE systems? > nonce is a uint8_t array, so of course yes, it's endian agnostic because you

ChachaPoly-05: Chacha20-Poly1305 for software crypto

OK? --- sys/crypto/cryptosoft.c | 24 1 file changed, 24 insertions(+) diff --git sys/crypto/cryptosoft.c sys/crypto/cryptosoft.c index f735c7c..2a4abce 100644 --- sys/crypto/cryptosoft.c +++ sys/crypto/cryptosoft.c @@ -511,18 +511,20 @@ swcr_authenc(struct cryptop

ChachaPoly-03: Chacha20-Poly1305 AEAD construction as per RFC7634

/chachapoly.c sys/crypto/chachapoly.c new file mode 100644 index 000..a670ab9 --- /dev/null +++ sys/crypto/chachapoly.c @@ -0,0 +1,94 @@ +/* + * Copyright (c) 2015 Mike Belopuhov + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby

Re: preparing pfi_kif to MP world

On 16 October 2015 at 13:28, Alexandr Nedvedicky wrote: > > may be it's kind of bike shading... > How about make kifs to stick to convention we see for other objects > such as rulesets/anchors: > > pfi_kif_find() > pfi_kif_find_or_create() >

Re: patch for two nits around pf_insert_src_node() et. al.

On Mon, Oct 12, 2015 at 22:29 +0200, Alexandr Nedvedicky wrote: > Hello, > > Richard Procter came back to me in private email with one more nit to fix: > > we can get rid of > > if (sn->rule.ptr != NULL) > test condition in pfioctl() function as well. > > The relevant

Re: preparing pfi_kif to MP world

On Tue, Oct 13, 2015 at 20:36 +1000, David Gwynne wrote: > > > On 12 Oct 2015, at 12:00 AM, Alexandr Nedvedicky > > wrote: > > > > Hello, > > > > patch below introduces struct refcnt to pfi_kif structure. Patch also > > changes > > pfi_kif_get() function to

Re: preparing pfi_kif to MP world

On Tue, Oct 13, 2015 at 20:36 +1000, David Gwynne wrote: > > > On 12 Oct 2015, at 12:00 AM, Alexandr Nedvedicky > > wrote: > > > > Hello, > > > > patch below introduces struct refcnt to pfi_kif structure. Patch also > > changes > > pfi_kif_get() function to

Re: link state change madness

On 8 October 2015 at 11:48, Martin Pieuchot wrote: > Recent NFS-related rtisvalid(9) regressions turns out to be related > to the use of DOWN RTF_CLONED route entries. Such entries are DOWN > because they are cloned from a DOWN RTF_CLONING entry. > > While investigating this

Re: RTF_LOCAL and link state

On Mon, Oct 12, 2015 at 14:06 +0200, Martin Pieuchot wrote: > It's currently possible to add a RTF_LOCAL route on an interface with a > DOWN link state (em(4) to not say which one). > > Diff below prevents a race and make sure such routes will be UP until > if_link_state_change() is executed. >

Re: rtisvalid(9) for local traffic

On Mon, Oct 12, 2015 at 14:08 +0200, Martin Pieuchot wrote: > RTF_LOCAL are always UP so this is safe. ok? > Makes sense to me after the "RTF_LOCAL and link state" diff. OK mikeb > Index: netinet/ip_input.c > === > RCS file:

Re: patch for two nits around pf_insert_src_node() et. al.

On 10 October 2015 at 20:02, Alexandr Nedvedicky wrote: > Hello, > > Patch fixes two small nits related to source node table in PF (a.k.a. > pf_src_tree_tracking). > > The first issue comes to `global` argument of pf_insert_src_node(). It is > always 0 everywhere

Re: patch for two nits around pf_insert_src_node() et. al.

On Mon, Oct 12, 2015 at 11:13 +0200, Martin Pieuchot wrote: > On 10/10/15(Sat) 20:02, Alexandr Nedvedicky wrote: > > Hello, > > > > Patch fixes two small nits related to source node table in PF (a.k.a. > > pf_src_tree_tracking). > > > > The first issue comes to `global` argument of

Re: unlocking em - unable to fill any rx descriptors

On Thu, Oct 08, 2015 at 01:20 +0200, Hrvoje Popovski wrote: > Hi all, > > i have fairly simple setup with receiver connected to em2 and sender > connected to em3. Both em are Intel I350. Setup is without pf with these > sysctls: > > kern.pool_debug=1 >net.inet.ip.forwarding=1 >

Re: unbreak trunk(4)

On Wed, Oct 07, 2015 at 15:41 +0200, Mike Belopuhov wrote: > Hi, > > If you have noticed recent problems with trunk(4) please try the > diff below as it fixes a subtle issue (not introduced by my changes!) > with setting lladdr on non primary trunk ports: trunk_port_ioctl >

unbreak trunk(4)

Hi, If you have noticed recent problems with trunk(4) please try the diff below as it fixes a subtle issue (not introduced by my changes!) with setting lladdr on non primary trunk ports: trunk_port_ioctl needs to be able to lookup the trunk port, but we didn't put it on the list yet, doh! OK's

Support for ActivCard, CRYPTOCard and SNK-004 authentication tokens

Hello, We're currently evaluating if we should keep providing support for ActivCard, CRYPTOCard and SNK-004 authentication tokens via login_token(8). If you're a user of "activ", "crypto", "snk" or "token" authentication methods (check your /etc/login.conf), please speak up so that we could

Re: Possible em(4) fix

On 6 October 2015 at 14:34, Mark Kettenis <mark.kette...@xs4all.nl> wrote: >> From: Mike Belopuhov <m...@belopuhov.com> >> Date: Tue, 6 Oct 2015 14:18:39 +0200 >> >> On 5 October 2015 at 22:45, Mark Kettenis <mark.kette...@xs4all.nl> wrote: &g

Re: Possible em(4) fix

On 5 October 2015 at 22:45, Mark Kettenis wrote: > Several people seem to complain on misc@ that they're seeing watchdog > timeouts on em(4). But none of them bother to submit a proper bug > report to bugs@. Anyway, here is a diff that might fix the issue. > Please

Re: iked patch for iOS9 IKEv2 VPN (and probably El Capitan)

On 30 September 2015 at 17:17, Reyk Floeter wrote: > Hi, > > the following diffs allows to use iked/OpenIKED with iOS9 IKEv2 > clients. You will be able to connect your super-large iPad Pro or > premium iPhone 6s+ via OpenBSD :) I don't have El Capitan yet, but it > might fix

Re: Simply use rtdeletemsg()

On Wed, Sep 30, 2015 at 10:37 +0200, Martin Pieuchot wrote: > On 25/09/15(Fri) 13:07, Martin Pieuchot wrote: > > This brings nd6_free() in line with arptfree() and adds a userland > > notification for free. > > > > ok? > > Anyone? > Since nobody has complained so far that arp is doing this, I

Re: sppp diet #2

On 30 September 2015 at 14:07, Stuart Henderson wrote: > Left-over from the removal of sppp's special queue handling. > OK! > - /* > -* Put low delay, telnet, rlogin and ftp control packets > -* in front of the queue. > -*/ This made me cry

Re: iked(8) cleanup

On 19 September 2015 at 20:08, Michael McConville wrote: > Drop some unnecessary NULL checks OK for those. > explicitly bzero sensitive memory. > While SADB_GETSPI doesn't export keys, I think this change won't harm nevertheless, so OK for it as well.

Re: nat-to/af-to samples for examples/pf.conf

On 12 September 2015 at 14:12, Stuart Henderson wrote: > What does anyone think about adding commented-out sections > dealing with nat and nat64/dns64 to examples/pf.conf and > unbound.conf? > > Index: etc/examples/pf.conf I think it's a good idea.

Re: rc script for ftp-proxy with v6

On 12 September 2015 at 14:20, Stuart Henderson wrote: > ftp-proxy can only open one listening socket, so to use it with > both IPv4 and IPv6, two instances are required. Now that rc.subr > does exact matches of the process name, we could add a separate > rc script for this.

Re: more IPv6 flensing

On 11 September 2015 at 09:53, Claudio Jeker wrote: > Kill yet another argument to functions in IPv6. This time ip6_output > ifpp - XXX: just for statistics > ifpp is always NULL in all callers so that statistic confirms ifpp is > dying > go for it.

Re: pf pool diff

On 4 September 2015 at 14:49, Mark Kettenis wrote: >> Date: Fri, 4 Sep 2015 13:54:00 +0200 (CEST) >> From: Mark Kettenis >> >> As far as I can tell, these pools are only ever used from process >> context as well. >> >> ok? > > mikeb@ pointed out

Re: bnx pool diff

On 4 September 2015 at 16:15, Mark Kettenis wrote: > We might call pool_put(9) on the bnx_tx_pool from bnx_watchdog() which > runs from a timeout. So this one doesn't get PR_WAITOK. > > ok? > > Sure.

Re: PF ignores block action when rule contains route-to/dup-to action

On 1 September 2015 at 14:31, Alexandr Nedvedicky wrote: > Hello, > > >> > As a side effect the patch breaks block rules with dup-to action. dup-to >> > action as a part of block rule might make some sense... So if there is >> > someone, who really needs block ...

Re: remove RH0 support from ping6(8)

On 30 August 2015 at 15:44, Florian Obser wrote: > RH0 has been deprecated for quite some time now in RFC 5095. It's > quite useless on OpenBSD since our stack unconditionally drops packets > with a RH0 header so you can't get the packet out anyway. > And last but not least

Re: RTM_DELETE and route refcount

On Thu, Aug 20, 2015 at 20:10 +0200, Martin Pieuchot wrote: On 20/08/15(Thu) 18:20, Mike Belopuhov wrote: Makes you wonder why the heck it wasn't done in the first place, doesn't it? If you look at the original CSRG source tree, you'll see how/why this happened :) When karels@ changed

Re: RTM_DELETE and route refcount

Makes you wonder why the heck it wasn't done in the first place, doesn't it?

Re: rtrequest1 error cleanup

I have followed your previous conversation and this diff looks good to me as well. Ok mikeb

Re: [PATCH] Enable -f in ndp(8)

of entries with -s and -f inspired by a diff from Mike Belopuhov m...@cvs.hnet.spb.ru, these semantics with theo, manpage jaredy jmc and bob, ok bob

Re: Xen still failing with recent v1.41 vector.S

On 16 July 2015 at 19:42, Joel j...@joelroberts.org wrote: Hello, I was excited to see Xen mentioned in a recent commit log. Unfortunately, there are still some issues when going multiprocessor. The dom0 machine was an Ubuntu server running 10.04.2 with a Xen version of 4.4.1 (refer to file

Re: [patch] cleaner checksum modification for pf

On 16 June 2015 at 03:09, Richard Procter richard.n.proc...@gmail.com wrote: - I was unable to test af-to, which does a lot of packet fiddling. I've never used it before and was unable to get it working on a generic kernel. I figure I'm just missing something. I used the line pass

Re: pf: increment rule counters after successful state insertion

On Tue, Jun 09, 2015 at 18:11 +0200, Mike Belopuhov wrote: Hi, I was surprised to see 'State Creations' rule counter go up when no real state creation happens. This is because we increment all counters too early, but then don't decrement 'states_tot' which is a total number of states

Re: patch: pppd: fix crash in LCP reject codepath

On 12 June 2015 at 15:18, Sergey Ryazanov ryazanov@gmail.com wrote: Friday, June 12, 2015, 4:09:09 PM, you wrote: pppd(8) creates Reject message by moving with memcpy(3) rejected option to left in buffer. If moving distance is less then option length than it falls in coping

Re: MTU on oce(4) nics

On 11 June 2015 at 17:59, Pedro Caetano pedrocaet...@binaryflows.com wrote: Hi tech@, I'm running some stress testing on a pair of hp dl320 gen8 servers with HP NC552SFP nics. This is a new installation, ip forwarding enabled, bug reproducible on 5.7 -stable and -current For this purpose

pfctl -ss -R

Hi, Any idea why don't we support filtering the show states output by the associated rule number? Diff below works fine here, OK? Index: pfctl.c === RCS file: /home/cvs/src/sbin/pfctl/pfctl.c,v retrieving revision 1.329 diff -u -p

SNMP: support new no-route pf counter

Hi, Please review SNMP bits for the new 'no-route' pf state insertion failure counter. Any improvements to the MIB description? Here's what I mean by no target addresses were available: for instance, with such ruleset: table empty persist pass in on vmx0 inet proto tcp to port 80 route-to

Re: pf: increment rule counters after successful state insertion

On Tue, Jun 09, 2015 at 18:11 +0200, Mike Belopuhov wrote: Hi, I was surprised to see 'State Creations' rule counter go up when I've just realised that I might have been a bit too vague in my description. no real state creation happens. Should read: when state creation/insertion fails

pf: increment rule counters after successful state insertion

Hi, I was surprised to see 'State Creations' rule counter go up when no real state creation happens. This is because we increment all counters too early, but then don't decrement 'states_tot' which is a total number of states created by the rule. Not entirely sure why was it done but I see no

Re: SNMP: support new no-route pf counter

On Tue, Jun 09, 2015 at 17:52 +0200, Mike Belopuhov wrote: Hi, Please review SNMP bits for the new 'no-route' pf state insertion failure counter. Any improvements to the MIB description? Here's what I mean by no target addresses were available: for instance, with such ruleset: table

RIP hzto(9) 3/4: the implementation

OK? diff --git sys/kern/kern_clock.c sys/kern/kern_clock.c index 279804c..e35f2f4 100644 --- sys/kern/kern_clock.c +++ sys/kern/kern_clock.c @@ -200,63 +200,10 @@ hardclock(struct clockframe *frame) if (timeout_hardclock_update()) softintr_schedule(softclock_si); } /*

RIP hzto(9) 1/4: IPsec

OK? diff --git sys/net/if_bridge.c sys/net/if_bridge.c index 637dea8..ce8d0d7 100644 --- sys/net/if_bridge.c +++ sys/net/if_bridge.c @@ -2181,11 +2181,10 @@ int bridge_ipsec(struct bridge_softc *sc, struct ifnet *ifp, struct ether_header *eh, int hassnap, struct llc *llc, int dir, int

RIP hzto(9) 2/4: NFS

OK? diff --git sys/nfs/nfs_socket.c sys/nfs/nfs_socket.c index 9edd615..a4a279f 100644 --- sys/nfs/nfs_socket.c +++ sys/nfs/nfs_socket.c @@ -1003,13 +1003,13 @@ tryagain: error = fxdr_unsigned(int, *tl); if ((nmp-nm_flag NFSMNT_NFSV3)

RIP hzto(9) 4/4: manual pages

OK? diff --git share/man/man9/Makefile share/man/man9/Makefile index d145186..c63132f 100644 --- share/man/man9/Makefile +++ share/man/man9/Makefile @@ -12,11 +12,11 @@ MAN=aml_evalnode.9 atomic_add_int.9 atomic_cas_uint.9 \ copy.9 config_attach.9 crypto.9 delay.9 \

Re: vmxnet3 panic

On Wed, Jun 03, 2015 at 23:14 +0200, mxb wrote: Any chance to get this committed? Stepped on it once more without this patch. I'd like to. OKs? //mxb On 2015-05-22 19:53, Mike Belopuhov wrote: vmx doesn't check if it's wasn't stopped before calling rx/tx interrupt routines

Re: pf_create_state() is sometimes better to use pf_unlink_state()

On Thu, May 28, 2015 at 23:46 +0200, Alexandr Nedvedicky wrote: /snip But we'll drop this reference in pf_src_tree_remove_state, then how will sns[PF_SN_NAT] and sns[PF_SN_ROUTE] be different? I think I should take PF class again ;-) I've just realized there is a test in

Re: pf_create_state() is sometimes better to use pf_unlink_state()

On Thu, May 28, 2015 at 01:17 +0200, Alexandr Nedvedicky wrote: Hello, On Wed, May 27, 2015 at 07:44:15PM +0200, Mike Belopuhov wrote: On Wed, May 27, 2015 at 10:39 +0200, Alexandr Nedvedicky wrote: Hello, - if (pf_state_insert(BOUND_IFACE(r, pd-kif), skw, sks, s

Re: pf_create_state() is sometimes better to use pf_unlink_state()

On Thu, May 28, 2015 at 13:34 +0200, Alexandr Nedvedicky wrote: On Thu, May 28, 2015 at 11:43:02AM +0200, Mike Belopuhov wrote: On Thu, May 28, 2015 at 01:17 +0200, Alexandr Nedvedicky wrote: Hello, On Wed, May 27, 2015 at 07:44:15PM +0200, Mike Belopuhov wrote: On Wed, May 27

Re: Use m_defrag in intel wireless drivers

On Tue, May 26, 2015 at 22:56 +0200, Mark Kettenis wrote: Some of you may have seen the iwn(4) diff before, but I tweaked it a bit to minimize the diff. Tested iwn(4) and wpi(4) myself. Further tests and/or ok's are welcome. OK mikeb

Re: pf_create_state() is sometimes better to use pf_unlink_state()

On Wed, May 27, 2015 at 10:39 +0200, Alexandr Nedvedicky wrote: Hello, - if (pf_state_insert(BOUND_IFACE(r, pd-kif), skw, sks, s)) { - pf_state_key_detach(s, PF_SK_STACK); - pf_state_key_detach(s, PF_SK_WIRE); This bug is not yours, but doing two

Re: pf_create_state() is sometimes better to use pf_unlink_state()

On Thu, May 21, 2015 at 21:28 +0200, Alexandr Nedvedicky wrote: Hello, On Thu, May 21, 2015 at 07:43:51PM +0200, Mike Belopuhov wrote: On Thu, May 21, 2015 at 17:34 +0200, Alexandr Nedvedicky wrote: Hello, Hi, snippet below comes from pf_create_state(): 3559

Re: softraid(4): Linux Unified Key Setup

Hi, PKCS PBKDF5 implementation doesn't belong to xform.c which hooks up algorithms to the crypto framework. Merging dev/luks.c into the softraid_luks.c would also make more sense to me since it just provides subroutines for the latter. Cheers, Mike

Re: mismatch for ICMP state created by inound response

On Thu, May 21, 2015 at 21:08 +0200, Alexandr Nedvedicky wrote: Hello, Well, not entirely (: I did it while exploring the code and sent out to provoke further discussion. Today I've talked to reyk@ and we think that it's better to go down a different road: make sure we don't create

Re: vmxnet3 panic

On Fri, May 22, 2015 at 19:35 +0200, mxb wrote: Hey, got a panic as of todays ‘cvs up’ trace below panic: vmxnet3_rxintr: NULL ring-m[44] Stopped at Debugger+0x9: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! IF RUNNING SMP, USE 'mach ddbcpu #'

Re: pf_create_state() is sometimes better to use pf_unlink_state()

On Thu, May 21, 2015 at 17:34 +0200, Alexandr Nedvedicky wrote: Hello, Hi, snippet below comes from pf_create_state(): 3559 if (pf_state_insert(BOUND_IFACE(r, pd-kif), skw, sks, s)) { 3560 pf_state_key_detach(s, PF_SK_STACK); 3561

Pf bikeshedding diff #2: cut down on those ifs

Like really! OK? Sanity checked by blambert. diff --git sys/net/pf.c sys/net/pf.c index d4cb67c..2ba04d5 100644 --- sys/net/pf.c +++ sys/net/pf.c @@ -4488,21 +4488,16 @@ pf_test_state_icmp(struct pf_pdesc *pd, struct pf_state **state, * Search for an ICMP state.

Pf bikeshedding diff #1: PF_ICMP_MULTI_LINK is just a flag

While looking into Alexandr's report I made a few nits that I consider worth getting in. This is the first one. multi is just a flag these days (for better or worse), so having a enum and a store in pf_icmp_mapping is pointless since the usage is always the same: try looking up an ICMP state

Re: mismatch for ICMP state created by inound response

On Thu, May 21, 2015 at 11:07 +0200, Alexandr Nedvedicky wrote: Hello, On Tue, May 19, 2015 at 14:07 +0200, Alexandr Nedvedicky wrote: Hello Mike, I've reworked patch from yesterday. I've done some quick testing to see if it fixes problem. It looks like it works. I have not

Re: mismatch for ICMP state created by inound response

On Tue, May 19, 2015 at 14:07 +0200, Alexandr Nedvedicky wrote: Hello Mike, I've reworked patch from yesterday. I've done some quick testing to see if it fixes problem. It looks like it works. I have not tested NAT-64 yet. Also I'd like to come up with test case, which will show the state

Re: mismatch for ICMP state created by inound response

On Mon, May 18, 2015 at 19:24 +0200, Alexandr Nedvedicky wrote: Hello, during our testing we've discovered small glitch in ICMP state handling. we use simple rule as follows: Hi, # pfctl -sr pass in on vnet2 all flags S/SA If that is the only rule there is, then you need to

SEEPROM bge's need larger handshake timeouts

Hi, We've got an onboard bge that has got this annoying printf that also shows up on every up and down (comes from bge_reset): bge0 at pci4 dev 0 function 0 Broadcom BCM5718 rev 0x10, BCM5717 B0 \ (0x5717100), APE firmware NCSI 1.1.19.0: msi, address fc:aa:14:16:14:26 brgphy0 at bge0 phy 1:

Re: Brainy: Kernel Use-after-free Memory Leak in hifn

On Mon, May 11, 2015 at 22:11 +0200, Maxime Villard wrote: Hi, I put here two bugs among others: sys/dev/pci/hifn7751.c 2757 if (!(m0-m_flags M_EXT)) m_freem(m0); len = MCLBYTES; totlen -= len;

Re: vfs_shutdown would like to do polled I/O at least on panic

On Fri, May 08, 2015 at 20:28 +0200, Mark Kettenis wrote: Date: Fri, 8 May 2015 20:15:58 +0200 From: Mike Belopuhov m...@belopuhov.com On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote: I think tsleep(9) and msleep(9) need to release and re-acquire the kernel lock

Re: vfs_shutdown would like to do polled I/O at least on panic

On 8 May 2015 at 11:43, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Thu, 7 May 2015 20:58:53 +0200 From: Mike Belopuhov m...@belopuhov.com As I've pointed out before, on panic we can be running on any CPU and our disk controller's interrupts can interrupt on the other one. Since

Re: vfs_shutdown would like to do polled I/O at least on panic

On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote: I think tsleep(9) and msleep(9) need to release and re-acquire the kernel lock in the cold || panicstr case. Well, it's not hard to do really, but... We might need this for handling interrupts during autoconf as soon as we

Re: vfs_shutdown would like to do polled I/O at least on panic

On 8 May 2015 at 04:51, Masao Uebayashi uebay...@tombiinc.com wrote: By doing complex VFS shutdown operation, the system's memory image will be modified a lot since a panic was triggered. I'd totally skip vfs_shutdown() after a panic [1], then do the best to dump a kernel core for analysis.

Re: tcp keep-alives sent without timestamps

On 6 May 2015 at 13:05, Martin Pieuchot m...@openbsd.org wrote: On 20/04/15(Mon) 18:37, Mike Belopuhov wrote: On Tue, Apr 14, 2015 at 22:08 +0300, Lauri Tirkkonen wrote: On Tue, Apr 14 2015 20:40:58 +0200, Mike Belopuhov wrote: According to 3.2 in RFC 7323: Once TSopt has been

Re: tcp keep-alives sent without timestamps

On 14 April 2015 at 21:08, Lauri Tirkkonen loth...@iki.fi wrote: On Tue, Apr 14 2015 20:40:58 +0200, Mike Belopuhov wrote: According to 3.2 in RFC 7323: Once TSopt has been successfully negotiated, that is both SYN and SYN,ACK contain TSopt, the TSopt MUST be sent in every non-RST

vfs_shutdown would like to do polled I/O at least on panic

As I've pointed out before, on panic we can be running on any CPU and our disk controller's interrupts can interrupt on the other one. Since we'll most likely be holding a kernel lock, dealing with unlocking it might get hairy very fast. Instead what we could do to improve the chances of a clean

Re: msleep(9) should handle cold and panics just like tsleep does

On Tue, May 05, 2015 at 11:02 -0700, Philip Guenther wrote: On Tue, May 5, 2015 at 9:35 AM, Mike Belopuhov m...@belopuhov.com wrote: ... Here's a diff to remedy this. This is the same chunk as in the tsleep, except it uses semantics of msleep. IPL dance is there to negate the IPL

msleep(9) should handle cold and panics just like tsleep does

Now that we have mutexes in our I/O path (SCSI, mfi, etc) vfs_shutdown codepath is no longer safe since it still doesn't disable process scheduling and relies on tsleep and now msleep not to get into the mi_switch by accident. Unfortunately msleep doesn't provide such guarantees yet. Here's a

Re: PATCH: bring crypto(9) up to speed with crypto/cryptodev.h

On 2 May 2015 at 22:07, Vincent Gross dermi...@kilob.yt wrote: Hi folks, crypto(9) describes functions and constants that are not part of crypto/cryptodev.h anymore (see 1.58 - 1.60), this patch fixes that. Cheers, committed a tweaked version. thanks.

Re: tcp keep-alives sent without timestamps

On Tue, Apr 14, 2015 at 22:08 +0300, Lauri Tirkkonen wrote: On Tue, Apr 14 2015 20:40:58 +0200, Mike Belopuhov wrote: According to 3.2 in RFC 7323: Once TSopt has been successfully negotiated, that is both SYN and SYN,ACK contain TSopt, the TSopt MUST be sent in every non-RST

Re: File protection, second attempt

On 15 April 2015 at 13:29, kanonenvogel@gmail.com kanonenvogel@gmail.com wrote: On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote: Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore. Underlying uvm calls are not mp safe True. and not protected

thread safe ipsp_address

Not sure it's worth the effort, but these printfs are sometimes useful. Anyone's willing to OK? diff --git sys/netinet/ip_ah.c sys/netinet/ip_ah.c index f66ea31..d1e270c 100644 --- sys/netinet/ip_ah.c +++ sys/netinet/ip_ah.c @@ -531,10 +531,13 @@ ah_input(struct mbuf *m, struct tdb *tdb, int

Re: File protection, second attempt

On 14 April 2015 at 17:19, kanonenvogel@gmail.com kanonenvogel@gmail.com wrote: Ok, I split my huge patch to some small. f_flag and f_iflags are not affected by this patch set, because they are under mp lock this time. And just for lulz, I made sys_pipe, sys_pipe2 syscalls and

Re: tcp keep-alives sent without timestamps

On Tue, Apr 14, 2015 at 19:40 +0300, Lauri Tirkkonen wrote: Synopsis:tcp keep-alives sent without timestamps Category:kernel Environment: System : OpenBSD 5.7 Details : OpenBSD 5.7-current (GENERIC) #860: Mon Apr 13 20:58:42 MDT 2015

Re: pfi_kif leaks for PBR rules

On 8 April 2015 at 19:16, Mike Belopuhov m...@belopuhov.com wrote: On Sun, Apr 05, 2015 at 12:06 +0200, Alexandr Nedvedicky wrote: Hello, while testing PBR on Solaris we found out the pfi_kif instances are not removed from pfi_ifs table. We took a look at crashdump and have seen pfik_route

rename gettdbbyaddr to gettdbbydst

OK to rename gettdbbyaddr to gettdbbydst since that's what it does and it aligns well with gettdbbysrc? --- sys/netinet/ip_ipsp.c | 47 +-- sys/netinet/ip_ipsp.h | 4 ++-- sys/netinet/ip_spd.c | 6 +++--- 3 files changed, 30 insertions(+), 27

gettdb* functions do not need mbuf and af arguments

OK to remove unused arguments? --- sys/netinet/ip_ipsp.c | 7 +++ sys/netinet/ip_ipsp.h | 7 +++ sys/netinet/ip_spd.c | 13 ++--- 3 files changed, 12 insertions(+), 15 deletions(-) diff --git sys/netinet/ip_ipsp.c sys/netinet/ip_ipsp.c index c6864e8..f6e598f 100644 ---

use tdb_flow for IP_IPSECFLOWINFO

Convert IP_IPSECFLOWINFO to use tdb flow id instead of an SPI. Tested with npppd and Windows NAT-T clients. OK? --- sys/netinet/ip_spd.c | 49 +++- sys/netinet/udp_usrreq.c | 2 +- 2 files changed, 29 insertions(+), 22 deletions(-) diff --git

introduce tdb flows and tdb flow hash

Each tdb (SA) bundle will receive a flow identificator that will be reassigned to the newly established SAs upon rekeying. Later this will be passed as IP_IPSECFLOWINFO control message to userland. Discussed with with Markus and Bret Lambert. OK? --- sys/netinet/ip_ipsp.c | 101

Re: rename gettdbbyaddr to gettdbbydst

On 8 April 2015 at 12:46, Martin Pieuchot m...@openbsd.org wrote: On 08/04/15(Wed) 12:15, Mike Belopuhov wrote: OK to rename gettdbbyaddr to gettdbbydst since that's what it does and it aligns well with gettdbbysrc? Makes sense to me. This is also coherent to the comments in ip_ipsp.h. One

make filter match optional in ipsp_aux_match

Since all other arguments are optional I don't see why filter is special. OK? --- sys/netinet/ip_ipsp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git sys/netinet/ip_ipsp.c sys/netinet/ip_ipsp.c index edeabc8..184c28f 100644 --- sys/netinet/ip_ipsp.c +++

perform bypass check before ipsecflowinfo

It's better to perform the socket bypass check before we start dealing with SAs. OK? --- sys/netinet/ip_spd.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git sys/netinet/ip_spd.c sys/netinet/ip_spd.c index 81e22da..e4b858c 100644 ---

Re: unused argument in pfr_create_kentry()

On 30 September 2014 at 18:03, Alexandr Nedvedicky alexandr.nedvedi...@oracle.com wrote: Hello, while working with PF code we've found the arg1 (flags) of pfr_create_kentry() is unused. the patch is trivial, just in case you are interested. regards sasha committed, thanks.

Re: pfi_kif leaks for PBR rules

On Sun, Apr 05, 2015 at 12:06 +0200, Alexandr Nedvedicky wrote: Hello, while testing PBR on Solaris we found out the pfi_kif instances are not removed from pfi_ifs table. We took a look at crashdump and have seen pfik_route counter at those object is still non-zero, while all rules were

Re: copy'n'paste like typo in pf.c

On 5 April 2015 at 15:14, Florian Obser flor...@openbsd.org wrote: On Sun, Apr 05, 2015 at 11:48:21AM +0200, Alexandr Nedvedicky wrote: Hello, when we ran PF sources through coverity we got an error as follows: 8310 if (ri-r-dst.addr.type == PF_ADDR_TABLE) 8311

<    1   2   3   4   5   6   7   8   9   10   >