From nobody Sat Aug 28 21:16:15 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AFCBD17A14B8 for ; Sat, 28 Aug 2021 21:16:17 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from unimail.uni-dortmund.de (mx1.hrz.uni-dortmund.de [129.217.128.51]) (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 (2048 bits) client-digest SHA256) (Client CN "unimail.tu-dortmund.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GxqBn3cNWz3J1F for ; Sat, 28 Aug 2021 21:16:17 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from [192.168.111.102] (p2e513846.dip0.t-ipconnect.de [46.81.56.70]) (authenticated bits=0) by unimail.uni-dortmund.de (8.17.1/8.17.1) with ESMTPSA id 17SLGFFQ028071 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Sat, 28 Aug 2021 23:16:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tu-dortmund.de; s=unimail; t=1630185376; bh=hyxjyZaLfeESpLqYxFiz4i6Jzyav2MuR9Q0MdW2JNIU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=nc7l796vqT7MBWS+UqtbhsMhBZfFBr81LK3L/VQcsONXWHqDKwqZ+Pzf0KInRp5LN 76eLAgPw2TXSxU72UpWpMayJLrhLYQYR6r4uomfHHWpuW1nNdLrmMe3VX+BW64M3Nn kCdRldMy5Sbw7Kx4uwAAkJW3Ja8+NLgehfL1H9fI= Subject: Re: Various unprotected accesses to buf and vnode To: Konstantin Belousov Cc: freebsd-fs , Horst Schirmeier References: <55f3661e-2173-793e-4834-bbcd79d3d99e@tu-dortmund.de> <380bdcc8-bede-2a64-8e5e-031552231d82@tu-dortmund.de> From: Alexander Lochmann Message-ID: <46649402-d28a-6f81-f0a8-39180b681f4c@tu-dortmund.de> Date: Sat, 28 Aug 2021 23:16:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE-1901 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GxqBn3cNWz3J1F X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 28.08.21 22:50, Konstantin Belousov wrote: > On Sat, Aug 28, 2021 at 08:53:19PM +0200, Alexander Lochmann wrote: >> On 27.08.21 20:40, Konstantin Belousov wrote: >>>> - Read of buf.b_blkno in cluster_write(): >>>> According to the documentation b_lock is needed. >>>> Is b_blkno maybe a read-only element of struct buf? >>> No, b_blkno is not read-only, it is the disk block number for the block, >>> as opposed to b_lbklno which is logical file block number. The buffer >>> is instantiated with b_blkno == b_lblkno, and when the buffer is mapped >>> to the real disk block, b_blkno is updated. >>> >>> Could you show me the backtrace of the situation where cluster_write() >>> is called with unlocked buffer? >>> >>>> >> If you don't mind, you can find them here: >> https://thasos.cs.tu-dortmund.de/bugs/ctx-buf-b_blkno-r-cex.html > I see some banner "Counterexamples", two buttons, and then a blank space. > Both under Firefox and Chrome under FreeBSD. > > I went as far as to ask and see what happens on Chrome under Windows, it > looks the same. Oh, I'm sorry. Pls click on "Show Member List", and then select an entry. For both cases, there should be only one entry. (JavaScript must be enabled for this to work.) > >> (Pls ignore the line 'Hypothesis 1: ....'.) >>>> - Write to vnode.v_bufobj.bo_object: >>>> https://github.com/freebsd/freebsd-src/blob/main/sys/vm/vnode_pager.c#L291 >>>> According to the documentation, '[...] the vnode lock which embeds the >>>> bufobj' is needed. However, interlock is taken in line 276. >>>> Is the interlock equivalent to the vnode lock? >>>> (I assume 'the vnode lock' refers to vnode.v_lock.) >>> vnode_pager_alloc() must be called with the vnode exclusively locked. >>> This is asserted at the beginning of the function. >>> >> Yeah, I see that check: ASSERT_VOP_LOCKED(vp, "vnode_pager_alloc");. >> However, our data says otherwise: According to our trace, the shared lock is >> taken. >> You may have a look at https://thasos.cs.tu-dortmund.de/bugs/ctx-vnode-v_bufobj.bo_object-w-cex.html. >> 'EMBSAME(vnode.v_lock[r])' refers to the shared vnode lock. >> A click on each lock description, e.g., EMBSAME(vnode.v_lock[r]), leads to >> the code where it was taken. >> (Pls ignore the line 'Hypothesis 1: ....'.) >>>> >>>> - Is buf.b_bufobj a read-only element? >>> You should scope the question. >>> >>> While buffer is owned by a vnode, b_bufobj is constant. Since buffers are >>> type-stable, they migrate between vnodes as cache finds it required to >>> reclaim and reuse. There, b_bufobj is changed. >>> >> I'm referring to getdirtybuf(): msleep(&bp->b_xflags, >> BO_LOCKPTR(bp->b_bufobj),PRIBIO | PDROP, "getbuf", 0); > And? The msleep() just uses the address as the sleep chain id. > The getdirtybuf() function fails if it really slept, thus dropping bo lock > and allowing the buffer identity to change (Really not identity, because > vnode is locked, but allowing the buffer to be written out and moved to > clean queue). > -- Technische Universität Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al