From owner-freebsd-fs@freebsd.org Mon Jul 16 17:44:19 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7CBB1032C85 for ; Mon, 16 Jul 2018 17:44:19 +0000 (UTC) (envelope-from jack@chillysky.com) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33D957B933 for ; Mon, 16 Jul 2018 17:44:19 +0000 (UTC) (envelope-from jack@chillysky.com) Received: by mail-wr1-x442.google.com with SMTP id a3-v6so23544341wrt.2 for ; Mon, 16 Jul 2018 10:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chillysky-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qP8oEVHu1Tz1fB9GsYqFgbEPewKnW9iHd2lJ5PDYhhQ=; b=rrb2zw2yWGzTj5BqTxU7cRRNR73UFyFOVZQ/Mzggs//Wv1wImfT/g3NTz96CjbxuBT fAacM/4D6K+S2uH1xVMPY0E4FCczjxH++mEJ9yqxn4BT7rxv/J4Y+t8rbJpL0jOVxpMo NUN/PWOk4jx2rmoxG55OXy3wob3wBv4ArvcnoqNxEMzAphT+rAbtx9rZYlSu3W5ky3TX SNYLIW1LLIqr4+1ZDfGzyIT2YeN2FhE3pROUbw3dUA57Y/nY/p4487vhj0ACMF5mQyVb 0GQV/mj6Jcfzh7aiGBVO2pBVbI+rHEKNS3iKP7L6T/zyRl06gR6LdhUfPnE0IJ+cY7W7 YLRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qP8oEVHu1Tz1fB9GsYqFgbEPewKnW9iHd2lJ5PDYhhQ=; b=bsto7xgtH3P6I5xT0yYTPPjbONVrU9u3mRzpYVhJYgrqvbISPh80/Jp8KQACPt3j85 Ke2woSRscLCYRZisJYdgrUgco/wrYsvS5dlzMrcLiwneDoqW+KedF/Cz319+aRgsu1eA 8VDPlp3E+DKeqIrP8HqjT7f+t/CbwOICmfZs3Kkf85AGLgEPmRLGXOtyPSrvl22sXBkK ejOoBt0ckhSNvbuXXihR7tn3/TnyQot9FxIS2+MVi0IBVJbbT8iiRVKAvnLKfdQCkMIX Z03FRcgX8t7CoSfSHgaLX6W9UVrV9fJRWT6JT5EEwtYfCH8nvfNwmgxyPZ7ho15H4EzB S/dw== X-Gm-Message-State: AOUpUlF1FM04Td7+F6oQW4vmRHzEaK5RfPh1MQ0ZLhJY6HMyUQaCSfQ0 SGRALSpNTbzMinPzeZZQmj8on0tp8EBbxEADsHXrCrum X-Google-Smtp-Source: AAOMgpehsMsqoMpn2YQxRnOGCCn12I4uwjHBKDkVzAMtZMFk397sA1v/hbmZQOwh3d8x47OeGqfIsUDrdOYGC4ddCNo= X-Received: by 2002:adf:a541:: with SMTP id j1-v6mr14048180wrb.155.1531763057937; Mon, 16 Jul 2018 10:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:3b09:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 10:44:17 -0700 (PDT) In-Reply-To: <20180714074829.GR5562@kib.kiev.ua> References: <20180714074829.GR5562@kib.kiev.ua> From: Jack Humphries Date: Mon, 16 Jul 2018 10:44:17 -0700 Message-ID: Subject: Re: tmpfs questions To: Konstantin Belousov Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 17:44:19 -0000 Thanks a lot, Konstantin. I also noticed that the tmpfs_mount structure is not necessarily protected by a lock when an access is made to the tm_nodes_inuse member in the if statement at the beginning of the tmpfs_alloc_node function in tmpfs_subr.c (though this member is protected by the allnode_lock when it is modified). Thus conceivably it is possible to create more nodes than the maximum number allowed if multiple threads try to do so at the same time. Do you know how this situation is handled? What am I looking at incorrectly? Thanks again! Jack On Sat, Jul 14, 2018 at 12:48 AM, Konstantin Belousov wrote: > On Fri, Jul 13, 2018 at 05:42:59PM -0700, Jack Humphries wrote: >> Hi everyone, >> >> I'm trying to study the FreeBSD tmpfs implementation as a personal >> project, and I had a couple questions. I've been looking through the >> code for a week and modifying various parts. I appreciate any help! >> >> 1. It seems that vnodes are locked before being passed to the various >> VOP functions in tmpfs (because there is a call to >> MPASS(VOP_ISLOCKED(vp)) near the beginning of each function). >> Therefore, is the implicit assumption that a thread that holds the >> vnode lock has exclusive access to the corresponding tmpfs_node >> struct? In other words, is this why there are accesses to the tmpfs >> node variables even though the tmpfs node is not locked? Note: I see >> tn_interlock, but based on a comment above it in the source, it only >> protects tn_vpstate and tn_status. > tmpfs nodes are protected by the vnode locks. Note that vnode lock > can be held exclusive or shared. Typically, only exclusive lock allows > the code to modify the node, owning shared vnode lock only means that > the node can be read safely. > > Interlock exists because node state must be examined sometimes without > owning the vnode lock, in non-sleepable context. > >> >> 2. What is the duplicate node list for (tn_dupindex)? If I had to >> guess, it seems to have something to do with the case where one thread >> calls readdir on a directory while another is modifying the directory, >> but I'm not sure. Can someone explain this deeper? > As an optimization, children of the directory node are organized into > red/black tree, which cannot hold two entries with the same key value. > If a second entry with the existing key is attempted to be created in > the directory, it is added to the dup list instead.