From owner-freebsd-bugs@FreeBSD.ORG Fri Aug 10 06:30:03 2007 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72C6916A417 for ; Fri, 10 Aug 2007 06:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 527AE13C494 for ; Fri, 10 Aug 2007 06:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7A6U3Nm086764 for ; Fri, 10 Aug 2007 06:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7A6U3rD086762; Fri, 10 Aug 2007 06:30:03 GMT (envelope-from gnats) Resent-Date: Fri, 10 Aug 2007 06:30:03 GMT Resent-Message-Id: <200708100630.l7A6U3rD086762@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Arthur Hartwig Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E2F216A41B for ; Fri, 10 Aug 2007 06:21:46 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 1D78713C442 for ; Fri, 10 Aug 2007 06:21:46 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l7A6LjOu078623 for ; Fri, 10 Aug 2007 06:21:45 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.1/8.14.1/Submit) id l7A6Ljps078622; Fri, 10 Aug 2007 06:21:45 GMT (envelope-from nobody) Message-Id: <200708100621.l7A6Ljps078622@www.freebsd.org> Date: Fri, 10 Aug 2007 06:21:45 GMT From: Arthur Hartwig To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/115371: Device removal leaves resource database such that "devinfo -r" causes panic X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2007 06:30:03 -0000 >Number: 115371 >Category: kern >Synopsis: Device removal leaves resource database such that "devinfo -r" causes panic >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 10 06:30:02 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Arthur Hartwig >Release: 7.0 >Organization: Nokia >Environment: >Description: I have been working on a private implementation of a "PCI hotplug" like device replacement. On device removal and subsequent freeing of resources the kernel resource database is left in a state such that the shell command "devinfo -r" or the ddb command??? can cause a panic. Analysis: Resources are allocated by calling rman_reserve_resource_bound() in kern/subr_rman.c which stores a pointer to the "requesting" device in the r_dev field of the device structure and marks the resource as allocated by setting RF_ALLOCATED in the r_flags field. When the resource is freed, int_rman_release_resource() is called which clears the RF_ALLOCATED flag in the resource structure but does not clear the r_dev field in the resource structure. The devinfo -r command causes sysctl_rman() to be called. sysctl_ramn() walks the resource list and assumes any resource with a non-null r_dev field has a pointer to a valid device structure but if the device structure has been freed the device_get_name(res->r_dev) call may generate a page fault and panic. There is a similar issue in dump_rman() in the same file. >How-To-Repeat: It may be possible to create a panic by removing a cardbus device and then issuing devinfo -r. Use of the kernel debugging mechanism to fill free malloc storage with 0xdeadcode is likely to increase the likelihood of seeing the problem. >Fix: Suggested fix: Clear the r_dev field of the resource structure when the RF_ALLOCATED flag is cleared: in int_rman_release_resource() change: r->r_flags &= ~RF_ALLOCATED; return 0; to r->r_flags &= ~RF_ALLOCATED; r->r_dev = NULL; return 0; >Release-Note: >Audit-Trail: >Unformatted: