Date: Mon, 11 Apr 2011 10:16:41 -0400 From: Mike Tancsa <mike@sentex.net> To: Brandon Gooch <jamesbrandongooch@gmail.com> Cc: freebsd-net@freebsd.org, Max Laier <max.laier@isilon.com>, Przemyslaw Frasunek <przemyslaw@frasunek.com>, Eugene Grosbein <egrosbein@rdtc.ru> Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 Message-ID: <4DA30D49.5080909@sentex.net> In-Reply-To: <BANLkTimU8Fwso2XHpK3mkdY-k-zeeghVsg@mail.gmail.com> 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> <4DA3060C.6090901@sentex.net> <BANLkTimU8Fwso2XHpK3mkdY-k-zeeghVsg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/11/2011 10:05 AM, Brandon Gooch wrote:
> 2011/4/11 Mike Tancsa <mike@sentex.net>:
>> 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 $
>> */
>
> So it's in HEAD? If so, any ideas about a possible MFC?
I dont think all of it is. Here is the diff from HEAD. Adding Max
Laier to the cc list as he was the one kind enough to send me the patch.
--- rtsock.c 2011-02-14 20:43:05.000000000 -0500
+++ /tmp/rtsock.c 2011-04-11 09:44:52.000000000 -0400
@@ -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.
@@ -892,10 +894,10 @@
*/
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)
@@ -1142,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);
}
/*
@@ -1167,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);
}
/*
@@ -1237,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);
}
}
@@ -1273,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 *
@@ -1333,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);
}
}
@@ -1349,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;
@@ -1362,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 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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DA30D49.5080909>