Date: Sat, 4 Aug 2007 09:44:33 +0400 (MSD) From: Dmitry Morozovsky <marck@rinet.ru> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: kib@freebsd.org, current@freebsd.org, howard0su@gmail.com Subject: Re: contemporary -current panic: locking against myself Message-ID: <20070804094047.V8449@woozle.rinet.ru> In-Reply-To: <20070803164108.C569@woozle.rinet.ru> References: <20070802155317.X50347@woozle.rinet.ru> <20070803102019.GG37984@garage.freebsd.pl> <20070803164108.C569@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Aug 2007, Dmitry Morozovsky wrote: DM> PJD> Here you can find two patches, which may or may not fix your problem. DM> PJD> The first one is actually only to improve debug. DM> PJD> DM> PJD> This patch adds all vnode flags to the output, because I believe you DM> PJD> have VI_OWEINACT set, but not printed: DM> PJD> DM> PJD> http://people.freebsd.org/~pjd/patches/vfs_subr.c.4.patch DM> PJD> DM> PJD> The problem here is that vm_object_reference() calls vget() without any DM> PJD> lock flag and vget() locks vnode exclusively when the VI_OWEINACT flag DM> PJD> is set. vget() should probably be fixed too, but jeff@ opinion is that DM> PJD> it shouldn't happen in this case, so this may be tmpfs bug. DM> PJD> DM> PJD> The patch below fixes some locking problems in tmpfs: DM> PJD> DM> PJD> http://people.freebsd.org/~pjd/patches/tmpfs.patch DM> PJD> DM> PJD> The problems are: DM> PJD> - tmpfs_root() should honour 'flags' argument, and not always lock the DM> PJD> vnode exclusively, DM> PJD> - tmpfs_lookup() should lock vnode using cnp->cn_lkflags, and not always DM> PJD> do it exclusively, DM> PJD> - in ".." case when we unlock directory vnode to avoid deadlock, we DM> PJD> should relock it using the same type of lock it was locked before and DM> PJD> not always relock it exclusively, DM> PJD> DM> PJD> Note, that this patch wasn't even compiled tested. DM> DM> Well, it at least compiled and booted on i386. Test release run is in progress DM> now, i'll followup with the results. Good news: It fills 4G of RAM + 2G of swap, bailed out but not paniced. If the error is not fixed, it at least well masked now. Please consider your patch for commit. Thanks! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070804094047.V8449>