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

[Jung-uk Kim]

On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
> 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. :-(

Please drop the attached patch in ports/lang/python26/files and test.  
Note I am not a Python guy, so please don't shoot me. ;-)

Thanks,

Jung-uk Kim
-------------- next part --------------
--- Modules/fcntlmodule.c.orig	2009-05-24 11:41:43.000000000 -0400
+++ Modules/fcntlmodule.c	2010-06-23 15:27:42.000000000 -0400
@@ -110,7 +110,12 @@
 	   in their unsigned long ioctl codes this will break and need
 	   special casing based on the platform being built on.
 	 */
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
+    defined(__OpenBSD__)
+	unsigned long code;
+#else
 	unsigned int code;
+#endif
 	int arg;
 	int ret;
 	char *str;