libnl - netlink library: Memory leak in address cache?
Hello Thomas and all, sorry for bothering you if this is the wrong place. The following tiny program leaks memory: #define _GNU_SOURCE #include sys/socket.h #include arpa/inet.h #include stdio.h #include netlink-local.h #include netlink/route/addr.h static void nl_addr_cb (struct nl_object *obj, void *userdata) { struct rtnl_addr *addr = (struct rtnl_addr *)obj; char buf[100]; char buf2[100]; extern char *if_indextoname(unsigned ifindex, char *ifname); printf (interface %s addr: %s\n, if_indextoname(rtnl_addr_get_ifindex (addr), buf2), inet_ntop(rtnl_addr_get_family (addr), rtnl_addr_get_local (addr)-a_addr, buf, sizeof (buf))); } int main(int argc, char *argv[]) { struct nl_handle *nlh; struct nl_cache *addr_cache; struct rtnl_addr *addr; int err = 1; extern unsigned if_nametoindex(const char *ifname); nlh = nl_handle_alloc(); if (!nlh) return -1; addr = rtnl_addr_alloc(); if (!addr) goto errout; if (nl_connect(nlh, NETLINK_ROUTE) 0) goto errout_free; addr_cache = rtnl_addr_alloc_cache(nlh); if (!addr_cache) goto errout_close; rtnl_addr_set_ifindex(addr, if_nametoindex(eth0)); nl_cache_foreach_filter(addr_cache, (struct nl_object *)addr, nl_addr_cb, NULL); err = 0; nl_cache_free(addr_cache); errout_close: nl_close(nlh); errout_free: rtnl_addr_put(addr); errout: return err; } The valgrind output: ==29411== 528 (96 direct, 432 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 8 ==29411==at 0x402095F: calloc (vg_replace_malloc.c:279) ==29411==by 0x403D938: nl_object_alloc (object.c:49) ==29411==by 0x404233F: rtnl_addr_alloc (addr.c:627) ==29411==by 0x404236B: addr_msg_parser (addr.c:194) ==29411==by 0x4037B7D: nl_cache_parse (cache.c:615) ==29411==by 0x4037CB6: update_msg_parser (cache.c:438) ==29411==by 0x403CD00: nl_recvmsgs (netlink-local.h:335) ==29411==by 0x4038238: __cache_pickup (cache.c:461) ==29411==by 0x40382F6: nl_cache_pickup (cache.c:494) ==29411==by 0x40386AF: nl_cache_refill (cache.c:671) ==29411==by 0x40422D0: rtnl_addr_alloc_cache (addr.c:650) ==29411==by 0x80489DA: main (in /home_crypt/pommnitz/himonn/HiMoNN-1.3-IPv6/xx/nltest/main) I think the leak comes from addr_msg_parser. The newly created address object gets added to the cache with nl_cache_add wich takes a reference, so the reference in addr_msg_parser should be dropped, e.g. the following patch might be correct: --- ../../COMMON/libnl/lib/route/addr.c (revision 1380) +++ ../../COMMON/libnl/lib/route/addr.c (working copy) @@ -288,7 +288,7 @@ if (err 0) goto errout_free; - return P_ACCEPT; + // return P_ACCEPT; errout_free: rtnl_addr_put(addr); -- Kind regards Joerg Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Does tc-prio really work as advertised?
Jarek, iptables chains (this is what I think you are referring to) are not the issue. This is about the qdisc that sits immediately over the device driver and decides the order waiting packets are sent over the line/air/carrier pigeon/... . My suspicion is that skb-priority used to be set to a value that derived from the TOS bits. Then something changed and nobody noticed. -- Regards Joerg - Ursprüngliche Mail Von: Jarek Poplawski [EMAIL PROTECTED] An: Jarek Poplawski [EMAIL PROTECTED] CC: Joerg Pommnitz [EMAIL PROTECTED]; netdev@vger.kernel.org; OLSR discussion and development [EMAIL PROTECTED] Gesendet: Dienstag, den 27. November 2007, 07:46:04 Uhr Betreff: Re: Does tc-prio really work as advertised? On 26-11-2007 23:25, Jarek Poplawski wrote: ... Are you doing this on the same box? I was tracing this long time ago too, and, if I didn't miss something, it was about the place! So, as I recall (after finding some old message) this TOS is considered only for packets going through the FORWARD chain. (But, I haven't checked this at all now, so no complaints...) ...Too exactly! Iptables aren't needed for this, so going through the forward. should be enough... Jarek P. Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: Does tc-prio really work as advertised?
Jarek, this is all about outgoing packets, e.g. egress to use your word. It doesn't matter whether the packets are originated locally or whether the packets are forwarded from another host (I tried both). To restate the problem: according to my observations the prio qdisc (and probably pfifo_fast, but I couldn't observe this) does not prioritize at all and always uses the band indicated by the first entry in the priomap. By default the priomap looks like this: qdisc prio 1: dev eth1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 there are 3 bands (1:1, 1:2 and 1:3). In theory the traffic should go through the different bands according to the TOS value of the packets. My observation is, that the traffic always uses the band pointed to by the first entry in the priomap. This value is 1 by default, so all traffic goes through band 1:2. Now it's entirely possible that I did something stupid, but nobody came forward to show me the error of my ways (neither here nor on the lartc list). -- Regards Joerg - Ursprüngliche Mail Von: Jarek Poplawski [EMAIL PROTECTED] An: Joerg Pommnitz [EMAIL PROTECTED] CC: netdev@vger.kernel.org Gesendet: Dienstag, den 27. November 2007, 10:58:38 Uhr Betreff: Re: Does tc-prio really work as advertised? On Tue, Nov 27, 2007 at 01:28:43AM -0800, Joerg Pommnitz wrote: Jarek, iptables chains (this is what I think you are referring to) are not the issue. Yes, but this could (wrongly) look like this according to my 1-st message. This is about the qdisc that sits immediately over the device driver and decides the order waiting packets are sent over the line/air/carrier pigeon/... . My suspicion is that skb-priority used to be set to a value that derived from the TOS bits. Then something changed and nobody noticed. I'm not sure of your problem: did you try this on a box which gets packets with TOS set earlier, does forwarding, and uses this prio on egress? If so, and this doesn't work, then you are right something could be wrong. Regards, Jarek P. __ Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern. www.yahoo.de/clever - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: Does tc-prio really work as advertised?
It works fine here, I'm guessing that Jörg is using an old kernel version that had a bug in prio classification without filters. This is 2.6.20.21, from 17-Oct-2007. -- Regards Joerg __ Ihre erste Baustelle? Wissenswertes für Bastler und Hobby Handwerker. www.yahoo.de/clever - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: Does tc-prio really work as advertised?
So, are you still sure you've tested such a case? Well, the problem that triggered my investigation was that the OLSR daemon (www.olsr.org) calculates the quality of a link according to the packet loss for LQ HELLO packets (UDP broadcast packets). To prevent other traffic from interfering with the LQ calculation, olsrd sends the HELLO packets with a TOS value of 0x10 (minimize delay). This should give them the highest priority. What I saw was a degrading Link quality with more user traffic over a link. The LQ fell so far that olsrd judged the other host unreachable and deleted the routing entry. The user traffic in question was iperf (TOS value 0x00). The OLSR traffic was obviously generated locally (not forwarded). You claim, that the TOS value for locally generated traffic does not influence its priority? Now I THINK that I did my tests both, for forwarded and for local traffic, but I'll redo my tests to make sure. -- Regards and thanks for taking an interest Joerg __ Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern. www.yahoo.de/clever - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Does tc-prio really work as advertised?
Great :-(. I went over the ChangeLogs for later kernel versions, but couldn't find anything. I'll try to come up with a working .config for the most current kernel that works on my hardware and test again. Do you have a pointer to the fix so that I could try to patch a 2.6.20 kernel? -- Regards Joerg - Ursprüngliche Mail Von: Patrick McHardy [EMAIL PROTECTED] An: Joerg Pommnitz [EMAIL PROTECTED] CC: Jarek Poplawski [EMAIL PROTECTED]; netdev@vger.kernel.org Gesendet: Dienstag, den 27. November 2007, 13:54:11 Uhr Betreff: Re: AW: Does tc-prio really work as advertised? Joerg Pommnitz wrote: It works fine here, I'm guessing that Jörg is using an old kernel version that had a bug in prio classification without filters. This is 2.6.20.21, from 17-Oct-2007. Yes, that version is broken. I think it was fixed in 2.6.22 or 2.6.23. Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Does tc-prio really work as advertised?
Hello all, I might make a fool out of me, but I think the prio qdisc doesn't work as advertised in any document I could lay my hands on. My problem was that the link quality reported by the olsr.org olsrd degraded depending on the amount of payload traffic transferred through an adhoc/mesh interface. The LQ is calculated from the packet loss of LQ Hello packets sent through this interface. To make sure normal traffic does not interfere with this value, olsrd sets the TOS field to 0x10 (Minimize-Delay) by default. This should give olsr traffic the highest priority on the link. Investigating this issue I replaced the default Pfifo_fast with a prio qdisc and attached a pfifo on each of the bands: INTERFACE=wifi0 tc qdisc add dev $INTERFACE root handle 1: prio tc qdisc add dev $INTERFACE parent 1:1 handle 10: pfifo tc qdisc add dev $INTERFACE parent 1:2 handle 20: pfifo tc qdisc add dev $INTERFACE parent 1:3 handle 30: pfifo The I used ping -Q TOSVALUE to send packets with different TOS values through the interface. tcpdump confirmed the correct TOS values in the outgoing packets. With tc -s qdisc ls dev wifi0 I could observe the effects of the different TOS values. The result: no effect at all! Every single packet used the band indicated by the first value in the priomap (e.g. band 1 by default, in my case the pfifo with handle 20:). I can't square this observation with the available documentation. Looking at the source code, it seems that sched_prio uses the skb-priority value to select the outgoing band. According to some documentation I found, an application can set this value. Now I'm at a loss. I can work around this problem with filters, but I don't think that this is the correct solution. Any suggestions? Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
IPsec with aes-cbc and geode-aes driver completely freezes 2.6.20.1
Hello all, the subject line basically says it all. I was trying to offload IPsec encryption to the hardware encryption engine on my Geode LX800. The exact same setkey command works fine with software aes. In case it matters: this is with a MSEP800/A board from DIGITAL-LOGIC AG (see http://www.digitallogic.com/english/products/catalog07/epic_detail.asp?id=MSEP800_L). Did anybody ever succeed with Geode hardware accelerated IPsec? Did you have to do anything special? -- Regards Joerg ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html