Date: Thu, 1 Feb 2001 18:47:25 +0100 From: Mitja Horvat <mitja.horvat@hermes.si> To: freebsd-stable@freebsd.org Subject: Fwd: kevents & umount -f kernel panic Message-ID: <01020118471700.48561@lamu.hermes.si>
next in thread | raw e-mail | index | archive | help
Hi all,
since I didn't get any response on freebsd-hackers@freebsd.org I'm reposting
this here. Hopefully nobody will get offended. It's about a panic in the
FreeBSD kernel, 4.2-STABLE(recent cvsup), with a simple patch included.
Basically it's a bug in the kevent code, which may reference a NULL pointer
if a process was waiting for a file growth with kevents(tail for example),
and the filesystem holding the file was forcibly unmounted.
It's not a serious bug, because it is triggered only on very specific
circuimstances, but the fix is trivial so I think it's worth commiting(I have
no commit access myself).
Should I rather send a GNATS report for such kind of bugs?
---------- Forwarded Message ----------
Subject: kevents & umount -f kernel panic
Date: Tue, 30 Jan 2001 17:54:57 +0100
From: Mitja Horvat <Mitja.Horvat@hermes.si>
To: freebsd-hackers@FreeBSD.ORG
Hi all,
I found a bug in the FreeBSD kernel today(it's 4.2-STABLE, cvsupped today).
It is related to kevents and the umount -f option(forcibly unmounting of a
filesystem).
The bug is easily reproducible by running this simple shell script:
#/bin/sh
while true
do
mount /cdrom
tail -f /cdrom/SOME_FILE & sleep 1
umount -f /cdrom
kill %%
done
(tail uses kevent, that's why the bug is triggered).
Here's the crashdump:
IdlePTD 3485696
initial pcb at 2ce260
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x88
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc017101f
stack pointer = 0x10:0xcd37fe5c
frame pointer = 0x10:0xcd37fe60
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 = 26 (tail)
interrupt mask = net tty bio cam
trap number = 12
panic: page fault
syncing disks...
done
Uptime: 48s
dumping to dev #ad/0x30001, offset 524312
dump ata0: resetting devices .. done
255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237
236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218
217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199
198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180
179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161
160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142
141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123
122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104
103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80
79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28
27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc013da57 in boot (howto=256) at ../../kern/kern_shutdown.c:309
#2 0xc013ddd4 in poweroff_wait (junk=0xc026d82f, howto=-872459200) at
.../../kern/kern_shutdown.c:556
#3 0xc023c361 in trap_fatal (frame=0xcd37fe1c, eva=136) at
.../../i386/i386/trap.c:951
#4 0xc023c039 in trap_pfault (frame=0xcd37fe1c, usermode=0, eva=136) at
.../../i386/i386/trap.c:844
#5 0xc023bc1f in trap (frame={tf_fs = -852033520, tf_es = -872546288, tf_ds
= -1057488880, tf_edi = -851968128, tf_esi = 0,
tf_ebp = -851968416, tf_isp = -851968440, tf_ebx = -851935296, tf_edx =
-1057466816, tf_ecx = 0, tf_eax = 8573,
tf_trapno = 12, tf_err = 0, tf_eip = -1072230369, tf_cs = 8, tf_eflags
= 66118, tf_esp = -851935296, tf_ss = -851968276})
at ../../i386/i386/trap.c:443
#6 0xc017101f in filt_vnread (kn=0xcd387fc0, hint=0) at
.../../kern/vfs_vnops.c:724
#7 0xc0134d55 in kqueue_scan (fp=0xc0f85840, maxevents=1, ulistp=0xbfbffbcc,
tsp=0x0, p=0xcbff5440)
at ../../kern/kern_event.c:610
#8 0xc013479d in kevent (p=0xcbff5440, uap=0xcd37ff80) at
.../../kern/kern_event.c:391
#9 0xc023c60d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds =
-1078001617, tf_edi = 4, tf_esi = 4, tf_ebp = -1077937164,
tf_isp = -851968044, tf_ebx = 672105792, tf_edx = 134526704, tf_ecx =
-1077937204, tf_eax = 363, tf_trapno = 7,
tf_err = 2, tf_eip = 671739848, tf_cs = 31, tf_eflags = 659, tf_esp =
-1077937384, tf_ss = 47})
at ../../i386/i386/trap.c:1150
#10 0xc0231035 in Xint0x80_syscall ()
The following patch fixes the bug for me, but since I'm far away from being a
kernel hacker I may have done something wrong, or most possibly didn't fix it
correctly. Anyway, here it is:
----8<---8<-----8<---8<----8<---8<----8<---8<----8<---8<----8<---8<---8<---8<
--- vfs_vnops.c.orig Sun Nov 26 03:55:11 2000
+++ vfs_vnops.c Tue Jan 30 17:33:44 2001
@@ -714,6 +714,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);
}
----8<---8<-----8<---8<----8<---8<----8<---8<----8<---8<----8<---8<---8<---8<
-------------------------------------------------------
Any comments?
Regards,
Mitja
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01020118471700.48561>