Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 822072 - fcntl.ioctl() caused an OverflowError: signed integer is greater than maximum
Summary: fcntl.ioctl() caused an OverflowError: signed integer is greater than maximum
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: python
Version: 5.8
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Dave Malcolm
QA Contact: Petr Šplíchal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-16 09:19 UTC by yunpingzheng
Modified: 2016-06-01 01:43 UTC (History)
11 users (show)

Fixed In Version: python-2.4.3-55.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-08 07:22:58 UTC
Target Upstream Version:


Attachments (Terms of Use)
strace info of ethtool (deleted)
2012-05-16 09:19 UTC, yunpingzheng
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0045 normal SHIPPED_LIVE python bug fix and enhancement update 2013-01-07 15:28:13 UTC

Description yunpingzheng 2012-05-16 09:19:09 UTC
Description of problem:
boot the guest using  Specific network parameters(If the tap was created using the fd=XX   by kvm-autotest csripts)network can not work normally. If the tap was created by the qemu-ifup-switch script, everything is ok.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.boot a guest using kvm-autotest ,create the tap using fd=XX

2. run ethtool -K eth0 tx on
3.
  
Actual results:
tx not on 

Expected results:

tx on 
Additional info:
guest info:
rhel 5.8

host info
rhel 5.8 

boot command:
 /root/autotest/client/tests/kvm/qemu -name 'vm1' -monitor unix:'/tmp/monitor-humanmonitor1-20120515-165709-wJhS',server,nowait -serial unix:'/tmp/serial-20120515-165709-wJhS',server,nowait -drive file='/root/autotest/client/tests/kvm/images/RHEL-Server-6.2-64-virtio.qcow2',index=0,if=virtio,media=disk,cache=none,boot=on,format=qcow2 -net nic,vlan=0,model=virtio,macaddr='9a:92:1f:1f:09:43' -net tap,vlan=0,script=/root/qemu-ifup -m 4096 -smp 4,cores=2,threads=1,sockets=2 -cpu 'qemu64' -soundhw ac97 -vnc :0 -rtc-td-hack -M rhel5.6.0 -boot c   -no-kvm-pit-reinjection -usbdevice tablet

when using autotest:
-net nic,vlan=0,model=virtio,macaddr='9a:92:1f:1f:09:43' -net tap,vlan=0,fd=19 

strace  ethtool info see the attachment.

Comment 1 yunpingzheng 2012-05-16 09:19:52 UTC
Created attachment 584913 [details]
strace info of ethtool

Comment 2 Ronen Hod 2012-05-21 16:59:21 UTC
Hi Yunping,

Please make sure that it works well for RHEL6.3.

Thanks, Ronen.

Comment 3 Amos Kong 2012-05-22 03:47:06 UTC
Yunping, 

Can you help to check if libvirt created VM works?
If it works, then autotest bridge/tap setup exists problem.

Comment 4 yunpingzheng 2012-05-22 05:28:36 UTC
when i run it using rhel6 host and 5.8 guest ,it ok

Comment 5 Amos Kong 2012-05-31 02:12:37 UTC
(In reply to comment #4)
> when i run it using rhel6 host and 5.8 guest ,it ok

What's the result of using libvirt & 5.8 guest & 5.8 host?

Comment 6 RHEL Product and Program Management 2012-05-31 02:18:59 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 7 yunpingzheng 2012-05-31 06:21:28 UTC
the result of using libvirt & 5.8 guest & 5.8 host: PASS

[root@localhost ~]# ps aux | grep qemu
root     16997 49.1  4.6 2331568 371964 ?      Sl   13:58   0:48 /usr/libexec/qemu-kvm -S -M rhel5.4.0 -m 2048 -smp 4,sockets=4,cores=1,threads=1 -name linux -uuid ed92d913-e1ab-ad93-5ce3-e84596bf5fad -monitor unix:/var/lib/libvirt/qemu/linux.monitor,server,nowait -no-kvm-pit-reinjection -no-reboot -boot nc -drive file=/var/lib/libvirt/images/linux-1.img,if=virtio,boot=on,format=raw,cache=none -net nic,macaddr=54:52:00:30:6f:77,vlan=0,model=virtio -net tap,fd=21,vlan=0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us -vga cirrus -balloon virtio

[root@localhost ~]# brctl show
bridge name	bridge id		STP enabled	interfaces
switch		8000.d4bed98eb973	no		vnet0
							eth0
virbr0		8000.000000000000	yes		

 Test Result:
[root@localhost ~]# ethtool  -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off
[root@localhost ~]# ethtool  -K eth0 tx off
[root@localhost ~]# ethtool  -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off
[root@localhost ~]# ethtool  -K eth0 tx on
[root@localhost ~]# ethtool  -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off

Comment 8 yunpingzheng 2012-06-07 09:24:24 UTC
host using 5.8 ,guest using 6.2,6.3 and 5.8 all of the guest os have this problem.

Comment 9 Amos Kong 2012-06-07 14:25:43 UTC
Autotest setup tap device by fcntl.ioctl()

In 5.8 host, an exception will be raised:
   OverflowError: signed integer is greater than maximum

https://github.com/autotest/autotest/blob/43118bf82af9d6bf5927e77472607af5e0d1302f/client/virt/virt_utils.py

def vnet_hdr_probe(tapfd):
    """
    Check if the IFF_VNET_HDR is support by tun.

    @param tapfd: the file descriptor of /dev/net/tun
    """
    u = struct.pack("I", 0)
    try:
        r = fcntl.ioctl(tapfd, TUNGETFEATURES, u)

^^^^ problem exists here (only in python-2.4.3-46.el5)

    except OverflowError:
        return False
    flags = struct.unpack("I", r)[0]
    if flags & IFF_VNET_HDR:
        return True
    else:
        return False

It seems a bug of python, after upgrading the python in host 5.8 to Python-2.6.6, problem could not be reproduced.

   77  wget http://..../Python-2.6.6.tar.bz2
   78  tar xjf Python-2.6.6.tar.bz2
   79  ./configure --prefix=/usr/local --exec-prefix=/usr/local
   81  cd Python-2.6.6
   82  ./configure --prefix=/usr/local --exec-prefix=/usr/local
   84  make -j 10
   85  make install
   86  ln -sf /usr/local/bin/python /usr/bin/python


So change the Component to 'python'.

Comment 11 RHEL Product and Program Management 2012-06-07 14:37:39 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 12 Dave Malcolm 2012-06-07 16:09:36 UTC
fcnt.ioctl is implemented in Python-2.4.3/Modules/fcntlmodule.c: fcntl_ioctl

The exception OverflowError: "signed integer is greater than maximum" comes from Python-2.4.3/Python/getargs.c:convertsimple when handling the "i" format code within PyArg_ParseTuple, presumably within
    PyArg_ParseTuple(args, "O&iw#|i:ioctl",
within fcnt_ioctl.

This exception occurs when the object being parsed in for the code is to be coerced to a C "int".  It is initially successfully coerced to a C long, but it is a larger integer value than C's INT_MAX and thus can't be stored into a C "int".

This is TUNGETFEATURES, which I see is initialized in https://github.com/autotest/autotest/blob/43118bf82af9d6bf5927e77472607af5e0d1302f/client/virt/virt_utils.py like this:
if ARCH == "ppc64":
    # From linux/include/linux/if_tun.h
    TUNGETFEATURES = 0x400454cf
else:
    # From linux/include/linux/if_tun.h
    TUNGETFEATURES = 0x800454cf

What I believe is happening is that the "else" clause has been run, and that TUNGETFEATURES is 0x800454cf, which is too large to fit in a C int on this platform, leading to the exception.

Looking at "man ioctl", I see that ioctl *does* expect a C "int" as the request code, whereas /usr/include/sys/ioctl.h says that it's a "unsigned long int".

fcntl_ioctl  was changed to use the "I" parsing code, which treats it as an "unsigned int" (before casting back to "int"), in these commits:
  http://hg.python.org/cpython/rev/7099f6e68183
  http://hg.python.org/cpython/rev/1774fe7ec0c7
This was:
  http://bugs.python.org/issue1231069

Subsequently http://bugs.python.org/issue1471 changed Python 2.5 onwards to use a C "unsigned int" for the ioctl request code.

Hence Python 2.6 works for ioctl codes >= 0x80000000, whereas our Python 2.4.3 doesn't on 32-bit archs.

Comment 13 Dave Malcolm 2012-06-07 16:11:30 UTC
(In reply to comment #12)
> Subsequently http://bugs.python.org/issue1471 changed Python 2.5 onwards to
> use a C "unsigned int" for the ioctl request code.
Note to self: this latter commit was http://hg.python.org/cpython/rev/1c24a09acb97

Comment 15 Lucas Meneghel Rodrigues 2012-06-08 13:26:25 UTC
Amos, Yunpin:

I see Amos has sent a patch that adds a debug statement to capture and log when that problem happens. It is OK, I guess we could alternatively catch the overflow, verify the currently running python version and if it's 2.4, then just return True, logging that a workaround had to be applied due to a bug in that python implementation.

Comment 22 errata-xmlrpc 2013-01-08 07:22:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0045.html


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