Date: Thu, 11 Dec 2008 00:54:20 +0100 From: "Paul B. Mahol" <onemda@gmail.com> To: "John Baldwin" <jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 Message-ID: <3a142e750812101554o656347f9w42c7486db4fc4a9e@mail.gmail.com> In-Reply-To: <200812101450.04638.jhb@freebsd.org> References: <200811191510.53793.jhb@FreeBSD.org> <200812091602.10850.jhb@freebsd.org> <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> <200812101450.04638.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/10/08, John Baldwin <jhb@freebsd.org> wrote: > On Wednesday 10 December 2008 12:22:43 pm Paul B. Mahol wrote: >> On 12/9/08, John Baldwin <jhb@freebsd.org> wrote: >> > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >> > lock. >> > It could be a property of the ISO image. "PX" holds permissions (owner, >> > etc.). Do you get the same messages w/o the patch with the same ISO > image / >> > CD? >> > >> > -- >> > John Baldwin >> > >> >> I searched little for this message and found kern/63446 PR interesting > comment: >> >> Caused by cd9660_vnops.c rev. 1.77. VOP_READDIR returns bogus >> d_fileno, VFS_VGET on this value returns bogus vnode with zeroed > attributes. >> >> I think that whatever locking is done is done wrong. > > That issue isn't a locking issue, it's an issue with VOP_READDIR() using a > different meaning for i-node numbers than VFS_VGET(), and would happen > regardless of any Giant or vnode locking. Yes, I know that that issue/PR doesnt have anything to do with locking. But displaying bogus messages and still having functional cd9660 for general use means that something is not correctly locked. -- Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a142e750812101554o656347f9w42c7486db4fc4a9e>