On Mon, Jun 19, 2017 at 03:53:21PM +0200, Martin Pieuchot wrote:
> New version including a fix for kqueue filters.
OK bluhm@
> Index: kern/uipc_socket.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.186
On 09/06/17(Fri) 15:54, Martin Pieuchot wrote:
> On 09/06/17(Fri) 00:32, Alexander Bluhm wrote:
> > On Tue, Jun 06, 2017 at 05:15:40PM +0200, Martin Pieuchot wrote:
> > > TCP/UDP are almost ready to run without KERNEL_LOCK() because accesses
> > > to their sockets are serialized via the
On Fri, Jun 09, 2017 at 03:54:04PM +0200, Martin Pieuchot wrote:
> Updated diff:
>
> - use a clever trick in sorflush() to make the new assert happy.
Perhaps a bit too clever. On my amd64 struct socket has nearly 400
bytes. That may be too much for our kernel stack.
> - convert
On 09/06/17(Fri) 00:32, Alexander Bluhm wrote:
> On Tue, Jun 06, 2017 at 05:15:40PM +0200, Martin Pieuchot wrote:
> > TCP/UDP are almost ready to run without KERNEL_LOCK() because accesses
> > to their sockets are serialized via the NET_LOCK(). On the other hand
> > pfkey and routing sockets
On Tue, Jun 06, 2017 at 05:15:40PM +0200, Martin Pieuchot wrote:
> TCP/UDP are almost ready to run without KERNEL_LOCK() because accesses
> to their sockets are serialized via the NET_LOCK(). On the other hand
> pfkey and routing sockets accesses still rely on the KERNEL_LOCK().
>
> Since we're
On Tue, Jun 06, 2017 at 05:15:40PM +0200, Martin Pieuchot wrote:
> TCP/UDP are almost ready to run without KERNEL_LOCK() because accesses
> to their sockets are serialized via the NET_LOCK(). On the other hand
> pfkey and routing sockets accesses still rely on the KERNEL_LOCK().
>
> Since we're
TCP/UDP are almost ready to run without KERNEL_LOCK() because accesses
to their sockets are serialized via the NET_LOCK(). On the other hand
pfkey and routing sockets accesses still rely on the KERNEL_LOCK().
Since we're going to work at the socket layer, first to remove the
KERNEL_LOCK() from