Date: Tue, 12 Aug 2008 11:15:00 -0400 From: John Baldwin <jhb@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Ed Schouten <ed@freebsd.org>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/io iodev.c Message-ID: <200808121115.01483.jhb@freebsd.org> In-Reply-To: <20080812231130.D760@besplex.bde.org> References: <200808081343.m78DhwYE068477@repoman.freebsd.org> <20080812014937.E21092@besplex.bde.org> <20080812231130.D760@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 12 August 2008 10:07:43 am Bruce Evans wrote: > I checked that bpf panics (even under UP) due to the obvious bugs in > its d_close(): > > # Generate lots of network activity using something like: > sysctl net.inet.icmp.icmplim=0; ping -fq localhost & > > # Race to panic eventually: > while :; do tcpdump -i lo0 & sleep 0.001; revoke /dev/bpf0 > > Most or all device drivers have obvious bugs in their d_close(); bpf > is just a bit easier to understand and more likely to cause a panic > than most device drivers, since it is simple and frees resources. A > panic is very likely when si_drv1 is freed, and si_drv1 is only locked > accidentally. I think revoke(2) should EINVAL (or ENOTTY) for non-ttys. Of course bpf is broken with revoke, but nobody uses revoke with bpf. What people do do in the normal course of using bpf is lots of concurrent bpf accesses, and w/o D_TRACKCLOSE, bpf devices don't get closed. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808121115.01483.jhb>