Commit Graph

4 Commits

Author SHA1 Message Date
Joel Sherrill
3fb7680513 2002-10-04 Jay Monkman <jtm@smoothsmoothie.com>
* netinet/in_cksum.c, netinet/ip_icmp.h, netinet/ip_input.c,
	netinet/tcp_input.c, netinet/tcp_subr.c, netinet/tcp_var.h,
	sys/queue.h: Address alignment requirements for the ARM.
2002-10-04 14:47:11 +00:00
Joel Sherrill
8379ada798 Patch from Eric Norum <eric@cls.usask.ca> to address the following problem
report from Philip A. Prindeville <philipp@zembu.com>:

        I was working on a device driver for a certain ethernet chipset that
    occassionally wraps in its buffer, and causes a resulting mbuf chain
    with only a few dozen bytes in the first mbuf of the chain.

        I wouldn't have thought this would be a problem, until I ran some
    stress tests that flooded the ethernet receiver with packets and
    started to get panics here:

       250
       251          if (m->m_pkthdr.len < sizeof(struct ip))
       252                  goto tooshort;
       253
       254  #ifdef  DIAGNOSTIC
       255          if (m->m_len < sizeof(struct ip))
       256                  panic("ipintr mbuf too short");
       257  #endif
       258
       259          if (m->m_len < sizeof (struct ip) &&
       260              (m = m_pullup(m, sizeof (struct ip))) == 0) {
       261                  ipstat.ips_toosmall++;
       262                  return;
       263          }
       264          ip = mtod(m, struct ip *);

    and the panic was at line 256.  But if I #undef'd DIAGNOSTICS,
    then the m_pullup() at line 260 does the right thing and the packet
    ends up being processed just fine.

    So I started wondering, (a) why was the test checking for
    something that apparently wasn't a fatal condition but rather
    one that is subsequently recovered from a couple of lines later
    and (b) why panic as a diagnostic "aid" from a recoverable
    condition rather than just (say) log a message to the console?

    All of this seems overly severe for no reason that is readily
    apparent to me.
1999-10-25 16:09:45 +00:00
Joel Sherrill
33679ec46e All warnings removed. 1998-08-21 13:04:55 +00:00
Joel Sherrill
39e6e65a2c Base files 1998-08-19 21:32:28 +00:00