Date: Fri, 8 Aug 2008 12:26:31 -0400 From: John Baldwin <jhb@freebsd.org> To: Ed Schouten <ed@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/io iodev.c Message-ID: <200808081226.32089.jhb@freebsd.org> In-Reply-To: <200808081343.m78DhwYE068477@repoman.freebsd.org> References: <200808081343.m78DhwYE068477@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 08 August 2008 09:43:56 am Ed Schouten wrote: > ed 2008-08-08 13:43:56 UTC > > FreeBSD src repository > > Modified files: > sys/dev/io iodev.c > Log: > SVN rev 181428 on 2008-08-08 13:43:56Z by ed > > Remove D_NEEDGIANT from io(4). > > There is no need to mark this device node to use Giant. The only > architectures that use io(4) (i386 and amd64) only change a flag in > td->td_frame, which is only accessed by curthread. > > Apart from this change, I think some fishy things may happen when using > /dev/io in multithreaded applications. I haven't tested, but looking at > the code, the flag doesn't get cleared when close() is called from > another thread, but this may not be this important. > > I'm not removing D_NEEDGIANT from mem(4), because this driver isn't > Giant safe at all (it calls GIANT_REQUIRED). It should be setting D_TRACKCLOSE though so that close() reliably clears the flag even in single-threaded processes. You can still get odd behavior if you explicitly open it twice in an app and then close one of the two fd's. You will no longer have IO permission even though you still have one fd open. However, if you do that I think you deserve what you asked for. :) Also, I don't see why memrw() is not MPSAFE actually (on amd64 and i386 at least). Stephan (ups@) even has a comment to that effect. The MTRR stuff backing memioctl() on x86 might need locking, but I think that is all mem(4) is missing. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808081226.32089.jhb>