[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-net
Subject:    Who increments la_numheld?
From:       Edgar =?iso-8859-1?B?RnXf?= <ef () math ! uni-bonn ! de>
Date:       2024-04-23 15:33:28
Message-ID: ZifUyEbi8ZZzwtWq () trav ! math ! uni-bonn ! de
[Download RAW message or body]

Hello,

I'm staring at grep -rF la_numheld sys and nxr.netbsd.org and can't find 
anyone incrementing la_numheld (apart from the old ARP code).

Putting aside the question what (apart from debugging that field's intended 
usage is, lltable_drop_entry_queue() (in sys/net/if_lltabl.c) does:

	pkts_dropped = 0;
	while ((lle->la_numheld > 0) && (lle->la_hold != NULL)) {
		next = lle->la_hold->m_nextpkt;
		m_freem(lle->la_hold);
		lle->la_hold = next;
		lle->la_numheld--;
		pkts_dropped++;
	}

which, as I currently get it, will never do any m_freem() at all.

I must be missing something.  Or anyone using IPv6 (or IPv4 on 10+) should 
suffer from severe mbuf leaks.

Is there some obscure #define using ## or the like that aliases la_numheld 
to something else entirely?  But even then, something in nd[6]_resolve() 
should be incrementing something.

Even the old arpresolve() code looks incorrect if m->m_nextpkt is allowed 
to be non-NULL on entry.
[prev in list] [next in list] [prev in thread] [next in thread]