netdev - Re: one more... iproute commands lockup whole system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4613A9F6.8000307@trash.net>
Date:	Wed, 04 Apr 2007 15:36:54 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	hadi@...erus.ca
CC:	Denys <denys@...p.net.lb>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev@...r.kernel.org
Subject: Re: one more... iproute commands lockup whole system

jamal wrote:
> On Wed, 2007-04-04 at 05:11 +0300, Denys wrote:
> 
>>I think this highly useful feature given by jamal, difficult to be avoided 
>>from crash, if user not enough experienced in networking(like me). I guess 
>>packet can be even not ipv4/ipv6 packet, maybe it can be cloned IPX or ARP, 
>>so TTL field cannot be used.


We have a loop counter (RTTL) in tc_verd. For some reason it is reset
after ing_filter though.

> I checked maybe sk_buff have some fields, seems 
>>also bad luck, if there can be something like "internal" counter for packet, 
>>how much times it got redirected, it will help. 
> 
> 
> Adding a field in the skb that keeps track of things would work well,
> but would be a controvesial thing to do because it actually requires a
> vector not just one field. There is a filed called cb[] but it cant be
> used in this case because every time we redirect it could be trampled.


It would be interesting to find out what the problem is exactly.
The configuration itself looks harmless, so I'm guessing its
rather a deadlock than a loop.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html