pool_setipl for tmpfs

PR_WAITOK implies process context, so IPL_NONE is fine. this is the same as the ufs change, but in tmpfs. ok? Index: tmpfs_vfsops.c === RCS file: /cvs/src/sys/tmpfs/tmpfs_vfsops.c,v retrieving revision 1.8 diff -u -p -r1.8

Re: set art_walk up for an mpsafe world

> On 18 Jun 2016, at 1:53 AM, Martin Pieuchot <m...@openbsd.org> wrote: > > On 15/06/16(Wed) 11:38, David Gwynne wrote: >> this tweaks art_walk in preparation for a world where the table may >> be updated on another cpu. >> >> at the moment we're relyi

pool_setipl() for src/sys/ufs

this is straightforward. filesystems only operate on behalf of processes, and these pools are initted with PR_WAITOK. its reasonable to assume IPL_NONE. ok? Index: ufs/ext2fs/ext2fs_vfsops.c === RCS file:

set art_walk up for an mpsafe world

this tweaks art_walk in preparation for a world where the table may be updated on another cpu. at the moment we're relying on the big lock to serialise updates, so this adds big lock calls in the right place. jmatthew@ has a diff to serialise changes with a mutex, so those kernel lock calls can

pool_setipl for src/sys/uvm

this adds pool_setipl to the pools in src/sys/uvm. this assumes that the various things are only allocated and freed from a process context. if any of these are released from an interrupt we should probably set them to IPL_VM. ok? Index: uvm_amap.c

splraise for sparc

this is kind of like the change i just made to sparc64. sparc created instances of inline functions for each of the splfoo calls. this provides an splraise call and turns splfoo into a macro to splraise(IPL_FOO). the spl code is quite long so i turned it into functions instead of inlines. could

Re: No need to second guess SXIE_ROUNDUP

