Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Jan 2021 00:34:28 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Alexey Dokuchaev <danfe@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r365787 - head/sys/fs/tmpfs
Message-ID:  <X%2B%2BjdADyu9VhxsDl@kib.kiev.ua>
In-Reply-To: <X%2B%2Bb7xbO3JksobOV@kib.kiev.ua>
References:  <202009152219.08FMJGMw065722@repo.freebsd.org> <20210101184400.GA77653@FreeBSD.org> <X%2B%2Bb7xbO3JksobOV@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 02, 2021 at 12:02:29AM +0200, Konstantin Belousov wrote:
> On Fri, Jan 01, 2021 at 06:44:00PM +0000, Alexey Dokuchaev wrote:
> > On Tue, Sep 15, 2020 at 10:19:16PM +0000, Konstantin Belousov wrote:
> > > New Revision: 365787
> > > URL: https://svnweb.freebsd.org/changeset/base/365787
> > > 
> > > Log:
> > >   Add tmpfs page cache read support.
> > >   
> > >   Or it could be explained as lockless (for vnode lock) reads.  Reads
> > >   are performed from the node tn_obj object.  Tmpfs regular vnode object
> > >   lifecycle is significantly different from the normal OBJT_VNODE: it is
> > >   alive as far as ref_count > 0.
> > 
> > This causes panics for me when building ports in the tmpfs-backed tinderbox.
> > Easily reproducible:
> > 
> > 1) ./tc tinderbuild ... -b "$@"
> > 2) tail -f .../tmp/make.log4 # on the adjacent console
> > 3) wait until the build job finishes
> > 4) ^C in the "tail" window -> crash
> What exactly 'crash' is ?  Provide literal transcription of the kernel
> messages and not your interpretation of them.
> 
> >  ...
> >   __mtx_lock_sleep()
> >   tmpfs_free_node()
> What is the source line for tmpfs_free_node() frame ?
> 
> >   tmpfs_fo_close()
> >   _fdrop()
> >   closef()
> >   fdescfree_fds()
> >   fdescfree()
> >   exit1()
> >   sigexit()
> >   postsig()
> >   ast()
> >   doreit_ast()

Forgot to mention this.  I tried a somewhat naive method to reproduce it:
# mount -t tmpfs none /mnt
# echo 123 >/mnt/1
# tail -f /mnt/1
while in other session,
# umount -f /mnt
but this only resulted in report of EIO from tail, and SIGINT killed tail
without producing the panic/page fault/whatever you see.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X%2B%2BjdADyu9VhxsDl>