Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5623932rwb; Mon, 5 Dec 2022 01:35:31 -0800 (PST) X-Google-Smtp-Source: AA0mqf6mF0r50GMq624XS/3anhAV90rBnDe/H5aJxREt8L7QYoMGf3A3/7OX6t3sNdiSHA5+Dvf5 X-Received: by 2002:a17:907:378:b0:7ad:db82:d071 with SMTP id rs24-20020a170907037800b007addb82d071mr55252548ejb.200.1670232931554; Mon, 05 Dec 2022 01:35:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670232931; cv=none; d=google.com; s=arc-20160816; b=y/ahDdMXv2OdcClPGZEqDH/lz0ia0quhqFPOmfv7NB4QvJvs+n8/VtGjR2X03Sh80Q d+etqcrWRezXpEdCyadxeTPDwpxFYuiouXRJdSSw+j/fYAqp5IcGG9HHrU+xGlkZ7Vm1 INq+Wr9QVPUMb+mLla+qPl3CG5u5QwUaVliDqahBsNHQHag4eZCnRArQ11lC1GhVWN4/ gFztcIODB5U2sW2ZLv6D3LqegeIpBqlc6Olq0P836c0PsjQqKZRse7vU1Xs7W7VM64ek F7RTPqWagbilt1hT5Z78Eq7iNROITeUqYbsffUqN+l2ewOaATJ0HxefqHSLfR2x3PmMC m5kg== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=FZTe72ZtMhkOhBUPXowTV3lMOQ0Kq2zfS8RbxXUdoEs=; b=Z81xXCw7SyW7CbU7OiUU0tdDLXtPIxf16pgK5mJeeforcoQ/tYN4+ky9ooRul4ETnw 1vg/R3Ogk+NEimn5CuJCel/B0WULMXxm/7Ke5Dg4V175h5TE0xJWsW8qb+RLEswGEY1z bQ9eLYma2bg4aoZjpkkunRLgOuCCvDmfsO7Slq0V13xESiWH8vEIdL1STdBOo6vReZ6e SM4XWCuNgBnBfqNwq4eGRzfHaT8mbiXLiKYMpr4lSIPaywGL36jwLu66JgQlmAZnkpo8 KqRCJNNPQLLUC0RZQnBzV5YLfaJVr45mH5+Xhc+WlF5WGSql6v2O4sNqgoQcn9k1dLoB me6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=Or4ZkhEG; dkim=neutral (no key) header.i=@suse.cz header.b=znC+EInC; 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 ho18-20020a1709070e9200b0078e063fc78csi12884790ejc.576.2022.12.05.01.35.01; Mon, 05 Dec 2022 01:35:31 -0800 (PST) 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=Or4ZkhEG; dkim=neutral (no key) header.i=@suse.cz header.b=znC+EInC; 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 S230320AbiLEJOG (ORCPT + 99 others); Mon, 5 Dec 2022 04:14:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230199AbiLEJNi (ORCPT ); Mon, 5 Dec 2022 04:13:38 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DC75C60 for ; Mon, 5 Dec 2022 01:13:37 -0800 (PST) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (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 E9EA01FE42; Mon, 5 Dec 2022 09:13:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1670231615; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FZTe72ZtMhkOhBUPXowTV3lMOQ0Kq2zfS8RbxXUdoEs=; b=Or4ZkhEGJFTGOHav6bqLlcVOzV38kUCQqJdPmduqMHr37a8zLm5P7QyCOvm9gzbYCIu6Qy JmMVgM52W8qQbKWf+mQZibJt0aSFr2bVYVmTIpRpz+sLQLtTwTueVfD/DbUmq0N8jclMgQ E82jzptPkJJsddE0RCDRZL09MVu0z6k= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1670231615; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FZTe72ZtMhkOhBUPXowTV3lMOQ0Kq2zfS8RbxXUdoEs=; b=znC+EInCDR9iM/514tyvza68c+U7S6vKdpjbkNjvTEQeQ+LZtsXQC+sVRXJ4U1Ic7r/mrl G9LbXiHrVMklDODg== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (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 imap1.suse-dmz.suse.de (Postfix) with ESMTPS id DA03413326; Mon, 5 Dec 2022 09:13:35 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id xL8xNT+2jWOyWQAAGKfGzw (envelope-from ); Mon, 05 Dec 2022 09:13:35 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 64117A0727; Mon, 5 Dec 2022 10:13:35 +0100 (CET) Date: Mon, 5 Dec 2022 10:13:35 +0100 From: Jan Kara To: Ritesh Harjani Cc: Jan Kara , Ted Tso , linux-ext4@vger.kernel.org, Christoph Hellwig Subject: Re: [PATCH v2 0/11] ext4: Stop using ext4_writepage() for writeout of ordered data Message-ID: <20221205091335.j2niiws6knrxmjjx@quack3> References: <20221202163815.22928-1-jack@suse.cz> <20221203005256.cqrvojj47blasal7@riteshh-domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221203005256.cqrvojj47blasal7@riteshh-domain> 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 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 Sat 03-12-22 06:22:56, Ritesh Harjani wrote: > On 22/12/02 07:39PM, Jan Kara wrote: > > Hello, > > > > this patch series modifies ext4 so that we stop using ext4_writepage() for > > writeout of ordered data during transaction commit (through > > generic_writepages() from jbd2_journal_submit_inode_data_buffers()). Instead we > > directly call ext4_writepages() from the > > ext4_journal_submit_inode_data_buffers(). This is part of Christoph's effort > > to get rid of the .writepage() callback in all filesystems. > > > > I have also modified ext4_writepages() to use write_cache_pages() instead of > > generic_writepages() so now we don't expose .writepage hook at all. We still > > keep ext4_writepage() as a callback for write_cache_pages(). We should refactor > > that path as well and get rid of ext4_writepage() completely but that is for a > > separate cleanup. Also note that jbd2 still uses generic_writepages() in its > > jbd2_journal_submit_inode_data_buffers() helper because it is still used from > > OCFS2. Again, something to be dealt with in a separate patchset. > > > > Changes since v1: > > * Added Reviewed-by tags from Ritesh > > * Added patch to get rid of generic_writepages() in ext4_writepages() > > * Added patch to get rid of .writepage hook > > Oh! And what about the WARN_ON_ONCE in ext4_writepages() while loop, > which we were discussing here [1]. Do you think that will help in > catching anything nasty? > > [1]: https://lore.kernel.org/linux-ext4/20221201115500.kbxtteft3v4pzqqx@quack3/T/#mcf7b6cc301062e52a3600194b03a9fd872ba52c5 Ah, right. Forgot about this. Thanks for reminder. > One thing I guess I missed in my previous review is the fast commit path. Good point, I didn't think about that one :) > In my overnight testing of previous patch series I observed this warning. > > WARNING: CPU: 1 PID: 1746936 at fs/ext4/inode.c:1994 ext4_writepage+0x4e6/0x5e0 > RIP: 0010:ext4_writepage+0x4e6/0x5e0 > Call Trace: > > __writepage+0x17/0x70 > write_cache_pages+0x166/0x3c0 > ? dirty_background_bytes_handler+0x30/0x30 > ? finish_task_switch.isra.0+0x8e/0x260 > ? _raw_spin_lock_irqsave+0x19/0x50 > ? finish_wait+0x34/0x70 > ? _raw_spin_unlock_irqrestore+0x1e/0x40 > generic_writepages+0x4f/0x80 > jbd2_journal_submit_inode_data_buffers+0x64/0x90 > ext4_fc_commit+0x2e0/0x830 > ? file_check_and_advance_wb_err+0x2e/0xd0 > ? preempt_count_add+0x70/0xa0 > ext4_sync_file+0x15c/0x380 > __do_sys_msync+0x1c1/0x2a0 > do_syscall_64+0x38/0x90 > entry_SYSCALL_64_after_hwframe+0x63/0xcd Yep, that path needs conversion as well. Honza -- Jan Kara SUSE Labs, CR