From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 13:46:15 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E29A9106566B; Mon, 11 Apr 2011 13:46:15 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 810A28FC21; Mon, 11 Apr 2011 13:46:15 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p3BDk6HA006833 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 11 Apr 2011 09:46:06 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4DA3060C.6090901@sentex.net> Date: Mon, 11 Apr 2011 09:45:48 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gleb Smirnoff References: <4D947756.6050808@freebsd.lublin.pl> <4D9F6C71.1040209@frasunek.com> <4DA171BA.9000507@frasunek.com> <4DA1E39C.9090300@rdtc.ru> <4DA23090.8060206@frasunek.com> <20110411054932.GU84445@FreeBSD.org> In-Reply-To: <20110411054932.GU84445@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Przemyslaw Frasunek , Eugene Grosbein Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 13:46:16 -0000 On 4/11/2011 1:49 AM, Gleb Smirnoff wrote: > On Mon, Apr 11, 2011 at 12:34:56AM +0200, Przemyslaw Frasunek wrote: > P> > Use command "vmstat -z|egrep 'ITEM|NetGraph'" and check FAILURES column. > P> > If you see non-zero values there, you need to increase netgraph memory limits > P> > net.graph.maxdata and net.graph.maxalloc using /boot/loader.conf. > P> > P> Unfortunately, increasing net.graph.maxdata & net.graph.maxalloc didn't > P> solved EPERM problems on netgraph control sockets. It is still appearing > P> every few hours, but failure counters are zero: > > IMO, any kind of memory allocation code (malloc, uma, netgraph item > allocator) never return EPERM, they return ENOMEM or ENOBUFS. > > So, there is a bug somewhere else. I am also running with the following patch from mlaier that is not in RELENG_8. --- rtsock.c 2010-10-30 07:54:55.000000000 -0400 +++ /tmp/rtsock.c 2011-04-11 09:44:52.000000000 -0400 @@ -27,7 +27,7 @@ * SUCH DAMAGE. * * @(#)rtsock.c 8.7 (Berkeley) 10/12/95 - * $FreeBSD: src/sys/net/rtsock.c,v 1.181.2.10 2010/10/30 11:54:55 bz Exp $ + * $FreeBSD: src/sys/net/rtsock.c,v 1.191 2011/02/10 01:24:09 mlaier Exp $ */ #include "opt_compat.h" #include "opt_sctp.h" @@ -159,7 +159,7 @@ struct rt_metrics_lite *out); static void rt_getmetrics(const struct rt_metrics_lite *in, struct rt_metrics *out); -static void rt_dispatch(struct mbuf *, const struct sockaddr *); +static void rt_dispatch(struct mbuf *, sa_family_t); static struct netisr_handler rtsock_nh = { .nh_name = "rtsock", @@ -513,6 +513,7 @@ int len, error = 0; struct ifnet *ifp = NULL; union sockaddr_union saun; + sa_family_t saf = AF_MAX; #define senderr(e) { error = e; goto flush;} if (m == NULL || ((m->m_len < sizeof(long)) && @@ -549,6 +550,7 @@ (info.rti_info[RTAX_GATEWAY] != NULL && info.rti_info[RTAX_GATEWAY]->sa_family >= AF_MAX)) senderr(EINVAL); + saf = info.rti_info[RTAX_DST]->sa_family; /* * Verify that the caller has the appropriate privilege; RTM_GET * is the only operation the non-superuser is allowed. @@ -883,7 +885,6 @@ m = NULL; } else if (m->m_pkthdr.len > rtm->rtm_msglen) m_adj(m, rtm->rtm_msglen - m->m_pkthdr.len); - Free(rtm); } if (m) { if (rp) { @@ -893,11 +894,14 @@ */ unsigned short family = rp->rcb_proto.sp_family; rp->rcb_proto.sp_family = 0; - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, saf); rp->rcb_proto.sp_family = family; } else - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, saf); } + /* info.rti_info[RTAX_DST] (used above) can point inside of rtm */ + if (rtm) + Free(rtm); } return (error); #undef sa_equal @@ -1140,7 +1144,7 @@ rtm->rtm_flags = RTF_DONE | flags; rtm->rtm_errno = error; rtm->rtm_addrs = rtinfo->rti_addrs; - rt_dispatch(m, sa); + rt_dispatch(m, sa ? sa->sa_family : AF_MAX); } /* @@ -1165,7 +1169,7 @@ ifm->ifm_flags = ifp->if_flags | ifp->if_drv_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; - rt_dispatch(m, NULL); + rt_dispatch(m, AF_MAX); } /* @@ -1235,7 +1239,7 @@ rtm->rtm_errno = error; rtm->rtm_addrs = info.rti_addrs; } - rt_dispatch(m, sa); + rt_dispatch(m, sa ? sa->sa_family : AF_MAX); } } @@ -1271,7 +1275,7 @@ __func__)); ifmam->ifmam_index = ifp->if_index; ifmam->ifmam_addrs = info.rti_addrs; - rt_dispatch(m, ifma->ifma_addr); + rt_dispatch(m, ifma->ifma_addr ? ifma->ifma_addr->sa_family : AF_MAX); } static struct mbuf * @@ -1331,7 +1335,7 @@ if (m->m_flags & M_PKTHDR) m->m_pkthdr.len += data_len; mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len; - rt_dispatch(m, NULL); + rt_dispatch(m, AF_MAX); } } @@ -1347,11 +1351,11 @@ m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info); if (m != NULL) - rt_dispatch(m, NULL); + rt_dispatch(m, AF_MAX); } static void -rt_dispatch(struct mbuf *m, const struct sockaddr *sa) +rt_dispatch(struct mbuf *m, sa_family_t saf) { struct m_tag *tag; @@ -1360,14 +1364,14 @@ * use when injecting the mbuf into the routing socket buffer from * the netisr. */ - if (sa != NULL) { + if (saf != AF_MAX) { tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short), M_NOWAIT); if (tag == NULL) { m_freem(m); return; } - *(unsigned short *)(tag + 1) = sa->sa_family; + *(unsigned short *)(tag + 1) = saf; m_tag_prepend(m, tag); } #ifdef VIMAGE ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/