Date: Thu, 1 Sep 2005 09:54:42 +0200 From: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> To: freebsd-net@freebsd.org Subject: sbspace() / sbappendaddr() problem Message-ID: <20050901075442.GA18666@zen.inc>
next in thread | raw e-mail | index | archive | help
Hi all. I have some reccurent problems with PFKey interafce for a while, whith ENOBUFS errors. While tracking down the problem, I found that a test goes wrong in sbappendaddr(), in kern_uipc_socket2.c, because the "space" variable (an int) gets "bigger" than the result of sbspace(sb), which shlould not happen. After having a deeper look at sbspace() macro, I noticed that there are some potential cast/sign problems with this macro (this is specified in the comments of the macro). So I wrote a new version of the macro, which should avoir all problems: #define sbspace(sb) \ (ulmin( ( (sb)->sb_hiwat > (sb)->sb_cc ? (sb)->sb_hiwat - (sb)->sb_cc : 0), \ (sb)->sb_mbmax > (sb)->sb_mbcnt ? (sb)->sb_mbmax - (sb)->sb_mbcnt : 0))) Then I set up the type of "space" variable in sbappendaddr() as u_long, and I have no more problems for now. But as this function and this macro are used on some other parts of the kernel, I don't know if I solved all problems, or if I generated new problems elsewhere while solving one. Does someone have any comments on this new sbspace() ? Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050901075442.GA18666>