Date: Sat, 2 Jan 2021 16:52:33 +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/CIsSKwm1w4dH/9@kib.kiev.ua> In-Reply-To: <20210102062906.GA98322@FreeBSD.org> References: <202009152219.08FMJGMw065722@repo.freebsd.org> <20210101184400.GA77653@FreeBSD.org> <X%2B%2Bb7xbO3JksobOV@kib.kiev.ua> <20210102062906.GA98322@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 02, 2021 at 06:29:06AM +0000, Alexey Dokuchaev wrote: > On Sat, Jan 02, 2021 at 12:02:23AM +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? > > The usual "Fatal trap 12: page fault while in kernel mode" panic. And everything else ? There is a lot of useful data there (for me at least). > > > Provide literal transcription of the kernel messages and not your > > interpretation of them. > > Sorry, I've just quickly copied function names off the screen since my > debug symbols did not match the running kernel at that moment and I've > thought maybe it's a known bug that was fixed after r368820. I've now > made things in sync so can provide full context (see below). > > > > ... > > > __mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfffffe0060636490 > > > tmpfs_free_node() at tmpfs_free_node+0xc7/frame 0xfffffe00606364c0 > > > > What is the source line for tmpfs_free_node() frame? > > /usr/src/crash-dec/sys/fs/tmpfs/tmpfs_subr.c:373 > > (kgdb) list *(tmpfs_free_node+0xc7) > 0xffffffff815246d7 is in tmpfs_free_node (/usr/src/crash-dec/sys/fs/tmpfs/tmpfs_subr.c:374). > 369 { > 370 if (refcount_release_if_not_last(&node->tn_refcount)) > 371 return; > 372 > 373 TMPFS_LOCK(tmp); > 374 TMPFS_NODE_LOCK(node); > 375 if (!tmpfs_free_node_locked(tmp, node, false)) { > 376 TMPFS_NODE_UNLOCK(node); > 377 TMPFS_UNLOCK(tmp); > 378 } > (kgdb) Ok. So two questions: 1. Do you have core dump? If not, can you configure it and obtain the dump? 2. Can you look more closely what you do from the user PoV there, and provide a recipe to reproduce without involving 'tc tinderbiuild', whatever it is ? In particular, I want to see the *node content.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X/CIsSKwm1w4dH/9>