Bug 822072 - fcntl.ioctl() caused an OverflowError: signed integer is greater than maximum
fcntl.ioctl() caused an OverflowError: signed integer is greater than maximum
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: python (Show other bugs)
5.8
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Dave Malcolm
Petr Šplíchal
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-16 05:19 EDT by yunpingzheng
Modified: 2016-05-31 21:43 EDT (History)
11 users (show)

See Also:
Fixed In Version: python-2.4.3-55.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-08 02:22:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace info of ethtool (4.10 KB, application/octet-stream)
2012-05-16 05:19 EDT, yunpingzheng
no flags Details

  None (edit)
Description yunpingzheng 2012-05-16 05:19:09 EDT
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 05:19:52 EDT
Created attachment 584913 [details]
strace info of ethtool
Comment 2 Ronen Hod 2012-05-21 12:59:21 EDT
Hi Yunping,

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

Thanks, Ronen.
Comment 3 Amos Kong 2012-05-21 23:47:06 EDT
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 01:28:36 EDT
when i run it using rhel6 host and 5.8 guest ,it ok
Comment 5 Amos Kong 2012-05-30 22:12:37 EDT
(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-30 22:18:59 EDT
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 02:21:28 EDT
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 05:24:24 EDT
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 10:25:43 EDT
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 10:37:39 EDT
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 12:09:36 EDT
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 12:11:30 EDT
(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 09:26:25 EDT
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 02:22:58 EST
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.