Re: question about mbuf intialization

[christos%astron.com@localhost (Christos Zoulas)]

In article <52475DB8.2070308%netbsd.org@localhost>,
Darren Reed  <darrenr%netbsd.org@localhost> wrote:
>On 27/09/2013 12:41 AM, Christos Zoulas wrote:
>> I've been looking at the code and it seems to me that not only m_get() 
>> needs to be changed, but also m_getcl() and MCLGET(). In essence, none 
>> of the allocators currently set m_len or m_pkthdr.len, and they leave 
>> it to the packet formation routines to do so. I am not against setting 
>> the length to 0 by default on construction to make things more robust 
>> (I don't think it makes any performance difference these days); I am 
>> just mentioning that if we do that we should fix it consistently (if 
>> anyone can call the mbuf API consistent...) christos 
>
>The correct argument to me would appear to be that since the mbufs
>contain no data in them when returned by m_get() that the length
>fields should read as "0" in order to reflect that (if they don't already.)

I agree and this is what Beverly is proposing. The latest unix
socket bug of returning random trash in the sockaddr of accept call
from a closed unix socket that has issued a connect proves just
that: mbufs that have just been created should contain no data
(m_len == 0); otherwise they will end up containing junk from their
previous pool use and this can lead to random bugs. I am planning
to initialize m_len and m_pkthdr.len to zero in the constructors
in the next couple of days and move the extra assignments unless
I hear otherwise. We already initialize most other fields in the
mbuf, so the performance loss claims don't really make sense.

christos