Bug 630129 - [RHEL5 IA64 XEN] netfront driver: alloc_dev: Private data too big.
Summary: [RHEL5 IA64 XEN] netfront driver: alloc_dev: Private data too big.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.6
Hardware: ia64
OS: Linux
urgent
medium
Target Milestone: rc
: ---
Assignee: Neil Horman
QA Contact: Boris Ranto
URL:
Whiteboard:
Depends On:
Blocks: 630163 637219 637220
TreeView+ depends on / blocked
 
Reported: 2010-09-03 18:44 UTC by Jarod Wilson
Modified: 2011-01-13 21:15 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Recently applied patch introduced a bug, which caused the Xen guest networking not to work properly on 64-bit Itanium processors. However, this bug also revealed an issue, which may have led to a data corruption. With this update, both errors have been fixed, and Xen virtual guest networking now works as expected.
Clone Of:
: 630163 (view as bug list)
Environment:
Last Closed: 2011-01-13 21:15:40 UTC


Attachments (Terms of Use)
utested patch (7.82 KB, patch)
2010-09-03 20:12 UTC, Neil Horman
no flags Details | Diff
tested patch (7.91 KB, patch)
2010-09-08 20:46 UTC, Neil Horman
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0017 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.6 kernel security and bug fix update 2011-01-13 10:37:42 UTC

Description Jarod Wilson 2010-09-03 18:44:18 UTC
Description of problem:
Since the inclusion of the patch for bug 620508, ia64 xen guest networking fails to function. However, this is probably a good thing, since it would appears that its historically been silently corrupting data.

Version-Release number of selected component (if applicable):
2.6.18-215.el5xen.ia64

How reproducible:
Install ia64 xen guest, update to 2.6.18-215.el5xen

Log snippets from 214 and 215 kernels:

Sep  3 12:55:05 dhcp71-32 kernel: Linux version 2.6.18-214.el5xen (mockbuild@bullwinkle.build.redhat.com) (gcc version 4.1.2        20080704 (Red Hat 4.1.2-48)) #1 SMP Fri Aug 27 18:15:55 EDT 2010
...
Sep  3 12:55:09 dhcp71-32 kernel: netfront: Initialising virtual ethernet driver.
Sep  3 12:55:09 dhcp71-32 kernel: netfront: device eth0 has flipping receive path.


Sep  3 13:57:19 dhcp71-32 kernel: Linux version 2.6.18-215.el5.testxen (root@altix3.rhts.eng.bos.redhat.com) (gcc version 4.1.2    20080704 (Red Hat 4.1.2-48)) #1 SMP Fri Sep 3 12:17:32 EDT 2010
...
Sep  3 13:57:24 dhcp71-32 kernel: netfront: Initialising virtual ethernet driver.
Sep  3 13:57:24 dhcp71-32 kernel: alloc_dev: Private data too big.
Sep  3 13:57:24 dhcp71-32 kernel: create_netdev> alloc_etherdev failed.
Sep  3 13:57:24 dhcp71-32 kernel: vif vif-0: 12 creating netdev
Sep  3 13:57:24 dhcp71-32 kernel: vif vif-0: 12 xenbus_dev_probe on device/vif/0

Comment 1 Jarod Wilson 2010-09-03 18:51:05 UTC
Adding Drew to the cc list so he's aware of this one too.

Comment 2 Jarod Wilson 2010-09-03 18:52:16 UTC
Since its a data corruptor, its likely we're going to want it for z-stream as well, so also adding z-stream folks to cc list.

Comment 3 Neil Horman 2010-09-03 20:12:45 UTC
Created attachment 442975 [details]
utested patch

Still need to test it, but heres my first pass at a patch to fix this.  Basically just allocate a wrapper struct as the netdev_private data, which contains a pointer to the separately allocated netfront_info struct that is more than 65kb long.  Should do the trick.  Will test it out ASAP.

Comment 5 RHEL Product and Program Management 2010-09-03 20:59:11 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 6 Jerome Marchand 2010-09-08 15:19:31 UTC
(In reply to comment #3)
> Created attachment 442975 [details]
> utested patch
> 
> Still need to test it, but heres my first pass at a patch to fix this. 
> Basically just allocate a wrapper struct as the netdev_private data, which
> contains a pointer to the separately allocated netfront_info struct that is
> more than 65kb long.  Should do the trick.  Will test it out ASAP.

Your patch should set err = -ENOMEM. The ERR_PTR() cast is already made when we return from the function.
Actually, since the only error it can return is -ENOMEM, we can get rid of err variable and ERR_PTR(-ENOMEM) all the time.

Comment 7 Neil Horman 2010-09-08 20:46:21 UTC
Created attachment 446082 [details]
tested patch

heres a version of the patch that I've tested and validated, and a brew build of it.  I'll post it shortly

http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2750022

Comment 10 Jarod Wilson 2010-09-10 21:41:21 UTC
in kernel-2.6.18-219.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

Comment 15 Jaromir Hradilek 2010-10-12 22:51:42 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Recently applied patch introduced a bug, which caused the Xen guest networking not to work properly on 64-bit Itanium processors. However, this bug also revealed an issue, which may have led to a data corruption. With this update, both errors have been fixed, and Xen virtual guest networking now works as expected.

Comment 18 errata-xmlrpc 2011-01-13 21:15:40 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0017.html


Note You need to log in before you can comment on or make changes to this bug.