ok.
> On 28 Mar 2018, at 10:07, Jonathan Matthew wrote:
>
> Reading through if_pppx.c I spotted a couple of places we need NET_LOCK().
>
> ok?
>
> Index: if_pppx.c
> ===
> RCS file: /cvs/src/sys/net/if_pppx.c,v
> retrieving revisi
Reading through if_pppx.c I spotted a couple of places we need NET_LOCK().
ok?
Index: if_pppx.c
===
RCS file: /cvs/src/sys/net/if_pppx.c,v
retrieving revision 1.63
diff -u -p -u -p -r1.63 if_pppx.c
--- if_pppx.c 12 Aug 2017 20:27:2
On 20/12/16(Tue) 19:51, Alexander Bluhm wrote:
> [...]
> The sosplice thread is only used for TCP. UDP runs in the softnet
> thread. As we are reading 64 bit values, we need some sort of
> locking. Now everything is in the kernel lock, but when we start
> working to unlock the socket layer, be
On Tue, Dec 20, 2016 at 01:55:03PM +0100, Martin Pieuchot wrote:
> rzalamena@ found that the IPv4 multicast code have two code paths ending
> in ip_output() that are not yet taking the NET_LOCK: sosetopt() and
> pffasttimo().
I see this also on my regress test machine.
splassert: ip_output: want
rzalamena@ found that the IPv4 multicast code have two code paths ending
in ip_output() that are not yet taking the NET_LOCK: sosetopt() and
pffasttimo().
Diff below fixes that and include pfslowtimo() as well as sogetopt() for
completeness.
While here remove a superfluous splsoftnet() which does
