FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e

[Jung-uk Kim]

On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
> On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
> > On 2010/06/23 11:37, Jung-uk Kim wrote:
> > > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
> > >> Hi,
> > >>
> > >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
> > >>> Hi,
> > >>>
> > >>> 	I am getting more than 4 thousand of the following messages
> > >>> a day:
> > >>>
> > >>> WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
> > >>> ffffffff8004667e
> > >>
> > >> [...]
> > >>
> > >> I think we may need to check the code and patch it.  Basically
> > >> this means that python (or some .so modules) passed an int or
> > >> unsigned int as parameter 'cmd', we need to change it  to
> > >> unsigned long.
> > >>
> > >> The warning itself should be harmless to my best of knowledge,
> > >> one can probably remove the printf in kernel source code as a
> > >> workaround.
> > >>
> > >> By the way it seems to be a POSIX violation and we didn't seem
> > >> to really use so wide cmd, but I have not yet verified
> > >> everything myself.
> > >
> > > Long time ago, I had a similar problem with termios TIOCGWINSZ
> > > and we patched the port like this:
> > >
> > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/A
> > >tt
> > > ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2
> > >Fpl ain
> > >
> > > I believe it was upstream patched at the time but I won't be
> > > surprised if something similar was reintroduced.  It happens
> > > when a Python internal integer type is converted to a native
> > > unsigned long.
> >
> > Well, only *BSD have cmd a long value so it's likely that it
> > would be reintroduced.
>
> Yes, that's what I mean.
>
> > I have checked the 4.4BSD archive and understood that our ioctl's
> > cmd parameter was made long around 1991 or 1992s but didn't see
> > what it actually buy us...
>
> Like it or not, it is too late to revert. :-(

From Python 2.6.5:

static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
	int fd;
	/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
	   format for the 'code' parameter because Python turns 0x8000000
	   into either a large positive number (PyLong or PyInt on 64-bit
	   platforms) or a negative number on others (32-bit PyInt)
	   whereas the system expects it to be a 32bit bit field value
	   regardless of it being passed as an int or unsigned long on
	   various platforms.  See the termios.TIOCSWINSZ constant across
	   platforms for an example of thise.

	   If any of the 64bit platforms ever decide to use more than 32bits
	   in their unsigned long ioctl codes this will break and need
	   special casing based on the platform being built on.
	 */
	unsigned int code;
...

It is still a kludge and it won't be fixed. :-(

Jung-uk Kim