Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Feb 2001 15:59:59 +0100 (CET)
From:      mitja.horvat@hermes.si
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   kern/25309: kernel panic related to umount -f & kevents
Message-ID:  <200102231459.f1NExwD15609@lamu.hermes.si>

next in thread | raw e-mail | index | archive | help

>Number:         25309
>Category:       kern
>Synopsis:       Bug with kevent & umount -f
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 23 07:00:02 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Mitja Horvat
>Release:        FreeBSD 4.2-STABLE i386
>Organization:
>Environment:

FreeBSD 4.2-STABLE i386, cvsupped on Feb 11th 2001.
PIII/800Mhz, 256MB of RAM, 15GB ATA/66 hard drive.

>Description:

Kernel panic occurs when waiting for a kevent on a UFS file and the
filesystem is forcibly unmounted.

>How-To-Repeat:

Since tail (in conjunction with -f) uses kevent to achieve it's job,
it can be used to reproduce the problem. Mount a filesystem, and 
tail -f a file. Unmount the filesystem using the -f flag(force). Note,
that the bug may not manifestate immediately.



#!/bin/sh
while true
do
	mount /dev/DEVICE /MOUNT_POINT
	tail -f /MOUNT_POINT/RANDOM_FILE &
	umount -f /MOUNT_POINT
	kill %%
done

Replace /dev/DEVICE with a device(eg. CDROM), /MOUNT_POINT with the mount point
of the device, and RANDOM_FILE with a random file on the filesystem.

>Fix:

The following patch fixes the problem for me. Please note that I'm far away from being
a kernel hacker, so I'm not 100% sure if it breaks something else or not
(although it's a very simple fix).

--- vfs_vnops.c.orig    Mon Feb 12 14:17:19 2001
+++ vfs_vnops.c Fri Feb 23 15:55:18 2001
@@ -722,6 +722,15 @@
        struct vnode *vp = (struct vnode *)kn->kn_fp->f_data;
        struct inode *ip = VTOI(vp);
 
+       /*
+        * If the underlying inode was freed(this can happen
+        * if the filesystem is forcibly unmounted with 
+        * umount -f), return as there was activity on the file,
+        * so the process will be woken up and later it will
+        * receive an error during read XXX
+        */
+       if (ip == NULL) return 1;
+
        kn->kn_data = ip->i_size - kn->kn_fp->f_offset;
        return (kn->kn_data != 0);
 }



>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102231459.f1NExwD15609>