lkml.org 
[lkml]   [2011]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: KVM induced panic on 2.6.38[2367] & 2.6.39
    On 07.06.2011 16:40, Brad Campbell wrote:
    > On 07/06/11 21:30, Patrick McHardy wrote:
    >> On 07.06.2011 05:33, Brad Campbell wrote:
    >>> On 07/06/11 04:10, Bart De Schuymer wrote:
    >>>> Hi Brad,
    >>>>
    >>>> This has probably nothing to do with ebtables, so please rmmod in case
    >>>> it's loaded.
    >>>> A few questions I didn't directly see an answer to in the threads I
    >>>> scanned...
    >>>> I'm assuming you actually use the bridging firewall functionality. So,
    >>>> what iptables modules do you use? Can you reduce your iptables rules to
    >>>> a core that triggers the bug?
    >>>> Or does it get triggered even with an empty set of firewall rules?
    >>>> Are you using a stock .35 kernel or is it patched?
    >>>> Is this something I can trigger on a poor guy's laptop or does it
    >>>> require specialized hardware (I'm catching up on qemu/kvm...)?
    >>>
    >>> Not specialised hardware as such, I've just not been able to reproduce
    >>> it outside of this specific operating scenario.
    >>
    >> The last similar problem we've had was related to the 32/64 bit compat
    >> code. Are you running 32 bit userspace on a 64 bit kernel?
    >
    > No, 32 bit Guest OS, but a completely 64 bit userspace on a 64 bit kernel.
    >
    > Userspace is current Debian Stable. Kernel is Vanilla and qemu-kvm is
    > current git
    >
    >
    >>> I can't trigger it with empty firewall rules as it relies on a DNAT to
    >>> occur. If I try it directly to the internal IP address (as I have to
    >>> without netfilter loaded) then of course nothing fails.
    >>>
    >>> It's a pain in the bum as a fault, but it's one I can easily reproduce
    >>> as long as I use the same set of circumstances.
    >>>
    >>> I'll try using 3.0-rc2 (current git) tonight, and if I can reproduce it
    >>> on that then I'll attempt to pare down the IPTABLES rules to a bare
    >>> minimum.
    >>>
    >>> It is nothing to do with ebtables as I don't compile it. I'm not really
    >>> sure about "bridging firewall" functionality. I just use a couple of
    >>> hand coded bash scripts to set the tables up.
    >>
    >> From one of your previous mails:
    >>
    >>> # CONFIG_BRIDGE_NF_EBTABLES is not set
    >>
    >> How about CONFIG_BRIDGE_NETFILTER?
    >>
    >
    > It was compiled in.
    >
    > With the following table set I was able to reproduce the problem on
    > 3.0-rc2. Replaced my IP with xxx.xxx.xxx.xxx, but otherwise unmodified

    Which kernel was the last version without this problem?

    > root@srv:~# iptables-save
    > # Generated by iptables-save v1.4.10 on Tue Jun 7 22:11:30 2011
    > *filter
    > :INPUT ACCEPT [978:107619]
    > :FORWARD ACCEPT [142:7068]
    > :OUTPUT ACCEPT [1659:291870]
    > -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
    > -A INPUT ! -i ppp0 -m state --state NEW -j ACCEPT
    > -A INPUT -i ppp0 -j DROP
    > COMMIT
    > # Completed on Tue Jun 7 22:11:30 2011
    > # Generated by iptables-save v1.4.10 on Tue Jun 7 22:11:30 2011
    > *nat
    > :PREROUTING ACCEPT [813:49170]
    > :INPUT ACCEPT [91:7090]
    > :OUTPUT ACCEPT [267:20731]
    > :POSTROUTING ACCEPT [296:22281]
    > -A PREROUTING -d xxx.xxx.xxx.xxx/32 ! -i ppp0 -p tcp -m tcp --dport 443
    > -j DNAT --to-destination 192.168.253.198
    > COMMIT
    > # Completed on Tue Jun 7 22:11:30 2011
    > # Generated by iptables-save v1.4.10 on Tue Jun 7 22:11:30 2011
    > *mangle
    > :PREROUTING ACCEPT [2729:274392]
    > :INPUT ACCEPT [2508:262976]
    > :FORWARD ACCEPT [142:7068]
    > :OUTPUT ACCEPT [1674:293701]
    > :POSTROUTING ACCEPT [2131:346411]
    > -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss
    > 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
    > COMMIT
    > # Completed on Tue Jun 7 22:11:30 2011

    The main suspects would be NAT and TCPMSS. Did you also try whether
    the crash occurs with only one of these these rules?

    > I've just compiled out CONFIG_BRIDGE_NETFILTER and can no longer access
    > the address the way I was doing it, so that's a no-go for me.

    That's really weird since you're apparently not using any bridge
    netfilter features. It shouldn't have any effect besides changing
    at which point ip_tables is invoked. How are your network devices
    configured (specifically any bridges)?


    \
     
     \ /
      Last update: 2011-06-07 17:37    [W:0.034 / U:63.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site