From amdmi3@mail.ru  Thu Dec  1 05:28:41 2005
Return-Path: <amdmi3@mail.ru>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id A5F1116A420
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  1 Dec 2005 05:28:41 +0000 (GMT)
	(envelope-from amdmi3@mail.ru)
Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D8FF243DA8
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  1 Dec 2005 05:28:15 +0000 (GMT)
	(envelope-from amdmi3@mail.ru)
Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121])
	by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 327CA4821BB
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 30 Nov 2005 16:46:28 +0300 (MSK)
Received: from [213.148.29.33] (port=2812 helo=nexii.panopticon)
	by mx1.mail.ru with esmtp 
	id 1EhSHt-000Nbi-00
	for FreeBSD-gnats-submit@freebsd.org; Wed, 30 Nov 2005 16:46:21 +0300
Received: from hades.panopticon (hades.panopticon [192.168.0.2])
	by nexii.panopticon (Postfix) with ESMTP id B9BD7311D
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 30 Nov 2005 16:50:44 +0300 (MSK)
Received: by hades.panopticon (Postfix, from userid 1000)
	id 922371145; Wed, 30 Nov 2005 16:49:55 +0300 (MSK)
Message-Id: <20051130134955.922371145@hades.panopticon>
Date: Wed, 30 Nov 2005 16:49:55 +0300 (MSK)
From: Dmitry Marakasov <amdmi3@mail.ru>
Reply-To: Dmitry Marakasov <amdmi3@mail.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: 6.0-RELEASE panics when applying `type devtype' rule to devfs
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         89784
>Category:       kern
>Synopsis:       [devfs] [patch] 6.0-RELEASE panics when applying `type devtype' rule to devfs [regression]
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kib
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 01 05:30:07 GMT 2005
>Closed-Date:    Fri May 16 15:31:24 UTC 2008
>Last-Modified:  Fri May 16 15:31:24 UTC 2008
>Originator:     Dmitry Marakasov
>Release:        FreeBSD 6.0-RELEASE i386
>Organization:
>Environment:
System: FreeBSD hades.panopticon 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Nov 23 05:48:39 MSK 2005 amdmi3@hades.panopticon:/usr/obj/usr/src/sys/HADES i386

>Description:
When applying rules, which match device type (i.e. `rule apply type devtype'),
to devfs mountpoint, kernel panic occurs.

The panic:
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc04c3124
stack pointer           = 0x28:0xd0c5aaf0
frame pointer           = 0x28:0xd0c5ab04
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 575 (devfs)


The backtrace (I've said `panic' in ddb, so 1-11 is debugger's frames):
...
#11 0xc067067a in calltrap () at /usr/src/sys/i386/i386/exception.s:139

#12 0xc04c3124 in devfs_rule_match (dk=0xc1701e00, de=0xc1751100)
    at /usr/src/sys/fs/devfs/devfs_rule.c:544
#13 0xc04c3201 in devfs_rule_run (dk=0xc1701e00, de=0xc1751100, depth=1)
    at /usr/src/sys/fs/devfs/devfs_rule.c:586
#14 0xc04c2df7 in devfs_rule_applyde_recursive (dk=0xc1701e00, de=0xc1751100)
    at /usr/src/sys/fs/devfs/devfs_rule.c:341
#15 0xc04c2ddb in devfs_rule_applyde_recursive (dk=0xc1701e00, de=0xc18b0280)
    at /usr/src/sys/fs/devfs/devfs_rule.c:340
#16 0xc04c2e1a in devfs_rule_applydm (dk=0x0, dm=0x0) at /usr/src/sys/fs/devfs/devfs_rule.c:351
#17 0xc04c2bd2 in devfs_rules_ioctl (dm=0xc18b0300, cmd=3245350400, data=0xc1701d00 "z\b\n", td=0x0)
    at /usr/src/sys/fs/devfs/devfs_rule.c:220
...


Panic happens when executing this code (devfs_rule.c:543):

if (dr->dr_icond & DRC_DSWFLAGS)
        if (dev == NULL ||
            (dev->si_devsw->d_flags & dr->dr_dswflags) == 0)
                return (0);

reading dev->si_devsw->d_flags value is the problem, because dev->si_devsw
can be a null pointer sometimes (in case of symlinks and directories, as far
as I understand).

In my case, that was `urandom' entry, which is a symlink and doesn't have
cdevsw.

Here's what dev is in my case:

{
        si_priv = 0xc155c300,
        si_flags = 22,
        si_atime = {
        tv_sec = 0,
        tv_nsec = 0
        },
        si_ctime = {
                tv_sec = 0,
                tv_nsec = 0
        },
        si_mtime = {
                tv_sec = 0,
                tv_nsec = 0
        },
        si_uid = 0,
        si_gid = 0,
        si_mode = 0,
        si_cred = 0x0,
        si_drv0 = 0,
        si_refcount = 1,
        si_list = {
                le_next = 0x0,
                le_prev = 0x0
        },
        si_clone = {
                le_next = 0x0,
                le_prev = 0x0
        },
        si_children = {
                lh_first = 0x0
        },
        si_siblings = {
                le_next = 0x0,
                le_prev = 0xc155c448
        },
        si_parent = 0xc155c400,
        si_name = 0xc155c378 "urandom",
        si_drv1 = 0x0,
        si_drv2 = 0x0,
        si_devsw = 0x0,
        si_iosize_max = 0,
        si_usecount = 0,
        si_threadcount = 0,
        __si_u = {
                __sit_tty = 0x0,
                __sid_snapdata = 0x0
        },
        __si_namebuf = "urandom", '\0' <repeats 56 times>
}

As you can see, si_devsw is null pointer.

FreeBSD 5.4 doesn't have this bug, because devfs_rule_getdev function
treated symlinks and dirs specially (devfs_rule.c, rev. 1.12, line 500).
So adding the similar check should solve the problem.
	
>How-To-Repeat:
mount_devfs dev /mnt
devfs -m /mnt rule apply type disk hide
>Fix:
As a workaround, don't use `type' rules, use `path' rules instead.

Here's the patch, that adds checks for dirent against symlink or directory.
I'm not actually good in devfs inner workings, so I'm not sure this patch
is acceptable, but it's similar to how it was done in 5.4 and it solves
the panic.

--- devfs.patch begins here ---
--- sys/fs/devfs/devfs_rule.c.orig	Mon Sep 26 18:36:52 2005
+++ sys/fs/devfs/devfs_rule.c	Wed Nov 30 06:38:21 2005
@@ -430,6 +430,9 @@
 static struct cdev *
 devfs_rule_getdev(struct devfs_dirent *de)
 {
+	if (de->de_dirent->d_type == DT_LNK ||
+		de->de_dirent->d_type == DT_DIR )
+		return (NULL);
 
 	if (de->de_cdp == NULL)
 		return (NULL);
--- devfs.patch ends here ---
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->phk 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Mon Dec 12 10:11:03 UTC 2005 
Responsible-Changed-Why:  
To devfs maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=89784 

From: Peter Much <pmc@citylink.dinoex.sub.org>
To: bug-followup@FreeBSD.org, amdmi3@mail.ru
Cc:  
Subject: Re: kern/89784: [devfs][patch] 6.0-RELEASE panics ...
Date: Mon, 24 Mar 2008 05:16:10 +0100

 Same problem is still present in 6.3-RELEASE-p1, 
 with quite similar backtrace.

From: Dmitry Marakasov <amdmi3@amdmi3.ru>
To: Peter Much <pmc@citylink.dinoex.sub.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/89784: [devfs][patch] 6.0-RELEASE panics ...
Date: Wed, 26 Mar 2008 22:55:53 +0300

 * Peter Much (pmc@citylink.dinoex.sub.org) wrote:
 > Same problem is still present in 6.3-RELEASE-p1, 
 > with quite similar backtrace.
 In 7.0 as well. Seems like no one care.
 
 -- 
 Dmitry A. Marakasov    | jabber: amdmi3@jabber.ru
 amdmi3@amdmi3.ru       | http://www.amdmi3.ru
State-Changed-From-To: open->closed 
State-Changed-By: kib 
State-Changed-When: Fri May 16 15:29:16 UTC 2008 
State-Changed-Why:  
Fix committed to the RELENG_6,7. 


Responsible-Changed-From-To: phk->kib 
Responsible-Changed-By: kib 
Responsible-Changed-When: Fri May 16 15:29:16 UTC 2008 
Responsible-Changed-Why:  
Take it, I committed the supposed fix. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=89784 
>Unformatted:
