From owner-svn-src-head@freebsd.org Sat Jan 2 06:29:07 2021 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 103D94C506F; Sat, 2 Jan 2021 06:29:07 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Bmy74r4z3GHn; Sat, 2 Jan 2021 06:29:06 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1609568947; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5st1pqN3yAH9RZI0HeO5q4iNYGKTXKdYxCPXggbVFv4=; b=sCV9x7wCLHWA+gKuSRLYhKJUbYj91VlE3/fulf3ieUBrfiSlucqdZ3w9n883sospdDLJYF NuVd9yYndbMkOnhG7FqtxViOs8tSailMs2CUXqdxstPzKWRPL5XdP7gCwcVJ+5r2euGUE5 PUXMoN759yvnERAzwHyDOp9DIYXLTJntaUM3QJIh009ojwPIAED40WUBHJkEUHe+noKTcG 4oVK9tlSWDdKfHnFWH0g+OesCz9fcc+prK6oXchakTwjRRrU/yIZQPNgPjklfkOd61fwuO 6EMtRsQDFZ4JELNUAz3XECAHCQpHtp+dO5+f/WGQn/6eYyncB+LlKudEY5Z3Cw== Received: by freefall.freebsd.org (Postfix, from userid 1033) id EB8B2F549; Sat, 2 Jan 2021 06:29:06 +0000 (UTC) Date: Sat, 2 Jan 2021 06:29:06 +0000 From: Alexey Dokuchaev To: Konstantin Belousov 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: <20210102062906.GA98322@FreeBSD.org> References: <202009152219.08FMJGMw065722@repo.freebsd.org> <20210101184400.GA77653@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1609568947; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5st1pqN3yAH9RZI0HeO5q4iNYGKTXKdYxCPXggbVFv4=; b=DQw+hsJ2mpDaKxmYLAAXmyxhMWZqQ+uUUW9oQmPetY4FtXP065u/xACYtOTToGXEo+AaDp M6n4z25k3kCPV5gxa0MUV+xv7RtD4fb4hk/r4RcBIuz9woans0hesnRJpYJy2uQdwvHzyH fR3wc7xXKkQTHtlw7DJgMGQnMqXt0TZnULS7c8N1Dqwz3Pq2j16TLVKhk6GA9tbBK1o+Af +O5awPP9B6p7FP9zUa6BhZ7JfJ3eS7367Nw485Cp/SVAElYO7LPLCxjgAqyIc3NCMLIyv7 DpoxVOa/HFZeoR/mk8tQfGhNbY9JJNI9ON+7TUaezFie5XHXJP7aIzH609B3tA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1609568947; a=rsa-sha256; cv=none; b=oEUNgBoCZAWYzEGBs3cEF9011Bi97ohYSLZcLOj819DJdNkM6uN2agYHVHLk9AAEs98/Nw LE9kbH/whQEfy7+RuTGgig/dZEcIG4T8CdD01pSdZyuUNNsKR+gm0IfiAKmtkj7epQFp6x OEm8edoYlDLMHm10zh1MIo8COmq1K4gvGD9/pH8bOqfZKiJQG6RWgTUmuWHWifXsGsFdhJ yzjEXosLVHEhPLQBScFnrUdGDC9GME/0dBpsgzTu+opo1jiFwQcvUz48Um0ry9o4VoW5R1 taKRjF0afbYgZAmuC41fuO64BJ6ptIh59j016uYQEVXK5Yk9rnOYIzgngUoOpQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 06:29:07 -0000 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. > 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) ./danfe