Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1041120rwd; Thu, 1 Jun 2023 09:39:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4pju/3xkZm8ccaxDPtHgKLdReo4P2l4e1e2dTfmmJ2n8t/hPa/TmvN4EcgSs/Bpoyvyg0s X-Received: by 2002:a17:90a:5d8d:b0:256:5a91:5b8 with SMTP id t13-20020a17090a5d8d00b002565a9105b8mr12716pji.5.1685637595601; Thu, 01 Jun 2023 09:39:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685637595; cv=none; d=google.com; s=arc-20160816; b=I1zOcp5mVwfqyNVJfO8llfmkzgBOMypNZlkTwxYyn0AhqD7IXhXkad5KQ7/JW3Zrma e7p0smVnXoJvjhBTt4AxAWvrMO0qabNPbuOzTphNpFWfIB1T2PwWKM5fdr4+0Q2LEVWo bqwZbQpCgkBI9t9mTopG+BfLfXx0jR170eGb/NkHY2Z+XT+7sMjhEjUXuNBmlep8nRJA u+2tDObmU+Xwi1laFxYrO+LN2yNc35hlyodmUDoFfoGFS65YoMBjSiSwMUzWfDjuMRAF KzJ21bb8Iw3gBjchJ3/JzLwVU11NuXl3rNzuJYBTaw0Qnocat0aBbEI5UJhxQvt/8GXh prDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:dkim-signature; bh=DCACy05Wl0giRQVOmv6yFaI8mWWnzdRymJdDTQkLh4I=; b=i8SO+5uiD6tal8lhu8chmOLYVgJVDYSzScTTw2DfODQEjEEtL5AY9ideVnh2jjZ4IL Qg6Kr3ntj1j2mHeD4uW59ptx6057ufd1nBJelAPsFNGM9RUKPG6SnmE0UEmssWCaCgx1 qsuJPZnl4y/3h7dkt24i5fUL9D3W7Zd2+BcnNz2ZA0J8T36fCuXjaX8Nvdq9NqYEIpE2 d/WU12pJ4BXwimzkXQOi5LXFHXGKZ2g8r7ylBkNlMG6WWWbzTmf1ATsjR4Gb7Rqg6Eob 2r0urudgsGz6BllItToDqZx1faZhsjbrsNA84WuCPD449KXus3tbhDhIfS3XEJPIv2Lv rouQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=Rw65AGoI; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k7-20020a635607000000b0053f163363c0si3183685pgb.95.2023.06.01.09.39.38; Thu, 01 Jun 2023 09:39:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=Rw65AGoI; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231521AbjFAQb1 (ORCPT + 99 others); Thu, 1 Jun 2023 12:31:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231660AbjFAQb0 (ORCPT ); Thu, 1 Jun 2023 12:31:26 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F92912C for ; Thu, 1 Jun 2023 09:31:24 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7685B1FDB4; Thu, 1 Jun 2023 16:31:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1685637082; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DCACy05Wl0giRQVOmv6yFaI8mWWnzdRymJdDTQkLh4I=; b=Rw65AGoIPOiCQGm4sgMEVhOd8h4OK2dng5lRPUcUeyC4GMel2vjLAvmn7Y1uWAacb7QAb9 tATB34eXAv1u+IEKQraCy/l8fCzB3M188ZSKp8lAK7qfmBijGewZmBv0XM8/lht47+dUoL GiYe8rRdFFVH6Wxl6zPPJbR0uCh2900= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1685637082; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DCACy05Wl0giRQVOmv6yFaI8mWWnzdRymJdDTQkLh4I=; b=chQbdQQeOW2b4uwAsmfVS1lI73Yhe2AT0AfRGROCblOlZkauEBesxESJBISOapzZQz4vvZ jfeqxGXO/To2JXAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 672EA13441; Thu, 1 Jun 2023 16:31:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id pS8ZGdrHeGRYDQAAMHmgww (envelope-from ); Thu, 01 Jun 2023 16:31:22 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id DFBDEA0754; Thu, 1 Jun 2023 18:31:21 +0200 (CEST) Date: Thu, 1 Jun 2023 18:31:21 +0200 From: Jan Kara To: Zhang Yi Cc: Zhihao Cheng , Jan Kara , linux-ext4@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, yi.zhang@huawei.com, yukuai3@huawei.com Subject: Re: [PATCH 4/5] jbd2: Fix wrongly judgement for buffer head removing while doing checkpoint Message-ID: <20230601163121.jjdo4f2xfpfx6dzi@quack3> References: <20230531115100.2779605-1-yi.zhang@huaweicloud.com> <20230531115100.2779605-5-yi.zhang@huaweicloud.com> <20230601094156.m4b7rxntmaxc5zy7@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=ham 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-ext4@vger.kernel.org On Thu 01-06-23 22:20:38, Zhang Yi wrote: > On 2023/6/1 21:44, Zhihao Cheng wrote: > > 在 2023/6/1 17:41, Jan Kara 写道: > > > > Hi, Jan > >> On Wed 31-05-23 19:50:59, Zhang Yi wrote: > >>> From: Zhihao Cheng > >>> > >>> Following process, > >>> > >>> jbd2_journal_commit_transaction > >>> // there are several dirty buffer heads in transaction->t_checkpoint_list > >>>            P1                   wb_workfn > >>> jbd2_log_do_checkpoint > >>>   if (buffer_locked(bh)) // false > >>>                              __block_write_full_page > >>>                               trylock_buffer(bh) > >>>                               test_clear_buffer_dirty(bh) > >>>   if (!buffer_dirty(bh)) > >>>    __jbd2_journal_remove_checkpoint(jh) > >>>     if (buffer_write_io_error(bh)) // false > >>>                               >> bh IO error occurs << > >>>   jbd2_cleanup_journal_tail > >>>    __jbd2_update_log_tail > >>>     jbd2_write_superblock > >>>     // The bh won't be replayed in next mount. > >>> , which could corrupt the ext4 image, fetch a reproducer in [Link]. > >>> > >>> Since writeback process clears buffer dirty after locking buffer head, > >>> we can fix it by checking buffer dirty firstly and then checking buffer > >>> locked, the buffer head can be removed if it is neither dirty nor locked. > >>> > >>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217490 > >>> Fixes: 470decc613ab ("[PATCH] jbd2: initial copy of files from jbd") > >>> Signed-off-by: Zhihao Cheng > >>> Signed-off-by: Zhang Yi > >> > >> OK, the analysis is correct but I'm afraid the fix won't be that easy.  The > >> reordering of tests you did below doesn't really help because CPU or the > >> compiler are free to order the loads (and stores) in whatever way they > >> wish. You'd have to use memory barriers when reading and modifying bh flags > >> (although the modification side is implicitely handled by the bitlock > >> code) to make this work reliably. But that is IMHO too subtle for this > >> code. > >> > > > > I write two litmus-test files in tools/memory-model to check the memory module > of these two cases as jbd2_log_do_checkpoint() and __cp_buffer_busy() does. > So it looks like the out-of-order situation cannot happen, am I miss something? After thinking about it a bit, indeed CPU cannot reorder the two loads because they are from the same location in memory. Thanks for correcting me on this. I'm not sure whether a C compiler still could not reorder the tests - technically I suspect the C standard does not forbid this although it would have to be really evil compiler to do this. But still I think with the helper function I've suggested things are much more obviously correct. Honza -- Jan Kara SUSE Labs, CR