Date: Wed, 23 Jun 2010 17:08:38 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-stable@FreeBSD.org Cc: d@delphij.net, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e Message-ID: <201006231708.40032.jkim@FreeBSD.org> In-Reply-To: <201006231538.27887.jkim@FreeBSD.org> References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <201006231510.50863.jkim@FreeBSD.org> <201006231538.27887.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-00=_XfnIM7O4aHYDEjI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote: > 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/fil > > > > >es /A tt > > > > > ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=te > > > > >xt %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. ;-) I found that Python guys added 'k' format since 2.3, which converts a Python integer to unsigned long. Please ignore the previous patch and try the attached patch instead. Cheers, Jung-uk Kim --Boundary-00=_XfnIM7O4aHYDEjI Content-Type: text/plain; charset="iso-8859-1"; name="patch-Modules-fcntlmodule.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-Modules-fcntlmodule.c" --- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.000000000 -0400 +++ Modules/fcntlmodule.c 2010-06-23 16:56:10.000000000 -0400 @@ -97,6 +97,13 @@ { #define IOCTL_BUFSZ 1024 int fd; +#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \ + defined(__OpenBSD__) +#define IOCTL_ULONG 1 +#endif +#ifdef IOCTL_ULONG + unsigned long code; +#else /* 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 @@ -105,12 +112,9 @@ 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; +#endif int arg; int ret; char *str; @@ -118,7 +122,11 @@ int mutate_arg = 1; char buf[IOCTL_BUFSZ+1]; /* argument plus NUL byte */ +#ifdef IOCTL_ULONG + if (PyArg_ParseTuple(args, "O&kw#|i:ioctl", +#else if (PyArg_ParseTuple(args, "O&Iw#|i:ioctl", +#endif conv_descriptor, &fd, &code, &str, &len, &mutate_arg)) { char *arg; @@ -169,7 +177,11 @@ } PyErr_Clear(); +#ifdef IOCTL_ULONG + if (PyArg_ParseTuple(args, "O&ks#:ioctl", +#else if (PyArg_ParseTuple(args, "O&Is#:ioctl", +#endif conv_descriptor, &fd, &code, &str, &len)) { if (len > IOCTL_BUFSZ) { PyErr_SetString(PyExc_ValueError, @@ -191,7 +203,11 @@ PyErr_Clear(); arg = 0; if (!PyArg_ParseTuple(args, +#ifdef IOCTL_ULONG + "O&k|i;ioctl requires a file or file descriptor," +#else "O&I|i;ioctl requires a file or file descriptor," +#endif " an integer and optionally an integer or buffer argument", conv_descriptor, &fd, &code, &arg)) { return NULL; @@ -209,6 +225,7 @@ } return PyInt_FromLong((long)ret); #undef IOCTL_BUFSZ +#undef IOCTL_ULONG } PyDoc_STRVAR(ioctl_doc, --Boundary-00=_XfnIM7O4aHYDEjI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201006231708.40032.jkim>