Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1550906pxf; Fri, 26 Mar 2021 09:39:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxB0av9zl1teFIB0r1fYDeAzktQEhaz693YbIRV3TrMUOG3hRZBREqd18c4OQfc7YUYgupl X-Received: by 2002:a17:906:ae88:: with SMTP id md8mr15896095ejb.264.1616776754016; Fri, 26 Mar 2021 09:39:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616776754; cv=none; d=google.com; s=arc-20160816; b=BYmqk55tQi+YYLQRicdt39fiaod1N8/a0zkbqzaIHRm2iXIiwk7yle+GHr1bN9u0dy abkQcOPpKpl0Je3mBmpca3hG9yevacWijT2vJEfQ+fjtbLWGNtfHgCh0cGdXY4vPFn2A 6xBcF0UXPbSOgWbqYKKM27fTLhizkXF48+gInybjFdFQOcetUZUEs2JtJsM+D6fodpE2 OIpAUP2xYqgwO1cmTV4zhCNpx2bCtdiw1b+FLFo/4arSWYbiwiJcy3/M549zDNuJjaMZ 2Kang63vjX226VuEDyJhexKo17Mj/3a2C+KM51zGJzL45L+J9JlXUrx5uURk95n++AY1 YR9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=j+vOzcjaNpFTIAhpYRbS01bJ2m/WSkazKUGIVK78QB4=; b=fESkqr0zlJGBepLTiaIhcvd3xm05+2gLIm5U+YNktTEyGH6LFSKKJLV00RaUZ6Vzv+ MxncEbBe2+cvXl0VwCnTb2e2jbJAm2kE+ojRfXMPl5deiSFSovJLog1tfbUHKJopUtI2 fUxUkGcXDXdotSsrSwJl1EIveyfGoF7Wb+F7/lOfzOve4dk9IRXsWQ7P7jxxHS37gAUv dy3z+ltBJcLUTubhwU1ReZNRO+V4mJepxXwl985ItRLynbIAVEoAvX3OmSDryOBjlRsi oND3F3iWuk7Fp9sNjAVn6SyGD9l89qQ4vni5hnns+gKUlrmkKUVUOdQmb9CipeT+5idM uKkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b13si7801434edd.315.2021.03.26.09.38.44; Fri, 26 Mar 2021 09:39:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230098AbhCZQiL (ORCPT + 99 others); Fri, 26 Mar 2021 12:38:11 -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-ext4@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