Re: svn commit: r365787 - head/sys/fs/tmpfs
On Tue, Jan 05, 2021 at 04:13:16PM +0100, Hans Petter Selasky wrote: > On 1/1/21 7:44 PM, Alexey Dokuchaev wrote: > >__mtx_lock_sleep() > >tmpfs_free_node() > >tmpfs_fo_close() > >_fdrop() > >closef() > >fdescfree_fds() > >fdescfree() > >exit1() > >sigexit() > >postsig() > >ast() > >doreit_ast() > > I'm seeing the same and I have a clue what is going on. > > Are you absolutely sure doreit_ast() is the bottom of your stacktrace, You can see for yourself (x3.txz for recent -current, minidump version 3, or x4.txz for r365977 if you are confined to minidump version 2 for some reason; the panic is the same). Both files are at my $home at freefall. ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On 1/1/21 7:44 PM, Alexey Dokuchaev wrote: __mtx_lock_sleep() tmpfs_free_node() tmpfs_fo_close() _fdrop() closef() fdescfree_fds() fdescfree() exit1() sigexit() postsig() ast() doreit_ast() I'm seeing the same and I have a clue what is going on. Are you absolutely sure doreit_ast() is the bottom of your stacktrace, or do you see ??'s in there? --HPS ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On Sat, Jan 02, 2021 at 06:47:14PM +0200, Konstantin Belousov wrote: > On Sat, Jan 02, 2021 at 04:35:22PM +, Alexey Dokuchaev wrote: > > On Sat, Jan 02, 2021 at 04:52:33PM +0200, Konstantin Belousov wrote: > > > ... > > > Ok. So two questions: > > > 1. Do you have core dump? > > > > I have vmcore.0 and matching kernel.debug, I'll gladly obtain and provide > > anything else you might wanna need. > ... > > I can upload the kernel core+debug files to freefall so you could have > > a closer look yourself. > > Lets try this. ff:/home/danfe/x.rar ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On Sat, Jan 02, 2021 at 04:35:22PM +, Alexey Dokuchaev wrote: > On Sat, Jan 02, 2021 at 04:52:33PM +0200, Konstantin Belousov wrote: > > ... > > Ok. So two questions: > > 1. Do you have core dump? > > I have vmcore.0 and matching kernel.debug, I'll gladly obtain and provide > anything else you might wanna need. ... > I can upload the kernel core+debug files to freefall so you could have > a closer look yourself. Lets try this. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On Sat, Jan 02, 2021 at 04:52:33PM +0200, Konstantin Belousov wrote: > ... > Ok. So two questions: > 1. Do you have core dump? I have vmcore.0 and matching kernel.debug, I'll gladly obtain and provide anything else you might wanna need. > 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? Yeah, I know that would be nice; the naive way (from the previous email of yours) indeed doesn't trigger it, I haven't found one which does yet. > In particular, I want to see the *node content. I can upload the kernel core+debug files to freefall so you could have a closer look yourself. ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On Sat, Jan 02, 2021 at 06:29:06AM +, 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 +, Alexey Dokuchaev wrote:
> > > On Tue, Sep 15, 2020 at 10:19:16PM +, 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 0xfe0060636490
> > > tmpfs_free_node() at tmpfs_free_node+0xc7/frame 0xfe00606364c0
> >
> > 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)
> 0x815246d7 is in tmpfs_free_node
> (/usr/src/crash-dec/sys/fs/tmpfs/tmpfs_subr.c:374).
> 369 {
> 370 if (refcount_release_if_not_last(>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.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On Sat, Jan 02, 2021 at 12:02:23AM +0200, Konstantin Belousov wrote:
> On Fri, Jan 01, 2021 at 06:44:00PM +, Alexey Dokuchaev wrote:
> > On Tue, Sep 15, 2020 at 10:19:16PM +, 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.
> 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 0xfe0060636490
> > tmpfs_free_node() at tmpfs_free_node+0xc7/frame 0xfe00606364c0
>
> 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)
0x815246d7 is in tmpfs_free_node
(/usr/src/crash-dec/sys/fs/tmpfs/tmpfs_subr.c:374).
369 {
370 if (refcount_release_if_not_last(>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)
./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On Sat, Jan 02, 2021 at 12:02:29AM +0200, Konstantin Belousov wrote: > On Fri, Jan 01, 2021 at 06:44:00PM +, Alexey Dokuchaev wrote: > > On Tue, Sep 15, 2020 at 10:19:16PM +, 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. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On Fri, Jan 01, 2021 at 06:44:00PM +, Alexey Dokuchaev wrote: > On Tue, Sep 15, 2020 at 10:19:16PM +, 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() ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365787 - head/sys/fs/tmpfs
On Tue, Sep 15, 2020 at 10:19:16PM +, 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 ... __mtx_lock_sleep() tmpfs_free_node() tmpfs_fo_close() _fdrop() closef() fdescfree_fds() fdescfree() exit1() sigexit() postsig() ast() doreit_ast() ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365787 - head/sys/fs/tmpfs
Author: kib
Date: Tue Sep 15 22:19:16 2020
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.
Ensure liveness of the tmpfs VREG node and consequently v_object
inside VOP_READ_PGCACHE by referencing tmpfs node in tmpfs_open().
Provide custom tmpfs fo_close() method on file, to ensure that close
is paired with open.
Add tmpfs VOP_READ_PGCACHE that takes advantage of all tmpfs quirks.
It is quite cheap in code size sense to support page-ins for read for
tmpfs even if we do not own tmpfs vnode lock. Also, we can handle
holes in tmpfs node without additional efforts, and do not have
limitation of the transfer size.
Reviewed by: markj
Discussed with and benchmarked by:mjg (previous version)
Tested by:pho
Sponsored by: The FreeBSD Foundation
Differential revision:https://reviews.freebsd.org/D26346
Modified:
head/sys/fs/tmpfs/tmpfs.h
head/sys/fs/tmpfs/tmpfs_subr.c
head/sys/fs/tmpfs/tmpfs_vfsops.c
head/sys/fs/tmpfs/tmpfs_vnops.c
Modified: head/sys/fs/tmpfs/tmpfs.h
==
--- head/sys/fs/tmpfs/tmpfs.h Tue Sep 15 22:13:21 2020(r365786)
+++ head/sys/fs/tmpfs/tmpfs.h Tue Sep 15 22:19:16 2020(r365787)
@@ -287,6 +287,7 @@ struct tmpfs_node {
* a position within the file is accessed.
*/
vm_object_t tn_aobj;/* (c) */
+ struct tmpfs_mount *tn_tmp;/* (c) */
} tn_reg;
} tn_spec; /* (v) */
};
@@ -415,6 +416,7 @@ voidtmpfs_ref_node(struct tmpfs_node *node);
inttmpfs_alloc_node(struct mount *mp, struct tmpfs_mount *, enum vtype,
uid_t uid, gid_t gid, mode_t mode, struct tmpfs_node *,
const char *, dev_t, struct tmpfs_node **);
+inttmpfs_fo_close(struct file *fp, struct thread *td);
void tmpfs_free_node(struct tmpfs_mount *, struct tmpfs_node *);
bool tmpfs_free_node_locked(struct tmpfs_mount *, struct tmpfs_node *, bool);
void tmpfs_free_tmp(struct tmpfs_mount *);
@@ -557,6 +559,8 @@ tmpfs_update_getattr(struct vnode *vp)
if (__predict_false(node->tn_status & update_flags) != 0)
tmpfs_update(vp);
}
+
+extern struct fileops tmpfs_fnops;
#endif /* _KERNEL */
Modified: head/sys/fs/tmpfs/tmpfs_subr.c
==
--- head/sys/fs/tmpfs/tmpfs_subr.c Tue Sep 15 22:13:21 2020
(r365786)
+++ head/sys/fs/tmpfs/tmpfs_subr.c Tue Sep 15 22:19:16 2020
(r365787)
@@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
#include
@@ -340,6 +341,7 @@ tmpfs_alloc_node(struct mount *mp, struct tmpfs_mount
/* OBJ_TMPFS is set together with the setting of vp->v_object */
vm_object_set_flag(obj, OBJ_TMPFS_NODE);
VM_OBJECT_WUNLOCK(obj);
+ nnode->tn_reg.tn_tmp = tmp;
break;
default:
@@ -697,6 +699,7 @@ loop:
vp->v_object = object;
object->un_pager.swp.swp_tmpfs = vp;
vm_object_set_flag(object, OBJ_TMPFS);
+ vp->v_irflag |= VIRF_PGREAD;
VI_UNLOCK(vp);
VM_OBJECT_WUNLOCK(object);
break;
Modified: head/sys/fs/tmpfs/tmpfs_vfsops.c
==
--- head/sys/fs/tmpfs/tmpfs_vfsops.cTue Sep 15 22:13:21 2020
(r365786)
+++ head/sys/fs/tmpfs/tmpfs_vfsops.cTue Sep 15 22:19:16 2020
(r365787)
@@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
#include
@@ -662,6 +663,8 @@ static int
tmpfs_init(struct vfsconf *conf)
{
tmpfs_subr_init();
+ memcpy(_fnops, , sizeof(struct fileops));
+ tmpfs_fnops.fo_close = tmpfs_fo_close;
return (0);
}
Modified: head/sys/fs/tmpfs/tmpfs_vnops.c
==
--- head/sys/fs/tmpfs/tmpfs_vnops.c Tue Sep 15 22:13:21 2020
(r365786)
+++ head/sys/fs/tmpfs/tmpfs_vnops.c Tue Sep 15 22:19:16 2020
(r365787)
@@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
#include
@@ -276,22 +277,25 @@ tmpfs_mknod(struct vop_mknod_args *v)
return tmpfs_alloc_file(dvp, vpp, vap, cnp, NULL);
}
+struct fileops tmpfs_fnops;
+
static int
tmpfs_open(struct vop_open_args *v)
{
- struct
