Date: Thu, 08 Aug 2002 10:03:44 +0900 From: SUZUKI Shinsuke <suz@kame.net> To: Don Lewis <dl-freebsd@catspoiler.org> Cc: jhay@icomtek.csir.co.za, hsu@FreeBSD.org, ume@FreeBSD.org, core@kame.net, current@FreeBSD.org Subject: Re: CFR - patch for TCPv6 accept lock violation bug Message-ID: <x7r8hakvpr.wl@s30.crl.hitachi.co.jp> In-Reply-To: <200208062316.g76NG3wr091139@gw.catspoiler.org> References: <200208062316.g76NG3wr091139@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Don, >>>>> On Tue, 6 Aug 2002 16:16:03 -0700 (PDT) >>>>> dl-freebsd@catspoiler.org(Don Lewis) said: > FreeBSD -current detects a lock violation in the IPv6 TCP accept code in > tcp6_usr_accept() caused by calling in6_mapped_peeraddr(), which calls > MALLOC() which may block, while a lock is being held. Instead of taking > the same approach to solve this problem as was done in tcp_usr_accept(), > which would result in a lot of duplicated code, it looks like a better > solution is to make a local copy of the address and port information > before dropping the lock, and then perform all the potentially blocking > operations after the lock as been dropped. Generally I agree with your patch, but please give me some time for a complete review. > If this same approach is used in other places where in_setsockaddr(), > in_setpeeraddr(), in6_setsockaddr(), and in6_setpeeraddr() are called, > then we can replace a bunch of duplicated code with calls to a few new > functions that accept the address and port information and convert it to > the sockaddr structure. > > I've still got a couple of questions, though. > > Why don't in6_setpeeraddr() and in6_setsockaddr() handle the IPv4 > mapping done in in6_mapped_peeraddr() and in6_mapped_sockaddr()? If > they did, we wouldn't need the latter routines. I don't see any reason > to have both sets of routines. I checked the KAME CVS repository, but they were like this from the first commit... I'll ask the original committer directly, and answer you. > Can the INP_IPV4 flag ever be set in the tcp6_usr_accept() case? If > not, the expanded code in tcp6_usr_accept() could be simplified. It is possible, so it has to be considered in some manner. (e.g. allows v6->v4 mapping using IPv4-mapped address and bind() to IPv4-mapped address) > The function prototypes in in_pcb.h and in6_pcb.h don't seem to be > sorted in any consistent order. With regard to these files, KAME has no problem for changing the order, since these files are specific to FreeBSD and don't need to consider other BSDs. So could you please tell me what is the appropriate order? (or just some consistency is enough?) (I read style(9), but couldn't find the rule for this.) Thanks, ---- SUZUKI, Shinsuke @ KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x7r8hakvpr.wl>