From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759209Ab1FHAPU (ORCPT ); Tue, 7 Jun 2011 20:15:20 -0400 Received: from fnarfbargle.com ([93.93.131.224]:52570 "EHLO fnarfbargle.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754303Ab1FHAPS (ORCPT ); Tue, 7 Jun 2011 20:15:18 -0400 Message-ID: <4DEEBF0F.1070902@fnarfbargle.com> Date: Wed, 08 Jun 2011 08:15:11 +0800 From: Brad Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bart De Schuymer CC: Patrick McHardy , kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org Subject: Re: KVM induced panic on 2.6.38[2367] & 2.6.39 References: <20110601011527.GN19505@random.random> <4DE5DCA8.7070704@fnarfbargle.com> <4DE5E29E.7080009@redhat.com> <4DE60669.9050606@fnarfbargle.com> <4DE60918.3010008@redhat.com> <4DE60940.1070107@redhat.com> <4DE61A2B.7000008@fnarfbargle.com> <20110601111841.GB3956@zip.com.au> <4DE62801.9080804@fnarfbargle.com> <20110601230342.GC3956@zip.com.au> <4DE8E3ED.7080004@fnarfbargle.com> <4DE906C0.6060901@fnarfbargle.com> <4DED344D.7000005@pandora.be> <4DED9C23.2030408@fnarfbargle.com> <4DEE27DE.7060004@trash.net> <4DEE3859.6070808@fnarfbargle.com> <4DEE6815.7040504@pandora.be> In-Reply-To: <4DEE6815.7040504@pandora.be> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/06/11 02:04, Bart De Schuymer wrote: > If the bug is easily triggered with your guest os, then you could try to > capture the traffic with wireshark (or something else) in a > configuration that doesn't crash your system. Save the traffic in a pcap > file. Then you can see if resending that traffic in the vulnerable > configuration triggers the bug (I don't know if something in Windows > exists, but tcpreplay should work for Linux). Once you have such a > capture , chances are the bug is even easily reproducible by us (unless > it's hardware-specific). Success isn't guaranteed, but I think it's > worth a shot... The issue with this is I don't have a configuration that does not crash the system. This only happens under the specific circumstance that traffic from VM A is being DNAT'd to VM B. If I disable CONFIG_BRIDGE_NETFILTER, or I leave out the DNAT then I can't replicate the problem as I don't seem to be able to get the packets to go where I want them to go. Let me try and explain it a little more clearly with made up IP addresses to illustrate the problem. I have VM A (1.1.1.2) and VM B (1.1.1.3) on br1 (1.1.1.1) I have public IP on ppp0 (2.2.2.2). VM B can talk to VM A using its host address (1.1.1.2) and there is no problem. The DNAT says anything destined for PPP0 that is on port 443 and coming from anywhere other than PPP0 (ie inside the network) is to be DNAT'd to 1.1.1.3. So VM B (1.1.1.3) tries to connect to ppp0 (2.2.2.2) on port 443, and this is redirected to VM B on 1.1.1.2. Only under this specific circumstance does the problem occur. I can get VM B (1.1.1.3) to talk directly to VM A (1.1.1.2) all day long and there is no problem, it's only when VM B tries to talk to ppp0 that there is an issue (and it happens within seconds of the initial connection). All these tests have been performed with VM B being a Windows XP guest. Tonight I'll try it with a Linux guest and see if I can make it happen. If that works I might be able to come up with some reproducible test case for you. I have a desktop machine that has Intel VT extensions, so I'll work toward making a portable test case. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brad Campbell Subject: Re: KVM induced panic on 2.6.38[2367] & 2.6.39 Date: Wed, 08 Jun 2011 08:15:11 +0800 Message-ID: <4DEEBF0F.1070902@fnarfbargle.com> References: <20110601011527.GN19505@random.random> <4DE5DCA8.7070704@fnarfbargle.com> <4DE5E29E.7080009@redhat.com> <4DE60669.9050606@fnarfbargle.com> <4DE60918.3010008@redhat.com> <4DE60940.1070107@redhat.com> <4DE61A2B.7000008@fnarfbargle.com> <20110601111841.GB3956@zip.com.au> <4DE62801.9080804@fnarfbargle.com> <20110601230342.GC3956@zip.com.au> <4DE8E3ED.7080004@fnarfbargle.com> <4DE906C0.6060901@fnarfbargle.com> <4DED344D.7000005@pandora.be> <4DED9C23.2030408@fnarfbargle.com> <4DEE27DE.7060004@trash.net> <4DEE3859.6070808@fnarfbargle.com> <4DEE6815.7040504@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Patrick McHardy , kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org To: Bart De Schuymer Return-path: In-Reply-To: <4DEE6815.7040504@pandora.be> Sender: owner-linux-mm@kvack.org List-Id: netdev.vger.kernel.org On 08/06/11 02:04, Bart De Schuymer wrote: > If the bug is easily triggered with your guest os, then you could try to > capture the traffic with wireshark (or something else) in a > configuration that doesn't crash your system. Save the traffic in a pcap > file. Then you can see if resending that traffic in the vulnerable > configuration triggers the bug (I don't know if something in Windows > exists, but tcpreplay should work for Linux). Once you have such a > capture , chances are the bug is even easily reproducible by us (unless > it's hardware-specific). Success isn't guaranteed, but I think it's > worth a shot... The issue with this is I don't have a configuration that does not crash the system. This only happens under the specific circumstance that traffic from VM A is being DNAT'd to VM B. If I disable CONFIG_BRIDGE_NETFILTER, or I leave out the DNAT then I can't replicate the problem as I don't seem to be able to get the packets to go where I want them to go. Let me try and explain it a little more clearly with made up IP addresses to illustrate the problem. I have VM A (1.1.1.2) and VM B (1.1.1.3) on br1 (1.1.1.1) I have public IP on ppp0 (2.2.2.2). VM B can talk to VM A using its host address (1.1.1.2) and there is no problem. The DNAT says anything destined for PPP0 that is on port 443 and coming from anywhere other than PPP0 (ie inside the network) is to be DNAT'd to 1.1.1.3. So VM B (1.1.1.3) tries to connect to ppp0 (2.2.2.2) on port 443, and this is redirected to VM B on 1.1.1.2. Only under this specific circumstance does the problem occur. I can get VM B (1.1.1.3) to talk directly to VM A (1.1.1.2) all day long and there is no problem, it's only when VM B tries to talk to ppp0 that there is an issue (and it happens within seconds of the initial connection). All these tests have been performed with VM B being a Windows XP guest. Tonight I'll try it with a Linux guest and see if I can make it happen. If that works I might be able to come up with some reproducible test case for you. I have a desktop machine that has Intel VT extensions, so I'll work toward making a portable test case. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org