From owner-freebsd-bugs@FreeBSD.ORG Fri Mar 18 19:10:06 2005 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A359B16A4DC for ; Fri, 18 Mar 2005 19:10:06 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A20843D1F for ; Fri, 18 Mar 2005 19:10:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j2IJA6Kc096827 for ; Fri, 18 Mar 2005 19:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j2IJA675096826; Fri, 18 Mar 2005 19:10:06 GMT (envelope-from gnats) Date: Fri, 18 Mar 2005 19:10:06 GMT Message-Id: <200503181910.j2IJA675096826@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Dan Nelson Subject: Re: kern/78664: truss does not work on 5-STABLE(5.4-PRERELEASE) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dan Nelson List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 19:10:06 -0000 The following reply was made to PR kern/78664; it has been noted by GNATS. From: Dan Nelson To: freebsd-gnats-submit@FreeBSD.org, hashiz@tomba.cskk-sv.co.jp, jeffr@FreeBSD.org Cc: Subject: Re: kern/78664: truss does not work on 5-STABLE(5.4-PRERELEASE) Date: Fri, 18 Mar 2005 13:08:01 -0600 In the last episode (Mar 17), Dan Nelson said: > HASHI Hiroaki wrote: > > truss command does not work with below message. > > > > "truss: PIOCBIS: Inappropriate ioctl for device" > > I've narrowed it down to something committed between 02-24 and 02-27, > but can't continue the binary search until tonight. It would be > really nice if this was fixed before 5.4 gets released :) Jeff, it looks like your fdesc-locking MFC inadvertantly broke the PIOCBIS ioctl. Craig Rodrigues' analysis at http://lists.freebsd.org/pipermail/freebsd-current/2004-November/043647.html looks accurate: the extra argument checking in kern/sys_generic.c:ioctl() is failing on a 0-byte IOC_IN ioctl that really should have used _IO(). A quick grep shows some misuse in the other direction. All the ioctls in aac_ioctl.h are _IO(), but many take struct* arguments and should have been _IOR or _IOW. Since the ioctl definition itself is consistent though, it would still pass the checks. I didn't see any ioctls (besides the pioctl.h ones) that would fail the checks, but since you can't guarantee that 3rd-party drivers aren't doing the same thing with private ioctls of their own, I think removing the size checks completely (maybe sending a kernel printf saying "this will fail on 6.x" on first occurance or something) is the best solution. Index: sys_generic.c =================================================================== RCS file: /home/ncvs/src/sys/kern/sys_generic.c,v retrieving revision 1.132.2.3 diff -u -r1.132.2.3 sys_generic.c --- sys_generic.c 27 Feb 2005 02:42:55 -0000 1.132.2.3 +++ sys_generic.c 18 Mar 2005 18:32:53 -0000 @@ -500,9 +503,7 @@ */ size = IOCPARM_LEN(com); if ((size > IOCPARM_MAX) || - ((com & (IOC_VOID | IOC_IN | IOC_OUT)) == 0) || - ((com & IOC_VOID) && size > 0) || - ((com & (IOC_IN | IOC_OUT)) && size == 0)) { + ((com & (IOC_VOID | IOC_IN | IOC_OUT)) == 0)) { fdrop(fp, td); return (ENOTTY); } -- Dan Nelson dnelson@allantgroup.com