From owner-freebsd-fs@freebsd.org Tue Mar 16 08:53:42 2021 Return-Path: Delivered-To: freebsd-fs@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 306B557CE4F for ; Tue, 16 Mar 2021 08:53:42 +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" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F06X52DQGz3lrX for ; Tue, 16 Mar 2021 08:53:40 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from [129.217.43.55] (chulak.cs.uni-dortmund.de [129.217.43.55]) (authenticated bits=0) by unimail.uni-dortmund.de (8.16.1/8.16.1) with ESMTPSA id 12G8rdNZ009707 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Tue, 16 Mar 2021 09:53:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tu-dortmund.de; s=unimail; t=1615884819; bh=VZQT1WYJRnMfCFIneMtYVfnM1uFh+wkyAfK8Ylp2y1A=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=Ud7Z0NhER2K7jLHdiLWK7f9rwF8kBx5/wh7h/Gn8ymUyro1S+sYQ6wXeb2Em0cui+ Hs5XQCRB3EYODTNtokJ90zQBHhhktGynsWUeM0zj8anKrk0C8jKCS2wjOD2OhzsO+z l9cAeu1GtUkdDmqm81CTStIy3JB58aXGmBukdXHQ= To: Konstantin Belousov Cc: freebsd-fs@freebsd.org References: <49130618-349a-bfc7-6d26-0c3763904dc5@tu-dortmund.de> <48913698-d2e8-9721-ee1a-4828a9265e55@tu-dortmund.de> From: Alexander Lochmann Subject: Re: [RFC] Understanding the locking of struct buf Message-ID: <9e591bfe-1790-251e-a90c-79c6ec66b3ac@tu-dortmund.de> Date: Tue, 16 Mar 2021 09:53:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4F06X52DQGz3lrX X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tu-dortmund.de header.s=unimail header.b=Ud7Z0NhE; dmarc=none; spf=pass (mx1.freebsd.org: domain of alexander.lochmann@tu-dortmund.de designates 129.217.128.51 as permitted sender) smtp.mailfrom=alexander.lochmann@tu-dortmund.de X-Spamd-Result: default: False [-5.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:129.217.128.0/24]; RWL_MAILSPIKE_GOOD(0.00)[129.217.128.51:from]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[129.217.128.51:from]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[tu-dortmund.de:+]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; ASN(0.00)[asn:680, ipnet:129.217.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[tu-dortmund.de:s=unimail]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tu-dortmund.de]; DWL_DNSWL_LOW(-1.00)[tu-dortmund.de:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] X-Mailman-Approved-At: Tue, 16 Mar 2021 11:19:46 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 08:53:42 -0000 On 14.03.21 09:35, Konstantin Belousov wrote: > You cannot write any working code that uses buffer cache, without studying > both buffer cache code itself, and examples using it from filesystems. > Short (even the whole-screen short) herald comment cannot explain all the > nuances that grown in the 40+ years codebase. I see. > >> Shouldn't that particular piece of documentation be updated? >> For example: b_bcount /* w: b_lock, r: no lock needed */ > Do you understand the purpose of the locking? What do you intent to do > with the read value of b_bcount, if you do not own the buffer? What is > you next action with that value? > I do know the purpose of locking. I have no particular usage in mind at the moment. I'm trying to understand how locking is handled in FreeBSD. In the Linux kernel, for example, there are such exceptions: Read a ptr without a lock to perform a NULL check. All I'm asking was whether the documentation should reflect those exceptions. I assume the answer is no. Thank you, Konstantin, for lifting the fog. - Alex -- 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