Re: locking against myself, mbuf was already freed

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Sep 30, 2019 at 02:59:19PM +0200, Edgar Fuß wrote:
> Thanks for the quick reply!
> 
> > Isn't there something missing in the stack trace here ?
> I don't think so.
> 
> > I can't see how m_prepend could be called from ipf_fastroute ...
> Maybe the compiler optimized out some function calls?
> 
> In fact, the display looks somewhat weird (I'll send you photographs in 
> private mail):
> <prompt># Kernel RNG "1619 1 1" momobit test FAILURE: 9702 ones
> cpnrg 1619 1 1: failed statistical RNG test
> panic: mbuf was already freed at nd_resolve,2351
> fatal breakpoint trap in suprevisor mode
> trap type 1 code 0 rip 0xffffffff8021ffa5 cs 0x8 rflags 0x246 cr2 0x7a47da76300[DISPLAY CUT-OFF]
>  ilevel 0x4 rsp 0xffff80013ceab990
> curlwp 0xfffffe841de11[VIOLET-ON-WHITE GARBAGE]
> Found: sd0a at 0
> Looking for 1 in autoconfig
> [FOUR-AND-A-HALF MORE LINES OF VIOLET-ON-WHITE GARBAGE]
> [GARBAGE]
> [GARBAGE]
> [GARBAGE]em) at  netbsd:breakpoint+0x05:  leave

that's strange. Maybe it's another effect of the mixed
SPL NOT LOWERED ON TRAP EXIT
that other CPUs print while entering ddb ?

> db{0}> bt
> breakpoint() at netbsd:breakpoint+0x5
> vpanic() at netbsd:vpanic+0x15d
> snprintf() at netbsd:snprintf
> m_prepend() at netbsd:m_prepend
> ipf_fastroute() at netbsd:ipf_fastroute+0x2e9
> ipf_send_ip() at netbsd:ipf_send_ip+0x13d
> ipf_check() at netbsd:ipf_check+0xd1e
> pfil_run_hooks() at netbsd:pfil_run_hooks+0x12f
> ip6_input() at netbsd:ip6_input+0x1ce
> ip6intr() at netbsd:ip6intr+0x87
> softint_dispatch() at netbsd:softint_dispatch+0xeb
> 
> > Ot maybe it's not m_prepend but m_freem.
> No.

I meant, maybe the debugger is wrong ...
If you have netbsd.gdb you can find to what source line
ipf_fastroute+0x2e9
points to

> 
> > Anyway, I guess the attached patch could fix it.
> I don't see anything attached.

Ops, sorry here it is

> 
> > Maybe try to
> > #define FASTROUTE_RECURSION
> > at the top of fil.c ? It looks like this is needed
> I'll give it a try.
> 
> Could my other, former panics/lock-ups because by the same issue?

If you don't have LOCKDEBUG I gues this can cause a lock up, yes.
Also the mbuf freed twice can certainly cause problems

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Index: ip_fil_netbsd.c
===================================================================
RCS file: /cvsroot/src/sys/external/bsd/ipf/netinet/ip_fil_netbsd.c,v
retrieving revision 1.23.2.1
diff -u -p -u -r1.23.2.1 ip_fil_netbsd.c
--- ip_fil_netbsd.c	14 Aug 2017 23:51:14 -0000	1.23.2.1
+++ ip_fil_netbsd.c	30 Sep 2019 11:37:46 -0000
@@ -1490,6 +1490,8 @@ ipf_fastroute6(struct mbuf *m0, struct m
 # else
 			error = nd6_output(ifp, ifp, m0, dst6, rt);
 # endif
+			if (error)
+				*mpp = NULL; /* m0 has been  freed */
 		} else {
 			error = EMSGSIZE;
 		}