[ovs-dev] [PATCH] datapath: Revert "datapath: rhel: Account for RHEL specific backports"

Jesse Gross jesse at nicira.com
Tue Jul 16 16:14:37 UTC 2013


On Tue, Jul 16, 2013 at 1:18 AM, Thomas Graf <tgraf at redhat.com> wrote:
> On 07/15/2013 09:54 PM, Jesse Gross wrote:
>>
>> On Mon, Jul 15, 2013 at 12:45 PM, Pravin B Shelar <pshelar at nicira.com>
>> wrote:
>>>
>>> This reverts commit 752378e1cd1f133a8366fbacec3b281a45ff8268
>>> (datapath: rhel: Account for RHEL specific backports).
>>> Change related to netif_needs_gso() is cuasing panic on RHEL
>>> and Xen platforms.  This way we revert back to use of ovs
>>> skb_gso_segment() and netif_skb_features() which has required
>>> compat code for gso for kernel older than 2.6.38.
>>>
>>> <1>[  924.855722] BUG: unable to handle kernel NULL pointer dereference
>>> at 000000a0
>>> <1>[  924.855789] IP: [<f0337fb7>] netdev_send+0x77/0x340 [openvswitch]
>>> <4>[  924.855849] *pdpt = 000000011bc66027 *pde = 0000000000000000
>>> <0>[  924.855895] Oops: 0000 [#1] SMP
>>> <0>[  924.855927] last sysfs file: /sys/class/net/lo/carrier
>>> <4>[  924.856551] Pid: 17937, comm: vif Not tainted
>>> (2.6.32.43-0.4.1.xs1.6.10.734.170748xen #1) VMware Virtual Platform
>>> <4>[  924.856618] EIP: 0061:[<f0337fb7>] EFLAGS: 00010246 CPU: 0
>>> <4>[  924.856659] EIP is at netdev_send+0x77/0x340 [openvswitch]
>>> <4>[  924.856697] EAX: 00000000 EBX: dd4fb800 ECX: 00000000 EDX:
>>> 00000289
>>> <4>[  924.856749] ESI: edd55a40 EDI: 000005dc EBP: df287aa8 ESP:
>>> df287a7c
>>> <4>[  924.856790]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
>>> <0>[  924.856825] Process vif (pid: 17937, ti=df286000 task=ee88d570
>>> task.ti=df286000)
>>> <0>[  924.856880] Stack:
>>> <4>[  924.856902]  00000000 be8b9067 00000000 e9b02000 dd523ac0 dd523b50
>>> f033aef1 b2e77c64
>>> <4>[  924.856966] <0> dd523ac0 ee902840 dd4fc58c df287ab8 f0336162
>>> edd55a40 ee902840 df287ac8
>>> <4>[  924.857043] <0> f032d684 0000001e ee10a300 df287b34 f032d6ef
>>> 0000001c 00000000 00000000
>>> <0>[  924.858942] Call Trace:
>>> <4>[  924.859553]  [<f033aef1>] ? flex_array_get+0x51/0x70 [openvswitch]
>>> <4>[  924.860189]  [<f0336162>] ? ovs_vport_send+0x12/0x50 [openvswitch]
>>> <4>[  924.860806]  [<f032d684>] ? do_output+0x34/0x50 [openvswitch]
>>> <4>[  924.861444]  [<f032d6ef>] ? do_execute_actions+0x4f/0x830
>>> [openvswitch]
>>> <4>[  924.862047]  [<f032dfa0>] ? ovs_execute_actions+0x70/0xd0
>>> [openvswitch]
>>> <4>[  924.862636]  [<f032fd3f>] ?
>>> ovs_dp_process_received_packet+0x8f/0xf0 [openvswitch]
>>> <4>[  924.863774]  [<f033690e>] ? ovs_vport_receive+0x5e/0x70
>>> [openvswitch]
>>> <4>[  924.864354]  [<f0337d9f>] ? netdev_frame_hook+0x4f/0x90
>>> [openvswitch]
>>> <4>[  924.864918]  [<c034f7ab>] ? netif_receive_skb+0x1bb/0x6a0
>>> <4>[  924.865469]  [<c03c193f>] ? vlan_gro_common+0x10f/0x230
>>> <4>[  924.866007]  [<c034fd58>] ? napi_skb_finish+0x38/0x40
>>> <4>[  924.866533]  [<c03c1e86>] ? vlan_gro_receive+0x76/0x80
>>> <4>[  924.867055]  [<f05adba4>] ? e1000_receive_skb+0x74/0x80 [e1000]
>>> <4>[  924.867571]  [<f05b2b67>] ? e1000_clean_rx_irq+0x1f7/0x3e0 [e1000]
>>> <4>[  924.868084]  [<f05b2970>] ? e1000_clean_rx_irq+0x0/0x3e0 [e1000]
>>> <4>[  924.869025]  [<f05b06ac>] ? e1000_poll+0x4c/0x1f0 [e1000]
>>>
>>> --snip--
>>>
>>> Signed-off-by: Pravin B Shelar <pshelar at nicira.com>
>>
>>
>> Thomas, can you also please take a look?
>>
>> I think our backports should be safe on all platforms, even if it the
>> distro has also backported it so it looks OK to me.
>
>
> The ABI will work but it will not be possible to compile 1.11 against
> the RHEL kernel source tree.

This surprises me somewhat because the existing backport uses a
#define to map the function calls in OVS to a newly named replacement
function, so I wouldn't think that there should be a conflict.

> Can you share some details on what version of RHEL the panic has been
> seen? We would like to fix it.

I think it is all versions of RHEL that do not have the backport that
you originally proposed this patch for. The issue is that the function
exists in stock 2.6.32 but with a different prototype. Therefore, your
compatibility check didn't apply the backport on 2.6.32 and a pointer
type was changed.
X-CudaMail-Whitelist-To: dev at openvswitch.org



More information about the dev mailing list