Bug 25309

Summary:

Bug with kevent & umount -f

Product:

Base System

Reporter:

mitja.horvat <mitja.horvat>

Component:

kern

Assignee:

dwmalone

Status:

Closed FIXED

Severity:

Affects Only Me

Priority:

Normal

Version:

4.2-STABLE

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
file.diff	none

Description mitja.horvat 2001-02-23 15:00:02 UTC

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

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).
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.

Comment 1 dwmalone 2001-02-23 15:38:42 UTC

On Fri, Feb 23, 2001 at 03:59:59PM +0100, mitja.horvat@hermes.si wrote:
> --- 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);
>  }

Amazingly, I suggested an almost identical patch earlier in the
week for another problem due to revoking file discriptors. I'll
try to get Peter or Jonathan to review the patch and I'll commit
it.

	David.

Comment 2 dwmalone freebsd_committer

2001-02-23 15:39:38 UTC

Responsible Changed
From-To: freebsd-bugs->dwmalone

I'll try to get someone to review this.

Comment 3 mitja.horvat 2001-02-23 16:44:30 UTC

On Friday 23 February 2001 16:38, you wrote:
> On Fri, Feb 23, 2001 at 03:59:59PM +0100, mitja.horvat@hermes.si wrote:
> > --- 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);
> >  }
>
> Amazingly, I suggested an almost identical patch earlier in the
> week for another problem due to revoking file discriptors. I'll
> try to get Peter or Jonathan to review the patch and I'll commit
> it.
>
> 	David.

Great, I'm glad that I have contributed to the comunity. Hopefully this will 
get committed before 4.3-RELEASE.

Regards,
Mitja

Comment 4 dwmalone freebsd_committer

2001-02-26 11:01:29 UTC

State Changed
From-To: open->closed

I believe the fix for this has now been merged into -stable.