From owner-freebsd-usb@FreeBSD.ORG Tue May 10 01:10:05 2005 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D486C16A4EB for ; Tue, 10 May 2005 01:10:05 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE02143D7B for ; Tue, 10 May 2005 01:10:05 +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 j4A1A56r018604 for ; Tue, 10 May 2005 01:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4A1A50q018603; Tue, 10 May 2005 01:10:05 GMT (envelope-from gnats) Date: Tue, 10 May 2005 01:10:05 GMT Message-Id: <200505100110.j4A1A50q018603@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Ian Dowse Subject: Re: usb/80829: possible panic when loading USB-modules X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ian Dowse List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2005 01:10:05 -0000 The following reply was made to PR usb/80829; it has been noted by GNATS. From: Ian Dowse To: hselasky@c2i.net Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: usb/80829: possible panic when loading USB-modules Date: Tue, 10 May 2005 02:07:20 +0100 In message <200505091849.15420.hselasky@c2i.net>, Hans Petter Selasky writes: > >There is a special mechanism where probe/attach can clear an entry in the >array pointed to by "uaa->ifaces". The existing USB-driver allocates the >"uaa" in memory, but the "uaa->ifaces" is still on the stack ! This is going >to cause a panic for some devices when loaded as a module. > >usbd_status >usbd_probe_and_attach(device_ptr_t parent, usbd_device_handle dev, > int port, int addr) > >... > usbd_interface_handle ifaces[256]; /* 256 is the absolute max */ > >... > uaa.ifaces = ifaces; Hi, Is there actually problem with any current usage of uaa.ifaces? I can see that the pointer to the ifaces[] array on the stack can get stored in the malloc'd `uaap' structure, but I couldn't see anywhere that actually references the ifaces[] array after usbd_probe_and_attach() returns - I'm probably missing something simple though. If nothing needs to use uaap->ifaces[] then I guess just setting it to NULL at the end of usbd_probe_and_attach() would make it clear that it is no longer valid? If there is some case where the stack array is referenced after usbd_probe_and_attach() returns, then it would be very helpful if you could post a quick description of how that can happen. Thanks, Ian