Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1753647pxm; Thu, 24 Feb 2022 08:44:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJw8QCfWXSGhiTifGRzcWVhltlJZ5TlrIOnCHGkwHxUtM2H6H/mnt0AdiCu1GeFz7CiZZWmm X-Received: by 2002:a17:902:bd4a:b0:14f:92ac:fa43 with SMTP id b10-20020a170902bd4a00b0014f92acfa43mr3358022plx.27.1645721099394; Thu, 24 Feb 2022 08:44:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645721099; cv=none; d=google.com; s=arc-20160816; b=e04R4ZKRc8/9CwOToR2yl/KZjZNOPbPi9ugHF/nPHuHPTvJ2w2jDeDfJqsk/1UDbzl +eKqyCViPDMPtOFhA0tFSTE66nYuI6FShiK2CysJ+FGdRO47L/ayFv/5BN/3VOCpDLr6 WDUQMyNxL0WxIjJETEJjrlOWeoLn1ZMa62ZdZSsiRT/iprv5cgrn9CadZWQu6STDjfnr NuXZj3xLGoaJnBrAJ2M5JUMjE3kKHpOCDmijYpRWpryAZ8n6zn0lhFRjJ/5mzNtg9iFQ vuzQ4kZKPy+QmZ0ODxWcCjDrPhQ/70bdGyJyCvEUSG5a6iDNJIrylgYkV1hJH2lHhucG 2qGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:mime-version:date:message-id :dkim-signature; bh=abk8/GB2gcYnvCWmUivO0/usmUPGxFy1f2YiAqoRRWM=; b=rwogINsBZteMnDUfMdJ9tvJ2I7EQok0OkB0AWSJUd291Vs0owqU2Hw/4/j9R5wwWLh 2CKsQfjS4N4HQidM6cg8fZO4bvc8M9vBAhKiHNqQuWU6H+SPipQ6ogTA6W+lB3NkHUfR ctMmznDt1T2g+UIEBUC2I2/2S3rSEMVvCvKRRQktuUI7kV7EtrRBxx/qpKvv5e2a4C9w 5d6XHwqQsTwPgBAQl8gIqt8ED4+vHhWh4GEKJ/UWobmcHHLHeCvWxgzgJPMnbT/ry2eE Iu0KwJ9iQJuOjQqTVTj82sDSgTKkNeCdm2rqcZL8YZby5Cnwp5Fmlr1Ke9A0jdIE8vrm pcLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (bad format) header.i=@dorminy.me header.s=mail header.b=KD0LqR8x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=dorminy.me Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id bj20si2793410pgb.740.2022.02.24.08.44.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Feb 2022 08:44:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=neutral (bad format) header.i=@dorminy.me header.s=mail header.b=KD0LqR8x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=dorminy.me Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6C7452036DC; Thu, 24 Feb 2022 08:24:17 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230288AbiBXQNO (ORCPT + 99 others); Thu, 24 Feb 2022 11:13:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229521AbiBXQNN (ORCPT ); Thu, 24 Feb 2022 11:13:13 -0500 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87EA41B0BF3; Thu, 24 Feb 2022 08:12:35 -0800 (PST) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 010FA803AB; Thu, 24 Feb 2022 11:10:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1645719060; bh=LBptnaz84kXUF48osWhg+vMhXBOFqAysTHDgWQz+/5M=; h=Date:Subject:To:References:From:In-Reply-To:From; b=KD0LqR8xTO6qwqQOxUaq8jxBCou8o56pHwuGsTPfCf1PMeqVJdJrfuw6dK+hbob6V krVa0xHr3PjYe8BslgHJPkXRhpbHuX+5/hStPhPZAieU9oORQYEoBQ1OcxqRjZvwJm UZ5xGi4Jp3DGoORsCAEh68xbEga1mHIsFqyHWSPwizZkvhe3dYQQXN62NQaLDAprWC ZmM3/XMKTqvlbyMAj1i9feTnZn6lV4zn7lBYRIiWM2VpapR0SSFVooHJZN4tXb+l0S YnxmD6QSbNIvYkqO0zyBeMtURlRYKF9C9zpxsjm29HMklOJNbC4aLIX3Goj9oFTBXL 7geTeoejQh9rg== Message-ID: <284ccc08-8de7-9188-19d8-20f4eda56cb4@dorminy.me> Date: Thu, 24 Feb 2022 11:10:59 -0500 MIME-Version: 1.0 Subject: Re: [PATCH v4] btrfs: add fs state details to error messages. Content-Language: en-US To: dsterba@suse.cz, Chris Mason , Josef Bacik , David Sterba , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com References: <20220224132210.GS12643@twin.jikos.cz> From: Sweet Tea Dorminy In-Reply-To: <20220224132210.GS12643@twin.jikos.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Added to misc-next with some minor updates, thanks. > Awesome, thank you. I realized this morning that it might be technically slightly racy actually and would propose something like the following static void btrfs_state_to_string(const struct btrfs_fs_info *info, char *buf) { unsigned int bit; + unsigned long fs_state = READ_ONCE(info->fs_state); unsigned int states_printed = 0; char *curr = buf; memcpy(curr, STATE_STRING_PREFACE, sizeof(STATE_STRING_PREFACE)); curr += sizeof(STATE_STRING_PREFACE) - 1; - for_each_set_bit(bit, &info->fs_state, sizeof(info->fs_state)) { + for_each_set_bit(bit, fs_state, sizeof(fs_state)) { All the other interactions with info->fs_state are test/set/clear_bit, which treat the argument as volatile and are therefore safe to do from multiple threads. Without the READ_ONCE (reading it as a volatile), the compiler or cpu could turn the reads of info->fs_state in for_each_set_bit() into writes of random stuff into info->fs_state, potentially clearing the state bits or filling them with garbage. Even if this is right, it'd be rare, but it would be exceeding weird for a message to be logged listing an error and then future messages be logged without any such state, or with a random collection of garbage states. I can send another patch if this explanation seems reasonable and you'd like it separate; or maybe this is too unlikely to worry about. Thanks again for the review! Sweet Tea