Re: [PATCH] fixes of tcp_hostcache.c

From: Andre Oppermann (andre_at_freebsd.org)
Date: 12/02/03

  • Next message: Bruce Evans: "Re: System hangs solid with ATAPICAM" 
    Date: Tue, 02 Dec 2003 14:06:12 +0100
To: taku@cent.saitama-u.ac.jp

    > Greetings,
    >
    > I found two calls of bcopy() in tcp_hostcache.c got the source and the
    > destination pointer wrongly.
    > # Perhaps the author got confused with memcpy(), I guess.

    Indeed. Originally these were memcpy calls and I've been asked to change
    them to bcopy calls. Which I did. It didn't occur to me that bcopy would
    change the destination from left-hand to right-hand argument... But that
    seems to be a common pitfall. :/

    > The fix is attached as a patch against tcp_hostcache.c as of revision 1.2.
    >
    > Please review and incorporate the patch to the tree because the bug makes
    > hostcache useless with TCPv6 and/or brings TTCP (RFC1644) meaningless.
    > Especially the bug renders it unusable to use TCPv6 and TTCP together.
    > # To confirm this: sysctl net.inet.tcp.rfc1644=1; telnet ::1

    This also fixes the problem Hajimu-san is seeing with pathmtu discovery
    which I thought to reside in ip6_getpmtu().

    Thank you for catching the bug! 

    -- 
Andre
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Bruce Evans: "Re: System hangs solid with ATAPICAM"

    Relevant Pages

    • removing bcopy... because its half broken
      ... Nothing in the kernel is using bcopy right know, and that is a good thing. ... the userspace standard bcopyis basically a memmove() with a weird ... explicit memcpy() and memmoveare prefered anyway ... -void bcopy ...
      (Linux-Kernel)
    • Re: libitery directory in gcc-3.1.1 source code package
      ... >programmer calls memcpywith two overlaped memory blocks, ... I feel that this implementation of memcpy() is too = ... I believe the "definition" of bcopy() (which is not ANSI C, ... >memcpydoes when processing large memory blocks, ...
      (comp.lang.c)
    • Re: strcpy() - dangerous? [Was Re: gets() - dangerous?]
      ... but my system does not provide a bcopy() function... ... bcopy, whose existence, as I understand it, pre-dates memmove or memcpy, ... Prev by Date: ...
      (comp.lang.c)