why not roundup() from src/sys/sys/param.h? > On 9 Jun 2016, at 09:04, Tom Cosgrove > wrote: > > If (pktlen & 3) == 0, SXIE_ROUNDUP returns pktlen anyway (that's its job): > it's defined as > >#define SXIE_ROUNDUP(size, unit) (((size) + (unit) - 1) &

Re: MBIM Patch (Round 2)

> On 2 Jun 2016, at 4:28 AM, Theo de Raadt wrote: > >> As I said, we could still change the name of the interface to 'ubm' >> while keeping 'umbim' as the name of the driver. > > No, I don't understand the proposal. I think it should be ubm > throughout, or I am

provide splraise on sparc64

it would be nice to have splraise as an MI api within the kernel so it could be used in some per cpu data structures. at the moment the only way to use the ipl passed to such things is to use mutexes, but then whats the point of having a per cpu data structure if you're guaranteed to not content

Re: using srp inside art

> On 6 Jun 2016, at 17:14, Jonathan Matthew wrote: > > We've finally got srp and art to the point where we can use srp to manage the > internal links in the art data structures. This allows us to do route lookups > without holding any locks, which is kind of nice. > > As

remove unused spls in sparc64

nothing using splsoftfd or splausoft on sparc64 so we can remove them. ok? Index: dev/fd.c === RCS file: /cvs/src/sys/arch/sparc64/dev/fd.c,v retrieving revision 1.45 diff -u -p -r1.45 fd.c --- dev/fd.c12 Jul 2014 18:44:43 -

store nd6 expiries in the rtentry

this makes it consistent with arp, where route get has the right expiry. note that you cannot have an nd6 llinfo thing without an associated rtentry, so nd_rt is always safe to deref. ok? Index: nd6.c === RCS file:

defer art table and node frees to tasks

if we traverse art tables and nodes via srps, this allows us to add sleeping srp_finalize calls before the pool_puts. ok? Index: art.c === RCS file: /cvs/src/sys/net/art.c,v retrieving revision 1.17 diff -u -p -r1.17 art.c --- art.c

measure ndp expiries against time_uptime

this complements my diff to make arp use time_uptime for expiries too. the point is time_second can be skewed by clock adjustements while time_uptime is monotonic. this is mechanical. after this and arp go in i think i can get rid of ln_expire and simply populate the rtentry associated with this

Re: make art_table_delete scrub the heap on all deletes

> On 1 Jun 2016, at 9:44 PM, Martin Pieuchot <m...@openbsd.org> wrote: > > On 01/06/16(Wed) 19:27, David Gwynne wrote: >> >>> On 1 Jun 2016, at 4:13 PM, Martin Pieuchot <m...@openbsd.org> wrote: >>> >>> On 01/06/16(Wed) 15:

Re: make art_table_delete scrub the heap on all deletes

> On 1 Jun 2016, at 4:13 PM, Martin Pieuchot <m...@openbsd.org> wrote: > > On 01/06/16(Wed) 15:31, David Gwynne wrote: >> currently it leaves early if it is the last entry being removed, >> which is an optimisation. in the future it is possible for another >> cpu

make art_table_delete scrub the heap on all deletes

currently it leaves early if it is the last entry being removed, which is an optimisation. in the future it is possible for another cpu to have a reference to the table while the last reference is being dropped, so we need to scrub it in case it gets read. ok? Index: art.c

prepare art_node for immediate use in rtable_insert

this reorders the code so a functioning art_node is inserted into the table instead of an empty node. if we move art to use srps, an insert will make the node available for lookups immediately. having a functional node in that situation is useful. this includes previous diffz so it can apply and

init art nodes in the one place

ok? Index: art.c === RCS file: /cvs/src/sys/net/art.c,v retrieving revision 1.14 diff -u -p -r1.14 art.c --- art.c 13 Apr 2016 08:04:14 - 1.14 +++ art.c 1 Jun 2016 03:40:34 - @@ -803,6 +803,7 @@

make nd6_llinfo_settimer use seconds, not ticks

internally, nd6 llinfo keeps track of seconds, and the majority of the callers work in seconds. the exception is the nd_ifinfo retrans stuff which is msec, not seconds. i believe there is a bug fix in here too relating to the use of nd_defrouter.expire handling in nd6_free. from what i can tell,

nd6 timers vs ticks

llinfo_nd6 thinks its expiry may extend beyond a timeout interval. so it keeps track of the number of ticks it really wants via ln_ntick in llinfo_nd6 and schedules multiple timeouts to reach it. i think this is a waste of time for two reasons: 1. nd6_llinfo_settimer() (which sets this up)

use time_uptime for route expiry times, not time_second

time_second is unix time, can jump with clock changes. time_uptime is better cos it is monotonic. userland expects the expiry to be in unix time though, so it's translated before it appears in route messages. ok? Index: net/route.c

remove special vlan ioctls in ifconfig

the vlan ioctls have been superseded by the generic ifparent and vnetid ioctls, and will eventually go away. this removes the vlan ioctl handling from ifconfig. however, to continue to support existing vlan interface configuration files (/etc/hostname.vlan*), the command line options have been

m_dup_pkt() for ubsec(4)

ok? Index: ubsec.c === RCS file: /cvs/src/sys/dev/pci/ubsec.c,v retrieving revision 1.161 diff -u -p -r1.161 ubsec.c --- ubsec.c 10 Dec 2015 21:00:51 - 1.161 +++ ubsec.c 12 May 2016 10:54:57 - @@ -1104,7 +1104,7

make mbufs in bpf const

bpf only reads packets, so we can claim theyre const. now that we have the caller mark the packet as dropped based on the return from the tap functions, it simplifies some of the internals of the bpf code too. ok? Index: bpf.c ===

Re: static in ze kernel

> On 28 Apr 2016, at 22:49, Mark Kettenis wrote: > >> Date: Thu, 28 Apr 2016 13:50:53 +0200 >> From: Martin Pieuchot >> >> The reason why we do not use 'static' in the kernel is no longer valid >> since all our platforms are ELF. ddb(4) handle them

Re: MP-safe TX for cnmac(4)

> On 25 Apr 2016, at 02:13, Visa Hankala wrote: > > This adds MP-safe TX for cnmac(4). OK? nearly. see inline. > > Index: arch/octeon/dev/if_cnmac.c > === > RCS file: src/sys/arch/octeon/dev/if_cnmac.c,v >

failure to send a udp packet is not a fatal error

the tftp proxy on the firewall is dying these days. i managed to track the failure down to an error sending the udp packet on. rather than err, i think it more appropriate to warn and let the client retry in this situation. ok? Index: tftp-proxy.c

less handrolled mbuf freeing code in uipc_mbuf.c

m_freem checks for NULL so the caller doesnt have to. ml_purge and m_purge were invented after some of the mq and ml code was written, so fix that code to use the "new" functions. ok? Index: uipc_mbuf.c === RCS file:

Re: rework vlan(4) configuration

On Thu, Apr 07, 2016 at 03:35:34PM +0200, Martin Pieuchot wrote: > On 05/04/16(Tue) 09:20, David Gwynne wrote: > > vlan config is now done via the vnet and parent ioctls. the idea > > is config can be set up while the vlan interface is down, and then > > "commit

rework vlan(4) configuration

vlan config is now done via the vnet and parent ioctls. the idea is config can be set up while the vlan interface is down, and then "committed' when it is brought up and running. vlan up does checks of the vlan state against the target parent, applies any config necessary to the parent, and then

Re: bpf and dropping packets

On Mon, Apr 04, 2016 at 08:07:47PM +1000, David Gwynne wrote: > > > On 4 Apr 2016, at 6:41 PM, Martin Pieuchot <m...@openbsd.org> wrote: > > > > On 04/04/16(Mon) 13:09, David Gwynne wrote: > >> this deprecates M_FILDROP. > >> > >> it i

Re: bpf and dropping packets

> On 4 Apr 2016, at 6:41 PM, Martin Pieuchot <m...@openbsd.org> wrote: > > On 04/04/16(Mon) 13:09, David Gwynne wrote: >> this deprecates M_FILDROP. >> >> it is only set by bpf, and it is only respected on inbound packets. >> however, packets may be marke

bpf and dropping packets

this deprecates M_FILDROP. it is only set by bpf, and it is only respected on inbound packets. however, packets may be marked for dropping early, but it only comes into effect very late. this moves the dropping to right after the bpf calls. this is easy now that if_input run bpf on behalf of the

Re: anyone using gdb "kvm proc/pcb" ?

I have only used target kvm, and only to inspect variables in the kernel. On 3 Apr 2016 13:50, "Philip Guenther" wrote: > > The gdb in base, when used against a live kernel or crash dump, is > supposed to be able to backtrace individual threads via the kvm proc and > kvm pcb

refactor bpf_filter

bpf_filter is hard to read. the difficulty is that it looks like you give it packets in vanilla memory buffers (ie, a pointer and a length) to read out of, but packets in the kernel are in mbufs. so if you pass a buffer with a zero length, the bpf filter code when built in the kernel magically

sys/mbuf.h and extra headers

i dont think mbuf.h needs to bring in sys/queue.h because it doesnt use anything in it. the malloc.h bits are only used to alias the mbuf allocator flags to the malloc ones, which is only necessary under _KERNEL. i think. hilariously the backend allocator for mbufs are pools too. an amd64 kernel

remove BIOC[SG]QUEUE from bpf.c

this basically reverts bpf.c r1.117. two reasons. firstly, nothing uses the ioctls. the tcpdump -Q support never materialised. secondly, and probably more importantly, the implementation assumes that bpf handles mbufs with pkthdrs in the first mbuf, but that is incorrect. bpf actually only deals

ie(4) and ie(4/sparc) vs bpf_tap

i think bpf_tap is broken, so id like to get rid of it. the only thing(s) using it is ie, but they dont require bpf_tap. the typical idiom with doing bpf on outgoing packets is to pass the mbuf in between dequeueing the packet from the send queue, and before it's given to the hardware. this

vlan(4) doesnt have to filter its own mac address

because the network stack does it for it on the way in. the following chunk in src/sys/net/if_ethersubr.c does the same job later on: int ether_input(struct ifnet *ifp, struct mbuf *m, void *cookie) { ... /* * If packet is unicast, make sure it is for us. Drop otherwise.

manpages for bpf_mtap(9) and co

=== RCS file: bpf_mtap.9 diff -N bpf_mtap.9 --- /dev/null 1 Jan 1970 00:00:00 - +++ bpf_mtap.9 29 Mar 2016 04:12:15 - @@ -0,0 +1,124 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2016 David Gwynne <d...@openbsd.org> +.\" +.\"

make bpf_mtap return whether to drop the packet or not

the end goal is to be able to pass the mbuf as a const. at the moment we still mark the packet with M_FILDROP to keep the changes minimal, but that will change in a later diff. ok? Index: bpf.h === RCS file:

Re: make vlan(4) remember its parent by index, not by reference

> On 23 Mar 2016, at 12:36 AM, Masao Uebayashi <uebay...@tombiinc.com> wrote: > > On Tue, Mar 22, 2016 at 09:36:18PM +1000, David Gwynne wrote: >> this basically makes the code use if_get instead of carrying a >> pointer around. this is as mechanical as i can make

replace m_copym2 with m_dup_pkt in pfkey.c

ok? Index: pfkey.c === RCS file: /cvs/src/sys/net/pfkey.c,v retrieving revision 1.29 diff -u -p -r1.29 pfkey.c --- pfkey.c 22 Mar 2016 11:53:21 - 1.29 +++ pfkey.c 22 Mar 2016 12:07:25 - @@ -142,7 +142,7 @@

replace m_copym2 with m_dup_pkt in pf.c

the subject says it all. could someone who uses dup-to try this? ok? Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.966 diff -u -p -r1.966 pf.c --- pf.c4 Mar 2016 22:38:23 - 1.966 +++ pf.c

make vlan(4) remember its parent by index, not by reference

this basically makes the code use if_get instead of carrying a pointer around. this is as mechanical as i can make it. ok? Index: if_vlan_var.h === RCS file: /cvs/src/sys/net/if_vlan_var.h,v retrieving revision 1.33 diff -u -p

use m_dup_pkt to realign bridge packets

could someone test this on a strict arch? ok? Index: if_bridge.c === RCS file: /cvs/src/sys/net/if_bridge.c,v retrieving revision 1.276 diff -u -p -r1.276 if_bridge.c --- if_bridge.c 8 Mar 2016 09:09:43 - 1.276 +++

Re: tcp syn cache random reseed

> On 21 Mar 2016, at 4:28 AM, Alexander Bluhm wrote: > > On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: >> Perhaps the tcps_sc_seedrandom counter with a netstat -s line should >> be commited anyway to show the problem. > > ok? how can i judge if this

Re: some more vlan protocol defines

Can you find any doco that states that? Or any other thing that does it? On 15 Mar 2016 02:21, "Stuart Henderson" <s...@spacehopper.org> wrote: > On 2016/03/14 21:13, David Gwynne wrote: > > this adds macros to describe the min and max valid vlan ids. > > > >

some more vlan protocol defines

this adds macros to describe the min and max valid vlan ids. this will be used in upcoming checks of the configured values from userland. ok? Index: if_ether.h === RCS file: /cvs/src/sys/netinet/if_ether.h,v retrieving revision

rework vlan(4) multicast handling

this refactors the multicast handling in vlan(4) a bit. the previous code had vlan_ether_purgemulti and vlan_ether_resetmulti, each of which does too many things. purgemulti would try and remove the multicast entries from the parent, and then free the local copies of the addresses. resetmulti

move vlan protocol definitions to if_ether.h

vlans are a standard part of ethernet now, it makes sense to me to keep all the protocol level stuff in a single place. ok? Index: net/if_vlan_var.h === RCS file: /cvs/src/sys/net/if_vlan_var.h,v retrieving revision 1.32 diff -u -p

Re: arm: dmamap_destroy: remove explicit unload of map

> On 6 Mar 2016, at 9:53 PM, Tobias Ulmer wrote: > > map is passed straight into free where it gets overwritten with junk. > No other arch makes map invalid before free, and my N2100 didn't > suddenly misbehave either. > > ok? ok > > Index: arch/arm/arm/bus_dma.c >

mpsafe vlan(4)

this is an unfortunately large reworking of vlan(4) to make tx mpsafe it also includes the following: - moving away from the vlan specific SIOC[SG]ETVLAN ioctls to the SIOC[SGD]{VNETID,IFPARENT} ioctls i did this to make the config transitions more straightforward. with the new ioctls you

Re: mpw(4) vlan handling

im going to commit this tomorrow unless anyone objects. i dont want to hold up vlan too much. On Wed, Mar 02, 2016 at 11:48:49AM +1000, David Gwynne wrote: > ive got a large reworking of vlan(4) to make vlan tx mpsafe, which > affected mpw(4). > > the biggest effect was that it w

Re: socppc/fdt: fix end signature check (again)

OK by me On 7 Mar 2016 12:51 a.m., "Martin Pieuchot" wrote: > On 28/02/16(Sun) 16:58, Patrick Wildt wrote: > > Hi, > > > > unfortunately the end signature check is still not correct. Consulting > > the spec cleared the confusion of why the check does not work on my ARM > >

Re: fdt: move code from socppc to sys/dev/fdt/

> On 2 Mar 2016, at 20:49, Patrick Wildt wrote: > > Hi, > > to allow FDT to be used on ARM I think we should move the FDT code from > socppc to sys/dev/fdt/. Opinions? i like this. does it need a directory of its own? could it be dev/ofw/fdt.c?

Re: bump the max_linkhdr size from 16 bytes to 64

> On 2 Mar 2016, at 8:04 PM, Martin Pieuchot <m...@openbsd.org> wrote: > > On 02/03/16(Wed) 10:33, Mike Belopuhov wrote: >> On 2 March 2016 at 05:50, David Gwynne <da...@gwynne.id.au> wrote: >>> the max_link hdr is basically how much space to reserve before a

Re: bump the max_linkhdr size from 16 bytes to 64

> On 2 Mar 2016, at 7:33 PM, Mike Belopuhov <m...@belopuhov.com> wrote: > > On 2 March 2016 at 05:50, David Gwynne <da...@gwynne.id.au> wrote: >> the max_link hdr is basically how much space to reserve before an >> ip packet for link headers, eg, ethernet. >&

Re: Patches for improving npppd with rdomain support

> On 2 Mar 2016, at 02:32, Claer wrote: > > Hello dear developers, > > I asked a friend, Mathieu Papineau, to help me with an issue I have with > npppd. > For a project here, I thought building multitenancy firewall with rdomain > support. For remote access, I wanted

bump the max_linkhdr size from 16 bytes to 64

the max_link hdr is basically how much space to reserve before an ip packet for link headers, eg, ethernet. 16 bytes was a good choice when everything was just ip inside ethernet, but now we deal with a bunch of encapsulations which blow that out of the water. 16 bytes isnt even enough if we have

mpw(4) vlan handling

ive got a large reworking of vlan(4) to make vlan tx mpsafe, which affected mpw(4). the biggest effect was that it was no longer safe to traverse the interface parent hierarchy looking for vlan interfaces. however, from what i could tell from the rfc, such traversal is unecessary. this refactors

factor out vlan header injection

this factors out the vlan shim header injection as vlan_inject() i intend to use this code in mpw in an upcoming diff. ok? Index: if_vlan.c === RCS file: /cvs/src/sys/net/if_vlan.c,v retrieving revision 1.151 diff -u -p -r1.151

Re: gc the unp_gcing flag

> On 26 Feb 2016, at 4:17 PM, Philip Guenther <guent...@gmail.com> wrote: > > On Thu, Feb 25, 2016 at 3:42 AM, David Gwynne <da...@gwynne.id.au> wrote: >> the gc is run from a task in the systq, so we dont need a flag to >> serialise it. it is already serialis

a pool_setipl for every pool_init

i am going to make setting the IPL mandantory for pools. eventually, the IPL will be set in pool_init, but the first step toward that is to actually set it on every pool. i just finished this. it compiles and boots on sparc64, but more eyes and tests would be appreciated. dlg Index:

gc the unp_gcing flag

the gc is run from a task in the systq, so we dont need a flag to serialise it. it is already serialised. ok? Index: uipc_usrreq.c === RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.95 diff -u -p -r1.95

Re: alignment fault on armv7 when using carp(4)

On Mon, Feb 08, 2016 at 11:02:06PM +1000, David Gwynne wrote: > On Sat, Feb 06, 2016 at 04:43:28PM -0500, Anthony Eden wrote: > > >Synopsis: > > > > To me that behavior might suggest the problem is deeper than a > > bookkeeping mistake of aligning memor

Re: alignment fault on armv7 when using carp(4)

> On 9 Feb 2016, at 9:12 PM, Mike Belopuhov <m...@belopuhov.com> wrote: > > On 9 February 2016 at 11:31, David Gwynne <da...@gwynne.id.au> wrote: >> On Mon, Feb 08, 2016 at 11:02:06PM +1000, David Gwynne wrote: >>> On Sat, Feb 06, 2016 at 04:43:28PM -0500

Re: Problem with svlan(4) and bge(4)

On Sun, Jan 10, 2016 at 05:58:13PM +0100, Denis Fondras wrote: > On Sun, Jan 10, 2016 at 03:42:34PM +, Christian Weisgerber wrote: > > You don't actually describe your interface configuration. I _guess_ > > you are trying to terminate IP traffic directly on an svlan(4) > > interface. That

rework em(4) tx ring handling

i found em_txeof hard to read, so i did this. i was originally going to follow myx/re and use a separate prod/cons for a ring of packet info which would point into the descriptor ring, but came to the conclusion that the "end of packet" pointer thats already there was more elegant. it also

Re: Checking MAC address of incoming unicast packets

> On 2 Jan 2016, at 7:55 AM, Stefan Fritsch wrote: > > Hi, > > by default, the ether_input() checks the destination MAC address of > incoming unicast packets only if the interface is in promiscous mode. If > not, it is assumed that the NIC filters unicast packets reliably.

Re: Make em(4) more mpsafe again

On Sat, Dec 05, 2015 at 03:41:24PM +0100, Claudio Jeker wrote: > So Mark and I spent some time to figure out what the issue was with ix(4) > based on that info I resurected the em(4) mpsafe diff that got backed out > and I applied the same fix. It is somewhat unclear if this fixes the > watchdog

mpsafe tx for re(4)

this builds on jmatthew@'s last commit and adds mpsafe tx. ive beat on it pretty hard, but more eyes/tests are appreciated. ok? Index: re.c === RCS file: /cvs/src/sys/dev/ic/re.c,v retrieving revision 1.188 diff -u -p -r1.188 re.c

mpsafe tx for bge(4)

this tweaks the bge tx code and marks it mpsafe. ok? Index: if_bge.c === RCS file: /cvs/src/sys/dev/pci/if_bge.c,v retrieving revision 1.380 diff -u -p -r1.380 if_bge.c --- if_bge.c29 Nov 2015 20:19:35 - 1.380 +++

Re: mpsafe re(4)

> On 26 Dec 2015, at 5:49 PM, Jonathan Matthew wrote: > > On Sat, Dec 05, 2015 at 06:11:51PM +0100, Jonathan Matthew wrote: >> The main interesting bit here is the txeof and start loops, which previously >> operated based on the prod/cons indices and the contents of the tx

vlan(4): better checks for valid vlan ids

the spec says vlan 0 and vlan 4095 are reserved, so we probably shouldnt use them. this tweaks the vlan tag check only allow valid ids per the spec. ok? Index: if_vlan.c === RCS file: /cvs/src/sys/net/if_vlan.c,v retrieving

wire libevent messages up to tftpd logging

if libevent dies it would be nice to have some kind of record of why it decided that was a good idea. by default those messages go nowhere. this has tftp register a log callback for libevent to call. if something goes wrong it should end up in the logs. ok? Index: tftpd.c

Re: [PATCH] doas authentication type

I would like this. It has my OK for what it is worth here. On 8 Dec 2015 11:41 am, "Stuart Henderson" wrote: > On 2015/11/25 00:14, Stuart Henderson wrote: > > On 2015/11/24 11:24, Richard Johnson wrote: > > > We use 2-factor authn for sudo & doas, as well as for most logins.

ifq serialisation, was Re: taskctx and revisiting if_start serialisation

On Sun, Dec 06, 2015 at 02:00:16PM +1000, David Gwynne wrote: > the current code for serialising if_start calls for mpsafe nics does what it > says. as per mpi@s suggestion, this makes the ifq code responsible for the task serialisation. all the machinery is there, but it provides a m

Re: taskctx and revisiting if_start serialisation

> On 7 Dec 2015, at 11:34 PM, Martin Pieuchot <m...@openbsd.org> wrote: > > On 07/12/15(Mon) 19:37, David Gwynne wrote: >> On Sun, Dec 06, 2015 at 03:51:26PM +0100, Martin Pieuchot wrote: >>> On 06/12/15(Sun) 14:00, David Gwynne wrote: >>>> [...]

Re: taskctx and revisiting if_start serialisation

On Sun, Dec 06, 2015 at 03:51:26PM +0100, Martin Pieuchot wrote: > On 06/12/15(Sun) 14:00, David Gwynne wrote: > > the current code for serialising if_start calls for mpsafe nics does > > what it says. > > > > however, kettenis realised it doesnt help us much when we'

vlan doesn thave to handle SIOCGIFADDR

cos the stack can do it for it. ok? Index: if_vlan.c === RCS file: /cvs/src/sys/net/if_vlan.c,v retrieving revision 1.149 diff -u -p -r1.149 if_vlan.c --- if_vlan.c 5 Dec 2015 10:07:55 - 1.149 +++ if_vlan.c 8 Dec 2015

taskctx and revisiting if_start serialisation

the current code for serialising if_start calls for mpsafe nics does what it says. however, kettenis realised it doesnt help us much when we're trying to coordinate between the start and txeof side of a driver when setting or clearing oactive. in particular, a start routine can figure out

Re: bridge_output() and KERNEL_LOCK

ok > On 4 Dec 2015, at 8:48 PM, Martin Pieuchot wrote: > > Now that if_start() will take the KERNEL_LOCK itself if the driver is > not marked as IFXF_MPSAFE if_enqueue() is almost mpsafe. > > The missing piece is addressed by the diff below. We want to ensure >

Re: introducing ip_send()/ip6_send() to OpenBSD kernel

> On 4 Dec 2015, at 06:44, Alexandr Nedvedicky > wrote: > > Hello, > > below is final patch I'm going to commit. Summary of changes: > - softnettq declaration moved to net/if_var.h (by bluhm@) > - lock order swapped: KERNEL_LOCK() goes first

Re: serialise if_start calls

> On 30 Nov 2015, at 9:55 PM, David Gwynne <da...@gwynne.id.au> wrote: > > this tweaks the guts of if_start so it guarantees that there's only > ever one call to ifp->if_start running in the system at a time. > previously this was implicit because it could only be calle

Re: bridge(4) never outputs packets

> On 2 Dec 2015, at 8:49 PM, Claudio Jeker wrote: > > On Wed, Dec 02, 2015 at 11:07:40AM +0100, Martin Pieuchot wrote: >> On 02/12/15(Wed) 10:25, Claudio Jeker wrote: >>> On Wed, Dec 02, 2015 at 09:57:59AM +0100, Martin Pieuchot wrote: Make sure if_output() and

Re: serialise if_start calls

> On 1 Dec 2015, at 5:40 AM, Hrvoje Popovski <hrv...@srce.hr> wrote: > > On 30.11.2015. 12:55, David Gwynne wrote: >> this tweaks the guts of if_start so it guarantees that there's only >> ever one call to ifp->if_start running in the system at a time. >>

serialise if_start calls

this tweaks the guts of if_start so it guarantees that there's only ever one call to ifp->if_start running in the system at a time. previously this was implicit because it could only be called with the KERNEL_LOCK held. as we move forward it would be nice to run the queue without having to take

Re: taskq_barrier(9)

> On 30 Nov 2015, at 5:54 PM, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > >> Date: Mon, 30 Nov 2015 16:28:55 +1000 >> From: David Gwynne <da...@gwynne.id.au> >> >> while playing with some options around running an interfaces send >> queue,

taskq_barrier(9)

while playing with some options around running an interfaces send queue, i came up with the following. if you've deferred work to a taskq and you're not reference counting, this can help you guarantee that any work before a point has completed before proceeding. think of it like intr_barrier. i

Re: Current kernel crash with de(4) interfaces

On Mon, Nov 23, 2015 at 11:21:26AM +, Ricardo Mestre wrote: > Hi, > > As soon as dlg@ sent the patch to tech@ for sys/net/if.c (1.408) and > sys/dev/pci/if_de.c (1.127), a few days ago, I wanted to test them > before the actual commit, but was not able until today. And it bit me > the hard

Re: trunk vs busy ports

> On 20 Nov 2015, at 11:23 PM, Reyk Floeter <r...@openbsd.org> wrote: > > On Fri, Nov 20, 2015 at 03:36:40PM +1000, David Gwynne wrote: >> IFF_OACTIVE means the hardware ring is full, not if it is busy. >> >> perhaps a better check is to see whether there a

Re: sppp(4) PP_NOFRAMING

> On 20 Nov 2015, at 9:36 PM, Stuart Henderson wrote: > > Currently pppoe(4) is the only user of sppp(4) and it uses PP_NOFRAMING. > Do we expect sppp(4) to be used for anything other than pppoe(4) in the > future? If not, we can simplify things by removing the code to

Re: trunk vs busy ports

> On 20 Nov 2015, at 8:18 PM, Martin Pieuchot <m...@openbsd.org> wrote: > > On 20/11/15(Fri) 15:36, David Gwynne wrote: >> IFF_OACTIVE means the hardware ring is full, not if it is busy. > > As discussed earlier, I'd still love to have a document (manpage?) > de

trunk vs busy ports

IFF_OACTIVE means the hardware ring is full, not if it is busy. perhaps a better check is to see whether there are pending packets on the send queue? i could also argue we dont need the check at all, but this is less of a semantic change. ok? Index: if_trunk.c

sppp_subr vs if_start and a use after free

once you enqueue an mbuf, you no longer own it. therefore you cant read the length out of it. this reads the length first, then tries to enq it. also, call if_start instead of a bare call to the underlying start routine. ok? Index: if_spppsubr.c

Re: em(4) watchdog timeouts

On Fri, Nov 13, 2015 at 10:18:51AM -0500, Sonic wrote: > On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best wrote: > > I've done some further testing and I think I've narrowed it down to the > > "Unlocking em(4) a bit further"-patch [0]. could you try this? its not written with the

Re: mpsafe ifqueues

On Fri, Nov 13, 2015 at 12:22:31PM +1000, David Gwynne wrote: > this introduces mpsafety to ifqueue operations. > > this follows on from some mopping up of (now) inappropriate use of > ifqueues and the IF_ and IFQ_ operations on them. in most cases > those ifqueues hav

mpsafe ifqueues

: share/man/man9/ifq_enq.9 diff -N share/man/man9/ifq_enq.9 --- /dev/null 1 Jan 1970 00:00:00 - +++ share/man/man9/ifq_enq.912 Nov 2015 05:50:12 - @@ -0,0 +1,140 @@ +.\" $OpenBSD$ +.\" +.\" Copyright (c) 2015 David Gwynne <d...@openbsd.org> +.\" +.\"

<    3   4   5   6   7   8   9   10   11   >