From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50208C433C1 for ; Fri, 26 Mar 2021 16:38:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1B59C61A18 for ; Fri, 26 Mar 2021 16:38:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230242AbhCZQiO (ORCPT ); Fri, 26 Mar 2021 12:38:14 -0400 Received: from mx1.hrz.uni-dortmund.de ([129.217.128.51]:58375 "EHLO unimail.uni-dortmund.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230070AbhCZQho (ORCPT ); Fri, 26 Mar 2021 12:37:44 -0400 Received: from [192.168.111.102] (p4fd97b97.dip0.t-ipconnect.de [79.217.123.151]) (authenticated bits=0) by unimail.uni-dortmund.de (8.16.1/8.16.1) with ESMTPSA id 12QGbYPE001987 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Fri, 26 Mar 2021 17:37:35 +0100 (CET) Subject: Re: [RFC] inode.i_opflags - Usage of two different locking schemes To: Jan Kara Cc: "Theodore Ts'o" , Horst Schirmeier , Jan Kara , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org References: <667b3ec3-a522-05a9-31e8-87d8bfaa7adb@tu-dortmund.de> <0f387f5b-a516-af45-856d-f38d1adfadf5@tu-dortmund.de> <20210316171429.GA22701@quack2.suse.cz> From: Alexander Lochmann Message-ID: <0e308673-a350-98af-b0a7-cde63abd4579@tu-dortmund.de> Date: Fri, 26 Mar 2021 17:37:34 +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: <20210316171429.GA22701@quack2.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16.03.21 18:14, Jan Kara wrote: > > So i_lock is supposed to protect i_opflags for writing AFAICT. For reading > we don't seem to bother in some cases and I agree that is potentially > problematic. It is *mostly* OK because we initialize i_opflags when loading > inode into memory / adding it to dcache. But sometimes we also update them > while the inode is alive. Now this is fine for the particular flag we > update but in theory, if the compiler wants to screw us and stores > temporarily some nonsensical value in i_opflags we'd have a problem. This > is mostly a theoretical issue but eventually we probably want to fix this. > > Honza > Thx for the detailed explanation. :-) - 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